In 26.2 to fix MC-305475, Tripwires schedule itself on a 0gt delay after depowering and then check that it is scheduled to prevent it from repowering right after turning off.
The problem is that scheduling 0gt delay scheduled ticks after the ticks were collected in the game tick is not correctly handled by the tick scheduling logic. This causes the first tick of the chunk in the scheduled tick phase to be this 0gt delay scheduled tick since it is going to be earlier than trigger tick wise than all other scheduled ticks - based off of DRAIN_ORDER. However, when scheduled ticks are being collected to be ran the game picks the chunk tick container based off the INTRA_TICK_DRAIN_ORDER. This ordering ignores the trigger tick going directly to the TickPriorityand the subTickOrder. Since this is scheduled with TickPriority.NORMAL and with high subTickOrder (due to the zero delay), this causes the scheduled ticks for this chunk in the next game tick to be processed after other chunks even when they should not be (see example image).
Note: This can affect any contraption that relies on cross chunk block tick ordering and has an active tripwire.
The simplest fix would be to change the delay from 0 to 1. This will place it correctly in the chunk’s tick queue and without changing the current tripwire’s behavior - the zero delay scheduling always happens in scheduled ticks so it will always execute in the next game tick anyway.
However, the problem goes deeper that. The fundamental issue is not that tripwires are misbehaving, it is that player entities running applyEffectsFromBlocks are likely adding spurious movements (ending up in finalMovementsThisTick) triggering more blocks than they should be or triggering them at the wrong timings. This was exposed in 1.21.9 when the forEachBlockIntersectedBetween speed limit was lowered to 1.0E-5F which allowed these movements to check the tripwires and thus activating them. These spurious movements need to be eliminated in order to properly fix MC-305475. When this is done, the 26.2 fix could be entirely reverted which will also “unbreak” some contraptions which utilized the pre-26.2 tripwire behavior.
Note: I have not identified the source of these spurious movements but they likely resulted from changes to applyEffectsFromBlocks since 1.21.2 but most likely from either 1.21.2 or 1.21.5.
Image Explanation:
Press button above dropper (filled with items) to drop item and trigger the tripwire [Anything that triggers the tripwire for less than 10gts will work].
Expected: Piston powered by repeater extends.
Observed: Piston powered by comparator extends.
Special thanks to: Garlic_Bread, cled0328, Autumn, Lintex, and noHax4u for finding this bug / testing possible fixes.
Attachments
Comments 4
This bug can at random break any redstone contraption that just happens to be in the same chunk as some string block (refer to the attached video), this is absurd. I fail to see how this is a “low priority“ issue.
Why was this marked low priority? It can literally break simple things like a redstone clock. Tripwires essentially behave as landmines when placed near any redstone contraption.
I was observing a small hiccup in a specific mechanism just because a tripwire somewhere else in the machine was being touched by an entity. But Savva’s demonstration showing it breaking something as simple and universal as a repeater clock indiciates that this is a much more serious issue. This would not just affect technical players but also mess with anyone trying to casually learn and engage with redstone in general.
Thank you for helping us improve Minecraft! We saved your files: