-
Bug
-
Resolution: Works As Intended
-
None
-
Minecraft 15w39a, Minecraft 15w39c, Minecraft 15w44b, Minecraft 15w45a, Minecraft 15w46a, Minecraft 15w47c, Minecraft 15w50a
-
Mac OS X 10.9.5
Java 8u45
-
Confirmed
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.
- relates to
-
MC-99343 Conditional repeating command blocks are activating 1 tick too late (or not at all)
- Reopened