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)