"Conditional" Command Blocks
All command blocks use this feature, not just Chain command blocks. Furthermore, all command blocks check behind themselves, including Chain blocks, rather than in sequence ("previous"). In this image, #4 is set to conditional and requires #1 to be successful in output, not #3. It needs #3 in order to connect to the chain of commands.
Impulse blocks behave as expected (image); the command block on the right is conditional but cannot run its command unless the one "behind" it (opposite of its facing) is successful.
Repeating blocks are the same as Impulse blocks, except they will not constantly send a signal if the block behind them was unsuccessful.
And while a conditional command block does not run its command if the block behind it fails, it will still push a signal through chain blocks. That means in this image, if the Repeating block is conditional and fails, all the chain blocks are activated once. Since it's a Repeating block, it will not send a signal after that point until a block behind it is successful. It's the same for Impulse blocks, minus the fact that they can't clock.
Not in a position to do major edits though, so just relaying info. Skylinerw (talk) 20:08, 20 August 2015 (UTC)
- I think I see what you're saying. I'll make a stab at correcting the article. —munin ·
· 20:20, 20 August 2015 (UTC)
DEFAULT Setting for Chain blocks
Chain command blocks all defaults to "always active", meaning they will activate depends on what chained to it, regardless the redstone.
221.221.224.140
Animated grid image
As with sea lanterns and prismarine, it would be nice if we could have an animated version of the grid image. —Fenhl 12:08, 12 September 2015 (UTC)
- @Majr: since you've uploaded File:Grid Magma Block.gif, could you also add these? —Fenhl 14:22, 21 May 2016 (UTC)
"Success" difference in Chain vs. Conditional not documented on this page?
There appears to be a small discrepancy in the page describing how the new command blocks work Two excerpts from the wiki:
- "Conditional": The command block should only execute its command if the command block behind it executed successfully
- "Chain" blocks are green. These execute only when the command block pointing to it executes successfully.
And the statement that:
- This differs from the Conditional option in that it detects what is pointing to it, instead of simply behind it. The command blocks pointing to it also need not be chain blocks themselves to trigger the chain.
This seems to imply that both options use the same type of 'success' and that it only differs between which block is checked, however a simple test shows this is not the case:
Setup: A button, a line of redstone weakly powering a command block, pointing into to another command block whose "back" correctly faces the previous. ( Images here ) ** CB1 is a regular impulse containing a 'testfor playernamehere' command CB2 contains 'say CB2 fired'
Tests:
- CB2 is a chain command block, the player is NOT on the server, the button is pressed. - Results: 'CB2 fired' displayed
- CB2 is a conditional impulse command block, the player is NOT on the server, the button is pressed. - Results: Nothing is displayed, CB2 is not activated.
- CB2 is a conditional chain command block, the player is NOT on the server, the button is pressed. - Results: Nothing is displayed, CB2 is not activated.
- CB2 is a conditional repeat command block*, the player is NOT on the server, the button is pressed. - Results: Nothing is displayed, CB2 is not activated.
- CB2 is a chain command block, the player IS on the server, the button is pressed. - Results: 'CB2 fired' displayed
- CB2 is a conditional impulse command block, the player IS on the server, the button is pressed. - Results: 'CB2 fired' displayed
- CB2 is a conditional chain command block, the player IS on the server, the button is pressed. - Results: 'CB2 fired' displayed
- CB2 is a conditional repeat command block*, the player IS on the server, the button is pressed. - Results: 'CB2 fired' is displayed repeatedly until the button unpowers CB1
(1.9/vanilla) (* not shown in image, ** Alternatively, you can power a block next to CB1 for the chain-block tests.)
Because of the alignment, both the conditional and chain draw their 'success' check from the same preceding block, which means they determine success differently if the wiki's description is true. However, this information is not present on the wiki page.
In particular, it appears the Chain command block executes whenever the previous command block is executed, regardless of the command's success value,
and the Conditional block executes when the previous command block is executed AND the command has succeeded.
-- 72.214.181.74 02:57, 12 March 2016 (UTC)
- Alternatively, for the chain-block tests only, you can power a solid block next to CB1 with the same results. -- 72.214.181.74 03:19, 12 March 2016 (UTC)
- I think the solution here would be to reword one of the "successfully"s as they obviously don't mean the same thing - one is that the command actually ran (not necessarily with a successcount) - the other is that the command ran and had a successcount -- 72.214.181.74 03:17, 12 March 2016 (UTC)
- Fixed the page for clarification about chain execution to not include "successfully", however be aware that you have run into a bug on how a conditional Impulse/Repeating block can't execute until the next tick. See MC-99343 for more information. Skylinerw (talk) 14:36, 12 March 2016 (UTC)
Chain Command Blocks
The article states " "Chain" blocks are green. These execute only..." Are they not Light Blue, as opposed to green?
OlidogMC (talk) 16:12, 19 April 2016 (UTC)
- The colors have more green than blue in them, but "blue-green" might be more accurate. —munin ·
· 23:25, 19 April 2016 (UTC)
Chains and Chunk boarders
I think that it takes an extra tick for command blocks to trigger across chunk boarders, similar to redstone circuits. Or, at least, some oddity occurs when going across. You can confirm this with a scoreboard that sets a score on one chunk, and resets it and list scores on the other. This should probably be added after the comment about them running on the same tick.
Also, I would like to ask if anyone knows if these can be used for loading chunks, and if so, what do we need to do (is just being on the chunk boarder good enough, need to point out of it, have our condition on the other side)? Firefish5000 (talk) 06:51, 19 May 2016 (UTC)
Command Block Effective Range
Command Blocks stop operating when in a chunk that isn't currently loaded but there appears to be an exception when the command block is close to the world spawn. I'm not sure if this is intended behavior or a convenient loophole, but it enables the creation of commands that have a global scope. This knowledge could make a big difference in how command blocks are used and placed, and certainly something I was trying to learn about when reading the Command Block article. Should we add it in somewhere?
--Lebrenth (talk) 02:07, 29 July 2016 (UTC)
- Spawn chunks stay loaded as long as one player is in the overworld, so this isn't unique to command blocks. —munin · · 03:12, 29 July 2016 (UTC)
1.11 custom sounds
1.11 custom sounds, can someone please give me the command for custom sounds in 1.11, there is no information on this anywhere, and it would be appreciated. Do I need to change the sound file again, which worked in 1.10 perfectly. –Preceding unsigned comment was added by 60.227.230.217 (talk) at 06:16, 17 November 2016 (UTC). Please sign your posts with ~~~~
- Do you mean the sounds.json file? or the
/playsoundcommand? – Sealbudsman talk/contr 12:12, 17 November 2016 (UTC)
How to add effects to two word blocks
Im trying to use one command block per block to add effects to blocks. It works for one word blocks but with blocks like snow tops and end stone. It doesn't word because there more than one word and adding an underscore in between the words like end_stone doesn't work either. Waluigi goes waa (talk) 03:49, 6 April 2019 (UTC)
The command I normally use is Execute ~ ~ ~ detect ~ ~-1 ~ (block) (color coad) (effect) Waluigi goes waa (talk) 03:54, 6 April 2019 (UTC)