1.13 is coming!

Discussion in 'General Minecraft Discussion' started by ShelLuser, Oct 25, 2017.

  1. Another snapshot!

    The fear of every server owner has come true, but that's the price they'll just have to pay. It is power to the players in the latest snapshot (17w48a) because this version adds:

    Craftable commandblocks! :cool:

    Isn't this just totally awesome? This is just the thing we've been waiting for. (un)Fortunately Mojang did add some failsaves by requiring bedrock which isn't available within survival play (yet?), but who knows what might happen. And it only gets better:

    Chained & Repeating are available too!

    The upcoming 1.13 version has never been so appealing as it is today, right guys? :D

    Ok, ok... an experienced Minecraft player will probably have seen that something doesn't add up here. Because grouped recipes do not differ per block (such as exchanging bedrock for a dye) but only per block type (lime dye vs. purple dye for example). Or they already read the release notes of course :p

    Anyway, what is happening here is that we finally got custom recipes! :eek:

    The stuff above? All added using my datapack:

    Code:
    {
      "type":"crafting_shaped",
      "group":"command_blocks",
      "pattern":[
        "xsx",
        "xpx",
        "xxx"
      ],
      "key":{
        "s":{"item":"minecraft:sign"},
        "p":{"item":"minecraft:player_head"},
        "x":{"item":"minecraft:bedrock"}
      },
      "result":{
        "item":"minecraft:command_block"
      }
    }
    
    For the best results you'd remove the group assignment from this recipe and keep it for the chain & repeating commandblocks ;)

    There's just one small setback: I was really hoping that we'd also be able to add JSON data to the craftable items. So, for example, being able to craft a player head (which would get you: minecraft:player_head{SkullOwner:"ShelLuser"}). Unfortunately that doesn't work, the recipes do not grok extra JSON.

    Even so it's definitely exciting so far I think!

    Because this will also allow you to create adventure maps where you simply turn off all vanilla recipes and replace those with your own, thus forcing players to really re-learn what they assume to already know.
  2. It's great to allow for custom item names(possibly) and it allows custom recipes further giving servers custom control in the economy/market.
    ShelLuser and ForeverMaster like this.
  3. ngl I'm low-key obsessed with the trapdoors
    ForeverMaster likes this.
  4. I was looking forward to you making a post on finally having custom crafting recipes, and yet you still fooled me with this... :rolleyes: :p
    I could try to use this to get my brother back into Minecraft again... but at the moment, I don't really feel like investing in Minecraft. :p
    ShelLuser, Tuqueque and ForeverMaster like this.
  5. Anyone bothered about some of the current Vanilla crafting recipes (not the dispenser)?

    I saw Reddit users asking for better stair recipes and recipes for smooth double-slabs and same-type slabs into full blocks on r/minecraftsuggestions.

    If Mojang does not add/change them for 1.13, we likely can. These blocks already exist in the game.
  6. We could use custom crafting to have the following crafting recipes:

    Iron Voucher + Iron Voucher = Gold Voucher
    Iron Voucher x4 = Diamond Voucher
    Gold Voucher = Iron Voucher x2
    2 Gold Vouchers = Diamond Voucher
    Diamond Voucher = 2 Gold Vouchers
    :eek:
    607 and ShelLuser like this.
  7. I don't know if custom crafting works with NBT-tags, as the supporter vouchers are just renamed pieces of paper, but, if it doea, it sounds like a really cool idea
    607 and ShelLuser like this.
  8. :eek: That would be really cool!
  9. While that would be cool, very likely not possible, unfortunately. Vouchers have unique id's associated with each one, so even though they appear alike, no two Gold Vouchers are actually the same item. Furthermore, the resulting vouchers crafted would have to somehow have their own id's attached in the crafting process.
    607 and ttyler333 like this.
  10. So water and transparent blocks can exist in the same space?
    Jelle68 and ShelLuser like this.
  11. Ayups.

    This won't be something done in 1.13 but in the update after that (the "Update Aquatic") water will behave in a different manner. So it will no longer be blocked by transparent blocks such as fences and probably signs.

    It might break certain farm designs and some underwater bases will definitely be in risk of flooding, but on the positive side an underwater building will look a lot better than it does now. No more weird air pockets.

    (though I'm going to miss my "use stairs to make a way down into the water" method :) )
    607 likes this.
  12. Unfortunately, they don't carry NBT tags in crafting :/

    https://www.youtube.com/watch?v=KX5ahU2adrY
  13. While doing some research and wrting for the Minecraft wiki regarding 1.13 I suddenly came across this small bit of nastiness again:

    I don't really keep track of Mojangs bugtracker because I consider it highly annoying that they often don't announce new features and/or changes which can then easily lead to you mistakenly picking up a feature (or change) as if it were a bug.

    Even so, someone pointed me to MC121934; it appears that the above issue has been officially picked up as a bug and this is said to be fixed in the next snapshot.

    Considering that I complained a few times about this bug I only think it's fair to also point out the upcoming solution :)
    607 likes this.
  14. Minecraft 1.13 has been delayed. An article was published on minecraft.net on the subject. 1.13 is now Technically Updated AND the Update Aquatic together. I made an in-depth comment on r/minecraft. Aikar and staff should know about this:

    https://www.reddit.com/r/Minecraft/comments/7smx4n/113_is_now_the_ocean_aquatic_update/dt64im3

    I'd take this announcement as a warning for an extensive wait for the update to come to EMC. We may not update until Holiday 2018 or sometime in 2019. Good luck waiting out for 1.13. :l
    Tuqueque, JesusPower2 and 607 like this.
  15. Good catch FM, nice going! If anyone is interested then here's the official Mojang statement.

    True that, it could become a bit dull where Minecraft updates are concerned, but on the positive side it also gives server owners and developers a much longer time to prepare for the inevitable breakage (and required repairing!) of everything. I already started testing stuff for my redstone world and well, I think that depending on the amount of used commands (and the changes in the actual codebase) they may very well need this extra time.

    Sure, you can't (and shouldn't) fully focus yourself on a snapshot but the new command structure (and parser) is more or less already a thing and it is unlikely that those new commands are going to be changed drastically again over time.

    And well, as far as I know plenty of server owners already somewhat planned on skipping 1.13 and using that as a testing ground to prepare for 1.14. That can still be done. So basically I don't think this is going to change much for us players anyway.

    What I am excited about after reading that comment is that we got some more official confirmations (I could have missed those): turtles are definitely becoming a thing, a new world format is coming (that could be a bad thing, I really hope it'll be an accessible format as the current so that tools like MCEdit can continue to exist), and the debug stick is also staying (which I think is really cool).

    There's also good news within bad news here :)
    607 and ForeverMaster like this.
  16. Are you taking into account that 1.13 is both a technical AND aquatic update now!? 1.14 features are unknown at this point. Java 1.14 is NOT the Update Aquatic.

    I'm concerned that we have to wait longer before EMC can start working towards the new 1.13.
    However, Spigot has supported developmental versions in the past; perhaps updating servers can be done without the Minecraft Coder's Pack. They may have a way to decompile Minecraft's source code. There are also some rumors - of server developers receiving exclusive information about upcoming technical changes.
  17. I'm well aware, yah.

    Thing is: there are 2 sides to this update for server owners. One is the whole command structure; basically every command block will have to be checked and re-tested because of the changed commands. And second is the code itself; this needs to be tested for plugins and custom changes (Spigot).

    You can't work on the code part right now as far as I know, but the in-game changes can be tested and prepared for.

    Well, generally speaking everyone can do that with a Java binary so I would be surprised if that doesn't apply here (can't say for sure because I never bothered trying to "hack" Minecraft binaries like that).

    But you're right: Spigot has supported snapshots before and it seems they're going there again. Look at this Spigot announcement: there's a preview available for the Bukkit 1.13 API. So that's a good start I guess.
    607 and ForeverMaster like this.
  18. A new snapshot has been released (18w05a) and Minecraft is getting better and better I think. Because now we have....

    The Chicken Boss!

    Minecraft will never be the same again :D

    Ok, ok, enough joking around but I am honestly a bit excited about this one because once again we get "vanilla support" for some pretty interesting features. In this case boss bars!

    We no longer have to mess around with spawning invulnerable (and renamed) boss mobs somewhere underground (to get a bossbar) and then trying to somehow link that with the health of the mob we want to use.

    /bossbar create <id> <name> is all we need.

    How does this work?

    This is seriously cool! Because now it really starts to show (IMO!) why the whole flattening and command change took place, it's because of things like this. The new command set simply makes several features a lot more accessible and it's showing!

    But... I'm getting carried away.

    First you need to create a bossbar and give it an ID and a name. In my example above I used: /bossbar create catslair:chicken "Chicken Boss". The ID is used to keep track of your bossbars and the name... should be obvious.

    Next you'll want to give it a specific color, as you can see I used red: /bossbar set catslair:chicken color red. And finally you'll need to specify which players can actually see the bossbar. In the example above I simply limited it to myself (I'll be testing this on a server later on and see how this works):

    /bossbar set catslair:chicken players @p

    So now we have created a bossbar and made it visible for ourselves. But a bossbar is obviously useless without an actual boss to fight! :mad: I decided to spawn in the most dangerous creatures of them all: the EnderChicken :eek:

    And thanks to 1.13's changed command set you don't even need tweaks any longer to give it a colored name: /summon minecraft:chicken ~-3 ~1 ~ {CustomName:"{\"text\":\"EnderChicken\",\"color\":\"red\"}",CustomNameVisible:1}

    But how do we link this chicken to our bossbar?

    First we need to find out how we can track the mobs health. For that you need the new /data command:

    Everything you wanted to know about the chicken :)

    The command I used above is: /data get entity @e[type=chicken,distance=..10,limit=1]. This command can be used to get information about all items in the game, blocks and entities alike (remember: players are entities too!).

    And if you look closely then you'll see this: "Health:0.4f". This tells us that the mobs health has value 4 and its type is float. That last part isn't interesting right now, but now we know how to get the chickens health: /data get entity @e[type=chicken,distance=..10,limit=1] Health.

    This introduces us to another new command: /execute store. Well, I suppose it's more of a new command feature, considering that /execute already existed. We're now going to store the chicken's health into our bossbar:

    /execute store result bossbar catslair:chicken value run data get entity @e[type=chicken,distance=..10,limit=1] Health.

    Unfortunately this will create one small problem :confused:

    Look at how small that bossbar is!

    But Mojang even thought about that. By default a bossbar's value ranges from 0 to 100, and it's set as type progress (so it counts down so to speak). And well, 4 out of 100 is pretty much nothing.

    Fortunately we can change this: /bossbar set catslair:chicken max 4.

    And the result can be seen above!

    I think this is an awesome feature which can even help spice up PVP a bit (I assume) because you can now set up an arena and actually have bossbars displayed for all involved entities.

    For example....

    It's in retreat! :D

    Of course the /execute command I used above doesn't continuously track the mobs health. It's a one time execution which gets the health of the mob and stores its result in the bossbar. But that's nothing which a repeating command block (or repeating function) can't solve.


    And there you have it!

    Minecraft is getting more exciting every snapshot it seems. Of course... this isn't really interesting for regular players but more for mapmakers. But I'm sure we'll soon get new custom in-game stuff too!
    Starsphere, 607 and cubefragment like this.
  19. I, uhm, "did something" and I'd like to share :)

    Note: everything you see above is done using vanilla commands!

    I've mentioned it many times already (and I think I will repeat it just as many times) but to me Minecraft has evolved from a "simple" sandbox game into one massive gaming platform. And the current snapshot (18w05a at the time of writing) only confirms this.

    So what do we have here? 4 command blocks (and a few preparations) will give you the above. If you come within 35 blocks of this mob (default follow distance) then the bossbar appears as shown above. If you move outside of this range then it will disappear. And if the mob dies then so will the bossbar.

    This is seriously exciting (if you're into this stuff).

    So first... the bossbar:
    • /bossbar create boss {"text":"Enraged Guardian","color":"gold","bold":"true"}
    • /bossbar set boss max 60
    A zombie has a maximum health of 20 by default, but this one is of course special so I multiplied that by 3 (=60). I also boosted its attack strength; from 3 to 5 and I gave it the usual effects such as fire and the orange / gold name in bold.

    This is the first (normal) commandblock, used to summon the guardian:

    Code:
    summon minecraft:zombie ~5 ~1 ~ {CustomName:"{\"text\":\"Enraged Guardian\",\"color\":\"gold\",\"bold\":\"true\"}",CustomNameVisible:1,CanBreakDoors:1,CanPickUpLoot:1,PersistenceRequired:1,Fire:32767,ActiveEffects:[{Id:12,Duration:32767,Ambient:0b,ShowParticles:0b}],Tags:["guardian"],Attributes:[{Name:"generic.maxHealth",Base:60b},{Name:"generic.attackDamage",Base:5d}],Health:60f}
    
    Another new feature in 1.13 is that CustomName (used within NBT tags) is now no longer a String but a full NBT component in itself. As a result we can now summon mobs with customized names which can also have different colors and different formatting. Such as a gold name in bold.

    Note: in 1.13 you can no longer use / at the start of a command within a command block, which is why I left it out in the code section above.

    So summing up this mob:
    • Has a custom name (duh!).
    • Is on fire but isn't damaged by it (I know, it's kind of obvious).
    • Can break through doors no matter what (now it becomes interesting!).
    • Can pick up loot lying on the ground (and immediately use it).
    • Does not despawn.
    • Has more health (60) and a higher attack (5).
    So now for the bossbar behavior...

    First you're going to need a repeating command block in order to update the bossbar. After all: if the mobs health goes down then this should get displayed in the bossbar. So we'll need this:

    Code:
    execute store result bossbar boss value run data get entity @e[tag=guardian,limit=1] Health
    
    Should be obvious enough: it executes the /data command command to get the mobs health, then stores the result in the bossbar.

    Next: a conditional chain command block (always active):

    Code:
    execute as @e[tag=guardian] at @s run bossbar set boss players @a[distance=..35]
    
    This is some of the new exciting stuff of 1.13. I'm executing a command as the guardian and from the position of the guardian. I set the players value of the bossbar to all players within a distance of 35 blocks.

    The fun part is that because this command gets executed repeatedly it will also remove the bossbar as soon as you get out of range:
    My range is bigger than 35 and therefor the bossbar is gone

    So one last problem remains: what to do if the guardian is dead? Well... Here's another super exciting 1.13 feature: running a command if there are no entities anymore!

    You'll need another chain command block but this time unconditional (and always active):

    Code:
    execute unless entity @e[tag=guardian] run bossbar set boss players
    
    This construction will remove the bossbar unless an entity with the tag guardian exists.

    Effectively resulting in the bossbar disappearing for all players as soon as the boss is defeated.

    Can it get better? Of course it can! Now imagine what's going to happen if you add another chain command block but (this time make it conditional) in which I use a /title command to congratulate the player(s)? :)

    The best part for me is that all of this has become possible without 'hacks', no functions and no patching with MCEdit: all it takes is a simple selection of vanilla commands.

    Figured I'd share :)
    607 and cubefragment like this.
  20. Yay, can't wait to download all my mdos again ;-;
    Roslyn likes this.