Buggy conditionality when command blocks are updated within a tick

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

• 15w47c I am quite confused, what is the conditionMet tag actually used for? Because it seems like indeed only the SuccessCount tag determines whether a command was executed successfully or not

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.