mojira.dev
MCPE-74281

"Needs redstone" repeating command blocks with long delay counts function unexpectedly

For repro steps and a technical explanation of the bug causing this issue, see this comment.

OK so this will be a bit of a long one to explain, sorry.  if you have a repeating command block with a somewhat large delay (say 100), it is pretty easy to make it run on multiple cycles (not the correct term but whatever).

 

description:

if you were to power a repeating command block (with needs red-stone of course), and set it for a delay of 100 ticks, then  unpower, and repower the command block while its still waiting its delay, it will start another loop of 100 ticks of the cycle, while the first 100 tick delay is sill active. once the original delay runs out, it will still execute it's command, and trigger any chain command blocks attached to it.  and it wouldn't just end there either, it will keep going, starting another 100 tick delay.  the second loop is also fully functional, and it is like you have 2 command blocks on 100 delay in the same block.  this is not limited to 2 loops, however, and you can have as many as you want, it seems.  the only way to stop it is if you unpower it, then let the loops finish their delay, then they realize they aren't powered and will stop.

 

replication:

this really isn't too hard to replicate, as all it takes is some unpowering and repowering of a repeating command block, with a command in it such as "/say hi", and the issue should become apparent.

 

if you want to see it in more detail, you can use these commands that i used to find out the issue.

 

/scoreboard objectives add timer dummy timer

/scoreboard objectives setdisplay sidebar timer

/scoreboard players set time timer 0

/scoreboard players set lastlog timer 0

/scoreboard players set delay timer 0

there should be a scoreboard on the right of your screen with 3 values

 

now we will have to use a few command blocks to help us out. first is an independent repeating command block on always active and no delay, with the command: "/scoreboard players add time timer 1"

the time on the left of the screen should start to quickly go up

 

now we can leave that one alone, and move on to a chain of 3 command blocks. the first is a repeating command block with a delay of 100, and set to needs redstone. this one should have the command "/scoreboard players operation delay timer = time timer"

the second one is a chain command block, with no delay, on always active, and chained from the repeating command block. this one should have the command: "/scoreboard players operation delay timer -= lastlog timer"

the last command block should be identical to our second command block in this chain, aside from being chained from the second command block, and the command being: "/scoreboard players operation lastlog timer = time timer"

 

now that should be all the commands we need. first, place a redstone block next to the repeating command block that is part of the chain of 3 command blocks. the delay may do something weird for a little bit, but after about 10-15 seconds, it should stay at 100. this means it works, and that the repeatoing command block is, in fact, going at a delay of 100.

now to see the bug, quickly break and replace the redstone block a few times, and when you are done breaking and replacing the redstone block, make sure that you left the redstone block there the last time so that it is still powering the repeating command block. now watch the delay go a bit odd, as the repeating command block isn't waiting 100 ticks each time, but less as it is running multiple waiting cycles and activating a command every time. eventually the delay will keep repeating the same numbers over and over again, as each loop is consistent, and repeating.

 

that is all. hanks for listening, and hopefully for fixing this one day. i also hope this isn't a repeat, but as far as i can tell, its new. thanks again!

 

edit for clarification: when doing the long demonstration, watch the delay. that is the delay between each time the command block activates. in the beginning, it is 100, what we set the command block to. but after we spam the redstone block, it starts to jump around because it is being triggered on loops that shouldn't be there, making it trigger much earlier than it should.


Original reported platform was Playstation 4.

Confirmation was performed on Windows 10.

Linked issues

Comments 2

Thank you for your report!
However, this issue has been temporarily resolved as Awaiting Response

Is this still an issue in the latest version?

If it is, please be sure to include steps to reproduce the problem:

Steps to Reproduce:
1.
2.
3.

Observed Results:
(Briefly describe what happens)

Expected Results:
(Briefly describe what should happen)

If your ticket does not look like the example given here, then it's likely to be closed as incomplete.

This ticket will automatically reopen when you reply.

Quick Links:
📓 Issue Guidelines – 💬 Mojang Support – 📧 Suggestions – 📖 Minecraft Wiki

This is still an issue in 1.16.100.

Steps to reproduce:

  1. Set up a repeating command block as follows:
    Condition: Unconditional
    Redstone: Needs Redstone
    Execute on First Tick: On
    Delay in Ticks: 150
    Command: say Tick!

  2. Attach a lever to the command block and turn it on.

  3. Observe the chat message "Tick!", then immediately turn off the lever.

  4. Wait a couple of seconds, then turn the lever on and leave it on.

Expected Results:
The chat message is repeated every 15 seconds.

Actual Results:
The chat message is repeated twice every 15 seconds in two overlapping cycles.

Note: The longer your Delay in Ticks is set to, the more cycles you can get going simultaneously. As the original description says, the only way to prevent multiple cycles from getting started is to leave the redstone power off long enough for all previously scheduled cycles to expire.

Corollary:
Although this ticket doesn't specifically mention it, there is an additional issue caused by this bug. After you remove the redstone power, you might expect that the command block would stop executing immediately. But in fact, when the delay expires the previously scheduled execution will run and execute the command anyway. It won't reschedule again because the power is off, but it does unexpectedly execute the command despite the redstone power being off.

There are other reports that I believe are consequences of this corollary issue. For example, it might be a factor for MCPE-105293.

Additional thoughts:
At first I thought that a solution might be to modify the code that runs the scheduled cycle so that it checks for the block to be powered and avoids executing the command if it isn't. Later I realized that this logic would still allow the unexpected result of the repro steps above, I think now the only solution will require cancelling the scheduled event that reactivates the command block when the redstone power is removed from it.

Peter Lund

(Unassigned)

440570

Confirmed

Multiple

1.14.60 Hotfix, 1.16.100

1.17.40.20 Beta, 1.17.40

Retrieved