World generation sometimes adds block ids wrongly into chunk section palettes, usually resulting in 16^3 blocks almost full of one block type or block types being exchanged within the chunk section. This happens very rarely and usually doesn't happen again (in the same place) when regenerating the world. Note that, for the few ❓ users affected, this happens relatively frequently.
Affected world downloads:
Description | Download link | Source | Location | Notes |
---|---|---|---|---|
Leaves replacing air |
| - | ||
Logs replacing air, leaves replacing air |
| Two chunk sections close to each other are affected | ||
Logs replacing air |
| - | ||
Multiple blocks are switched up in a village | Walk to 181 75 102 | More than one mixup in a single chunk section | ||
Stone replacing air |
| - | ||
Red coral blocks replacing water |
| Some blocks mined out by user | ||
Granite replacing air |
| - | ||
Stone brick stairs replacing water |
| - |
From the original description:
Weirdly I actually broke a whole row of the blocks. on the top of the wood block on the edge and that was even the still image for the world but when I loaded it back in the blocks were there like I had done nothing.
Blocks you break around the giant blocks of blocks stay the same,
If I just punch the blocks to break them I cannot enter the space where the block disappears from. In general I cant seem to break the blocks myself because if i leave the area and the chunk loads back in (or save and quit then return), the blocks are still there. Only by natural decay methods does it seem to get rid of them.
Linked issues
is duplicated by 37
relates to 1
Attachments
Comments 31
Couldn't find even a single chunk of missing leaves/trees, or a full chunk section of leaves. Can you two please force a crash by pressing F3 C for 10 seconds while in-game and attach the crash report ([minecraft/crash-reports/crash-<DATE>-client.txt|http://hopper.minecraft.net/help/guides/finding-minecraft-data-folder]
) here?
edit: did you maybe restart the game while one of the chunks was generating?
Sure. But also like I said the best way to re-create it is to generate a random new world and look around for it.
If you load the seed or re-create the world you wont find the same error generated in the same places or even at all.
edit: No I didn't I looked around some worlds for a good solid 10-20 minutes sometimes before finding a missing gap or giant chunk of leaves.
To me it looks like a sudden math error with tree and forest generation as the game attempts to properly load that chunk and it either dumps a bunch of blocks in that its supposed to or none at all; and then if you remake the world it doesn't always meet that generation math error and it can generate as it is supposed to.
I have taken a look at two affected chunk sections and found they have some common features.
It helps to understand how 1.13 saves chunk data. Chunk data are saved in Sections. These Sections store the blocks in a Palette which describes the blocks, and index into the Palette with an array of Long called BlockStates that can vary in size with a minimum size of 256 (corresponding to a Palette size of 16). These sections also have other data.
In chunks with this corruption, the Palette appears normal. The BlockStates array is corrupted. The BlockStates array has many repeats of the value "1". Sometimes this fills the entire BlockStates array, other times other values are present but the value "1" dominates.
In a corrupted BlockStates array I examined with 27 entries in the Palette, the first two Longs look like this:
{color:red}21{color} 84 10 42 08 21 84 10
42 08 21 84 10 42 08 21
To decode this, reverse the hex values (little endian order), convert to binary and take five bits at a time:10 84 21 08 42 10 84 {color:red}21{color}
...(8 values)
0100 0010 0001 0000 1000 0100 0010 0001
...01 00001 00001 00001 00001 00001 00001
...-- ----- ----- ----- ----- ----- 00001
= 00001
...-- ----- ----- ----- ----- 00001 -----
= 00001
...-- ----- ----- ----- 00001 ----- -----
= 00001
etc.
The whole array has repeats of the sequence 21 84 10 42 08
which means it is filled with the value 00001
.
The other array I examined had other values as well but the value 1 dominated.
It looks like the value "1" is used to initialise the array and then the array is populated with the correct values. It looks like the population of the array occasionally terminates before completion leading to the corruption.
at some point i got confused about what version I was using so I edited that out.