-
Bug
-
Resolution: Fixed
-
Minecraft 18w15a, Minecraft 18w20c
-
None
-
Confirmed
After doing some more testing on MC-128509, I've found that the updates are not exclusive to portals.
This is a problem because it can lead to things being triggered/broken that shouldn't be.
To reproduce
- Download FloatingSand.zip
, which contains stairs over floating sand in all possible positions. - Load it in Minecraft 1.12.2, and observe the totally legitimate floating sand.
- Load it in Minecraft 18w15a (or another 1.13 snapshot), and observe that some of the sand has fallen (note that on lazy (far away) chunks, it will fall on top of the slab instead of breaking).
Alternatively:
- Download UpdateDetector.zip, which contains a new form of update detector.
- Load it in 1.12.2, and observe that nothing has exploded.
- Load it in 1.13, and observe an explosion.
Blocks
The following blocks are known to do it:
- Stairs (all varieties)
- Cobblestone walls
- Fence gates
- Glass panes
- Vines
- Redstone
- Redstone Repeaters
- Fire
- Tripwire
- Chests
The following blocks are known not to do it:
- Stone
- Anvils
- Carpet
- Ladders
- Banners (only tested floor)
- Signs (both wall and floor)
- Doors
- Leaves
- End rods
- Buttons
- Observers
- Daylight detector
- Trapdoors
- Droppers
The pattern
This only happens for blocks on chunk borders. The blocks that are updated vary by the position: if it's on the edge of a chunk, all blocks on that edge (for all Y values) are updated; if it's on the corner all blocks on that corner are updated. Blocks not on an edge/corner are not updated at all.
Call stacks
Obtained via JDB; these are copied from MC-128509.
Obf, as found in 18w15a:
> stop at bct:109 Set breakpoint bct:109 > Breakpoint hit: "thread=Server thread", bct.a(), line=109 bci=0 Server thread[1] where [1] bct.a (SourceFile:109) [2] bhj.a (SourceFile:244) [3] bjc$b$1.a (SourceFile:210) [4] bjc.a (SourceFile:155) [5] bjc.a (SourceFile:147) [6] bjc.a (SourceFile:58) [7] biv.B (SourceFile:1,043) [8] biv$$Lambda$905.848302274.run (null) [9] java.util.concurrent.Executors$RunnableAdapter.call (Executors.java:511) [10] java.util.concurrent.FutureTask.run (FutureTask.java:266) [11] k.a (SourceFile:146) [12] net.minecraft.server.MinecraftServer.w (SourceFile:671) [13] net.minecraft.server.MinecraftServer.v (SourceFile:627) [14] dal.v (SourceFile:155) [15] net.minecraft.server.MinecraftServer.run (SourceFile:532) [16] java.lang.Thread.run (Thread.java:748)
And as found in 18w14b:
> stop at bcj:109 Set breakpoint bcj:109 > Breakpoint hit: "thread=WorldGen-Worker-3", bcj.a(), line=109 bci=0 WorldGen-Worker-3[1] where [1] bcj.a (SourceFile:109) [2] bgy.a (SourceFile:244) [3] bir$b$1.a (SourceFile:210) [4] bir.a (SourceFile:155) [5] bir.a (SourceFile:147) [6] bir.a (SourceFile:58) [7] bik.B (SourceFile:1,044) [8] bik.G (SourceFile:1,148) [9] se.a (SourceFile:33) [10] se.put (SourceFile:11) [11] it.unimi.dsi.fastutil.longs.Long2ObjectMaps$SynchronizedMap.put (Long2ObjectMaps.java:371) [12] sg.a (SourceFile:207) [13] sg$$Lambda$937.1969878285.apply (null) [14] java.util.concurrent.CompletableFuture.uniApply (CompletableFuture.java:602) [15] java.util.concurrent.CompletableFuture$UniApply.tryFire (CompletableFuture.java:577) [16] java.util.concurrent.CompletableFuture.postComplete (CompletableFuture.java:474) [17] java.util.concurrent.CompletableFuture.postFire (CompletableFuture.java:561) [18] java.util.concurrent.CompletableFuture$UniCompose.tryFire (CompletableFuture.java:929) [19] java.util.concurrent.CompletableFuture$Completion.exec (CompletableFuture.java:443) [20] java.util.concurrent.ForkJoinTask.doExec (ForkJoinTask.java:289) [21] java.util.concurrent.ForkJoinPool$WorkQueue.runTask (ForkJoinPool.java:1,056) [22] java.util.concurrent.ForkJoinPool.runWorker (ForkJoinPool.java:1,692) [23] java.util.concurrent.ForkJoinWorkerThread.run (ForkJoinWorkerThread.java:157)
Notes
The first affected snapshot is 17w47b (probably a is affected too; 17w46a is not), which was the snapshot that introduced the flattening.