Talk:Chunk format

1.13 chunk format changes
In 1.13 the Sections-Tag changes to this (BlockStates is a long array tag, but there is not yet a symbol for it in the wiki):


 * : List of Compound tags, each tag is a sub-chunk of sorts.
 * An individual Section.
 * : The Y index (not coordinate) of this section. Range 0 to 15 (bottom to top), with no duplicates but some sections may be missing if empty.
 * : Encodes the id-values from the Palette-Tag. The id-value is equal to the index of the palette entry. One long value might store multiple block ids at once, if possible. The minimum storage unit per block is 4 bit. One section always stores 16*16*16 = 4096 blocks, therefore the amount of bits per block can be calculated like that: size of BlockStates-Tag * 64 / 4096 (64 = bit of a long value). Since you can only have 4096 blocks in a section + the entry for air which is always there, the most that can be used is 2 byte = 16 bit per block.
 * : List of block states that exist in the section (first value is always air, even if there is no air in the section). Index-values are used in the BlockStates-Tag
 * : Block-ID-name of the block
 * : Only for blocks that have different states. Properties of the block state
 * : The value of the block state property.
 * : 2048 bytes recording the amount of block-emitted light in each block. Makes load times faster compared to recomputing at load time. 4 bits per block.
 * : 2048 bytes recording the amount of sunlight or moonlight hitting each block. 4 bits per block.
 * : 2048 bytes recording the amount of sunlight or moonlight hitting each block. 4 bits per block.

This is based on region file data I read using a custom program. --NeunEinser (talk) 20:49, 22 November 2017 (UTC)
 * Thanks, I was looking for this since it's not really documented anywhere else -- so has the chunk Version field changed with 1.13? ExtremeHeat11 (talk) 06:48, 19 February 2018 (UTC)

Removal of most entity data
I've noticed that the expansion areas for specific entities has been removed, and no replacement location for that information has been made available. This information is incredibly useful for map makers and the like, and certainly belongs somewhere on this wiki. I felt this page was an acceptable place for it, but apparently others disagree. Have plans been made to move this information elsewhere? and if so, where? Firebastard (talk) 01:51, 14 June 2018 (UTC)

Further information about BlockState format
I've just finished writing my own save file decoder (I know, it's been done, but half the fun is doing it myself).

Important information about the BlockState array that wasn't documented:


 * To recover the bitstream, process each of the uint64 values in _little_ endian order.
 * To assemble tokens from the bitstream, interpret each block of N bits in the stream in _little_ endian order.

This threw me, because most of the save file uses big-endian values, but I was getting corruption otherwise.

Relevant pieces of one Section from my 1.13 test save:

(palette entries 0x00 through 0x1d are valid): 0x00 - air 0x01 - netherrack 0x02 - magma ...

(first couple of words of BlockState, spaces added for clarity): 0x 1084 4201 8410 8400 0x 4210 8420 8400 0842 ...

Grouping the first word's binary data little-endian: (last) (0001) 00001 00001 00010 00010 00010 00010 00010 00001 00001 00001 00000 00000 (first)

...Getting air and netherrack and magma. Going through the rest of the Section gets more of the same.

Grouping the first word's binary data big-endian: (first) 00010 00010 00010 00100 00100 00100 00100 00100 00010 00010 00010 00000 (0000) (last)

...Getting air and magma and unexpected material. Alignment goes off by an extra bit with every new uint64 processed, so the Section ends up as a scrambled hash of unusual materials (and sometimes invalid palette entries).

I do not plan to get a login on this wiki any time soon. If anyone wants to fold in relevant parts of this material, go for it. Knowing about the endianness ahead of time would have really helped.

--107.142.102.195 22:37, 7 October 2018 (UTC)

Arrow OwnerUUIDLeast+Most
Can someone please point me to what I need to edit to add OwnerUUIDLeast and OwnerUUIDMost to the arrow NBT tree? And does someone know when they were added? Fabian42 (talk) 14:00, 2 August 2019 (UTC)
 * Similarly, to remove xTile, yTile and zTile from arrows, they apparently don't exist anymore. Fabian42 (talk) 11:50, 15 August 2019 (UTC)

1.15 biome tag array
The new biome tag layout seems to be missing information. From the chunks I've looked at, it's the same 16 values repeated 256 times. This is even less data than the original 256 integers previously. Is there more information hidden away somewhere else now?

73.51.11.196 20:29, 2 October 2019 (UTC)


 * The biome array no longer stores each x/y's biome ID, instead it's per 4x4x4 blocks. The overworld currently doesn't support the y axis biomes, but the nether does (no clue about the end).
 * The smooth curves of the biomes is no longer saved, and instead is done via an algorithem while the game runs. FVbico (talk) 08:30, 3 October 2019 (UTC)


 * Thanks. That's pretty freaking wild. Looks like there will be a decent amount of work to make this look nice in the Overviewer. 73.51.11.196 05:10, 4 October 2019 (UTC)

xPos/zPos coordinates system
When positions are specified in the NBT data for a chunk: xPos: X position of the chunk. zPos: Z position of the chunk

... are they supposed to be relative to the chunk origin (e.g: in the 0-31 range), or are they supposed to be absolute positions expressed in the world coordinate system?

-- Sylvain 80.67.177.9 17:55, 29 October 2019 (UTC)