Buggy conditionality when command blocks are updated within a tick
If you have 2 impulse command blocks set up in the following manner:
[>][>]
1st, Impulse: testfor Fails
2nd, Impulse, Conditional: say $
And activate them within the same tick using a fill clock, the first one fails and the last one does nothing, as expected.
If you then change the first block to testfor @a and activate them again within the same tick, the first succeeds and the last one DOES NOT execute, even though the first one succeeded.
I have now shown this to be a SuccessCount problem. When a block's command is changed, SuccessCount is reset to 0. If this tag is manually reset to its previous state when the command is changed, this now fails whenever SuccessCount updates, which is any time the checked condition does.
Other notes:
- Having a repeat command block for the second one produces the aforementioned effect, but a chain command block works properly.
I tested whether it was a block data problem, and the SuccessCount tag is updated.This is a SuccessCount problem! While the tag is updated (as can be checked using /blockdata during the tick), it's not performed fast enough for command blocks to check properly.
This is a real pain for high - speed efficient circuits (in fact, I have a similar setup to the one mentioned above switching over 50 command blocks), so please do fix soon.
[Mojang] Searge (Michael Stoyke)
2015-09-21, 05:20 PM
2017-12-30, 12:13 AM
2015-11-26, 04:33 PM
0
5
block-update, command_block, conditional
-