MC-123692TileTicks upgrader could cause update for unintended block
The bug
Based on 17w50a decompiled using CFR 0_119
It appears the TileTicks upgrader (method b(fm) of the static inner class vt.b) determines the block id of the block to update based on the block at this position. Due to MC-108726 this could cause updates to blocks which did not have an update scheduled before.
The block ids of TileTicks entries could likely be directly updated since there is probably no case where the block id has to determined based on blockstate properties, NBT data or surrounding blocks.
How to reproduce
How to reproduce
- Download this world and put it in .minecraft/saves.
- Load the world in the latest version.
- Teleport to 0, 0.
/teleport 0 ~ 2
→
The dispenser is activated and shoots out the stone item
Attachments1
Created Issue:
TileTicks upgrader could cause update for intended block
The bug
Based on 17w50a decompiled using CFR 0_119
It appears the TileTicks upgrader (method b(fm) of the static inner class vt.b) determines the block id of the block to update based on the block at this position. Due to MC-108726 this could cause updates to blocks which did not have an update scheduled before.
The block ids of TileTicks entries could likely be directly updated since there is probably no case where the block id has to determined based on blockstate properties, NBT data or surrounding blocks.
The bug
Based on 17w50a decompiled using CFR 0_119
It appears the TileTicks upgrader (method b(fm) of the static inner class vt.b) determines the block id of the block to update based on the block at this position. Due to MC-108726 this could cause updates to blocks which did not have an update scheduled before.
The block ids of TileTicks entries could likely be directly updated since there is probably no case where the block id has to determined based on blockstate properties, NBT data or surrounding blocks.
How to reproduce
- Create a superflat world with the following preset in 1.12.2
3;minecraft:sandstone;127;- Set the render distance to 6
- Run the following commands
/setworldspawn 100000 0 0 /teleport @s 0 ~ 0 /setblock 0 1 0 command_block facing=south replace {Command:"/teleport @p 100000 ~ 0"} /setblock 0 2 0 wooden_button facing=up /setblock 0 1 1 chain_command_block facing=south replace {auto:1b,Command:"/setblock 0 2 0 dispenser facing=up replace {Items:[{Slot:0b,id:\"stone\",Count:1b}]}"}- Press the button
- Close the world
- Open the world in the latest version
- Teleport to 0, 0
/teleport 0 ~ 0→
The bug
Based on 17w50a decompiled using CFR 0_119
It appears the TileTicks upgrader (method b(fm) of the static inner class vt.b) determines the block id of the block to update based on the block at this position. Due to MC-108726 this could cause updates to blocks which did not have an update scheduled before.
The block ids of TileTicks entries could likely be directly updated since there is probably no case where the block id has to determined based on blockstate properties, NBT data or surrounding blocks.
How to reproduce
- Create a superflat world with the following preset in 1.12.2
3;minecraft:sandstone;127;- Set the render distance to 6
- Run the following commands
/setworldspawn 100000 0 0 /teleport @s 0 ~ 0 /setblock 0 1 0 command_block facing=south replace {Command:"/teleport @p 100000 ~ 0"} /setblock 0 2 0 wooden_button facing=up /setblock 0 1 1 chain_command_block facing=south replace {auto:1b,Command:"/setblock 0 2 0 dispenser facing=up replace {Items:[{Slot:0b,id:\"stone\",Count:1b}]}"}- Press the button
- Close the world
- Open the world in the latest version
- Teleport to 0, 0
/teleport 0 ~ 0→
TileTicks upgrader could cause update for unintended block
![[Mod] violine1101](../../../data/avatars/users/92858.png){kind=small}
![[Mojang] Adrian Östergård](../../../data/assets/gravatar/nighter.jpeg){kind=small}
![[Mojang] Grum (Erik Broes)](../../../data/assets/gravatar/grum.png){kind=small}
[Mojang] Grum (Erik Broes)![[Mojang] Nathan Adams](../../../data/assets/gravatar/dinnerbone.png){kind=small}
[Mojang] Grum (Erik Broes)![[Mod] Greymagic27](../../../data/avatars/users/92875.png){kind=small}
![[Mod] NeunEinser](../../../data/avatars/users/39263.png){kind=small}
The bug
Based on 17w50a decompiled using CFR 0_119
It appears the TileTicks upgrader (method b(fm) of the static inner class vt.b) determines the block id of the block to update based on the block at this position. Due to MC-108726 this could cause updates to blocks which did not have an update scheduled before.
The block ids of TileTicks entries could likely be directly updated since there is probably no case where the block id has to determined based on blockstate properties, NBT data or surrounding blocks.
How to reproduce
- Create a superflat world with the following preset in 1.12.2
3;minecraft:sandstone;127;- Set the render distance to 6
Run the following commands/setworldspawn 100000 0 0 /teleport @s 0 ~ 0 /setblock 0 1 0 command_block facing=south replace {Command:"/teleport @p 100000 ~ 0"} /setblock 0 2 0 wooden_button facing=up /setblock 0 1 1 chain_command_block facing=south replace {auto:1b,Command:"/setblock 0 2 0 dispenser facing=up replace {Items:[{Slot:0b,id:\"stone\",Count:1b}]}"}Press the button- Close the world
- Open the world in the latest version
- Teleport to 0, 0
/teleport 0 ~0→
The bug
Based on 17w50a decompiled using CFR 0_119
It appears the TileTicks upgrader (method b(fm) of the static inner class vt.b) determines the block id of the block to update based on the block at this position. Due to MC-108726 this could cause updates to blocks which did not have an update scheduled before.
The block ids of TileTicks entries could likely be directly updated since there is probably no case where the block id has to determined based on blockstate properties, NBT data or surrounding blocks.
How to reproduce
How to reproduce
- Download this world and put it in .minecraft/saves.
- Load the world in the latest version.
- Teleport to 0, 0.
/teleport 0 ~ 2→
![[Mod] Les3awe](../../../data/avatars/users/79847.png){kind=small}
![[Mod] ManosSef](../../../data/avatars/users/61702.png){kind=small}
![[Mod] redstonehelper](../../../data/avatars/users/10122.svg){kind=small}
To reproduce
- Create a world in 1.12.2
- Place a line of repeaters, maybe 10 long, and a button to activate it
- Press the button
- Pause the game when the line of repeaters is halfway activated
- Save and quit to title
- Open the world in 17w50a
→ The repeater line is stuck in the middle
Code analysis
Based on 17w50a decompiled using CFR 0_119
It looks like the method b(fm) of the static inner class vt.b tries to upgrade the TileTicks of a chunk based on the block at the location of the tile tick (see MC-123692). The position is encoded to y << 8 | z << 4 | x and passed to the method vt.b.a(int). It appears the person who write this assumed the position is an offset in the chunk, but it is the position in the world. This means any scheduled update not inside (0, 0, 0) → (15, 15, 15) (all values inclusive) can be lost.
Can confirm in 1.17.1.