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)


 * I'll be glad to edit the page. I'll wait until my library is further along and I can perform more extensive testing, just to be sure. --Quartzmmn (talk) 15:49, 28 September 2013 (UTC)


 * Gee... I just added to the page the details we discussed here, and realized that some poor fellow already helpfully explained the same thing via the block of pseudo-code that I didn't bother to examine before. :-P Silly me! Oh well, maybe my paragraph will be more accessible to other lazy readers like me. Paraphrased redundancy can be a good thing. --Quartzmmn (talk) 02:52, 12 October 2013 (UTC)

Horse Variant
Since the Variant of Horses is said to be in (baseColor | markings << 8), which is something you can't just enter into any calculator, I'd like to request a more common format. I am trying to spawn an specific horse and I don't want to scroll through every number possible, so it would be very helpful. Thanks in advance --Fayti1703 (talk) 20:11, 14 December 2013 (UTC)


 * Mojang isn't going to change the file format just because you're feeling lazy ;)  LB ( T 04:42, 15 December 2013 (UTC)


 * I think they wanted the description here on the wiki written differently, not a change in the file format itself. An equivalent calculation is . -- Orthotopetalk 06:54, 15 December 2013 (UTC)


 * Thanks Orthotope, that's exactly what I wanted. Fayti1703 (talk) 10:40, 15 December 2013 (UTC)

Merge request discussion
About this request.

I would like to vote against the merge. The section belongs with the rest of this page - the fact that using the commands requires you to look at this page doesn't mean we should merge the pages, as the command syntax is quite unrelated to the NBT structures described here.  LB ( T 03:49, 9 January 2014 (UTC)


 * I have to disagree with you. It took me a long time to find this, I never expected to find it in Chunk format. I expected it to be in the Tutorials/Command_NBT_Tags page. Toxicdonut1672483 (talk) 13:32, 10 January 2014 (UTC)


 * It is in that page, as a link. Just because there is now a command syntax to take advantage of the various NBT formats does not mean that the page describing the format should be merged with the page describing the commands - many other things use the NBT format, not just the commands, and you don't see merge requests for those.  LB ( T


 * Agreed; I'm also against the merge. I come here when writing MCedit filters and WorldEdit scripts, not just when using commands. I wouldn't expect the game's save format to be documented in a tutorial page. Besides, following this logic, Player.dat format would also need to be merged - and that doesn't even cover block, enchantment, status effect, and attribute IDs. It would be as backwards as merging Commands into Command Block. WolfieMario (talk) 08:41, 12 January 2014 (UTC)


 * Agreed as well, with all the points above. It simply isn't necessary. Skylinerw (talk) 19:45, 17 January 2014 (UTC)

Using "pseudocode"???
I see there is some useful "pseudocode", but how do I use it??? I want to make a mapviewing program. BTW, I know how to program in Java. Thanks! 64.180.204.56 04:48, 15 February 2014 (UTC)


 * What confuses you? If you know how to program in Java, the pseudo code on this page should almost nearly be copy-paste-able. We intentionally tuned it to Java instead of C/C++ because we knew more people used Java for Minecraft-related things.  LB ( T 05:52, 15 February 2014 (UTC)


 * Where do I put the code? How do I get to the level files from a completely seperate program? And, what does "almost nearly copy-paste-able" mean?
 * Thanks, 64.180.204.56 Gary Koopa


 * Your questions don't make sense. How much programming experience do you have? You can't try to go into this with little to no programming experience.  LB ( T 17:17, 23 February 2014 (UTC)


 * I have quite a bit of exprerience in Java, not in any other language, and I just started working on a Kirby game. I can work on really compicated things if I need. Does the code need to be inserted into a mod, or can I put it into a seperate mapviewing program, and if so, how? -Gary_Koopa 64.180.205.211 01:05, 10 July 2014 (UTC)


 * Since the code snippet in question makes no reference to any aspect of Minecraft, it doesn't matter where you use it. <font color="green" style="text-shadow: 0px 0px 8px #0f0;"> LB ( T 19:57, 10 July 2014 (UTC)

How do you access datatags?
I would like to know how to access datatags to see an entity(player)'s rotation, so I can use command blocks to summon firework bullets in a minigame. Would someone either tell me how or prove to me it can't be done? Thanks! 76.226.150.238 20:33, 15 June 2014 (UTC)


 * Use /testfor and/or target selectors. These questions are better asked on the forums. &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 21:50, 15 June 2014 (UTC)

Category Tags
I've seen that it gets pretty confusing at times when for example writing an MCEdit filter. For example: I tried to figure out the tags that determine wheter an ocelot is tamed or not. And on the ocelot itself it just says the Type of Ocelots and not the tag I was looking for. So I then realized that they we're longer up the page where the "Tameable animals" we're listed. And also there, it states about a format that will be changed in 1.8 but the new format is nowhere to be seen. So to make this page less of a mess I would suggest making each and every mob have their own list even though there might get duplicates. ▶ ZlingerZZ ◀ ( talk At 11:45, July 3, 2014 (Coordinated Universal Time).


 * You seem to have misread, there is a difference between "pre-1.8" and "for 1.8". <font color="green" style="text-shadow: 0px 0px 8px #0f0;"> LB ( T 22:55, 3 July 2014 (UTC)

Armor Stand - DisabledSlots
It's not that easy to see at first glance, that to disable placing Leggings you must calculate |1<<(armorPos+16) for the armorPos value of 2

It is explained, but it would be might be more helpful with a nice little table. Not sure of a good way to include one in the article, or if one should be included. So i'm placing one here in the talk for now at least.

Given the following values of ArmorPos

and the following calculations

we get the following resulting table

Oozebull (talk) 19:59, 13 August 2014 (UTC)

Mob NBT format - Equipment
For the Equipment tag in the "Mobs" section, the article claims that All 5 entries will always exist (even for players).

This is not true for players in snapshot 14w33c - the "Equipment" tag does not exist at all in the player data.


 * Ah, yes, this information was updated on Player.dat format but not here. Fixed. <font color="green" style="text-shadow: 0px 0px 8px #0f0;"> LB ( T 18:46, 20 August 2014 (UTC)

Would it be useful to add Command Examples?
Some people use this page as a reference for editing NBT tags with Command Blocks. Perhaps it might be useful to include one or two command examples in collapsible boxes for each tag? Or at least any where the usage isn't quite clear?

The downside I can see is it might clutter the page a bit, and it doesn't particularly have anything to do with the actual data structure which is the main purpose of the article. Kavukamari (talk) 10:08, 19 August 2014 (UTC)


 * I think it would add too much clutter to an already-long page. Examples of how to use tags would be useful, but would fit better on a tutorial page such as Tutorials/Command NBT Tags. -- Orthotopetalk 10:18, 19 August 2014 (UTC)


 * Just as I thought, the page is incredibly large already and I can see why that would be a bit too much. Perhaps I'll add a few examples over in the tutorial page then, if that would be a better place. Kavukamaritalk 12:28, 19 August 2014 (UTC)

chested horse tag
Does anybody know if the chested horse tag still crashes the game if used on a non-donkey/mule as of 1.8? Also, does anybody know if the chested horse crash only applies to regular horses and not zombie/skeleton horses or does it apply to zombie/skeleton horses too? I am confused about this and would really like some answers. My main confusion is that zombie/skeleton horses don't have a natural armor slot like donkeys and mules so that makes me think that the chested horse tag would work on them without crashing the game, but they are called a horse and can be summoned with armor like a horse, (although that can't be removed), so that makes me think that they would crash the game if they had chests. If someone could answer this it would be much obliged as I really don't want to crash and possibly corrupt my game over something like this. Please help and please don't delete this, I really need to know this for a certain project I'm working on. Thank you. Brickticks (talk) 19:29, 20 August 2014 (UTC)

Splitting the page into templates
This gave me an idea: I think it would be better to split out all the format trees into sub-pages to be used as templates. This way the currently massive page will shrink dramatically in size and it will be easier to edit specific information. Additionally, we can do some fancy things to have a link to click and expand to show inherited members (such as how Mob inherits from Entity, Tameable and Breedable inherit from Mob, Wolf inherits from Tameable and Breedable, Creeper inherits from Mob, etc). I think this will help comprehension as well. <font color="green" style="text-shadow: 0px 0px 8px #0f0;"> LB ( T 21:20, 4 September 2014 (UTC)


 * I think that could be helpful. I'm only trying out putting tile entity structure on pages, I haven't completely committed to it yet, but it does seem helpful to have a tile entity's data structure right there on the page, without having to scan through the entire tile entity section here looking for shared branches indentified by a tiny icon. It'll probably be even more helpful for mobs which have many more shared branches.


 * Shared branches often have notes about how the branch applies to specific entities though, which may be irrelevant info when transcluded to main articles. I could probably live with that if transclusion improves maintainability.


 * Instead of inherit links, I think it would be better if clicking on, say, EntityHorse just loaded its entire data structure from a subpage which itself transcluded data structures from Entity, Mob, Breedable, and Tameable, plus its own private data structure. That wouldn't preclude having those other subpages loadable (or just loaded) at the top of their sections too. &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 22:02, 4 September 2014 (UTC)


 * I've added my plan below. I don't really know how to go about implementing it so the formatting looks nice with inheriting. <font color="green" style="text-shadow: 0px 0px 8px #0f0;"> LB ( T 22:06, 4 September 2014 (UTC)


 * I'm not clear if you're talking about how to organize the article (as a giant collapsed/expandable treeview?), or organize the subpages.


 * I wouldn't use templates, just load subpages (subpages can load other subpages just like templates can -- there's nothing special about templates except their namespace is assumed by ). They could even use template conditionals or switches to change which information they present based on an id parameter or something (for example, the tile entity CustomName tag behaves differently for   than it does for containers). Templates are good when they'll be loaded into many pages (so you want a page-inspecific namespace), but these are very purposed to the chunk format article -- they'll get loaded into other articles too, but that's fine.


 * What does nbt/inherit do? Can we just use collapsible tables or LoadBox? &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 00:38, 5 September 2014 (UTC)


 * Oops, yes, I mean subpages and not templates. I'm still learning the ropes of MediaWiki.


 * As for nbt/inherit, this is what happens when you use LoadBox:


 * root
 * child 1
 * child 2


 * child 5
 * child 6


 * No idea how to fix that <font color="green" style="text-shadow: 0px 0px 8px #0f0;"> LB ( T 01:39, 5 September 2014 (UTC)


 * to in-line it. Add some styling, and…


 * root
 * child 1
 * child 2
 * child 2
 * child 2
 * That works surprisingly well. I don't think we would need to get rid of the bold.


 * Wiki tables don't seem to play nice in lists though. &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 04:44, 5 September 2014 (UTC)


 * OK, this is what I was thinking for the styling with inheritance for e.g. PigZombie:


 * PigZombie has these additional fields:
 * : Ticks until the Zombie Pigman becomes neutral. -32,768 to 0 for neutral Zombie Pigmen; 1 to 32,767 for angry Zombie Pigmen. Value depletes by one every tick if value is greater than 0.
 * : Ticks until the Zombie Pigman becomes neutral. -32,768 to 0 for neutral Zombie Pigmen; 1 to 32,767 for angry Zombie Pigmen. Value depletes by one every tick if value is greater than 0.
 * It seems the nested LoadBoxes don't work properly, which is a problem - we'd have to flatten the inheritance hierarchy and list all the bases up front. Also, it would be nice if the tree inside the loadbox lined up with the tree outside, do you know how that might be accomplished? It doesn't need to be precise alignment, just enough to emphasize that they're all at the same level of nesting. <font color="green" style="text-shadow: 0px 0px 8px #0f0;"> LB ( T 16:14, 5 September 2014 (UTC)


 * I think the show/hide/edit links are added with javascript, so we'd have to ask an admin's help with that. It may be that the javascript can't run on something that's not there yet.


 * They look aligned to me? Unless you mean, for example, Anger should line up with IsVillager, etc., in which case it's just a matter of adding an additional asterisk. But internal branches are going to make lining everything up impossible I think. The border line, though useful, may throw things off by a pixel too.


 * Let's talk about the article structure for a minute. Just to be clear, we're not talking about replacing everything with a single collapsed-but-giant treeview, right? I think it would make it hard to find things, and hard to link to them. I think I'd like to see the article retain its current heading structure, and each id would get its own treeview, and there describe its complete structure (with structures previously described initially hidden/unloaded), as I think you did with PigZombie above. But, instead of saying "PigZombie has these additional fields", we'd just say "PigZombie has these fields" (or just drop a treeview from PigZombie without the explanation). I think that will make it easy to find and link to things, and easy to incorporate data structures into articles.


 * By the way, all the links in your sig are linking to LB not LB1. &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 20:19, 5 September 2014 (UTC)


 * Yes, the icon for Anger should line up with the icon for IsVillager. Being a pixel off is perfectly fine. I just removed the asterisk from before the LoadBox template:


 * PigZombie has these additional fields:
 * : Ticks until the Zombie Pigman becomes neutral. -32,768 to 0 for neutral Zombie Pigmen; 1 to 32,767 for angry Zombie Pigmen. Value depletes by one every tick if value is greater than 0.
 * : Ticks until the Zombie Pigman becomes neutral. -32,768 to 0 for neutral Zombie Pigmen; 1 to 32,767 for angry Zombie Pigmen. Value depletes by one every tick if value is greater than 0.


 * Yes, you and I have the same idea for how the page will be. All of the sections will remain in place, etc. just that the page will contain 90% less use of the nbt template. The page will effectively loek identical except for the new options to show inherited tags.


 * And whoops, I fixed my signature now. I was originally LB before the curse merge and went through several username changes after the migration. I have also responded to you below in the Planning section. <font color="green" style="text-shadow: 0px 0px 8px #0f0;"> LB ( T 20:50, 5 September 2014 (UTC)

Planning
This is the planned list of pages, excluding talk pages.
 * Chunk format - the current page
 * Chunk format/Format - contains the tree from the NBT structure section
 * Chunk format/Entity - contains the tree from the Entity format section
 * Chunk format/Mob - contains the tree from the Mobs section and inherits Entity
 * Chunk format/Breedable - contains the tree from the "Additional fields for mobs that can breed" section
 * Chunk format/Tameable - contains the tree from the "Additional fields for mobs that can be tamed by players" section
 * Chunk format/Projectile - contains the tree from the "Projectiles have these additional fields:" section and inherits Entity
 * Chunk format/ShakyProjectile - inherits Projectile and adds the "shake" tag from the "Projectiles except..." section
 * Chunk format/Ageable - contains the "Age" tag from the "Items have these additional fields" section
 * Chunk format/Vehicle - contains the tree from the Vehicles section and inherits Entity
 * Chunk format/Hangable - contains the tree from the "Paintings and Item Frames share these additional fields" section and inherits Entity
 * Chunk format/TileEntity - contains the tree from the Tile entity format section
 * Chunk format/Nameable - contains the "CustomName" tag from the "Various containers may have these additional fields" section
 * Chunk format/Lockable - contains the "Lock" tag from the "Various containers may have these additional fields" section
 * Chunk format/9Slotted - contains the tree from the "Trap and Dropper have these additional fields" section and inherits Entity
 * Chunk format/Every entity - a page for all of the entity types in all the tables (even ones without their own unique tags), all inheriting from the correct templates as described on the page currently (LavaSlime should inherit from Slime)
 * Chunk format/TileTick - contains the tree from the Tile tick format section


 * I've added /Mob and /TileEntity.


 * A number of these entries shouldn't inherit anything because they won't be the top-level inheritance of specific entity types. For example, /Breedable and /Tameable are both inherited by EntityHorse -- if they both inherit /Mob, then EntityHorse will inherit /Mob twice. Better to have /Breedable and /Tameable not inherit /Mob, and EntityHorse inherits /Mob, /Breedable, and /Tameable separately. Same with /Nameable and /Lockable. I've gone ahead and removed those inheritance notes (obviously, you can re-add them if I'm confused about something).


 * If something only has one or two tags, and is only added to two or three write-ups, it may not be worth making a subpage for it, just add it directly to the appropriate structure write-ups. For example, I wouldn't bother with Ageable or 9Slotted (they only have one tag each and are only added to two write-ups each), but ShakyProjectile, Nameable, and Lockable, although having only one tag, are added to a bynch of structures so are probably useful (but maybe not).


 * /Items may be a useful subpage, if we use a parameter to modify the described slot count.


 * Do we need /Format? That won't get inherited by anything, or get transcluded into other articles, will it?


 * &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 20:19, 5 September 2014 (UTC)


 * Ah, then I think we'll be forced to use the flattened inheritance model instead of nesting. In that case we won't need to fix the javascript for LoadBox. <font color="green" style="text-shadow: 0px 0px 8px #0f0;"> LB ( T 20:50, 5 September 2014 (UTC)


 * Well, there are still examples of "multi-generational" inheritance which could use nesting (e.g., EntityHorse < Mob < Entity), in addition to those "drop-in" data structures, but yeah, since fixing LoadBox nesting might require some attention, let's try doing it flat first and see how it goes. So … none of the subpages would themselves have LoadBoxes within them. … Right.


 * Let's give it a few days to see if anyone else has any suggestions before we start drastically changing the article. But we could probably start creating the subpages and play around with building treeviews from them somewhere else (create the subpages where they should be, but do experiments somewhere else -- maybe here). Basically it'll just be copying the lists into appropriate subpages and then figuring out if the number of asteriskses (?) needs to be modified to get things to line up correctly. (Huh, I have two dictionaries immediately available to me, and neither can confirm for me the plural of asterisk.) Tile entity format might be a good place to start since its mid-level complicated (complicated enough to test things but not too complicated) and it's the one I care about for article transclusion. : )


 * Ah, here we go. For ShakyProjectile, Nameable, and Lockable, just use a transclusion instead of a LoadBox. That way we keep things consistent with a common transclusion, but we don't have to worry about nesting issues and force the user to click a link just to see a single tag. It'll just appear as a tag like all the other id-unique tags, even though its loaded from a subpage. &mdash;munin &middot; Grid_Book_and_Quill.png Grid_Stone_Pickaxe.png &middot; 22:01, 5 September 2014 (UTC)