Upon server restart, the game loads the spawn chunks and the chunks of persisted tickets, which currently includes chunks loaded by portals and chunks that are force loaded.

While experiments indicate that simulation/ticking of these chunks stop together consistently on server shutdown, the experiment presented in this issue show that the spawn chunks and chunks of persisted tickets might not start simulating/ticking together, likely depending on hardware.

As a consequence, some redstone circuits and technical builds may break if the server is shut down at an unfortunate time.

As a player, one can ensure that chunks are properly loaded before a multi-chunk contraption is started, and one can ensure that those chunks are kept loaded (e.g. by using portal-based chunk loading) until after the multi-chunk contraption stops. There is no way to detect or react to a server shutdown however, so to avoid breaking multi-chunk contraptions the simulation/ticking of all reloaded chunks need be started together, consistently.

That is, all spawn chunks and chunks loaded by persisted tickets must be loaded before the first game tick occurs.

Explanation of test setup

The contraption

The attachment contraption.png shows a redstone circuit, denoted the contraption:

1. Upon hitting the note block, the observer detects a state change.

2. 2 game ticks later, the observer powers the redstone wire for 2 game ticks.

   1. The redstone wire crosses a chunk boundary.

3. The redstone wire powers the sticky piston, provided both chunks are loaded.

   1. The sticky piston leaves its block behind upon contraction, due to the shortness of the pulse.

Test setup

The attachment setup.png shows a test setup:

• The area covered by blocks of netherite, gold, and iron are the (block ticking) spawn chunks of a test world.

  • /setworldspawn 0 56 0

  • /gamerule spawnChunkRadius 2 (the default)

• The area covered by blocks of lapis lazuli are two chunks that are force loaded:

  • /forceload add 0 48 15 79 (i.e. chunks [x:0, z:3] and [x:0, z:4])

    • The chunk [x:0, z:3] is also loaded as part of the spawn chunks, but no simulation or ticking normally occurs here.
      (All the chunks outside the iron blocks are loaded by the spawn chunks, but not simulated due to ticket level.)

• Every spawn chunk or force loaded chunk in the setup contains the sticky piston part of the contraption.

  • Every spawn chunk and force loaded chunk is connected together by a web of these contraptions, starting from the netherite covered center chunk.

The blocks of netherrite, gold, iron, and lapis lazuli are not important; they are only for illustrative purposes.

Steps to reproduce the issue

1. Build the test setup in a test world.

   1. The attachment setup.zip is a compressed Minecraft world where the test setup has been built.

2. Run /tick freeze

3. Hit the note block of every contraption built in the test setup.

4. Run /tick step so all the redstone wire is one game tick away from triggering.

5. Run /tp 1000 90 1000 to ensure that none of the chunks in the test setup are loaded by the player.

6. Save and quit the world (assuming single player game; the game server must shut down to unload all chunks).

7. Reload and enter the world.

   1. Note: The tick freeze does not persist across reloads, so the game will run upon entering the world.
      The observers will power their respective redstone wire in the first game tick after their respective chunks load.

8. Run /tp 0 90 0 to return to the test setup.

9. Observe the 27 blocks on top of sticky pistons, one for each contraption / chunk.

Expected result

All 27 blocks should be floating one block above their sticky piston.

All chunks that reload upon server restart, i.e.

• Spawn chunks

• Force loaded chunks

• Portal loaded chunks

should load together, and none of those chunks should start simulating/ticking before all of them are loaded.

Actual result

The result that I observe is that only the blocks in the following chunks float above their sticky piston

• The 25 spawn chunks.

• Chunk [x:0, z:3], the force loaded chunk that also is loaded as part of the spawn chunks as a non-simulation chunk.

while the block in chunk [x:0, z:4] does not float above its sticky piston.

This indicates that simulation/ticking of the 25 spawn chunks and chunk [x:0, z:3] began at the same time, while chunk [x:0, z:4] only was loaded and started simulating/ticking later, as it did not receive its redstone signal.

Note

While this experiment uses force loaded chunks to show that chunks of persisted tickets start ticking later than e.g. the spawn chunk, the unexpected behavior was originally observed with chunks loaded by a portal. The experiment uses force loaded chunks for simplicity, but the implications for portal-based chunk loaders are likely more interesting to players.

A general protection against the issue described here is to contain technical systems within a single chunk, but for large contraptions, e.g. some encoded storage tech, this is not possible.