Difference between revisions of "Map Format"

From wiki.vg
Jump to navigation Jump to search
m (Updated Minecraft version)
m (Updated biomes info and link do new minecraft wiki)
 
(21 intermediate revisions by 11 users not shown)
Line 1: Line 1:
This page covers the world information as of 1.2.5 through 1.3.2.  See [[Alpha Map Format]] for Alpha information.
+
This page covers the world information as of 1.2.5 to the present.  See [[Alpha Map Format]] for Alpha information.
 +
 
 +
<!--Page may be outdated, since new versions changed how the world is generated-->
 +
 
 +
{{Box
 +
  |BORDER = #BF880D
 +
  |BACKGROUND = #F7B217
 +
  |WIDTH = 100%
 +
  |ICON =
 +
  |HEADING = Heads up!
 +
  |CONTENT = Some information in this article may be outdated due to the new world generation introduced in the 1.17 update.
 +
}}
  
 
==General Information==
 
==General Information==
Worlds are represented as a series of regions, within which are a number of columns, and chunks.  Each region is 32x1x32 columns, each column is 1x16x1 chunks, and each chunk is 16x16x16 blocks.  The overall block height of a column is 256.  Each chunk stores four (or five) things - block IDs (8-bit), block metadata (4-bit), block light (4-bit), and sky light (4-bit).  The optional fifth value is "add" data, which is four bits to be added to block IDs for additional block ID support (not used in vanilla Minecraft).  Block light is light cast by things like torches and glowstone, and is calculated with a 3D [http://en.wikipedia.org/wiki/Flood_fill Flood Fill] algorithm.  Sky light is the light cast by the sky, and is calculated by starting at the top and working your way down.  As you pass through semi-transparent blocks, you decrease the lighting value until you hit an opaque block.  The opaque block is the last block whose skylight has a nonzero value.  Lighting starts at 0xF (brightest) and works down to 0x0 (dimmest).  Columns store biome information.  Each 1x256x1 cuboid of blocks has the same biome value, for a total of 256 possible biome values per chunk (16x16).  Biome values are stored as bytes.
+
Worlds are represented as a series of regions, within which are a number of columns, and chunks.  Each region is 32x1x32 columns, each column is 1x16x1 chunks, and each chunk is 16x16x16 blocks.  The overall block height of a column is 384.  Each chunk stores four (or five) things - block IDs (8-bit), block metadata (4-bit), block light (4-bit), and sky light (4-bit).  The optional fifth value is "add" data, which is four bits to be added to block IDs for additional block ID support (not used in vanilla Minecraft).  Block light is light cast by things like torches and glowstone, and is calculated with a 3D [http://en.wikipedia.org/wiki/Flood_fill Flood Fill] algorithm.  Sky light is the light cast by the sky, and is calculated by starting at the top and working your way down.  As you pass through semi-transparent blocks, you decrease the lighting value until you hit an opaque block.  The opaque block is the last block whose skylight has a nonzero value.  Lighting starts at 0xF (brightest) and works down to 0x0 (dimmest).  Columns store biome information.  Each 1x256x1 cuboid of blocks has the same biome value, for a total of 256 possible biome values per chunk (16x16).  Biome values are stored as bytes.
  
 
===Biome Values===
 
===Biome Values===
  
{| class="wikitable"
+
As of 1.20.6 there are 64 unique biomes (53 for the Overworld, 5 for the Nether, 5 for the End, and <code>minecraft:the_void</code>).
|-
+
{{Minecraft Wiki|Biome#Biome_IDs|Here}} you can find a mapping of biome to its respective numerical ID.
! Name
 
! Value
 
|-
 
| Ocean
 
| 0
 
|-
 
| Plains
 
| 1
 
|-
 
| Desert
 
| 2
 
|-
 
| Extreme Hills
 
| 3
 
|-
 
| Forest
 
| 4
 
|-
 
| Taiga
 
| 5
 
|-
 
| Swampland
 
| 6
 
|-
 
| River
 
| 7
 
|-
 
| Hell
 
| 8
 
|-
 
| Sky
 
| 9
 
|-
 
| Frozen Ocean
 
| 10
 
|-
 
| Frozen River
 
| 11
 
|-
 
| Ice Plains
 
| 12
 
|-
 
| Ice Mountains
 
| 13
 
|-
 
| Mushroom Island
 
| 14
 
|-
 
| Mushroom Island Shore
 
| 15
 
|-
 
| Beach
 
| 16
 
|-
 
| Desert Hills
 
| 17
 
|-
 
| Forest Hills
 
| 18
 
|-
 
| Taiga Hills
 
| 19
 
|-
 
| Extreme Hills Edge
 
| 20
 
|-
 
| Jungle
 
| 21
 
|-
 
| Jungle Hills
 
| 22
 
|}
 
 
 
==Protocol==
 
 
 
[https://gist.github.com/2164987 Here] is a dump of 1.2.5 world-related packets.
 
 
 
[[Protocol#0x32|Here]] and [[Protocol#0x33|here]] is the relevant documentation.
 
 
 
For sending map packets to a client, all of the above information is required.  Even though lighting is sent to the client, the vanilla client will calculate lighting itself.  For distant areas, the client's value is used.  For the immediate surroundings, the value provided by the server is used.  If a custom server has not properly implemented lighting yet, setting all block light and sky light values to 0xF will not cause client lag, where other values are likely to cause significant lag.
 
 
 
The map is sent a column at a time.  Initialize each column with a [[Protocol#0x32|map column allocation packet (0x32)]]  The entire column need not be sent; only the chunks that are not completely air are actually sent.  If your column is representative of all chunks from Y=0 to Y=255, you should set "ground-up continuous" to true.  This holds true even if you omit several packets because they are completely air.  If you omit chunks that are not completely air, set this value to false.
 
 
 
The chunks that you do choose to send are specified via the primay bit-map.  You specify chunks from the bottom up, starting at Y=0.  The primary [http://en.wikipedia.org/wiki/Bit_array bit-map's] first bit (representing the lowermost chunk) is the least significant bit.  This assumes that you use little-endian and reverse the endianness when sending the value to a client.  The add bit-map is the same, but you should only include it for chunks whose block IDs require the additional information.
 
 
 
What follows the bit-maps is compressed data.  First, an integer representing the total size of the compressed data, followed by an unused int.  The compressed data is a concatenated array of raw chunk data, followed by biome data.  For each chunk included in the primary bit-map, concat the following information into a byte array:
 
 
 
* Block type array (1 byte per block, 4096 bytes per chunk)
 
* Block metadata array (half byte per block, 2048 bytes per chunk)
 
* Block light array (half byte per block, 2048 bytes per chunk)
 
* Sky light array (half byte per block, 2048 bytes per chunk)
 
* Add array (half byte per block, 2048 bytes per chunk)
 
 
 
Only include the add array if that particular chunk is represented in the add bit-map.  After all the chunks have been concatenated in this manner, and if ground-up continuous is set to true, concat the biome array.
 
  
 
==Storage==
 
==Storage==
Line 135: Line 52:
 
** NBTInt(SpawnZ)
 
** NBTInt(SpawnZ)
 
** NBTInt(thunderTime)
 
** NBTInt(thunderTime)
** NBTInt(version): 19113 for 1.2.5
+
** NBTInt(version): 19133 for 1.2.5
 
** NBTLong(LastPlayed)
 
** NBTLong(LastPlayed)
 
** NBTLong(RandomSeed)
 
** NBTLong(RandomSeed)
Line 141: Line 58:
 
** NBTLong(Time)
 
** NBTLong(Time)
 
** NBTString(generatorName)
 
** NBTString(generatorName)
** NBTString(levelName)
+
** NBTString(LevelName)
  
===[playername].dat===
+
===[playeruuid].dat===
  
Each player that has ever connected is given a [playername].dat file.
+
Each player that has ever connected is given a [playeruuid].dat file.
  
 
* NBTCompound
 
* NBTCompound
Line 177: Line 94:
 
*** NBTDouble
 
*** NBTDouble
 
*** NBTDouble
 
*** NBTDouble
** NBTList(Position)
+
** NBTList(Pos)
 
*** NBTDouble
 
*** NBTDouble
 
*** NBTDouble
 
*** NBTDouble
Line 187: Line 104:
 
===[region].mca===
 
===[region].mca===
  
Each region file is named "r.x.z.mca", where x and z are the coordinates.  These coordinates are relative to each region.  Given column coordinates, divide them by 32 to get the region coordinates.
+
Each region file is named "r.x.z.mca", where x and z are the coordinates.  These coordinates are relative to each region.  Given chunk column coordinates, divide them by 32 to get the region coordinates. [https://wiki.vg/Region_Files Region files] are not raw NBT files and must therefore be parsed differently see [https://wiki.vg/Region_Files Region files].
 +
Every generated chunk has a 5-byte header with the first four bytes as the length of the compressed chunk in bytes and the fifth byte as the compression scheme.
 +
 
 +
{| class="wikitable"
 +
|-
 +
!
 +
!Length of the compressed<br />chunk in bytes
 +
!Compression Scheme
 +
|-
 +
!Decoded
 +
|5033
 +
|zlib
 +
|-
 +
!On Disk(in hex)
 +
| <code>00 13 A9</code>
 +
| <code>02</code>
 +
|}
 +
 
 +
====Compression schemes====
 +
The compression scheme can have four values:
 +
{| class="wikitable"
 +
|-
 +
!Compression<br />Scheme
 +
!Value
 +
|-
 +
|LZ4
 +
|<code>4</code>
 +
|-
 +
|none
 +
|<code>3</code>
 +
|-
 +
|zlib
 +
|<code>2</code>
 +
|-
 +
|gzip
 +
|<code>1</code>
 +
|}
 +
 
 +
The notchian implementation will '''never''' write uncompressed or gzip compressed chunks, but can read if provided.
 +
 
 +
====LZ4 Compression====
 +
LZ4 compressed data is saved using the LZ4BlockOutputStream stream implementation of [https://github.com/lz4/lz4-java lz4-java]. This format is not compatible with the standard LZ4 Frame format.
 +
Block stream data consists of multiple blocks of data, each of which is prepended by a 21 byte header.
 +
 
 +
{| class="wikitable"
 +
|-
 +
|
 +
! Magic
 +
! Token
 +
! Compressed Length
 +
! Decompressed Length
 +
! XXH32 Checksum
 +
|-
 +
! Decoded
 +
| <code>LZ4Block</code>
 +
| <code>38</code>
 +
| <code>489</code>
 +
| <code>2911</code>
 +
| <code>71030836</code>
 +
|-
 +
! On Disk (in hex)
 +
| <code>4C 5A 34 42 6C 6F 63 6B</code>
 +
| <code>26</code>
 +
| <code>E9 01 00 00</code>
 +
| <code>5F 0B 00 00</code>
 +
| <code>34 D8 3B 04</code>
 +
|}
 +
 
 +
=====Token value=====
 +
 
 +
The token field encodes the compression method and compression level for the block:
 +
<pre>
 +
compressionLevelBase = 10;
 +
 
 +
compressionMethod = token & 0xf0;
 +
compressionLevel = compressionLevelBase + (token & 0x0f);
 +
</pre>
 +
 
 +
There are two different compression methods available:
  
* NBTCompound
+
{| class="wikitable"
** NBTCompound(Chunk [x,z]): x and z are region column coordinates, not relative to the overall world.  The compound name is a misnomer, it actually represents column.
+
|-
*** NBTCompound(Level)
+
!Method
**** NBTByte(TerrainPopulated): 1 if this column has been generated
+
!Value
**** NBTInt(xPos): In global, world-relative chunk coordinates
+
|-
**** NBTInt(yPos): In global, world-relative chunk coordinates
+
|Raw/uncompressed
**** NBTLong(LastUpdate): The last time a block changed in this column
+
|<code>0x10</code>
**** NBTByteArray(Biomes)
+
|-
**** NBTList(Entities)
+
|LZ4
***** NBTCompound
+
|<code>0x20</code>
****** NBTByte(OnGround)
+
|}
****** NBTShort(Air)
+
 
****** NBTShort(AttackTime)
+
Uncompressed block should be used if using LZ4 compression would make the block data larger.
****** NBTShort(DeathTime)
+
 
****** NBTShort(Fire)
+
=====Checksum=====
****** NBTShort(Health)
+
 
****** NBTShort(HurtTime)
+
Block checksums use the XXHash32 algorithm with the seed value <code>0x9747b28c</code> [https://github.com/lz4/lz4-java/blob/master/src/java/net/jpountz/xxhash/StreamingXXHash32.java as implemented in lz4-java].
****** NBTFloat(FallDistance)
+
When finalizing the hash value, this implementation [https://github.com/lz4/lz4-java/blob/7c931bef32d179ec3d3286ee71638b23ebde3459/src/java/net/jpountz/xxhash/StreamingXXHash32.java#L106 removes the last nibble from the result], which is something that might need to be done manually when using other implementations.
****** NBTString(id): Example: "Skeleton"
+
 
****** NBTList(Motion)
+
<pre>
******* NBTDouble
+
checksum = xxh32(blockData) & 0xFFFFFFF; //these are seven, not eight, Fs
******* NBTDouble
+
</pre>
******* NBTDouble
+
 
***** NBTList(Pos)
+
===Chunk format===
******* NBTDouble
 
******* NBTDouble
 
******* NBTDouble
 
***** NBTList(Rotation)
 
****** NBTFloat
 
****** NBTFloat
 
**** NBTList(Sections): Chunks
 
***** NBTCompound
 
****** NBTByte(Y): 0-16
 
****** NBTByteArray(BlockLight)
 
****** NBTByteArray(Blocks)
 
****** NBTByteArray(Data)
 
****** NBTByteArray(SkyLight)
 
**** NBTList(TileEntities)
 
***** [http://www.minecraftwiki.net/wiki/Alpha_Level_Format/Chunk_File_Format#Tile_Entity_Format See this]
 
**** NBTIntArray(HeightMap)
 
  
=== See also ===
+
Note: The following example is outdated. It is accurate for (at least) 1.4, but at some point the format has been changed. However, you will still need to support this version if you want reverse compatibility with old save files.
  
[http://wiki.vg/User:Sprenger120 How to read Minecraft mca files]
+
<pre>
 +
TAG_Compound(''): 2 entries
 +
{
 +
  TAG_Compound('Level'): 11 entries
 +
  {
 +
    TAG_List('Entities'): List of entities in the chunk column
 +
    {
 +
      TAG_Compound(): Each entity has a Tag_Compound
 +
      {
 +
        ...
 +
      }
 +
    }
 +
    TAG_List('Sections'): 5 entries
 +
    {
 +
      TAG_Compound(''): 5 entries
 +
      {
 +
        TAG_Byte('Y'): 0
 +
        TAG_Byte_Array('BlockLight'): 2048 bytes
 +
        TAG_Byte_Array('Blocks'): 4096 bytes
 +
        TAG_Byte_Array('Data'): 2048 bytes
 +
        TAG_Byte_Array('SkyLight'): 2048 bytes
 +
      }
 +
      TAG_Compound(''): 5 entries
 +
      {
 +
        TAG_Byte('Y'): 1
 +
        TAG_Byte_Array('BlockLight'): 2048 bytes
 +
        TAG_Byte_Array('Blocks'): 4096 bytes
 +
        TAG_Byte_Array('Data'): 2048 bytes
 +
        TAG_Byte_Array('SkyLight'): 2048 bytes
 +
      }
 +
      ...
 +
    }
 +
    TAG_List('TileEntities'):
 +
    TAG_Long('InhabitedTime'): 16
 +
    TAG_Long('LastUpdate'): Last time a block changed in this column
 +
    TAG_Byte('LightPopulated'): Is the light calculated
 +
    TAG_Byte('TerrainPopulated'): Has the terrain been generated
 +
    TAG_Int('xPos'): X position of the region. Each single increment to x is 512 blocks
 +
    TAG_Int('zPos'): Z position of the region. Each single increment to z is 512 blocks
 +
    TAG_Byte_Array('Biomes'): 256 bytes. Biomes affect blocks in 1x256x1 columns
 +
    TAG_Int_Array('HeightMap'): 256 bytes
 +
  }
 +
  TAG_Int('DataVersion'): 1343
 +
}
 +
</pre>
  
 +
=== See also ===
 +
[https://wiki.vg/Region_Files Region Files]
 +
[https://minecraft.wiki/w/Chunk_format/BlockEntity Block entity format]
 
[[Category:Minecraft_Modern]]
 
[[Category:Minecraft_Modern]]

Latest revision as of 11:34, 30 May 2024

This page covers the world information as of 1.2.5 to the present. See Alpha Map Format for Alpha information.


Heads up!

Some information in this article may be outdated due to the new world generation introduced in the 1.17 update.

General Information

Worlds are represented as a series of regions, within which are a number of columns, and chunks. Each region is 32x1x32 columns, each column is 1x16x1 chunks, and each chunk is 16x16x16 blocks. The overall block height of a column is 384. Each chunk stores four (or five) things - block IDs (8-bit), block metadata (4-bit), block light (4-bit), and sky light (4-bit). The optional fifth value is "add" data, which is four bits to be added to block IDs for additional block ID support (not used in vanilla Minecraft). Block light is light cast by things like torches and glowstone, and is calculated with a 3D Flood Fill algorithm. Sky light is the light cast by the sky, and is calculated by starting at the top and working your way down. As you pass through semi-transparent blocks, you decrease the lighting value until you hit an opaque block. The opaque block is the last block whose skylight has a nonzero value. Lighting starts at 0xF (brightest) and works down to 0x0 (dimmest). Columns store biome information. Each 1x256x1 cuboid of blocks has the same biome value, for a total of 256 possible biome values per chunk (16x16). Biome values are stored as bytes.

Biome Values

As of 1.20.6 there are 64 unique biomes (53 for the Overworld, 5 for the Nether, 5 for the End, and minecraft:the_void). Here you can find a mapping of biome to its respective numerical ID.

Storage

This section documents the Anvil format for servers.

Maps are stored as a specific directory structure with several NBT files within. For the sake of examples, the world we'll be working with is stored in a folder called "/world".

Directory Structure

  • /world/data: Unused
  • /world/DIM-1: Nether world
  • /world/DIM-1/region: Nether world regions
  • /world/DIM1: End world
  • /world/DIM1/region: End world regions
  • /world/players: Player data
  • /world/region: Overworld regions

level.dat

In the root directory is a level.dat file. The structure of that file is this:

  • NBTCompound(Data)
    • NBTByte(hardcore)
    • NBTByte(MapFeatures): Set to 1 if structures are generated, such as villages
    • NBTByte(raining): Set to 1 if currently raining
    • NBTByte(thundering): Set to 1 if currently thundering (only if there is potential for thunder, not if a thunderbolt is currently in progress)
    • NBTInt(GameType)
    • NBTInt(generatorVersion): 0 for 1.2.5
    • NBTInt(rainTime): The ticks remaining until rain stops?
    • NBTInt(SpawnX)
    • NBTInt(SpawnY)
    • NBTInt(SpawnZ)
    • NBTInt(thunderTime)
    • NBTInt(version): 19133 for 1.2.5
    • NBTLong(LastPlayed)
    • NBTLong(RandomSeed)
    • NBTLong(SizeOnDisk): Always 0 for 1.2.5
    • NBTLong(Time)
    • NBTString(generatorName)
    • NBTString(LevelName)

[playeruuid].dat

Each player that has ever connected is given a [playeruuid].dat file.

  • NBTCompound
    • NBTByte(OnGround)
    • NBTByte(Sleeping)
    • NBTShort(Air)
    • NBTShort(AttackTime)
    • NBTShort(DeathTime)
    • NBTShort(Fire): Ticks until the player is no longer on fire, or zero
    • NBTShort(Health)
    • NBTShort(HurtTime)
    • NBTShort(SleepTimer)
    • NBTInt(Dimension)
    • NBTInt(foodLevel)
    • NBTInt(foodTickTimer)
    • NBTInt(playerGameType)
    • NBTInt(XpLevel)
    • NBTInt(XpTotal)
    • NBTFloat(FallDistance)
    • NBTFloat(foodExhastionLevel)
    • NBTFloat(foodSaturationLevel)
    • NBTFloat(XpP)
    • NBTCompound(Inventory)
      • NBTCompound
        • NBTByte(Count)
        • NBTByte(Slot)
        • NBTShort(Damage): Damage -or- metadata
        • NBTShort(id)
    • NBTList(Motion)
      • NBTDouble
      • NBTDouble
      • NBTDouble
    • NBTList(Pos)
      • NBTDouble
      • NBTDouble
      • NBTDouble
    • NBTList(Rotation)
      • NBTFloat
      • NBTFloat

[region].mca

Each region file is named "r.x.z.mca", where x and z are the coordinates. These coordinates are relative to each region. Given chunk column coordinates, divide them by 32 to get the region coordinates. Region files are not raw NBT files and must therefore be parsed differently see Region files. Every generated chunk has a 5-byte header with the first four bytes as the length of the compressed chunk in bytes and the fifth byte as the compression scheme.

Length of the compressed
chunk in bytes
Compression Scheme
Decoded 5033 zlib
On Disk(in hex) 00 13 A9 02

Compression schemes

The compression scheme can have four values:

Compression
Scheme
Value
LZ4 4
none 3
zlib 2
gzip 1

The notchian implementation will never write uncompressed or gzip compressed chunks, but can read if provided.

LZ4 Compression

LZ4 compressed data is saved using the LZ4BlockOutputStream stream implementation of lz4-java. This format is not compatible with the standard LZ4 Frame format. Block stream data consists of multiple blocks of data, each of which is prepended by a 21 byte header.

Magic Token Compressed Length Decompressed Length XXH32 Checksum
Decoded LZ4Block 38 489 2911 71030836
On Disk (in hex) 4C 5A 34 42 6C 6F 63 6B 26 E9 01 00 00 5F 0B 00 00 34 D8 3B 04
Token value

The token field encodes the compression method and compression level for the block:

compressionLevelBase = 10;

compressionMethod = token & 0xf0;
compressionLevel = compressionLevelBase + (token & 0x0f);

There are two different compression methods available:

Method Value
Raw/uncompressed 0x10
LZ4 0x20

Uncompressed block should be used if using LZ4 compression would make the block data larger.

Checksum

Block checksums use the XXHash32 algorithm with the seed value 0x9747b28c as implemented in lz4-java. When finalizing the hash value, this implementation removes the last nibble from the result, which is something that might need to be done manually when using other implementations.

checksum = xxh32(blockData) & 0xFFFFFFF; //these are seven, not eight, Fs

Chunk format

Note: The following example is outdated. It is accurate for (at least) 1.4, but at some point the format has been changed. However, you will still need to support this version if you want reverse compatibility with old save files.

TAG_Compound(''): 2 entries
{
  TAG_Compound('Level'): 11 entries
  {
    TAG_List('Entities'): List of entities in the chunk column
    {
      TAG_Compound(): Each entity has a Tag_Compound
      {
        ...
      }
    }
    TAG_List('Sections'): 5 entries
    {
      TAG_Compound(''): 5 entries
      {
        TAG_Byte('Y'): 0
        TAG_Byte_Array('BlockLight'): 2048 bytes
        TAG_Byte_Array('Blocks'): 4096 bytes
        TAG_Byte_Array('Data'): 2048 bytes
        TAG_Byte_Array('SkyLight'): 2048 bytes
      }
      TAG_Compound(''): 5 entries
      {
        TAG_Byte('Y'): 1
        TAG_Byte_Array('BlockLight'): 2048 bytes
        TAG_Byte_Array('Blocks'): 4096 bytes
        TAG_Byte_Array('Data'): 2048 bytes
        TAG_Byte_Array('SkyLight'): 2048 bytes
      }
      ...
    }
    TAG_List('TileEntities'):
    TAG_Long('InhabitedTime'): 16
    TAG_Long('LastUpdate'): Last time a block changed in this column
    TAG_Byte('LightPopulated'): Is the light calculated
    TAG_Byte('TerrainPopulated'): Has the terrain been generated
    TAG_Int('xPos'): X position of the region. Each single increment to x is 512 blocks
    TAG_Int('zPos'): Z position of the region. Each single increment to z is 512 blocks
    TAG_Byte_Array('Biomes'): 256 bytes. Biomes affect blocks in 1x256x1 columns
    TAG_Int_Array('HeightMap'): 256 bytes
  }
  TAG_Int('DataVersion'): 1343
}

See also

Region Files Block entity format