Introduction

In 17w16a the command block mechanics were changed to now traverse chains live instead of scheduling the chain command blocks for the next tick (see this comment).

The claim that this will "revolutionize command blocking" is a pretty big one, so let me explain why I think that this is the case.

New possibilities

Live changes to command block chains / Live switches

As described in slicedlime's video "Advanced Commands Tutorial – Instant-off, If-Else and Minecraft 1.12 Chains" you can now change a command block chain in the same tick it is running and the changes will affect the chain. This used to not be the case but instead was only possible one tick delayed.

This change is a pretty important one and allows for example more efficient command block contraptions. Image you have multiple command blocks which are only required if a certain condition is met. Thanks to this change you can now skip these command blocks in the same tick if the condition is not met saving a lot of unnecessary command executions.

Loops

Despite the fact that the developers tried to prevent loops, they are possible with some tricks.

It looks like you can achieve them by changing the chain command blocks which need to run a second time. A "simple" (but expensive) way to do this is to /clone ... replace move them.

Here is a quick demonstration: http://ift.tt/2pL4FrJ
The gif is showing a loop which prints a score of the player (which is set to 500 at the beginning) and then reduces it by one each iteration. To show that this is happening all in a single tick a repeating command block is placed next to the redstone block printing "Tick" each tick.

This creates so many possibilities; it make for example owner detection possible. Owner detection is a pretty important part for most multiplayer maps. Imagine someone wants to create a paintball game and somehow has to track which snowball was thrown by whom. This can be done by giving the players an incrementing ID score and then giving the snowball the same ID value. The problem with this is that you cannot use dynamic values in selectors, but only static ones. Therefor you could test the ownership for one player at a time by subtracting their ID value from the ones of the snowball and then execute on the snowballs with value 0 since they had the same ID value as the player. With loops you can still only do this one player at a time but continue that in the same tick until all players have been processed.

Another great use for this would be /u/SethBling's "BASIC Programming Language in Minecraft" which could now very likely parse a script in a single tick; this tick might then take some seconds but it would be still much faster in total.

Closing words

This snapshot added really great new possibilities for map makers and I am really grateful to the developers for these changes!

One thing which would be great though is if the current measures to prevent loops were removed. I know loops can cause pretty bad damage because you are unable to save your game, but they add so many new possibilities as well. Therefor a gamerule like maxChainCommands could solve this in a more reliable way. The default value could be for example 2048. Every time the next chain command in a chain should run the game could test if alreadyExecutedCommandCount < maxChainCommands. This way infinite loops could be prevented and you could set a very low value during testing / building, but once you are done and there are large loops you can set it to a higher value (up to 2^31 – 1). If possible the maxChainCommands value should be retrieved every time in case a command in the chain changes it.

Edit: Apparently exactly that happened! Thank you so much Searge! The gamerule maxCommandChainLength with default value 65536 was added in 17w16b.

http://ift.tt/2hlWhNi

Apparently, they found the source of all evil and are going to fix several issues which share the same bug in the code base

summary: hoppers and droppers will not input water bottles into brewing stand after potions have been removed by a hopper from brewing stand –> fixed!

View a list of all sound changes (To Be Updated) here

In this snapshot, there are a few new unused sound events! None of these have actual sounds yet, but they indicate that the sounds will be added soon. Amongst these sounds are the following 5 noteblock sounds:

• block.note.bell (Noteblock on Gold Block)
• block.note.chime (Noteblock on Packed Ice)
• block.note.flute (Noteblock on Clay)
• block.note.guitar (Noteblock on Wool)
• block.note.xylophone (Noteblock on Bone Block)

The blocks are an educated guess right now, as they play no sound when the noteblock is on top of them. Hype!

On a side note, a few new sounds will be added when a boat is paddled on land and in water, and also new sounds for when you are drowning and when you are on fire. Also endereyes seem to be getting a death sound, and fishing rods will get a sound when retrieving.

The most recent snapshot updated their palletes to match the rest of the color changes, and they look great! Only problem htough…is the regular(purple) shulker box, while it does look good it looks weird on shulkers, and they no longer blend with purpur blocks.

The easiest way to fix this, is make it so there's a regular shulker box, with the original texture, and the new purple one is a dyed version. Similar to how Hardened Clay(Now Terracotta) works.