The following is a list of changes/additions made to command blocks starting from the 15w34a snapshot. Note that the nature of a snapshot is to be buggy, so some things may have become broken unintentionally or behavior discovered is not fully functional or intended.
Please note that the "Impulse" command block is the old command block.
(left to right: Impulse, Repeating, Chain)
Directional Command Blocks
All command blocks now include a directional facing, which is visible on the texture itself. This determines the direction of output into the Chain command blocks.
Assuming the Chain blocks in the above image are powered: when the Impulse command block is activated, it will then activate an adjacent Chain block in the direction it is facing. When a Chain block gets activated, it will continue the signal towards the direction it's facing. Note that not all Chain blocks required being powered:
The Chain blocks at the very end will still run their commands while the Chain blocks in the middle will not run their commands.
Commands run do not need to be successful in order to activate a Chain via directional facing. Even if there were no command in the Impulse block in either of the above images, the chain would still activate.
New Block: Impulse
/give @p minecraft:command_block
These are the original command blocks. Functionality has not changed for them specifically, although their directional facing is used to interact with Chain blocks.
New Block: Repeating
/give @p minecraft:repeating_command_block
When powered with a redstone signal, these command blocks will automatically activate once per tick, equating to the original /fill clocks.
Their directional facing can be used to activate Chain blocks once per tick.
New Block: Chain
/give @p minecraft:chain_command_block
Chain blocks can only be initially activated by an Impulse or Repeating block, both of which must be directionally facing the Chain block.
Once activated, a Chain block will attempt to active another Chain block in its directional facing. This continues in the same tick until all Chain blocks in the group have been activated, making it compatible with the Repeating block as a fully functional, direction-specified clock.
However, while Chain blocks will activate adjacent Chain blocks, they do not actually run their command unless they are considered "powered". One way to do this is to simply place a redstone source anywhere next to the Chain blocks.
A secondary way to do this is to apply the "powered" byte tag with a value of 1 to the command block. Just note that block updates will switch the "powered" value back to 0 (Chain blocks activating one another does not send a block update):
/blockdata X Y Z {powered:1b}
Conditional Activation
When a command block is set to be conditional, it will not activate its command unless the command block behind it (opposite of the direction it is facing) was successful in output.
For Impulse blocks set to be conditional, any command block specifically behind it (regardless of that other command block's directional facing) will have to be successful in output for the Impulse block to activate once. In the following image, the Impulse block on the right is set to be conditional and will not be able to run its command because the command block behind it has no success output.
For Repeating blocks, it is essentially the same as Impulse command blocks. Instead, it will repeatedly activate so long as the command block behind it remains successful.
For Chain command blocks, it is also the same as Impulse blocks. The conditional direction is still behind the command block. In the following image, #4 is set to conditional. It requires #1 to be successful in output, not #3.
The command block's blockstate determines both the orientation and the conditional status. For example, the following sets a Chain block facing downwards.
/setblock ~ ~1 ~ minecraft:chain_command_block 8
When the command block behind a conditional block is successful, the conditional block will have its "conditionMet" tag set to 1. Otherwise, if the command block was unsuccessful or if there was no command block behind it, the value is set to 0. Non-conditional command blocks will always be set to 1.
/blockdata X Y Z {conditionMet:1b}
Automatic Activation
When a command block is set to "auto", it will no longer require a redstone signal to activate its command. When applied to an Impulse block, its command will activate once. When applied to a Repeat block, it will activate every tick as expected. When applied to Chain blocks, they will not require a redstone signal to activate their command when the chain is activated.
The auto state is controlled by the "auto" byte tag.
/blockdata X Y Z {auto:1b}
Example (20t/s clock)
A 20t/s clock (that does not create block updates like /fill) can be accomplished using Repeating and Chain blocks.
None of the command blocks above requires a command inside them. All of the Chain blocks have "powered" set to 1 manually. If any of the command blocks has a command inside it, that command will be activated in directional order (from left to right in the image, as that's the direction the command blocks are facing) 20 times per second.
There is a new "conditional" option for command blocks. For chain blocks, when this is enabled the command is only run if the previous command in the chain returned success. Conditional chain blocks still pass the power signal on to the next block regardless of success. Repeating and impulse blocks behave the same when set to conditional; they will not execute their command, but will pass on signal to chain blocks (conditional repeating blocks will not repeat the signal). Conditional command blocks that do not execute their command are treated as returning failure.
Basically, using comparators for truth testing is now obsolete.
There is a new "conditional" option for command blocks. For chain blocks, when this is enabled the command is only run if the previous command in the chain returned success. Conditional chain blocks still pass the power signal on to the next block regardless of success. Repeating and impulse blocks behave the same when set to conditional; they will not execute their command, but will pass on signal to chain blocks (conditional repeating blocks will not repeat the signal). Conditional command blocks that do not execute their command are treated as returning failure.
Basically, using comparators for truth testing is now obsolete.
Just a correction: all command blocks check "behind" them. Chain blocks are the same, so it's not checking the previous Chain block in the order of execution, but instead checking for the opposite direction of its facing (like the others). I've added a section for them to the thread now.
Very informative and short explanation, great. They don't really add anything, but it sure makes things a bit easier. I'd test it if it wasn't for the lag in 1.9 snapshots...
When 1.9 is actually finished, these new command blocks will make everything less laggy
Just a correction: all command blocks check "behind" them. Chain blocks are the same, so it's not checking the previous Chain block in the order of execution, but instead checking for the opposite direction of its facing (like the others). I've added a section for them to the thread now.
Ah so branches are possible with conditionals. Never mind the power flow is linked the other way.
In 15w35b command blocks now have a toggle setting: "needs redstone" / "always powered", which does exactly what it looks like. As well, the conditional NBT tag was removed and conditionality was moved to block states.
I like this. I tested the snapshot and it is very good but the chain are too fast so It can´t work in some cases and the repeating command is too fast too; cause it can´t test players like the old clock for a map or something else.
Loving loving loving the new command blocks. Really gonna add some fun with logic. Been playing with them for a few hours now and I think the only thing missing is being able to pass the target from the first block into the rest of the chain. (let the @p output into the chain)
All commands that needs updates as fast as possible, like testfor commands, will be so much smoother and less laggy now. All systems will be a lot more compact and easier to build too, and aoecloud could add some cool possibilities. I hope the update comes out this month so i can finish my map and realm builds, I'm tired of waiting ...
Rollback Post to RevisionRollBack
Creations are only restricted by your imagination.
A simple slower clock could involve a scoreboard, 2 repeater blocks and a chain block. the first one just adds 1 to the scoreboard every tick and the 2nd repeater block tests that fake player for the desired tick count which will then pulse out, with the first pulse resetting the scoreboard back to zero.
Command examples are:
/scoreboard objectives add Timer dummy Timers
/scoreboard players add ticks Timer 1
/scoreboard players test ticks Timer 20 >> chain to>> /scoreboard players set ticks Timer 0
The scoreboard test can be set to any tick rate you want. This is actually do-able in 1.8 using the fill clock and a comparator to accomplish the same effect.
If the clock is really fast sometimes the comparator won't be able to output a signal. Also, the comparator needs to be deactivated before being able to run again another command.
The Meaning of Life, the Universe, and Everything.
Join Date:
10/6/2013
Posts:
255
Minecraft:
setzke
Xbox:
setzke
Member Details
What I dislike about the chains:
If ran from a repeater, it's as if they too are repeaters. Even when the repeater is not successful, the chains run every tick, independently.
One fix, I know, is to run them all conditionally, but I was hoping instead they worked like this:
When the repeater successfully fires off, it's like running a redstone line to each of the blocks. All run that are able to run. if one is not successful, it doesn't break later ones!
Ugh! Does anyone feel my frustrations? Does anyone have any questions for clarification?
The following is a list of changes/additions made to command blocks starting from the 15w34a snapshot. Note that the nature of a snapshot is to be buggy, so some things may have become broken unintentionally or behavior discovered is not fully functional or intended.
Please note that the "Impulse" command block is the old command block.
Directional Command Blocks
All command blocks now include a directional facing, which is visible on the texture itself. This determines the direction of output into the Chain command blocks.
Assuming the Chain blocks in the above image are powered: when the Impulse command block is activated, it will then activate an adjacent Chain block in the direction it is facing. When a Chain block gets activated, it will continue the signal towards the direction it's facing. Note that not all Chain blocks required being powered:
The Chain blocks at the very end will still run their commands while the Chain blocks in the middle will not run their commands.
Commands run do not need to be successful in order to activate a Chain via directional facing. Even if there were no command in the Impulse block in either of the above images, the chain would still activate.
New Block: Impulse
These are the original command blocks. Functionality has not changed for them specifically, although their directional facing is used to interact with Chain blocks.
New Block: Repeating
When powered with a redstone signal, these command blocks will automatically activate once per tick, equating to the original /fill clocks.
Their directional facing can be used to activate Chain blocks once per tick.
New Block: Chain
Chain blocks can only be initially activated by an Impulse or Repeating block, both of which must be directionally facing the Chain block.
Once activated, a Chain block will attempt to active another Chain block in its directional facing. This continues in the same tick until all Chain blocks in the group have been activated, making it compatible with the Repeating block as a fully functional, direction-specified clock.
However, while Chain blocks will activate adjacent Chain blocks, they do not actually run their command unless they are considered "powered". One way to do this is to simply place a redstone source anywhere next to the Chain blocks.
A secondary way to do this is to apply the "powered" byte tag with a value of 1 to the command block. Just note that block updates will switch the "powered" value back to 0 (Chain blocks activating one another does not send a block update):
Conditional Activation
When a command block is set to be conditional, it will not activate its command unless the command block behind it (opposite of the direction it is facing) was successful in output.
For Impulse blocks set to be conditional, any command block specifically behind it (regardless of that other command block's directional facing) will have to be successful in output for the Impulse block to activate once. In the following image, the Impulse block on the right is set to be conditional and will not be able to run its command because the command block behind it has no success output.
For Repeating blocks, it is essentially the same as Impulse command blocks. Instead, it will repeatedly activate so long as the command block behind it remains successful.
For Chain command blocks, it is also the same as Impulse blocks. The conditional direction is still behind the command block. In the following image, #4 is set to conditional. It requires #1 to be successful in output, not #3.
The command block's blockstate determines both the orientation and the conditional status. For example, the following sets a Chain block facing downwards.
When the command block behind a conditional block is successful, the conditional block will have its "conditionMet" tag set to 1. Otherwise, if the command block was unsuccessful or if there was no command block behind it, the value is set to 0. Non-conditional command blocks will always be set to 1.
Automatic Activation
When a command block is set to "auto", it will no longer require a redstone signal to activate its command. When applied to an Impulse block, its command will activate once. When applied to a Repeat block, it will activate every tick as expected. When applied to Chain blocks, they will not require a redstone signal to activate their command when the chain is activated.
The auto state is controlled by the "auto" byte tag.
Example (20t/s clock)
A 20t/s clock (that does not create block updates like /fill) can be accomplished using Repeating and Chain blocks.
None of the command blocks above requires a command inside them. All of the Chain blocks have "powered" set to 1 manually. If any of the command blocks has a command inside it, that command will be activated in directional order (from left to right in the image, as that's the direction the command blocks are facing) 20 times per second.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
There is a new "conditional" option for command blocks. For chain blocks, when this is enabled the command is only run if the previous command in the chain returned success. Conditional chain blocks still pass the power signal on to the next block regardless of success. Repeating and impulse blocks behave the same when set to conditional; they will not execute their command, but will pass on signal to chain blocks (conditional repeating blocks will not repeat the signal). Conditional command blocks that do not execute their command are treated as returning failure.
Basically, using comparators for truth testing is now obsolete.
Putting the CENDENT back in transcendent!
Just a correction: all command blocks check "behind" them. Chain blocks are the same, so it's not checking the previous Chain block in the order of execution, but instead checking for the opposite direction of its facing (like the others). I've added a section for them to the thread now.
Minecraft-things: http://skylinerw.com
More Minecraft-things: https://sourceblock.net
Guides for command-related features (eventually moving to Source Block): https://github.com/skylinerw/guides
I primarily hang out in the /r/MinecraftCommands discord, where there's a lot of people that help with commands: https://discord.gg/QAFXFtZ
Their corresponding subreddit: https://www.reddit.com/r/MinecraftCommands/
When 1.9 is actually finished, these new command blocks will make everything less laggy
3D Redstone Cables+
>> Get 'm now! <<
jomy10.weebly.com
Ah so branches are possible with conditionals.Never mind the power flow is linked the other way.Putting the CENDENT back in transcendent!
I chose the worst time to be homeless... I really want to play with these new command blocks.
Could you use pistons to push around a redstone block in a chain so different ones could activate?
In 15w35b command blocks now have a toggle setting: "needs redstone" / "always powered", which does exactly what it looks like. As well, the conditional NBT tag was removed and conditionality was moved to block states.
Putting the CENDENT back in transcendent!
I like this. I tested the snapshot and it is very good but the chain are too fast so It can´t work in some cases and the repeating command is too fast too; cause it can´t test players like the old clock for a map or something else.
But i liked your explanation
Those new command blocks are great but there are still so many issues
Here a video
Wow, now we will have better maps! think the possibilities!
Loving loving loving the new command blocks. Really gonna add some fun with logic. Been playing with them for a few hours now and I think the only thing missing is being able to pass the target from the first block into the rest of the chain. (let the @p output into the chain)
All commands that needs updates as fast as possible, like testfor commands, will be so much smoother and less laggy now. All systems will be a lot more compact and easier to build too, and aoecloud could add some cool possibilities. I hope the update comes out this month so i can finish my map and realm builds, I'm tired of waiting ...
Creations are only restricted by your imagination.
A simple slower clock could involve a scoreboard, 2 repeater blocks and a chain block. the first one just adds 1 to the scoreboard every tick and the 2nd repeater block tests that fake player for the desired tick count which will then pulse out, with the first pulse resetting the scoreboard back to zero.
Command examples are:
/scoreboard objectives add Timer dummy Timers
/scoreboard players add ticks Timer 1
/scoreboard players test ticks Timer 20 >> chain to>> /scoreboard players set ticks Timer 0
The scoreboard test can be set to any tick rate you want. This is actually do-able in 1.8 using the fill clock and a comparator to accomplish the same effect.
Thank you, this really helped a lot!
testfor is buggy.
it does not always activate other command blocks connected to it (with a comparator) even if the player is in the correct place.
Thank you.
What I dislike about the chains:
If ran from a repeater, it's as if they too are repeaters. Even when the repeater is not successful, the chains run every tick, independently.
One fix, I know, is to run them all conditionally, but I was hoping instead they worked like this:
When the repeater successfully fires off, it's like running a redstone line to each of the blocks. All run that are able to run. if one is not successful, it doesn't break later ones!
Ugh! Does anyone feel my frustrations? Does anyone have any questions for clarification?