MC-89220Buggy 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.
Environment
Mac OS X 10.9.5
Java 8u45
Linked Issues
Low
Created Issue:
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, 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. After this, the second one will work correctly and say $, and there's no problem going from success to failure, but from failure to success is buggy.
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. The next command block just doesn't execute. This doesn't mean that isn't the issue, just check other things first.
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.
Environment
Mac OS X 10.9.5
Java 8u45
Attachments3
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. After this, the second one will work correctly and say $, and there's no problem going from success to failure, but from failure to success is buggy.
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. The next command block just doesn't execute. This doesn't mean that isn't the issue, just check other things first.
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.
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. After this, the second one will work correctly and say $, and there's no problem going from success to failure, but from failure to success is buggy.
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. The next command block just doesn't execute. This doesn't mean that isn't the issue, just check other things first.
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.
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. After this, the second one will work correctly and say $, and there's no problem going from success to failure, but from failure to success is buggy.
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 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.
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. After this, the second one will work correctly and say $, and there's no problem going from success to failure, but from failure to success is buggy.
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 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.
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. After this, the second one will work correctly and say $, and there's no problem going from success to failure, but from failure to success is buggy.
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 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.
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.After this, the second one will work correctly and say $, and there's no problem going from success to failure, but from failure to success is buggy.
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 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.
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!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.
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!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.
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] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
![[Mojang] Searge (Michael Stoyke)](../../../data/assets/gravatar/searge.png){kind=small}
[Mojang] Searge (Michael Stoyke)A comment with security level 'global-moderators' was removed.
relates to
![[Mod] Michael Wobst](../../../data/avatars/users/37868.png){kind=small}
that has to do with the order of execution, it first runs the conditional then the testfor because of the set up, if you want then to activate in the certain order, use chain command blocks
Invalid according to FVBico's comment.
Sorry, forgot to mention that. I set these up in the correct execution order (-X > +X) and it still didn't work properly.
Like I said, use chain command blocks
Can't use chain command blocks if I need the second one to switch a chain based on the condition of the first one. Believe me, if there was a way around it, I would be using it.
If a chain needs to extend from the conditional one, i use a conditional repeat command block, just as easy
For crying out loud.
I'm a serious command block engineer, and I have used repeating command blocks for this purpose in the past. Due to my own experiments, plus some reasoning around said subject, I have determined that, for slower clocks, this method of conditionality is more efficient. However, as previously mentioned, THERE IS A BUG WITH CONDITIONALITY which makes it unfeasible from a reliability standpoint, when the only other alternative is to clock 150 command blocks constantly, or run calculations faster than servers can reasonably handle, due various parameters such as executes resolving to hundreds or thousands of entities.
Additionally, you should have already stopped arguing, as I have proven this to be a valid bug, and it should be reported as such, with as few extraneous comments as possible, to avoid slowing the processing. You're not arguing about the invalidity of the bug, just command block programming techniques, so I would ask you to refrain from commenting and let the mods handle this page.
I used command blocks since they came out, I can make your system easely, just switch tge 2 command blocks around then...
The way you use them (setblock clock) has never fully been supported, found an issue? Fix your system first.
I'm not going to spend more time on this ticket, goodbye
I already said it has almost nothing to do with what I'm doing with them. Conditionality doesn't update properly, there's no workaround, it's a bug, and it should be fixed!
Reopened.
Thanks.
I would guess both that this is caused by MC-11193, and that chain command blocks were created specifically to work around that issue. The order in which blocks are updated in a tick is determined by their location.
It's not, /fill has a well-defined update order.
Tested this morning; Still present in 15w45a.
Did some further testing; Still present in 15w46a.
Still present in 15w47c.
Confirmed for
The order of execution, especially when it comes to handling the conditional flag, is only guaranteed with chain command blocks.
The order of execution should be defined by the redstone update order (and, with powered blocks & fill, this is well-defined), which means that it is guaranteed. I have not seen a single instance of this bug not being present, so the only logical conclusion is that it it just that: A bug. Stance unchanged.
Data tag updates might be delayed until after command execution. Is there a reason you're not using chained command blocks for this?
Yes. This technique allows the switching of long chains of blocks, within a tick, based on a given condition (except that, because of this bug, it doesn't work properly.
) Imagine:
[Repeat>][Repeat - Conditional>][Chain][Chain][Chain][...]
The chain only ever executes when the first repeat block succeeds.
This is incredibly useful for high speed systems that have to remain efficient, such as server mechanics. Such a system would respond to input within a tick, as with ordinary repeat-chain links, but only the first block would be on all the time, thus lowering the command count the server has to process each tick, and raising efficiency dramatically.
Other thing, about data tags and execution: If you check the data of the block during the tick (with blockdata x y z {}, and unconditional), and look at the result tag after pressing the button, SuccessCount is correct. So, it really just looks like a function call was misplaced.
If this really does work as intended, and the conditionality flag is not well-defined, please change it! This would be integral to command block design if it worked properly. The purpose of the new command blocks is to improve command design. Using Conditional on impulse and repeat blocks agrees with that philosophy completely. Speaking for map makers and lovers of vanilla everywhere, this is relevant.
Still present in 15w50a.
This absolutely should be corrected. It's very useful, and many game items which are not nearly as critical are being fixed. Please, please, change this.
It's not an arbitrary decision. If they could make it that way without having a substantial impact on performance, or ripping out and rewriting redstone entirely, they probably would. They may do that in the future, but certainly not for 1.9.
Redstone wouldn't have to be rewritten, as block powering order is well-defined based on the xyz axes (the undefined part of redstone is the wire). Conditionality already works this way with chain command blocks. Plus, command blocks have already been heavily modified, and conditionality is present in all three types. If 1.9 is to truly improve command blocks, and command theory, items such as this must be taken into account.
Also, as I recall, part of the reason the new dev team was hired was to clean up the code. You don't even have to modify the redstone code here! The problem lies in the conditionality check and data tag updates, and working it out will probably make things more efficient and easier to deal with for further updates.
This should definitely be fixed, as it is a useful technique and fits perfectly with the 1.9 command block philosophy.
I’m working on a command block server, and being able to switch impulse and repeat blocks at high speed using the conditionality flag would really improve the systems.
This is not a discussion forum. If you believe this ticket needs to be reopened you can make your case in a concise post on http://mojira.reddit.com
About: "The order of execution should be defined by the redstone update order (and, with powered blocks & fill, this is well-defined), which means that it is guaranteed."
The update order (XYZ) was never well defined. It is coincidence that this order remained the same and could change at any time if a different update order has advantages over the current one. It's the main reason chain command blocks were introduced to have a defined order of execution.
The current behavior of command blocks and the conditional flag is exactly how it needs to work. Different ways to handle ticking and conditional flags have been tested and this proved to be the most consistent. Chain blocks are the way to execute commands in a defined order.
And as redstonehelper just said, this is not a discussion forum.
Yeah, put something on the reddit after redstonehelper said that. In this case, hell, things are going to get annoying concerning multiple updating lines.
In 1.12 /fill, /setblock and /blockdata work instant but conditional repeating command blocks and normal command block have a delay.