mojira.dev
MCPE-73342

Adjacent block updates causes liquids and fire to spread faster

There are a few block updates where there is supposed to be a specific delay. These are liquids flowing and observers giving a pulse. However, the actual delay can be shortened by an adjacent block update, assuming both are in the same chunk.

How to reproduce

  1. Place 2 rows of solid blocks, with a 1-wide gap in between. Make sure the entire construction is in 1 chunk.

  2. On top of each row, place observers, each facing the nearest endpoint. This gives an observer clock with an additional observer on each end.

  3. Create a third "extended observer clock above the gap between the first 2.

  4. Fill the gap with lava.

  5. Break one of the observers on the side. I expected there to be a delay before the lava flows, since lava is slow outside of the Nether. In reality, the lava fills the observer's space almost immediately, but it then flows at more normal speed.

Impacts
Like MCPE-15793, this could break the timing of certain contraptions, especially if observers are affected by all block updates. It can also be exploited to make water and lava flow super fast, such as in Navynexus's basalt farm.

Linked issues

Comments 4

EveryCabbage884

Resolving temporarily as Awaiting Response. Does this issue still occur in the latest version (1.16.201)?

[Mojang] Mega_Spud (Jay)

Cleaning up old tickets: This ticket had been set to 'Awaiting Response', but has not received a response from the reporter (~3 months+) so is being closed as Incomplete. If you feel this is still a valid issue then please comment, or create a new ticket following the Issue Guidelines which includes steps to reproduce the problem.

For any account or purchasing related issues, please contact Minecraft Customer Support directly, as we cannot assist with those here at the bug tracker.

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

Reopened based on duplicate reports, and removed information about locking observers since that was a different issue (MCPE-64409).

This behavior is also used to create fast portal lighting systems in portal-ticking gold farms by placing a row of 5 observers next to a row of lava that is next to a row of trapdoors next to the portal. The observers trigger the lava to spread fire onto the trapdoors, which lights the portal. The trapdoors never get consumed because they don't burn, but they receive the fire updates for a tick, presumably because they are wooden.

I have posted a deeper analysis of liquid spread timings in a comment on MCPE-21038. The gist for this report is that adjacent block updates do not simply cause liquids and fire to spread faster. Rather, repeated block updates create the appearance of faster spread by stacking scheduled spread attempts in the pending tick queue. A lava blocks always tries to spread lava and fire 30 ticks after receiving a block update. The behavior described in this report occurs because a lava block does not check whether it has pending spread attempts already scheduled when it schedules new ones. Thus, once it has been adjacent to a 6 game tick observer clock for 30 ticks, it will attempt to spread every 6th tick as its scheduled updates come due.

A simple fix to cancel previously scheduled spread attempts when a new one is created could have the undesirable effect of allowing liquid spread to be delayed indefinitely by repeated block updates. See my comment on MCPE-21038 for further discussion.

Blobs2

(Unassigned)

901014

Confirmed

Multiple

java-parity

1.20.10.21 Preview, 1.14.60 Hotfix, 1.19.11 Hotfix, 1.19.20, 1.19.83 Hotfix, 1.20.41 Hotfix, 1.21.41 Hotfix

Retrieved