Overview
If you have a repeat command block on conditional mode and attach a trailing chain of chain command blocks to it, you can activate and deactivate all of the chain (including the repeat command block itself) by powering and unpowering the repeat command block with no problem, as long as it's condition is true, if however the condition is false, it strangely powers all the chain command blocks exactly once when receiving a redstone signal. If you keep it powered and instead change the state of the condition, then the execution of the repeat command block both starts and stops one tick earlier then the rest of the chain.
Exact reproduction steps
First you setup 4 command blocks:
(a) Impulse, Unconditional, Needs Redstone
(b) Repeat, Conditional, Needs Redstone
(c) Chain, Unconditional, Needs Redstone
(d) Chain, Unconditional, Needs Redstone
Here (a), (b), (c), (d) should be in a straight line with (a) pointing into (b), (b) pointing into (c) and (c) pointing into (d).
They have the following commands:
(a) say success
(b) say repeat
(c) say chain1
(d) say chain2
Then you try the following things
#1
Remove all redstone blocks from previous tests.
If you just did #3, you first need to create (a) again.
Do "/say ----------------", so you can later scroll through the chat and know where you started.
[@] ----------------
Power (a) with a redstone block.
[@] success
Then Power (b) and quickly unpower (b) afterwards so you chat doesn't get spammed.
[@] repeat[@] chain1[@] chain2[@] repeat[@] chain1[@] chain2[@] repeat[@] chain1[@] chain2[@] repeat[@] chain1[@] chain2[@] repeat[@] chain1[@] chain2
As you can see the redstone block activated and deactivated the repeat and chain command blocks as expected.
#2
Remove all redstone blocks from previous tests.
If you just did #1, you need to remove (a) and create it again so that it has SuccessCount data of 0.
If you just did #3, you might want to create (a) again, but it is actually not involved in this part of the bug reproduction.
Do "/say ----------------", so you can later scroll through the chat and know where you started.
[@] ----------------
Then power (b) with a redstone block.
[@] chain1[@] chain2
As you can see, the repeat command block (b) doesn't execute any command, but upon being powered it powers the chain on it exactly once. I find this very strange and it seems buggy.
#3
Remove all redstone blocks from previous tests.
If you just did #1, you need to remove (a) and place it again so that it has SuccessCount data of 0.
You need to power (b) and keep it powered with a redstone block.
Do "/say ----------------", so you can later scroll through the chat and know where you started.
[@] ----------------
Then power (a) with a redstone block and quickly break (a) afterwards so you chat doesn't get spammed.
[@] repeat[@] repeat[@] chain1[@] chain2[@] repeat[@] chain1[@] chain2[@] repeat[@] chain1[@] chain2[@] repeat[@] chain1[@] chain2[@] chain1[@] chain2
As you can see, (b) both starts and stops outputting one tick before (c) and (d) do.
Attachments
Comments 8
Here are some scenarios. I suspect that this has to do with block ticks vs. redstone ticks and thus will be hard to fix.
Unfortunately, this fix causes conditional chain command blocks not to detect the success of the block behind them, making all three scenarios operate improperly. All scenarios involving repeating conditional command blocks now execute all commands in the chain at least twice, because the evaluation of the condition is delayed until the next execution. The scenario involving the impulse command block does not function at all because of a lack of repeated invocations. (See MC-87566 )
Update: The issue is mediated somewhat in 15w35d, however all repeating command chains execute twice, and the impulse chain works correctly in a success condition, but not in a failure condition.
What do you mean by "however all repeating command chains execute twice"?
EDIT: I think I got you, I didn't see the screenshots.
EDIT2: ..but what do you mean by "and the impulse chain works correctly in a success condition, but not in a failure condition"
Conditional command blocks will execute when the condition returns success, but conditional command blocks will not not execute when the condition returns failure.
You description has probably a mistake as c and d won't do anything at all unless they are set to "Always active" or powered by a redstone source.
BTW: This is actually already a bug in 15w34d. (You would use redstone blocks to power the chain command blocks then, because of the Always Active option missing.)