mojira.dev
MC-279119

Reducing height of dimension resets existing chunks, rather than preserving area

With MC-276585 (discovered while testing!) having been in full releases, before getting fixed (resolution still pending), map makers were forced to increase world height in worlds that previously were less than 384 blocks high.
Now that it got fixed, a new problem becomes visible. Any world which has its height increased simply adds new empty chunk sections above/below existing chunk sections, but any world which has its height decreased resets the whole chunk.
This makes it so that any map which was forced to increase height can no longer go back to the original height it had.

Steps to reproduce:

  1. Install the data pack named "Extra Height.zip" in the attachments

  2. Open the world

  3. Use /execute in custom:test_dimension run teleport @s 0 15 0

  4. Build a structure you can recognize

  5. Close the world

  6. Install the data pack named "Less Height.zip" in the attachments

  7. Open the world

  8. Look for the structure you build.

Expected behavior

If the max Y is reduced, chunk sections on the top of the world would be removed until the new max Y.
If the min Y is increased, chunk sections on the bottom of the world would be removed until the new min Y.
Just like how increasing height just adds empty chunk sections to the same parts on the inverse cases.

Actual behavior

The entire chunk column is reset, removing anything build in the area that is expected to still exist.
The game log shows tons of exceptions being thrown, followed by chunk debug files being created (example (of the first world I noticed this behavior in) is attached).

[14:27:50] [Server thread/ERROR]: Failed to load chunk 291,-5
java.lang.ArrayIndexOutOfBoundsException: Index 16 out of bounds for length 16
	at dyt.a(SourceFile:386) ~[server-1.21.4.jar:?]
	at dyt.a(SourceFile:304) ~[server-1.21.4.jar:?]
	at eao.a(SourceFile:328) ~[server-1.21.4.jar:?]
	at aqi.a(SourceFile:591) ~[server-1.21.4.jar:?]
	at java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:646) ~[?:?]
	at java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:482) ~[?:?]
	at bra.d(SourceFile:164) ~[server-1.21.4.jar:?]
	at ara$b.d(SourceFile:602) ~[server-1.21.4.jar:?]
	at bra.B(SourceFile:138) ~[server-1.21.4.jar:?]
	at ara$b.B(SourceFile:611) ~[server-1.21.4.jar:?]
	at ara.d(SourceFile:277) ~[server-1.21.4.jar:?]
	at net.minecraft.server.MinecraftServer.bv(SourceFile:877) ~[server-1.21.4.jar:?]
	at net.minecraft.server.MinecraftServer.B(SourceFile:865) ~[server-1.21.4.jar:?]
	at bra.bA(SourceFile:123) ~[server-1.21.4.jar:?]
	at net.minecraft.server.MinecraftServer.x_(SourceFile:833) ~[server-1.21.4.jar:?]
	at net.minecraft.server.MinecraftServer.y(SourceFile:719) ~[server-1.21.4.jar:?]
	at net.minecraft.server.MinecraftServer.a(SourceFile:292) ~[server-1.21.4.jar:?]
	at java.base/java.lang.Thread.run(Thread.java:1570) [?:?]

Linked issues

Attachments

Comments 4

Can confirm:

[media][media]

And by extension, you also confirmed MC-276585 got fixed. 🙂 

This issue and MC-276585 will alternate in presence between snapshots and full releases - we try to be more strict with catching crashes in full releases. As they’re the same underlying issue, can they be merged back into the original issue? Thanks!

Why will it alternate between crashing and not crashing? The crashing is fixed now, right? So wouldn't it be better to keep that crash fix in the snapshots, making this the only issue? 

Dhranios

(Unassigned)

Community Consensus

Custom Worlds, Data Packs

1.21.4

Retrieved