When using a structure whose pieces are using “terrain_matching”, the expected behavior is that the piece will use the WORLD_SURFACE_WG heightmap which ignores other structures and features in the generating chunk. For the most part, this works as expected as seen with village roads.
However, if a user exits a world or reverses direction so the chunks are unloaded and saved into world’s save, re-entering that world o going back will load the chunks back from the save but the WORLD_SURFACE_WG heightmap is now incorrectly set to the same value that WORLD_SURFACE is. This leads to village roads or other terrain matching structure pieces to not conform to trees and other features that should not be matching on top of.
To reproduce:
Put on the heightmap_bug.zip datapack. In the world, there is a yellow concrete layer at y = 110 placed by the structure and a red concrete layer that is set to be terrain matching.
If you explore the world in a straight line, the red concrete layer never terrain matches onto the yellow concrete which is expected.
Now exit the world, let it save, and then re-enter the world.
Continue flying and you will see a bunch of chunks where the red concrete terrain matched onto the yellow concrete.
It appears that in the process of chunk saving or loading from the save, the WORLD_SURFACE_WG heightmap was updated to include the yellow concrete layer when it should not have done so. The issue is highly reproducible with the provided datapack that created the perfect conditions to easily see this. However, the issue impact all terrain matching structures including villages. If you make a datapack that makes villages spawn in most chunks, leave world, and re-enter, you will see cases of roads being on top of trees or perhaps even houses.
Attachments
Comments 2
After digging through the code some more, the issue appears to be that the CARVERS and FEATURES ChunkStatus are set to FINAL_HEIGHTMAPS EnumSet to specify what heightmaps to update for that status and also to persists to disk for the chunk if the chunk unloads and read from the chunk later.
However, if the chunk never unloads, the chunk will continue to hold the WORLD_SURFACE_WG heightmap in memory (frozen in state because it does not get updated anymore due to not being in the chunkstatus’s EnumSet anymore) and the entirety of Feature and Structure generation is relying on this undefined behavior.
Thus when the CARVERS ChunkStatus chunk unloads, the WORLD_SURFACE_WG heightmap is erased from memory and not saved to disk either. Thus when chunk is loaded again, the heightmap snapping code defaults to the non-worldgen heightmaps that were previously being updated to include features and structure block placements. Which then causes Village roads on tree.
Yep, worldgen is literally built upon non-persistent worldgen heightmap memory state. A possible fix could be to make SerializableChunkData save and read all available heightmaps present if the chunk is not a FULL ChunkStatus chunk.
Datapack to use and photo of issue. Had to made it separate due to Jira not working properly with initial submission