This is a problem because chain can be changed during execution and expectation is that the changes made should be accounted in the next tick.
Examples are in attachment.
This
screenshot shows workaround with using setblock clock.
I'm not sure that this isn't intended but it is certainly not expected.
Linked issues
Attachments
Comments 5
It doesn't have to be determined on the go. I expected it to be determined after the chain executes and I thought it was clear from bug description.
Sadly it's intended to work this way but I still think this should be changed.
This certainly is unexpected behavior... I would suggest only scheduling the first command block to run, then when it does, have it tell the next command block to execute without scheduling it, and have that block tell the next, and so on through the chain. To prevent infinite loops, have each command block, when told to run, check if it has been run this tick, if yes, have it not run the command, nor tell the next block to run.
p.s. Is this the correct place to suggest this? Or should I have put this on redit, with the rest of the suggestions?
I was unsure if it really works intended, however it does:
The quote from Searge says
Searge: RCB -> repeat the whole execute RCB, schedule RCB, traverse CCBs, execute CCBs
Lets pretends we have a chain like this:
RCB1: Start command block, no command
CCB1: Command:
/setblock ~ ~ ~ air
CCB2: Command:
/say Test
Now the repeating command block is powered:
Run RCB1: Nothing to do
Schedule RCB1 for next tick
Add CCB1 to be run this tick
Add CCB2 to be run this tick
Run CCB1: Add
/setblock
command for next tickRun CCB2: Add
/say
command for next tick
— Next tick —
Run RCB1: Nothing to do
Schedule RCB1 for next tick
Add CCB1 to be run this tick
Add CCB2 to be run this tick
Execute
/setblock
command (eventually remove CCB1's command for the next tick as this command block does not exist anymore)Execute
/say
commandRun CCB2: Add
/say
command for next tick
Possible solution
The problem is currently that Minecraft traverses the chain command blocks at the beginning of a tick before the command from the last tick are executed. So there are from what I see at least two possible solutions, both use a list of "end tasks" which run after the normal tasks of a tick finished (but also in the same tick).
Instead of adding the RCB to the "normal" tasks, add it to the "end" tasks.
Instead of traversing when the RCB runs at the beginning of the tick, the traversing could be scheduled for the end tasks
Note: This would at least reduce the count of the /say
command being executed to 1 (instead of 2)
I don't see any problem with that at the moment
If scheduling was determined on the go you could schedule infinitely many commands in one tick.
Working as intended per Searge's comment on MC-86677 and https://www.reddit.com/r/Minecraft/comments/3hnjga/can_you_do_a_loop_with_the_new_chain_command/cu8wo06