View source for User:Jocopa3/Pocket Level Format Test

{{msgbox
| title = This page is a work-in-progress rewrite of the existing [[Pocket Edition level format]] page.
| text = Constructive user edits and suggestions are welcome.
}}

The Pocket Edition level format varies majorly from the PC level format.

== LevelDB Format ==

Pocket Edition uses a modified version of Google's LevelDB, which uses Zlib compression for level storage.

=== Key Format ===

There are two primary types of keys: named keys and chunk keys. Named keys often store global NBT data while chunk keys store data relating to individual chunks (i.e. terrain data, entity NBT data, chunk version, etc.).

E.g. The Overworld: <code>| x: 32 | z: 32 | tag: 8 | (optional) subchunk id: 8 |</code>

Any other dimension: <code>| x: 32 | z: 32 | dimension: 32 | tag: 8 | (optional) subchunk id: 8 |</code>

{| class="wikitable"
 |-
 ! colspan=15 | Key Bytes
 |-
 ! 0 !! 1 !! 2 !! 3 !! 4 !! 5 !! 6 !! 7 !! 8 !! 9 !! 10 !! 11 !! 12 !! 13 !! 14
 |-
 | colspan=4 | Chunk X
 | colspan=4 | Chunk Z
 | colspan=1 | Tag
 |-
 |}

Keys in 1.0 are formatted similar to 0.9 format. 

=== Tags ===

Below are a list of all tags used to store data. Not all tags will be saved for a particular chunk even if other tags are present for that particular chunk. The only exception is the `Version` tag which always exists for generated chunks.

{| class="wikitable"
|-
! Name !! Tag Id (Hex) !! Description
|-
| Data2D || 45 ({{dec-hex|45}}) || Stores heightmap, grass, and biome information
|-
| Data2DLegacy || 46 ({{dec-hex|46}}) || Stores 2D terrain data; only present in pre-1.0 chunks.
|-
| SubChunkPrefix || 47 ({{dec-hex|47}}) || Stores terrain data for a particular subchunk in the chunk
|-
| LegacyTerrain || 48 ({{dec-hex|48}}) || Stores terrain data using the non-chunked format; only present in pre-1.0 chunks.
|-
| BlockEntity || 49 ({{dec-hex|49}}) || Stores all block entities in the chunk
|-
| Entity || 50 ({{dec-hex|50}}) || Stores all entities in the chunk
|-
| PendingTicks || 51 ({{dec-hex|51}}) ||
|-
| BlockExtraData || 52 ({{dec-hex|52}}) || Stores extra block data; only used for top snow.
|-
| BiomeState || 53 ({{dec-hex|53}}) || 
|-
| FinalizedState {{upcoming|ver=Pocket 1.1}} || 54 ({{dec-hex|54}}) || Stores an integer marking what stage of generation the chunk is at.
|-
| Version || 118 ({{dec-hex|118}}) || Stores a single byte indicating the chunk format version.
|}

Below is a list of which tags are available for different chunk formats.

{| class="wikitable" style="text-align:center" data-description="Tag versions"
! '''Tag'''
! 0.9 (2)
! 1.0 (3)
! 1.1 (4)
|-
! style="text-align:left" | Data2D
| {{tc|no}}
| {{tc|yes}}
| {{tc|yes}}
|-
! style="text-align:left" | Data2DLegacy
| {{tc|na|unknown}}
| {{tc|na|unknown}}
| {{tc|na|unknown}}
|-
! style="text-align:left" | SubChunkPrefix
| {{tc|no}}
| {{tc|yes}}
| {{tc|yes}}
|-
! style="text-align:left" | LegacyTerrain
| {{tc|yes}}
| {{tc|partial|read-only}}
| {{tc|partial|read-only}}
|-
! style="text-align:left" | BlockEntity
| {{tc|yes}}
| {{tc|yes}}
| {{tc|yes}}
|-
! style="text-align:left" | Entity
| {{tc|yes}}
| {{tc|yes}}
| {{tc|yes}}
|-
! style="text-align:left" | PendingTicks
| {{tc|no}}
| {{tc|yes}}
| {{tc|yes}}
|-
! style="text-align:left" | BlockExtraData
| {{tc|no}}
| {{tc|yes}}
| {{tc|yes}}
|-
! style="text-align:left" | BiomeState
| {{tc|no}}
| {{tc|yes}}
| {{tc|yes}}
|-
! style="text-align:left" | FinalizationState
| {{tc|no}}
| {{tc|no}}
| {{tc|yes}}
|-
! style="text-align:left" | Version
| {{tc|yes}}
| {{tc|yes}}
| {{tc|yes}}
|}

==== Data2D ====

Stores 2D per-chunk column data such as a height map and biome data. The data in this tag is ordered as ZX; the position of a particular column in the array can be calculated as <code>16*Z + X</code>. This tag stores 768 bytes of data in total.

{| class="wikitable"
|-
! Section Name !! Size !! Description
|-
| Heightmap Data || 512 Bytes || Stores the y-position of the top-most block as a little-endian short.
|-
| Biome Data || 256 Bytes || Stores the biome ID as a byte. See [[Data values#Biome_IDs|Biome ID's]] for a list of ID's.
|-
|}

==== Data2DLegacy ====

==== SubChunkPrefix ====

This tag stores all terrain data for subchunks.

==== FinalizationState ====

Described by [[Tommaso Checchi|Tommaso]]: "chunks always generate and save out even if they aren't finished, then they are completed, then they get replaced with."

{| class="wikitable"
|-
! Name !! Id !! Description
|-
| NeedsInstaticking || 0 || Chunk needs to be ticked
|-
| NeedsPopulation || 1 || Chunk needs to be populated with mobs
|-
| Done || 2 || Chunk generation is complete
|}

=== PE 1.1 ===

Lighting is no longer read from disk, only written. {{upcoming|ver=PE 1.1}} The chunk version has be updated to version 4 in-order to detect chunks containing [[bed]]s and convert beds to block entities. A new <code>FinalizedState</code> tag has been added to the format; it stores a single integer. The possible values are:

    enum class Finalization {
        NeedsInstaticking = 0, // Chunk needs to be ticked
        NeedsPopulation = 1, // Chunk needs to be populated with mobs
        Done = 2 // Chunk generation is fully complete
    };

=== PE 1.0 ===

1.0 stores each subchunk separately as a different leveldb key.<ref>https://www.reddit.com/r/MCPE/comments/5cw2tm/level_format_changes_in_mcpe_0171_100/d9zv9s8/</ref>

The possible tags are these:

To ask for a specific SubChunk you need to put "47" in the Tag and a number between 0 and 15 in the Subchunk ID. Note that subchunks are allowed to not exist! But they will always work like a stack, eg. if a chunk is there, all chunks below it should also be there.

The SubChunks are formatted like so:

* '''Version:''' 1 byte
* '''Block IDs:''' 4kb, 8 bits per block
* '''Block Data:''' 2kb, 4 bits per block
* '''Sky Light:''' 2kb, 4 bits per block
* '''Block Light:''' 2kb, 4 bits per block

=== PE 0.9 ===

Mojang's modified LevelDB is available at https://github.com/Mojang/leveldb-mcpe , and the build parameters required to build it are documented by Tommaso at {{tweet|_tomcc|477950809427427328}}. The Official LevelDB page is at https://code.google.com/p/leveldb/. To read a Pocket Edition level see here: https://github.com/tinfoiled/leveldb

The database is stored in the db/ subdirectory of a Pocket Edition world. It seems this is also where terrain generation is stored. This is because you can turn an old world infinite by replacing its db folder with one from an infinite world. 

There are three types of data stored in the database: terrain data, entity data, and tile entity data.

Key format: 9 byte key, which seems to consist of:
* x coordinate of chunk as little endian integer
* z coordinate of chunk as little endian integer
* one more byte indicating the type of the data:
** 0x30 (48 in decimal, '0' ASCII) for what appears to be terrain data
** 0x31 (49 in decimal, '1' ASCII) for tile entity data
** 0x32 (50 in decimal, '2' ASCII) for entity data
** 0x76 (118 in decimal, 'v' ASCII) for 1-byte data

Since the introduction in version 0.12.1 of the Nether, there are also special keys for Nether chunks, which are 13 bytes long, and seem to consist of:
* x coordinate of chunk as little endian integer
* z coordinate of chunk as little endian integer
* 1 as little endian integer (0x01 0x00 0x00 0x00)
* one more byte indicating the type of the data:
** 0x30 (48 in decimal, '0' ASCII) for what appears to be terrain data
** 0x31 (49 in decimal, '1' ASCII) for tile entity data
** 0x32 (50 in decimal, '2' ASCII) for entity data
** 0x76 (118 in decimal, 'v' ASCII) for 1-byte data

The 0x30 terrain data entry appears to contain block data for an x*z*y = 16*16*128 block chunk. The value associated with the 0x30 terrain data key is always of length 83,200 and seems to consist of the following data:
* 32,768 bytes of block data which appears to be a x*z*y = 16*16*128 block chunk.
* 16,384 bytes of regular data (one nibble for each byte of block data above).
* 16,384 bytes of skylight data (one nibble for each byte of block data above).
* 16,384 bytes of block light data (one nibble for each byte of block data above).
* 256 bytes of additional data which appears to be a z*x = 16*16 byte array (one  byte for each vertical y column of 128 bytes of block data above) containing dirty column info.
* 1,024 bytes of additional data which appears to be a 16*16*4 byte array (four bytes for each vertical y column of 128 bytes of block data above) containing grass color info.

The following definitions are provided to clarify the mapping between the location of a block within a LevelDB entry containing a chunk of 32,768 blocks and the corresponding location of the block within the entire world:
* Let X and Z be the values contained within the LevelDB key.
* Let C [] be a three dimensional array of the chunk of 32,768 blocks contained within the LevelDB entry. The first two indices i and j range from 0 to 15, and the third index y ranges from 0 to 127.
* Let W [] be a three dimensional array of the blocks contained within the entire world.
** For old style worlds, the first two indices x and z both range from 0 to 255. For infinite worlds, the first two indices x and z both range over the values of a four byte integer and may be negative as well as positive.
** The third index y ranges from 0 to 127 for both old style and infinite worlds.
Assuming the definitions above, the location of a block with a LevelDB entry with key values X and Z maps to the corresponding location of the block within the entire world as follows:
* C [i, j, y]  <->  W [x, z, y] where x = 16*X + i and z = 16*Z + j
The x index specifies the North to South location where a smaller value of x is farther North than a larger value of x. The z index specifies the East to West location where a smaller value of z is farther East than a larger value of z. The y index specifies the vertical location where a smaller value of y is at a lower height than a larger value of y. For an old style world, the block at the bottom of the North-East corner of the world is W [0, 0, 0].

The 0x31 tile entity and 0x32 entity data entries above are NBT encoded and may contain 0, 1, or multiple-concatenated Compound tags at the root level. In the case of 0 Compound tags, LevelDB indicates 0 as the length of the value associated with the key. Multiple-concatenated tags are supported because there can be more than one entity per chunk. Every 0x31 tile entity and 0x32 entity entry has an associated 0x30 terrain entry, but an 0x30 terrain entry will not necessarily have an associated 0x31 tile entity or 0x32 entity entry.

The number of 0x30 terrain entries and 0x76 1-byte data entries is always the same, and there is a one-to-one relationship between these entries where the corresponding entries both have the same x and z values. Three values have been observed for the 1-byte data including the binary values 0, 1, and 2. The value 0 has been observed in old style worlds, and the values 1 and 2 have been observed in infinite worlds.

There's also the special key ~local_player for an entity data entry that holds the local player entity. If entity data exists here, it takes precedence over the player data stored in level.dat. The value associated with the ~local_player key is NBT encoded and only has a single compound tag at the root level.

There's also a special key for remote players which consists of two parts. The first part is the prefix "player_" (without the quotes) and the second part is the client ID which is contained in the remote player's clientid.txt file. For example, player_-12345678 would be the key for a remote client with an client ID of -12345678. The value associated with the “player_” prefixed key is NBT encoded and only has a single compound tag at the root level.

There's also a special “game_flatworldlayers” key of length 20 for flat worlds. The value associated with this key is a set of numbers in ASCII text format. An example of a value associated with the “game_flatworldlayers” key is “[7,3,3,2]” where the value length for this example is 9.

=== LOG ===
The LOG files are located at the /db path of a level, and are part of the leveldb format, used in between compaction of the LDB files.  It is similar to a Log file for a program. The format is:

<font color="blue">YYYY /MM/DD-Hour/Minute/Second.StepName "Info"</font>

Example:

<font color="blue">2014/07/24-22:20:08.400488 4a3638 Recovering log #3</font>

== level.dat ==

==== Structure ====
<div class="treeview">
* {{nbt|compound}} World data.
** {{nbt|int|Dimension}}: The dimension the player is in. 0 is the Overworld.
** {{nbt|int|GameType}}: Whether in survival (0) or in creative (1) mode.
** {{nbt|long|Generator}}: World Type: Old, Infinite, or Flat
** {{nbt|long|LastPlayed}}: Stores the Unix time stamp (in seconds) when the player saved the game.
** {{nbt|string|LevelName}}: Specifies the name of the level.
** {{nbt|compound}} LimitedWorldOrigin. (Only applies to old type worlds)
*** {{nbt|int|LimitedWorldOriginX}}: X coordinate where limited world generation started. 
*** {{nbt|int|LimitedWorldOriginY}}: Y coordinate where limited world generation started.
*** {{nbt|int|LimitedWorldOriginZ}}: Z coordinate where limited world generation started.
** {{nbt|int|Platform}}: Seems to store the platform that the level is created on. Currently observed value is 2.
** {{nbt|int|RandomSeed}}: Level Seed
** {{nbt|int|SizeOnDisk}}: Estimated size of level in bytes
** {{nbt|compound}} Spawn Coordinates of world
*** {{nbt|int|SpawnX}}: X coordinate of the player's spawn position. Default is 0.
*** {{nbt|int|SpawnY}}: Y coordinate of the player's spawn position. Default is 64.
*** {{nbt|int|SpawnZ}}: Z coordinate of the player's spawn position. Default is 0.
** {{nbt|int|StorageVersion}}:Version of Pocket Edition Storage Tool, currently is 4
** {{nbt|long|Time}}: Stores the current "time of day" in ticks. There are 20 ticks per real-life second, and 14400 ticks per Minecraft [[day/night cycle]], making the full cycle length 12 minutes—8 minutes shorter than the standard 20 minute day/night cycle. 0 is the start of [[Day/night cycle#Daytime|daytime]], 7200 is the start of [[Day/night cycle#Sunset/Dusk|sunset]], 8280 is the start of [[Day/night cycle#Nighttime|nighttime]], 13320 is the start of [[Day/night cycle#Sunrise/Dawn|sunrise]], and 14400 is daytime again. The value stored in level.dat is always increasing and can be larger than 14400, but the "time of day" is always modulo 14400 of the "Time" field value.
** {{nbt|long|dayCycleStopTime}}: Added in 8.0. Default is 18446744073709552000.
** {{nbt|int|spawnMobs}}: Disable (0) or enable (1) mob spawning.

== 0.8.1 and below ==

=== level.dat ===
The level.dat file is in NBT format, based on the format of level.dat in a Desktop world. level.dat is an uncompressed little-endian NBT file that stores environmental data (time of day, for example) and player health, inventory, velocity, and position within the map.

The file begins with an 8-byte header, consisting of a little-endian 4-byte integer indicating the type of the file, which is 3 (was 2 before latest update) for level.dat. It is followed by another integer containing the length of the file, minus the header.<ref>https://github.com/TkTech/OpenNBT/blob/master/opennbt/helpers.py</ref>

==== NBT Structure ====
<div class="treeview">
* {{nbt|compound}} World data.
** {{nbt|int|GameType}}: Whether in survival (0) or in creative (1) mode.
** {{nbt|long|LastPlayed}}: Stores the Unix time stamp (in seconds) when the player saved the game.
** {{nbt|string|LevelName}}: Specifies the name of the level.
** {{nbt|int|Platform}}: Seems to store the platform that the level is created on. Currently observed value is 2.
** {{nbt|compound|Player}}: Player entity information. See [[#Entity Format|Entity Format]] and Mob Entity Format for details. It is missing the id tag and has additional elements:
*** {{nbt|list|Armor}}: Each TAG_Compound in this list defines a piece of armor that the player is wearing. This is a list with length 4 - for helmet, chestplate, leggings, and boots.
**** {{nbt|compound}} Inventory item data
***** {{nbt|short|id}}: [[Bedrock Edition data values|Item or Block ID.]]
***** {{nbt|byte|Count}}: Number of items stacked in this inventory slot. Any item can be stacked, including tools. Range is 1-255. Values above 255 are not displayed in-game.
***** {{nbt|short|Damage}}: For armor, the amount of wear they have suffered. The maximum durability of the armor means undamaged. When the Damage reaches 0, it breaks and disappears.
*** {{nbt|int|Dimension}}: The dimension the player is in. 0 is the Overworld.
*** {{nbt|list|Inventory}}: Each TAG_Compound in this list defines an item the player is carrying or holding.
**** {{nbt|compound}} Inventory item data
***** {{nbt|byte|Slot}}: Indicates which inventory slot this item is in.
***** {{nbt|short|id}}: [[Bedrock Edition data values|Item or Block ID.]]
***** {{nbt|byte|Count}}: Number of items stacked in this inventory slot. Any item can be stacked, including tools. Range is 1-255. Values above 255 are not displayed in-game.
***** {{nbt|short|Damage}}: For tools, the amount of wear they have suffered. The maximum durability of the tool (for example, 33 for golden tools) means undamaged. When the Damage reaches 0, it breaks and disappears.
*** {{nbt|int|Score}}: The score of the player.
*** {{nbt|byte|Sleeping}}: 1 or 0 (true/false) - true if the player was in a bed when this tag was saved; has no effect on whether the player is in a bed when they log in.
*** {{nbt|short|SleepTimer}}: The number of ticks the player had been in bed when this tag was saved. No effect.
*** {{nbt|int|SpawnX}}: X coordinate of the player's spawn position. Default is 0.
*** {{nbt|int|SpawnY}}: Y coordinate of the player's spawn position. Default is 64.
*** {{nbt|int|SpawnZ}}: Z coordinate of the player's spawn position. Default is 0.
*** {{nbt|compound|abilities}}: The abilities this player has.
**** {{nbt|byte|mayfly}}: 1 or 0 (true/false) - true if the player can fly.
**** {{nbt|byte|flying}}: 1 or 0 (true/false) - true if the player is currently flying.
**** {{nbt|byte|invulnerable}}: 1 or 0 (true/false) - true if the player is immune to all damage and harmful effects except for [[The Void|void]] damage.
**** {{nbt|byte|mayBuild}}: 1 or 0 (true/false) - true if the player can place and destroy blocks.
**** {{nbt|byte|instabuild}}: 1 or 0 (true/false) - true if the player can instantly destroy blocks.
** {{nbt|long|RandomSeed}}: Random number providing the Random Seed for the terrain.
** {{nbt|long|SizeOnDisk}}: Estimated size of the entire world in bytes.
** {{nbt|int|SpawnX}}: X coordinate of the world's spawn position. Default is 0.
** {{nbt|int|SpawnY}}: Y coordinate of the world's spawn position. Default is 64.
** {{nbt|int|SpawnZ}}: Z coordinate of the world's spawn position. Default is 0.
** {{nbt|int|StorageVersion}}: Version of Pocket Edition NBT, is 3.
** {{nbt|long|Time}}: Stores the current "time of day" in ticks. There are 20 ticks per real-life second, and 14400 ticks per Minecraft [[day/night cycle]], making the full cycle length 12 minutes—8 minutes shorter than the standard 20 minute day/night cycle. 0 is the start of [[Day/night cycle#Daytime|daytime]], 7200 is the start of [[Day/night cycle#Sunset/Dusk|sunset]], 8280 is the start of [[Day/night cycle#Nighttime|nighttime]], 13320 is the start of [[Day/night cycle#Sunrise/Dawn|sunrise]], and 14400 is daytime again. The value stored in level.dat is always increasing and can be larger than 14400, but the "time of day" is always modulo 14400 of the "Time" field value.
** {{nbt|long|dayCycleStopTime}}: Added in 8.0. Default is 18446744073709552000.
** {{nbt|int|spawnMobs}}: Disable (0) or enable (1) mob spawning.
</div>

=== chunks.dat ===
This file stores the 16x16 (256) chunk arrays holding all 256x256x128 (8,388,608) blocks in each default map. Every 4,096 bytes or 4kb's is one sector length, where in total for a default map there are 5,377 sectors. The file has a maximum of 32x32 (1024) chunks and 512x512x128 (33,554,432) blocks, but in a default map generated by the game the map will be its standard size. The type of the bytes in this file are mostly 32-bit little-endian, except for a few sections of data

The first sector of the file is a data location table, which points to what chunks are available and where in the map and the file. Every 128 bytes of the location table describes a row of chunks in the map, but usually there is only 64 bytes of data because there are only 16 chunks per row. 

The format for each chunk in the location table is 15 XX ZZ 00, where the 15 (21<sub>dec</sub>) describes how many sectors are in the section, the second number describes the X coordinate in hex to the top left corner of the chunk, the third number is the Z coordinate in hex describing which row the chunk is in, and the final number goes unused until an update where map sizes are increased. You can also think of the "X" coordinate as the chunk's starting point on the map.

To find the offset of a chunk based on the table, all one must do is use the algorithm <code>4096+(x*21*4096)+(z*21*16*4096)</code>, the reason being is the first sector is a location table, so we start at 4096. Every 86,016 bytes or 21*4096 bytes is a new chunk, so then times by x. It's the same for the z coordinate, just every 16 chunk sections is a new row, so multiply by 16.

Example of finding an offset is say we have these three numbers in the table, <code>15 4d 02 00</code>, the first number tells how many sectors are in the chunk, in this case 21, the second number (4d<sub>hex</sub>) is the "x coordinate", the third (02<sub>hex</sub>) is the "z coordinate" and the fourth number is to be used when dealing with larger maps. So now we take <code>77*21*4096</code> and add it to <code>4096</code> (make up for the location table) to get <code>6,627,328</code>, now add <code>2*21*4096*16</code> to get <code>9,379,840</code>, which is the decimal offset of the chunk.

The first 8 sectors of the first chunk at offset 1000<sub>hex</sub> or 4096<sub>dec</sub> is the first array of blocks in the file. The first 4 bytes starting at offset 1000<sub>hex</sub> or 4096<sub>dec</sub> is a chunk header, identifying the start of a new chunk. The chunk header will always be <code>04 41 01 00</code> in hex. After the chunk header, every 128 blocks is a column. Every 16 columns is a new row. Columns can be stored as short[]'s (short arrays).

After the first 8 sectors of block data is 4 sectors of regular data in big-endian used to store information about certain blocks. Since this section is only 4 sectors long, each byte represents two blocks. 

An example use of the data section is say you placed some blue wool and then some red wool in a column at <code>[4,76,14]</code> in the chunk. By dividing the X,Y,Z coordinates of the wool within the chunk in half you can find where the data for that block is <code>[2,38,7]</code>. Now that you have the new coordinates, you can find the byte by starting at the data sector's offset and then using the algorithm <code>(x*64)+y+(z*64*16)</code>. The data at that offset would then be EB<sub>hex</sub>, and since these sectors are big-endian you would read it as BE<sub>hex</sub>. Since B is the data for blue wool and E is the data for red wool, you will have to split the byte and get B and E separate to get the individual data for those blocks.

After the 4 sectors of data is 4 sectors of skylight data. Once again every byte is two blocks and each byte should be read in big-endian like in the data sectors. If a light value is F, that means the lighting is dark, while if a light value is 0, then the lighting is light. Because the game automatically generates lighting, it is unimportant to modify this part of the file when generating a world via an outside program.

The last 4 sectors are like the skylight data, but instead are block light data. Once again every byte represents 2 blocks and should be read as big-endian. The light values are the same as skylight values, where F is dark and 0 is light. Once again, because the game automatically generates lighting, it is unimportant to modify this part of the file when generating a world via an outside program.

=== entities.dat ===
This file uses the modified little endian uncompressed NBT format. It appears to store entity information using a format based on the Alpha Level Chunk Format. It also stores [[tile entity]] information as well.

The file has a 12 byte header. It begins with the ASCII Characters "ENT", then one zero byte, then a little-endian integer with the value 1, followed by another little endian integer stating the length of the file in bytes, not counting the header.<ref>https://github.com/TkTech/OpenNBT/blob/master/opennbt/helpers.py</ref>

==== NBT Structure ====
<div class="treeview">
* {{nbt|compound}} Root compound tag.
** {{nbt|list|Entities}}: Each TAG_Compound in this list defines an entity in the world. See [[#Entity Format|Entity Format]] below.
** {{nbt|list|TileEntities}}: Each TAG_Compound in this list defines a [[Tile entity]], such as a [[furnace]], in the world.
</div>

==== Entity Format ====

Every entity is an unnamed TAG_Compound contained in the Entities list of a chunk file. The sole exception is the Player entity, stored in level.dat.

All entities share this base:

<div class="treeview">
* {{nbt|compound}} Entity data
** {{nbt|int|id}}: [[Bedrock Edition data values#Entity_IDs|Entity Type ID]]. Known values are 13 for Sheep, 32 for Zombie, and 64 for item drops.
** {{nbt|list|Pos}}: 3 TAG_Floats describing the current X,Y,Z position of the entity.
** {{nbt|list|Motion}}: 3 TAG_Floats describing the current dX,dY,dZ velocity of the entity. (Note: 0,0,0 is no motion.)
** {{nbt|list|Rotation}}: Two TAG_Floats representing rotation in degrees.
*** {{nbt|float}}: The entity's rotation clockwise around the Y axis (called yaw). Due west is 0. Can have large values because it accumulates all of the entity's lateral rotation throughout the game.
*** {{nbt|float}}: The entity's declination from the horizon (called pitch). Horizontal is 0. Positive values look downward. Does not exceed positive or negative 90 degrees.
** {{nbt|float|FallDistance}}: Distance the entity has fallen. Larger values cause more damage when the entity lands.
** {{nbt|short|Fire}}: Number of ticks until the fire is put out. Negative values reflect how long the entity can stand in fire before burning.
** {{nbt|short|Air}}: How much air the entity has, in ticks. Fills to a maximum of 300 in air. Decreases while underwater.
** {{nbt|byte|OnGround}}: 1 if the entity is touching the ground.
</div>

==== [[File:ZombieFace.png|16px]] Mobs ====

<div class="treeview">
*Additional fields for mobs:

** {{nbt|short|AttackTime}}: Number of ticks the entity's "invincibility shield" is lasting after the entity was last struck.
** {{nbt|short|DeathTime}}: Number of ticks the entity has been dead for. Controls death animations.
** {{nbt|short|Health}}: Amount of health the entity has. Players and enemies normally have up to 20 health. Livestock has up to 10 health.
** {{nbt|short|HurtTime}}: Unknown, maybe time invincible after being hit

* Additional field for animals such as Sheep:

** {{nbt|int|Age}}: Age of the animal.

[[File:SheepFace.png|16px]] '''Sheep''' has two additional fields:

** {{nbt|byte|Sheared}}: 1 or 0 (true/false) - true if the sheep has been shorn.
** {{nbt|byte|Color}}: 0 to 15 - see [[Data_values#Wool|wool data values]] for a mapping to colors. There is evidence that this value does not affect sheep rendering, but does affect wool drops.<ref>http://www.minecraftforum.net/topic/1035251-sheep-wool/</ref>

* [[File:Cobblestone.png|16px]] Additional fields for '''Item''':

** {{nbt|short|Health}}: Starts at 5, and currently only decreases as the item takes fire damage. When health reaches 0, the item is destroyed.
** {{nbt|short|Age}}: The amount of time an item has been "untouched" on the ground. After 2400 'ticks', or 2 minutes, the item is destroyed.
** {{nbt|compound|Item}}: Item data
*** {{nbt|short|id}}: [[Data values|Item or Block ID.]]
*** {{nbt|short|Damage}}: The amount of wear each item has suffered. 0 means undamaged. When the Damage exceeds the item's durability, it breaks and disappears. Only tools and armor accumulate damage normally.
*** {{nbt|byte|Count}}: Number of [[item]]s contained in this item drop entity. Any item can be stacked, including tools, armor, and vehicles. Range is 1-255.
</div>

== History ==

{{History|pocket alpha}}
{{History||v0.2.0|level.dat is now a NBT formatted file.
|player.dat information now moved to level.dat
|Added entities.dat.}}
{{History||v0.3.2|Entities.dat extended to store [[tile entity]] information.}}
{{History||v0.9.0|Added a new world save format, based on LevelDB 1.17 with Zlib compression support added. Older worlds are automatically converted to the new format when loaded.}}
{{History|pocket}}
{{History||1.0|Each sub chunk is now stored separately as a different leveldb key.}}
{{History|foot}}

== References ==
<references/>