Talk:Chunk format

Disk Usage
"MCRegion changed this by storing groups of 32x32 chunks in individual ".mcr" files with the coordinates in Base10, with the goal being to reduce disk usage by cutting down on the number of file handles Minecraft had open at once."

Reducing concurrent file handle counts will not reduce disk _space_ usage. "disk usage" seems either wrong or at least ambiguous here.

Not having a lot of file handles open would increase efficiency, though, and having nearby chunks in one single could increase locality of the data on disk and reduce seek times. –Preceding unsigned comment was added by 174.5.64.175 (Talk) 19:29, 1 December 2012 (UTC). Please sign your posts with
 * It is correct, "disk usage" is usually used to refer to the seek time, whereas "disk space" is of course for space.  LB ( T 23:32, 1 December 2012 (UTC)

Deleting Chunks
Hi! I was wondering about getting chunks to re-generate - can I just delete the folders for outlying chunks, then have them re-generate by the engine? I guess the question becomes, are chunk files referenced by any other dat files?

--Jkerr88 18:12, 22 January 2011 (UTC)


 * With pre-MCRegion format files, all you have to do is delete the folder for the chunk. With pre-Anvil and Anvil format files, there are many chunks within each region file and you have to use a program like MCEdit or NBTexplorer to delete specific chunks. LB 20:13, 21 June 2012 (UTC)


 * Simply use SPC or WorldEdit! –Preceding unsigned comment was added by 79.226.237.55 (Talk) 21:49, 8 July 2012. Please sign your posts with

Confusing format
I find some parts of this page confusing, specifically missing type specifications. For example, what's a TAG_Compound? What's its structure? and other questions.

Anyone could make this page clearer when it comes to types?

--RichardG867 00:40, 1 May 2011 (UTC)


 * See Development Resources where it says "Notch's notes on NBT format files.", that explains the TAG_Madness that you see. LB 20:11, 21 June 2012 (UTC)
 * Actually, I made an article: NBT Format. LB 01:39, 22 June 2012 (UTC)

I think it is confusing too, it would be nice if each section had an example of how this might be used in the /summon or /give commands. (i'm creating an adventure map and want to spawn zombies with armor, etc.)Mokiki 03:31, 10 September 2013 (UTC)


 * That would be pretty excessive. Right now with the colorful pictures I just don't see how to make it any more clear. Maybe it would help if you learned the JSON format, which is what the syntax of the /summon command uses.  LB ( T 12:13, 10 September 2013 (UTC)

InGround tag
Could someone confiirm/disprove the fact that the InGround field of arrows, eggs and snowballs controls whether or not the entity is stuck in the ground? I think a tag is missing from the three types of entities controlling what I just said because the entities act differently depending on whether or not they are stuck in the ground (for example, eggs and snowballs disappear if they become stuck in the ground, and arrows stop moving and don't do damage when stuck in the ground). Haosys 17:32, 19 June 2011 (UTC)


 * I have personally checked all projectile types, and they all have just those tags plus the entity base tags. LB 20:09, 21 June 2012 (UTC)

Entity format
I never seen TAG_String("World") in any entity. I tried all version since Beta 1.2_02. Could someone confirm this tag?

--Famajo321 15:07, 18 September 2011 (UTC)


 * I can confirm that it doesn't exist; I've checked all known entity types. LB 20:15, 21 June 2012 (UTC)

Move to Chunk format
I agree. The info applies to Alpha, Beta, and Release formats. It looks kind of odd being the only subpage under Alpha Level Format. -Codewarrior 12:17, 1 December 2011 (UTC)

Missing entities
The entities section misses the folloing entities:

Blaze Magma cube EnderDragon Mooshroom Snow Golem Villager Endercrystal Darksonn 18:30, 8 January 2012 (UTC)


 * I added EnderCrystal but it has all the same tags as the base Entity. I put it in items because I wasn't sure where else to put it. LB 20:08, 21 June 2012 (UTC)

128 or 256
Are they in 16x128x16 or 16x256x16 since the last update??? –Preceding unsigned comment was added by Addamondes (Talk&#124;Contribs) 04:26, 6 March 2012. Please sign your posts with


 * Neither. See Anvil file format. This page is now out of data, although I want to pull in changes from the Anvil file format page here. --Thvortex 21:37, 8 March 2012 (UTC)


 * I've written it as 16x256x16 and explained how Sections worked, and have updated the page quite a bit. Is this good enough for you? LB 02:33, 3 July 2012 (UTC)

Merge with Anvil file format
Can we merge the Anvil file format page into this one? This page is a lot more detailed. We could also include a link on the this page that pulls up the older version of the page so one can still easily find what the previous chunk format looked like. --Thvortex 21:35, 8 March 2012 (UTC)


 * It would be difficult to do since past versions of the page may not have even been complete for their time. Personally I think the past versions don't need to be documented any more as there is always source code out there that will work if needed, and the minecraft_server.jar can be invoked via code to update worlds. It would take a lot of time and effort to correctly document the chunk format through the ages - is it really worth it? LB 02:38, 3 July 2012 (UTC)

Outdated information
The information for the NBT Structure of a chunk is outdated. Tile Tick information is correct, but I see some changes to the rest: I'm going to try and update the information, especially seeing as it still discusses file names for the chunks. LB 03:23, 22 June 2012 (UTC)
 * I'm almost done updating and filling in all information. The page has undergone quite a transformation as I test each and every aspect and find better ways to organize everything. Be on the look out for typos... LB 02:30, 3 July 2012 (UTC)

Head data
I hope someone figures out the information for the Head block - I'm guessing it's using tile entities for orientation and even type (I'm not seeing the head type in the data value, despite what's listed at Block_ids). Erich666 13:04, 14 September 2012 (UTC)
 * You're right; I thought they each used a block ID and the data value for orientation like signs, but it is indeed a tile entity. I've added it for you ;)  LB ( T 23:47, 14 September 2012 (UTC)

On the topic of riding
Obviously entities can, under the right circumstances, ride other entities; e.g. Skeletons riding Spiders, Players riding Pigs. Is this in any way part of the Mob Entity ID, and if so, can it be manipulated? For example, via NBTedit or some such, could you make a Mob Spawner spawn a Zombie Pigman w/ an enchanted sword and armor riding a Ghast w/ Regen potion effect? I'm just wondering because I would like to make a challenge map in which Skeletons ride Blazes, etc. 216.9.31.209 07:06, 29 October 2012 (UTC)
 * Sadly, no. You could ask Dinnerbone. You may notice that if you save and reload with a spider jokey that the skeleton dismounts the spider. There is no saved form of mounting mobs. You could use some Bukkit plugins, though, or a mod.  LB ( T 12:20, 29 October 2012 (UTC)


 * DB is working on this right now Last username 13:04, 18 January 2013 (UTC)


 * This has now been incorporated into Minecraft; see the entity format for details. An entity stores the data for the mob it is riding.  LB ( T 20:48, 19 March 2013 (UTC)

Enderman Anger
Is there no bit determining if an Enderman is angry or not or has it not been discovered?Toadbert 20:20, 25 January 2013 (UTC)
 * There is no tag for this. Like all other mobs, Endermen take anger management courses and can forgive you if you reload the chunk they are in or get too far away. Zombie Pigmen don't take anger management courses and they have to cool off - this cool off is saved in with the chunk.  LB ( T 21:47, 25 January 2013 (UTC)
 * I see Toadbert 01:43, 26 January 2013 (UTC)
 * Just to be clear, I wasn't trolling you - I just got carried away with an analogy.  LB ( T 02:09, 26 January 2013 (UTC)
 * Yeah I gotcha Toadbert 20:28, 26 January 2013 (UTC)

Chunk vs Chunk Column
This page describes a "Chunk" as a 16x256x16 area divided into 16 vaguely described "sections"

The majority of the modding community describes this 16x256x16 area as a "Chunk Column" divided into 16x16x16 "Chunks"

Is there a reason this page uses the different terminology? 72.89.41.193 07:52, 19 March 2013 (UTC)


 * 'Chunk' and 'Section' are the terms used in region files' NBT structure. Also, historically (pre-Anvil), a chunk was a 16x128x16 column, with no subdivisions, so I have no idea why modders decided to re-define already-accepted terms. -- Orthotope 08:24, 19 March 2013 (UTC)


 * I agree with Orthotope here. The article uses the same terminology as Minecraft itself. I've never seen modders use the phrase "chunk column" or call sections chunks before, could you link to this?  LB ( T 20:37, 19 March 2013 (UTC)

MobSpawner EntityId and SpawnData
There was an edit war about what these tags do. I've decided to put both of these explanations on the page, to hopefully stop this edit war. If you have any proof for either explanation, post it in here. --93.73.186.104 21:27, 12 April 2013 (UTC)
 * With experience from dealing with spawners a lot, I can tell you that the game does not overwrite EntityId and SpawnData when the spawner is loaded. It determines the next spawn, which is also the entity you see spinning in the cage; this is its entire purpose in the game. It is only overwritten when the game checks the SpawnPotentials list for a new entity - it will always spawn from the current SpawnData before doing this if it exists. If SpawnData does not exist and a spawner is loaded, its next spawn will be a generic entity of EntityId type. If SpawnPotentials does not exist, the game will create it when it needs to spawn a new entity - the generated SpawnPotentials will be based on the current EntityId and SpawnData. Therefore, the second explanation is closer to correctness - The tags are not deprecated, and are very much still in use. You can test this yourself; have a spawner with a single SpawnPotentials for a mob renamed "Two", and have SpawnData contain a mob renamed "One". When you load the world, the first mob to spawn will be One, and all subsequent mobs will be Two. --WolfieMario 04:10, 13 April 2013 (UTC)

I figured presenting it in this form may help people understand:
 * SpawnData and SpawnPotentials absent; EntityId present (EntityId is not optional): This is the state found in vanilla spawners, i.e. those found in dungeons. Entities of type EntityId are spawned, with randomized properties such as armor and sheep wool colors (the same randomization found when using spawn eggs or when a mob spawns naturally). SpawnData and SpawnPotentials will not be created.
 * SpawnData and EntityId present; SpawnPotentials absent: This is the state of custom spawners created by players before SpawnPotentials were added; therefore Dinnerbone was kind enough to include backwards-compatibility. The next mob spawned by this spawner will use EntityId and SpawnData. After this spawning, SpawnPotentials is generated, with a single entry where Type is the existing EntityId, Properties is the existing SpawnData, and Weight is 1. After this, SpawnData and EntityId are overwritten, as normal, by a randomly selected SpawnPotential - of course, as the only existing SpawnPotential was derived from SpawnData and EntityId themselves, it will not appear to change. The end result is that this spawner will behave exactly as it would have prior to the existence of SpawnPotentials.
 * SpawnData, EntityId, and SpawnPotentials are all present: This is likely the most "proper" way to set up your custom spawners, as it is also the final state of any spawner with custom SpawnData/Potentials which you create. SpawnData and EntityId determine the next spawned entity, and you can preview it by looking at the miniature which spins in the cage. After this spawning, a new SpawnData and EntityId are chosen (overwriting the old ones) using SpawnPotentials, and the cycle can go on.
 * SpawnPotentials and EntityId present; SpawnData absent: I personally consider this the least correct setup. The next mob spawned by the spawner will be treated as a vanilla spawn, with randomized armor, wool color, etc... After this, SpawnPotentials will generate a SpawnData/EntityId pair, and the spawner will thereafter fall in the previous category. I consider this setup incorrect because it results in a one-time-only initial spawn that ignores your custom Properties: there is very little practical use for the behavior. All three preceding setups have consistent behavior: the first setup is constant; it will never change its behavior after spawning. The second will automagically transform into the third setup after spawning, but even in the process of doing so, its actual spawning behavior will remain unchanged. The third setup, if SpawnData and EntityId also exist as an identical Properties/Type pair in SpawnPotentials, will also not change its behavior after the first spawn. However, if the SpawnData and EntityId pair have no corresponding Properties and Type, then the very first spawn attempt made will never be made again - just as this fourth setup will create a one-time-only vanilla spawn and then decay to the third setup - the resting state for any non-vanilla-style spawner.

Therefore, if you don't need SpawnData and SpawnPotentials, do not use them at all. If you want to specify custom properties, but aren't interested in multiple possibilities, your best bet is to go with the second setup - SpawnData without SpawnPotentials, as the game will automatically upgrade it to a proper version of the third setup. You can create the third setup manually yourself, but if no Type/Properties pair corresponds to your EntityId/SpawnData pair, it will not be a "proper" version of this setup, until at least one spawn is made. Obviously, you have no choice but to use SpawnPotentials if multiple custom property sets is something you seek - for a proper setup, SpawnData and EntityId should be taken from an arbitrary Properties and Type entry in SpawnPotentials - they should not be a dummy value, if consistency is what you want. The fourth setup should probably be avoided unless you have some legitimate reason to use it - it decays to a proper version of the third setup after one spawning, just as an improper version of the third setup would. '''tl;dr The game's very forgiving if you do something wrong; if you let the spawner spawn once, it will always have a proper and consistent setup afterwards. When lazy or in doubt, go with the second setup; otherwise go with the third but avoid being lazy.'''

For another point of confusion, data which is randomized upon spawning (apart from Pos) is only randomized for vanilla spawns. If SpawnData exists at the time of the spawning (the second and third setups), then this data is not generated. This data includes custom armor, skeletonType in the nether, zombies occasionally spawning as villager zombies, sheep wool color, and so on - only constant-valued tags such as Health will be generated. Thus, the only way to get the full benefit of vanilla spawn randomization is the first setup - the fourth setup will create exactly one vanilla spawn attempt, and all subsequent attempts will not have randomized properties. No, excluding "Properties" in SpawnPotentials does not work; if absent upon spawning, all Properties are initialized as empty compounds - and subsequently set as SpawnData, and even empty SpawnData prevents the vanilla randomization from occurring. --WolfieMario 01:05, 18 April 2013 (UTC)

"SpawnData" Mob Spawner Additional field crashes Minecraft and corrupts save
Adding the compound tag "SpawnData" stated in the article into a mobspawner using an NBT editor causes Minecraft to crash. On startup, the game will always crash when loading the save.--67.1.213.18 00:27, 17 April 2013 (UTC)


 * See the above conversation Talk:Chunk format - I think the tags were deprecated for a good reason but nobody would listen ;)  LB ( T 02:23, 17 April 2013 (UTC)
 * Care to add to the discussion? I've yet to have crashes with SpawnData, and it exists in any preexisting spawner. It is by no means deprecated - its purpose was just changed when SpawnPotentials were added. You can get crashes easily enough if anything within SpawnData is invalid, i.e. you made Health a TAG_Int instead of a TAG_Short. You could just as easily make the same flub in SpawnPotentials, and have the same negative results. I've been using SpawnData and SpawnPotentials the proper way for the past five months, and have not had any crashes. EDIT: For clarification, SpawnData for the past five months, and SpawnPotentials since around whenever it was released. --WolfieMario 23:44, 17 April 2013 (UTC)

EDIT: I'm the same guy that posted the Spawndata corrupt world problem and I found out why it happens. If EntityId's value is left blank and Spawndata is put in, it will corrupt the world save. I had to use MCedit to delete the block to get my world back.--67.1.213.18 03:27, 18 April 2013 (UTC)

Rounding decimals
IEEE 754 floating-point numbers are unable to represent some decimals precisely. A value of 0.7 specified in source code will be changed to 0.69999999999999996 when compiled, since that's the closest representable value to 0.7. I think it's reasonable to round off such numbers, since it's easier to read, it's what the Mojang devs wrote in the original source code, and the difference is so small as to be insignificant. -- Orthotope 18:13, 11 May 2013 (UTC)

"ownerName" tag
According to the code, exp bottles, thrown potions, and snowballs also have the "ownerName" tag (eggs too, but they're not saved). --mister_person 22:40, 29 June 2013 (UTC)
 * Tested in 1.6.1 and confirmed for ThrownExpBottle, ThrownPotion, and Snowball. Others not tested.  LB ( T 23:32, 29 June 2013 (UTC)


 * I don't mess with the code, just save files, so I wouldn't know. It does save for horses though, but only on 1.6.2.  Firebastard 07:58, 6 July 2013 (UTC)

Specifics on Byte Arrays
I was using this page to help me write a C-based NBT reading/writing library. Very helpful, thank you! But one or two potholes I encountered that I thought I might share, for the benefit of others: Quartzmmn (talk) 03:41, 22 September 2013 (UTC)
 * 1) The "HeightMap" TAG_IntArray has this note: "This array's indexes are ordered ZX whereas the other array indexes are ordered XZ or YZX." According to my testing on Minecraft 1.6.2 map data, no array in the whole chunk appears to be ordered XZ. Actually, "Biomes" seems to be the only candidate, since it's the only other 2D array, and it seems to be perfectly consistent with the standard YZX ordering (which yields the most natural scan direction), simply omitting the inapplicable Y dimension.
 * 2) Wherever we have a 4-bit-per-block array (i.e. "Add," "Data," "BlockLight," & "SkyLight," each having a byte size of 2048), the page helpfully specifies "4 bits per block." However, it remains unclear which half of the byte is used for which block, and I assumed at first the natural human-readable printing direction - i.e. most significant 4 bits for even-numbered blocks & least significant 4 bits for odd-numbered blocks. But my testing yields the reverse scenario, wherein the data is interlaced with the most significant 4 bits for odd-numbered blocks & least significant 4 bits for even-numbered blocks; block[0] is in byte[0] at 0x0f, block[1] is in byte[0] at 0xf0, block[2] is in byte[1] at 0x0f, etc. I recommend specifying this in the page, if a reasonable way of wording it can be found.


 * Thanks for researching this info, I haven't had the time to research it myself which is why I left the wording on the page ambiguous. If you can double check to confirm this then you can feel free to edit the page to remove the ambiguity. I don't have time to check myself though - all I know is that endianness is a scary place to get lost.  LB ( T 17:28, 23 September 2013 (UTC)