When reloading an area the order in which the present tile entities get processed may change.
In cases where players rely on the order, this might lead to unexpected behaviour.
There are currently two known examples for this:
Blocks moved by pistons
Hoppers
Reproduce
The the easiest way to reproduce it is by checking the order with command blocks.
In the case of hoppers, this can be done by reading the inventory of several hopper clocks with a comparator.
For pistons moving redstone blocks works well.
[media] contains a a build to test for both cases.
The order will be printed in chat by the command blocks.
The case of hoppers is tested by a row of hopper clocks, which should all be in order after pasting the build, due to the order the blocks are placed by structure blocks.
When turning the levers on top of the hoppers the command blocks should output in an order from 1 to 6.
After reloading the world this order might (or might not) change. If it changes seems to be dependent on a number of factors, such as the position of the build and the position of other tile entities in the world.
To test it for pistons, a piston needs to be triggered and in a really short period afterwards the world needs to be unloaded.
It can be a bit tricky to get the timing right in this case, but again the order can completely change.
Sometimes the position needs to be changed a few times before it works, or a few other tile entities need to be placed.
Video of both cases: https://youtu.be/8A9RPLdmzBU
Cause
There are two suspected causes:
Depending on the order in which chunks load, tile entities in different chunks may change order.
The order in which tile entities are saved seems to be dependent on a hashing order, therefore tile entities inside the same chunk also may get mixed.
Linked issues
is duplicated by 1
relates to 3
Attachments
Comments 6
Yep, the first fix is simply a change from HashMap to LinkedHashMap.
The second fix is simply that the piston tile entity didn't save lastProgress, with the fix it does.
reuploaded the structure file because of MC-197549
Can confirm in 1.17.1. Also relates to MC-74648.
This issue causes a lot of sensitive contraptions to break.
Here is a testing setup to replicate the issue:
To replicate follow these steps:
1. Reset the contraption by the note block labeled Reset (next to a gold block).
2. Test the contraption by clicking the note block (next to the diamond block). Observe the pistons extending, only the pistons in the same row activates.
3. Reload the world. After the reload the pistons no longer behave normally. Their behavior changes by the pistons on random side extending.
4. Resetting the contraption fixes it till the area reloads resulting in the scrambled order again.
Noting that the bug is locational. It appears after reload. It affects more than pistons, all block entity's are affected.
This happens due to order in which ticking block entities get ticked is scrambled upon a chunk reload due to the way they are stored.
This bug affects a lot of redstone contraptions, such as storage systems, flying machines, and basically all contraptions which rely on block entity ticking order, so basically any sensitive contraption.
There is a simple way to fix this issue:
in
```
ChunkAccess.java
```
The fix is in done by changing the hash map to a linked hash map
```
protected final Map<BlockPos, BlockEntity> blockEntities = new Object2ObjectOpenHashMap<>();
```
the fix is simply done by changing it to
```
new Object2ObjectLinkedOpenHashMap<>();
```
If I'm reading this right, then the fix for this looks pretty simple.
First check out line 37 of this patch: https://github.com/gnembon/carpetmod112/blob/staging/patches/net/minecraft/world/chunk/Chunk.java.patch
In net/minecraft/world/chunk/Chunk.java, there's a HashSet that needs to be replaced by a LinkedHashSet.
Secondly, search for "pistonSerializationFix" in https://github.com/gnembon/carpetmod112/blob/staging/patches/net/minecraft/tileentity/TileEntityPiston.java.patch
Earthcomputer is the one who fixed it, so maybe if I did an inadequate job here, that will encourage him to add a deeper explanation. 🙂