Bug
Observers are inconsistent on chunk borders.
How to reproduce
1. Place a line of observers facing towards/crossing a chunk border
2. Update all of the observers at the same time
What I expect to happen
All the observers will output at the same time
What actually happened
Some observers will update before others, causing an inconsistency
This bug affects multiple Redstone contraptions, especially things like piston doors, flying machines, or anything that uses observers.
Linked issues
is duplicated by 3
relates to 3
Attachments
Comments 9
Thank you for your report!
However, this issue has been temporarily closed as Awaiting Response
Is this still an issue in the latest version? If so, please make sure the ticket description contains the following information:
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
Having done some testing of this, I have found that there are some blocks which don’t cause observer inconsistency, namely bells, pistons, moving blocks, and mob heads (ender dragon and piglin). Based on this, the bug seems to be an issue with updates created by scheduled ticks not progressing across chunk borders consistently, as all of the blocks that aren’t inconsistent are block entities that are constantly ticked for powered/active state (droppers, dispensers, and hoppers are block entities, but they don’t update their powered state in the block entity stage, thus not being consistent). Also, the inconsistency notably matches for any components crossing the same chunk border, thus likely being an issue with update propagation.
(Note, in the video linked in the report involving pistons, the behavior shown is actually piston inconsistency (the two pistons in the flying machine like unit activate/deactivate on the same tick, and their order isn’t fixed, so the behavior is inconsistent, but not part of this bug report).
I know what is happening here. This is 100% about how pending ticks are processed. Suppose we have chunk A which updates before chunk B. Then if a pending tick is processed in chunk A and causes the creating of a pending tick in chunk B, that will then be PROCESSED WITHIN THE SAME GT. This is obviously stupid and the game should just delay these updates to the next gt.
How does this affect observer reliability? Well, whether or not the observer reacts 1rt earlier to an event (and causes randomness) determines on whether or not the update was in a redstoning tick or not. For example, adding a wall into these setups (where applicable) for 1gt delay will act as a sort of NOT gate that flips whether or not it is reliable or not (to be clear, the wall gets updated across a chunk border, not the observer).
Confirmed in 1.16.50 iOS.