Talk:Chunk format/Archive 1

From Minecraft Wiki
Jump to: navigation, search
This is an archive page of Talk:Chunk format. Do not edit this page.
New sections can be added at the current talk page.


Disk Usage[edit]

"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 (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|C) 23:32, 1 December 2012 (UTC)

Deleting Chunks[edit]

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 (Talk) 21:49, 8 July 2012. Please sign your posts with ~~~~

Confusing format[edit]

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|C) 12:13, 10 September 2013 (UTC)

InGround tag[edit]

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[edit]

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[edit]

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[edit]

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[edit]

Are they in 16x128x16 or 16x256x16 since the last update??? –Preceding unsigned comment was added by Addamondes (Talk|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[edit]

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[edit]

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[edit]

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|C) 23:47, 14 September 2012 (UTC)

On the topic of riding[edit]

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. 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|C) 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|C) 20:48, 19 March 2013 (UTC)

Enderman Anger[edit]

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|C) 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|C) 02:09, 26 January 2013 (UTC)
Yeah I gotcha Toadbert 20:28, 26 January 2013 (UTC)

Chunk vs Chunk Column[edit]

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? 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|C) 20:37, 19 March 2013 (UTC)

MobSpawner EntityId and SpawnData[edit]

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. -- 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[edit]

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.-- 00:27, 17 April 2013 (UTC)

See the above conversation Talk:Chunk format#MobSpawner EntityId and SpawnData - I think the tags were deprecated for a good reason but nobody would listen ;) LB(T|C) 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.-- 03:27, 18 April 2013 (UTC)

Rounding decimals[edit]

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[edit]

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|C) 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[edit]

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:

  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.

Quartzmmn (talk) 03:41, 22 September 2013 (UTC)

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|C) 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[edit]

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|C) 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 baseColor + (markings * 256). -- 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[edit]

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|C) 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|C)
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"???[edit]

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! 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|C) 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, 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|C) 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 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. LB(T|C) 19:57, 10 July 2014 (UTC)

How do you access datatags?[edit]

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! 20:33, 15 June 2014 (UTC)

Use /testfor and/or target selectors. These questions are better asked on the forums. —munin · 16 px 16 px · 21:50, 15 June 2014 (UTC)

Category Tags[edit]

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 | contribs | edits ) 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". LB(T|C) 22:55, 3 July 2014 (UTC)

Armor Stand - DisabledSlots[edit]

It's not that easy to see at first glance, that to disable placing Leggings you must calculate <<(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

ArmorPos Slot
0 Hand
1 Boots
2 Leggings
3 Chestplate
4 Helmet

and the following calculations

Calculation Effect
1<<armorPos Disable remove of armorPos
1<<(armorPos+8) Disable replace of armorPos
1<<(armorPos+16) Disable placement of armorPos

we get the following resulting table

Flag Number Slot Effect
1 Disable removing Everything, and placing/replacing Hand
2 Disable removing Boots
4 Disable removing Leggings
8 Disable removing Chestplate
16 Disable removing Helmet
256 Disable replacing/removing Hand
512 Disable replacing/removing Boots
1024 Disable replacing/removing Leggins
2048 Disable replacing/removing Chestplate
4096 Disable replacing/removing Helmet
65536 Disable placing Hand
131072 Disable placing Boots
262144 Disable placing Leggings
524288 Disable placing Chestplate
1048576 Disable placing Helmet

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

Mob NBT format - Equipment[edit]

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. LB(T|C) 18:46, 20 August 2014 (UTC)

Would it be useful to add Command Examples?[edit]

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[edit]

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)

You should probably test it in a new world that doesn't have any of your stuff in it. I just made a new Superflat world (preset ge) dedicated to testing this, summoned a chested horse using /summon EntityHorse ~ ~ ~ {Tame:1,ChestedHorse:1}, and then rode it and checked my and the horse's inventory. None of these actions crashed the game, and I was using the latest version 1.8.4. Therefore, there is no chested horse crash. (Note: Maybe it *SOMETIMES* crashes, so I would recommend using a dedicated world to test, just to make sure it never crashes.) 10:26, 4 May 2015 (UTC)
Oh, OK, thank you. I tried making a skeleton horse with chests, and it worked perfectly. Well, almost perfectly, when I tried to put items in the chests the game crashed, so perhaps that's something that should be noted on the wiki page. I know it wasn't just some random crash for some random reason, as I repeatedly tried to put items in that chested skeleton horse and every time, it crashed. I tried command blocks, bones, and a singe piece of stone block. All crashed the game, and for some reason, my skeleton horse was cloned, twice, by these crashes. Perhaps it would be noteworthy to put this information on the wiki, it's up to you really, I'll just sit here, with my faulty chested skeleton horse. Hope this helps. P.S. For some reason, all the bats in my world went wonky after the crashes too, just sayin'. Brickticks (talk) 15:56, 26 May 2015 (UTC)
I have been playing on the new 1.9 snapshots w3x-w41b and have been using a chest horse without any crashes. Of course a chested horse has to be summoned in, but I think what ever crashed it before must have been sorted out. Laige 04:05, 9 October 2015 (UTC)

Splitting the page into templates[edit]

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. LB(T|C) 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. —munin · 16 px 16 px · 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. LB(T|C) 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 Control 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}}? —munin · 16 px 16 px · 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 LB(T|C) 01:39, 5 September 2014 (UTC)
float=none to in-line it. Add some styling, and…
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. —munin · 16 px 16 px · 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:
    • All fields from Zombie

    •  Anger: 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. LB(T|C) 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. —munin · 16 px 16 px · 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:
  • All fields from Zombie

    •  Anger: 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. LB(T|C) 20:50, 5 September 2014 (UTC)

It's easy to make nested loadpage work. I didn't bother adding that originally because I didn't want people nesting them and thus creating multiple loading waits (one is bad enough, frankly), however I think this is a valid use-case. I don't think this can be done properly just using {{LoadBox}}, instead I think we need a script that merges the list content together, similar to transclusion.

  • Inherited from Zombie [show] (pretend this stuff is collapsed) User:Majr/Chunk format/Zombie
    •  Anger: 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.

⎜ 09:17, 8 September 2014 (UTC)


This is the planned list of pages, excluding talk pages.

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?
munin · 16 px 16 px · 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. LB(T|C) 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. —munin · 16 px 16 px · 22:01, 5 September 2014 (UTC)
I've added /Items above, and I've italic'd entries I don't think we need. Agree?
I can't get wiki tables to work in treeview lists, but I can put a treeview list in a collapsed table. Still need to play around with styling, I think, but I've added samples for Banner and Control below. —munin · 16 px 16 px · 18:18, 6 September 2014 (UTC)
Yes, it's fine with me if we don't make those pages. The programmer in me just wanted to refactor all commonalities between things as much as possible. LB(T|C) 23:32, 6 September 2014 (UTC)
So the main thing bothering me now is that subpages intended for LoadBoxes start at one asterisk, while subpages intended for transclusion start with two, which makes repurposing difficult (for example, if we wanted to list tags common to all entities at the top of the section as well as in LoadBoxes for each entity). —munin · 16 px 16 px · 01:19, 7 September 2014 (UTC)
I think that's why I originally tried to use templates - is there a way with normal sub-pages to pass parameters like with templates? LB(T|C) 02:09, 7 September 2014 (UTC)
Yes, when you transclude the subpage (then it's exactly like a template, except you have to specify the namespace, which you can abbreviate with a colon when its the same as where you're transcluding from) -- in fact, I'm already using them in a couple subpages. But not when you use LoadBox. And I haven't been able to put collapsible tables in the lists (which would be a possible alternative to LoadBoxes, though it could make for a huge page). It is working, though, with that repurposing caveat. —munin · 16 px 16 px · 05:35, 7 September 2014 (UTC)

Ah, so then, we would just have to make the default 'no parameters given' version be the version that goes in the LoadBox, right? LB(T|C) 15:17, 7 September 2014 (UTC)

I think so. The only place so far where I want to do a parameter in a LoadBox is to actually specify the correct entity id, tile entity id, etc. The id is in a common data structure which makes sense to put in a LoadBox (for example, I wouldn't want to transclude Entity into every single entity -- that would make the article huge even if it's initially collapsed), but it would be nice to actually specify the correct id in the data structure (like I've done in some articles). We may find some other exceptions too. —munin · 16 px 16 px · 22:39, 7 September 2014 (UTC)
So THIS is why I was having trouble finding some tags. As someone who constantly needs to double-check what tags do, you are making it EXTREMELY FUCKING ANNOYING to find them on this page by hiding them in collapsible tabs. When ctrl-f doesn't work, you have to pick through and find where the damn thing is hidden on this page. Dude, screw these collapsible tabs, there's no point in them. When a page has a nice large amount of information like this in one place, why do you insist on making it collapse. I may just straight remove these changes myself if you're not going to. If you really want to "organize" this page more, set up a table of contents for the top of the page like does. When you collapse everything at random locations on the page you're just making it stupidly harder to find things. TrazLander (talk) 17:09, 4 June 2015 (UTC)
Fixing the Ctrl+F issue isn't a hard thing to do. This page is massive and is a huge pain to keep up to date, we're just trying to shorten it and make it easier to maintain. 90% of the information on this page shouldn't even be here, it's just sort of grown out of control organically. Do you have a suggestion that doesn't involve making the page even longer? LB(T|C) 17:30, 4 June 2015 (UTC)

Eight months later, where are we on this idea?[edit]

I'm glad I read this first. I was wondering whether to start putting NBT sections on all the mob and vehicle pages. I think it would be better if this were done first. My question is, Munin295, LB1, how ready-to-go do you think this idea is? It's at the stage where it's mostly ready, you're just trying to make LoadBox work the way you want, or something, is that about right? – Sealbudsman (Aaron) frameless t/c 05:16, 20 May 2015 (UTC)

There are already a few /ED pages, Bat/ED, Zombie/ED, Bat/ED1, {{static link|Mobs/ED}} and {{static link|Mobs/ED1}}, all created by NickTheRed37. –LauraFi - talk 13:48, 20 May 2015 (UTC)
Just trying to figure out if it's working to people's satisfaction before I would start to run with it ... NickTheRed37? – Sealbudsman (Aaron) frameless t/c 18:13, 21 May 2015 (UTC)
If you can get it to reasonably work, I say go for it. It doesn't have to be perfect (wikis can be improved later). —munin · 16 px 16 px · 18:25, 21 May 2015 (UTC)
I've lost much interest in this... especially since I mostly withdrew from editing in English wiki in favor of Russian wiki. Currently I may have even less interest due to resuming to play games like OpenTTD. — x18px NickTheRed37 (talk|contributions) 18:47, 21 May 2015 (UTC)
I say just start making the sub-pages and we'll tweak them over time. My original hesitation was just because I have a tendency to try to be perfect on the first try, but as Minin says, it doesn't have to be perfect on the first try. I just want to avoid a maintenance nightmare. LB(T|C) 05:10, 25 May 2015 (UTC)
I've attempted to use the already existing Creeper subpage and creating a load box, however I've ran into a few problems. Is there any way to stop the loadbox from jumping below the side table when expanding and also retaining the entity sprite template (doesn't seem to work when placing it in the loadbox template)? GoandgooTalk
23:57, 7 November 2015 (UTC)
Actually using the collapsible tables from below is probably better, although perhaps the wikitext is not as elegant. GoandgooTalk
00:03, 8 November 2015 (UTC)


I've just about finished converting all of the entity pages to the new format, I just have the projectiles section left to do. All of the transcluded pages are subpages of the base page with their respective data. (e.g. Wither/ED, Item Frame/ED etc). Where there are more than 1 entity for a page (e.g. shulkers), the content is transcluded from a /ED page and a /ED1 page (e.g. Shulker/ED and Shulker/ED1). All of these pages are in :Category:Entity data pages. For all the top-level data pages, such as Chunk format/Tameable, I've created the category :Category:Top-level data pages so these can be easily found.

After the projectiles section is finished, I plan to convert the existing Block Entity pages into the new format and continue to create collapsible tables for them. Thoughts, suggestions, potential improvements to what has been done so far? GoandgooTalk
12:17, 8 November 2015 (UTC)

It looks like you're doing great work! Unfortunately I can't be very helpful at this time. LB(T|C) 07:38, 9 November 2015 (UTC)
I'm basically finished! Is it still necessary to list every single entity with a hidden header as the table of contents is now quite large considering the shorter length of the page? Perhaps anchoring the entities might be better considering the length. I've also experimented with the transclusions not being part of a load box (i.e. uncollapsible by default) but I can't find any good way to do this as the transcluded tree does not connect with the non-trascluded one (see Zombie/ED). GoandgooTalk
11:37, 9 November 2015 (UTC)
Overall looks good. I agree that the headers should go, at least if all the sections are going to remain collapsed. I'd certainly get rid of the loadboxes. They're for when the wiki is too slow to load a large amount of content all at once, whereas this is small/tiny amounts of content, which load fast. Using loadboxes for this actually makes the page slower.
I was thinking the other day about all the sub-page stuff we do, and how it would be better if we could keep the content on the page itself, then transclude part of the page into collection pages like this (like is done with snapshot pages using <onlyinclude>). I didn't want something like SMW as it's far too complicated, slow, and somewhat buggy. Instead I came across Labeled Section Transclution, which looks like it would do the job, and apparently has been included in DPL all along, so if it weren't for a bug in DPL3's implementation, we looks like we could start testing it right away. MajrTalk
02:26, 10 November 2015 (UTC)
That labelled section transclusion seems like a great extension, when would we be able to use it? In regards to removing the loadbox, is there any good way to do this and keep the data tree continuing without breaks? (If you look at Zombie/ED, you can see that the tree has a break where the data is transcluded from Zombie/ED1. GoandgooTalk
07:33, 10 November 2015 (UTC)
That would be because the content of Zombie/ED was wrapped in a div, thus it move into a separate unordered list upon page rendering. Since it really didn't need to be wrapped in a div, I removed that fixing it. It should be easy enough to remove the load boxes, though trying to keep the collapsible factor is hard, since lists don't seem to like containing tables, and the collapsible Javascript does not support divs.
As for LST, I've seen it used on Wikipedia where subpage data seems to be frowned upon, and it worked very well over there (most notably used there for episode seasons being transcluded onto an "List of episodes" pages). I would agree to switching to that as a more idea solution than all these subpages. KnightMiner t/c 18:24, 10 November 2015 (UTC)
Hmm, when trying to transclude Zombie/ED1 into Zombie Pigman/ED, the top of the tree connects but not the bottom part. Is there any way to fix this KnightMiner? GoandgooTalk
01:32, 11 November 2015 (UTC)
Once the bug is fixed. You can of course test it now, if you just ignore the errors that the section tags produce. They seem to work fine otherwise.
The breaks were due to surrounding whitespace, so was easily fixed. As for collapsing, we could have the lists be separate and do the treeview connection manually (can be easily done with a class), or use HTML lists rather than wikitext, less convenient than wikitext lists but if we modified the NBT template (or made a new one) to include the list item, it wouldn't be so much of an issue. MajrTalk
10:34, 11 November 2015 (UTC)
Ok, so I've fixed those errors where appropriate and for the meanwhile, I've gotten rid of any unnecessary load boxes. I'd probably wait to see one of you guys implement this new method because I am quite prone to making errors on things like this, so once you guys have set up the system I can do what ever conversions are necessary. GoandgooTalk
11:43, 11 November 2015 (UTC)
One more thing, in terms of actual page content it states that MinecartSpawner inherits all fields from the MobSpawner block entity, excluding the base block entity fields - is this just the id, x, y and z tags or are there others as well that are not inherited? Skylinerw Anomie x GoandgooTalk
11:46, 11 November 2015 (UTC)
The "inherited" fields in 15w45a are: Delay, MinSpawnDelay, MaxSpawnDelay, SpawnCount, MaxNearbyEntities, RequiredPlayerRange, SpawnRange, SpawnData, SpawnPotentials. 1.8 also has EntityId. In code terms using MCP class names, both EntityMinecartMobSpawner and TileEntityMobSpawner include a MobSpawnerBaseLogic that they call to implement things. Anomie x (talk) 12:24, 11 November 2015 (UTC)
I've made an example of the inheritance format I'm going for here (obviously just transcluding pages since DPL isn't fixed yet). It keeps the inherited fields inline so the tree structure actually makes sense, and it uses the newly updated collapsing script so we don't have to have tables everywhere. MajrTalk
09:36, 17 November 2015 (UTC)
I think it looks good. I would agree to using that (especially since it removes the annoying load times) KnightMiner t/c 17:06, 7 December 2015 (UTC)

Do armor stands count as mobs?[edit]

I know that armor stands have the equipment tag and I was wondering if they have any other tags that belong to mobs. If they do, shouldn't there be a note of that on the page? 20:14, 21 September 2014 (UTC)

They do appear to be a subset of mobs, having all of the available Mob tags at their disposal. Even though they don't really seem like mobs, they probably do belong under the "Mobs" heading instead of "Other". Skylinerw (talk) 07:10, 25 September 2014 (UTC)

Fishing Rod Bobbers[edit]

Despite the bobbers not having a valid entity type (same problem as thrown eggs) they still have projectile NBT fields, and they can still be selected and edited with /entitydata with @e[name=...]. Why doesn't this page show their icon or name anywhere? Should they be added? 13:38, 30 November 2014 (UTC)

I believe they should. They can be selected by name ("unknown"), they can be teleported and killed, and they do have some tags specific to them ("OnGround"). In all respects other than the fact that they can't be selected by type, they are like any other entity. KingSupernova (talk) 04:33, 12 March 2015 (UTC)
"unknown" is given to entities that don't have a name. If more unnamed entities are added, they would also be "unknown". Since this page is documenting a file format, it only contains information about things that are saved to disk. Fishing bobbers are not saved, so this page should not document them. LB(T|C) 18:49, 12 March 2015 (UTC)
One of the main uses of this page is to find a list of all the tags for entities and blocks, to use in commands. With that in mind, I think the page should list all entities, so people have a way to find out the tags that affect them. KingSupernova (talk) 04:28, 13 March 2015 (UTC)
Fishing rod bobbers don't have a unique name, and they are not saved. As far as I know, they have no further tags than those already documented on this page (see the section on projectiles). To document them is as simple as this. LB(T|C) 07:04, 14 March 2015 (UTC)
Ok, my mistake. I thought that they had some unique tags. KingSupernova (talk) 09:20, 14 March 2015 (UTC)
Does anyone remember SethBling's video on Grappling hooks ? In that video He used Fishing Bobbers to, well, grapple. Does anyone know how he did that ?

Block entity vs. tile entity[edit]

If a discussion of this should occur, I recommend it continue a discussion started at Talk:Block_entity#Block_entity_vs._tile_entity. —munin · 16 px 16 px · 22:49, 7 December 2014 (UTC)

Chested Horse Crash Bug APPEARS NOT TO EXIST[edit]

I opened a new Superflat world with preset ge and summoned a chested horse via /summon ~ ~ ~ {Tame:1,ChestedHorse:1}. I got on it, checked its inventory, and none of this caused the game to crash. Could someone do some research into this and find out if the chested horse crash bug really doesn't exist, or if perhaps the surrounding world affects whether the bug happens or not? 10:33, 4 May 2015 (UTC)

I can confirm that the bug has been fixed. All horse types get a chest (in fact, a zombie horse has a unique texture for its chest). I've removed the notice. Skylinerw (talk) 15:36, 4 May 2015 (UTC)
I was able to summon command a skeleton horse, and can confirm that the ChestedHorse tag still has one small problem. Whenever one attempts to place an item into the chested horse, (provided it's not a donkey or mule, at least), the game crashes. Thus, having a chested horse will only be aesthetically pleasing, and not functional. Hope this helps. Also, if you do attempt to place items in that chest, for some reason, (and I don't know if it was just an isolated case or not), all bats in your world will go wonky, and the horse will be cloned every time the game crashes as a result. Hope this helps others not make the same mistake I did, (although, I'm happy to report that after a while, all my bats returned to normal). Brickticks (talk) 17:13, 26 May 2015 (UTC)
I have readded the notice to the page. The user who removed the notice has been notified. In fact, this is actually the intended behavior per Dinnerbone:

Horses are not supposed to have chests.

on MC-16234
BDJP (t|c) 19:56, 26 May 2015 (UTC)
Actually, what I said was, you can still have a chested horse in game, you just can't put items in the chest, the chests will still be there, but they will only be aesthetically pleasing, and won't actually allow items to be placed in them. Just summoning the horse won't crash the game, but attempting to place items in the chests on it will. So, you wording is a little off. The way you've worded it makes it seem like chested horses can't exist at all with out the game crashing. They can in fact exist, they just can't have items placed in the chests they're summoned with. I hope this helps with the wording of the notice. Brickticks (talk) 13:23, 27 May 2015 (UTC)
Chests did crash the game at one point. It may have been fixed. 05:36, 29 May 2015 (UTC)

Updating NBT data from snapshots?[edit]

Just wondering if this is still something we'd be doing, as there's been plenty of additions and changes thus far in 15w31a. Skylinerw (talk) 15:45, 29 July 2015 (UTC)

I did that last time and noone seemed to mind; but then again, that was just adding new tags, not changing old ones. Maybe we should hold off for now? Firebastard (talk) 04:27, 30 July 2015 (UTC)

So far I think the ones changes made to tags was a status of "deprecation" (for Equipment and DropChances). I think we'll be set to add the other tags, but I won't mark the old ones as deprecated myself. Skylinerw (talk) 04:33, 30 July 2015 (UTC)
I just have something to say, the Structure block (which can only be placed by setblock) has a tile entity. The tags and their default values are: metadata:"",mirror:"NONE",ignoreEntities:0b,author:"",posX:1,mode:"DATA",posY:1,sizeX:0,posZ:1,name:"",id:"Structure",sizeY:0,sizeZ:0 and the x y z tags which all tile entities have. Sorry if I'm doing something wrong, but this is the first time I use the Talk in minecraftwiki FVbico (talk) 13:25, 30 July 2015 (UTC)
I'm not sure wether this is intended on not, but when I spawn tnt in 15w36d it has the tag Fuse as short not as Byte, I don't exactly know what to change the wiki page to, but it seems to have changed (found it after my tnt replacement broke) FVbico (talk) 13:37, 9 September 2015 (UTC)

Classifying ShulkerBullet[edit]

I'm not sure where to put ShulkerBullet if I were to add it. It doesn't have the same fields as a projectile, but that is what I would call it. Firebastard (talk) 04:28, 30 July 2015 (UTC)

ShulkerBullet directly extends the Entity class rather than any Projectile. The Shulker mob itself actually extends SnowMan, interestingly enough. Skylinerw (talk) 04:32, 30 July 2015 (UTC)

Outdated tags[edit]

Much of the information on this page seems to be outdated and should be removed, according to the style guide. Those which say pre-1.8 etc should be removed. Does deprecated refer to the tag still being in the game, but no longer used, or no longer existing? If they no longer exist then they don't need to be on the page. GoandgooTalk
05:20, 1 August 2015 (UTC)

Would we need to get a History section up and running to record removed tags?
As far as deprecated goes, it would be for tags that are still in the game but are considered "legacy". Unfortunately what is considered "legacy" is a bit vague since developers don't outright tell us. We'll need to come up with a precise definition for the sake of consistency.
To suggest a definition to roll with: "tags are deprecated if they are checked for data only when another tag does not exist". For example, the "potionValue" integer tag for ThrownPotion entities is only checked when a "Potion" compound tag does not exist on that entity. That would consider "potionValue" deprecated since there's a preferred alternative when checking the data. "potionValue" won't be stored on the entity afterwards though, but having the definition rely on whether it's saved on an entity won't work because the "Team" tag, which is a new tag with a specific function on loading, is not saved on the entity. Open to suggestions or refinement, of course! Skylinerw (talk) 15:18, 1 August 2015 (UTC)
As Skylinerw says, if the tag still has code in the game for it, it should stay on this page. LB(T|C) 16:46, 1 August 2015 (UTC)
Having a history table to document removed tags would definitely be helpful. That way we can make it so the main content only displays information from the latest version, like the rest of the wiki. GoandgooTalk
01:25, 8 August 2015 (UTC)

Minecraft 2.0 April Fools Entity Tags[edit]

I am posting this here in addition to the Minecraft 2.0 Talk page about that versions unique Entity Tags. I don't want to mess with such a complex page, and even fight over if this info is even important to add. So I am leaving it here for the comunity to decided; at least then its here for those that need it.

The Pig (Pony) is just a normal pig with a tag integer ModelType:1 to call the skin change; ModelType:0 is of coarse the normal Pig.

Similarly the Cow (Horse) has a tag integer Type:1(Not ModelType). Mooshrooms in this version appear to look like normal cows and cow (horses), but with mushrooms on their backs. They too have the tag.

The Redstone bug is just a Silverfish with a tag integer Color:######### and the integer is a really high number (8 digets). I did a test and change the tag to 99999999 which resulted in a white silverfish; again I tested with another number and got a yellow silverfish, so I'm sure every color is possible. The normal silverfish has a tag integer of Color:0.

The Friendly wither is Id:WitherHug I can't figure out a numerical Id, perhaps the Id numbers were phased out already by that time. Tell me if you know a way. I tried to make spawner for the WitherHug, and although it showed a WitherHug inside, only pigs were spawned. I think it is just similar to how a spawner can't spawn a normal WitherBoss. Additionally WitherHug has a tag short Heads:0 which increases as you grow heads on it.

The chicken has a tag byte DiamondChicken:0 and 1 if it is a diamond chicken. So perhaps the name "blue chicken" should be dropped from theMinecraft 2.0 wiki page in my opinion.

The domesticated animals (the tame-able / feed-able ones) all have an additional tag byte Fatness:#.

Sheep have the additional tag byte Floating:0 and 1 if they are floating.

The PigZzmbie is holding an enchanted sign with enchantments id:16 lvl:4 and id:19 lvl:2. You can look those up as I'm not that interested in what the enchantments are.

The Furnace tile entity has a tag integer Heat:##. I didn't care to look much more into it, but the integer was 40 and I had only just started smelting iron ore in it; and a sec later 73. I'm not sure how long before it explodes.

I can't find and special tags for the Flopper (dropper) tile entity, so it shooting out fish must be in the Java code. Nor can I find anything with that causes the speach bubbles on blocks.

I found this info using Mcedit and the NBT Editor filter within MCedit. Laige 17:56, 9 October 2015 (UTC)

Missing tags[edit]

Can someone add the Type tag from 15w41a for boats, the ShowBottom tag from 15w44a for ender crystals, the Potion to AreaEffectCloud from 15w44b, powered to note blocks from 15w34a and Potion to AreaEffectCloud. Now that I've added the history table, it should be easier to spot other missing tags. GoandgooTalk
09:03, 6 November 2015 (UTC)

 Done. Skylinerw (talk) 02:56, 7 November 2015 (UTC)
Thanks, is there anything else from the 1.9 snapshots that are missing? GoandgooTalk
04:08, 7 November 2015 (UTC)
MinecartHopper supports the LootTable and LootTableSeed tags, though I'm not sure when that happened. The UUID tag for Entity has been removed in 15w33 (not sure which a, b, or c). I should mention that all fireballs (DragonFireball, SmallFireball, Fireball, WitherSkull) inherit the "direction" tag from a 'FireballBase' class, not just on Fireball and WitherSkull. New to the snapshots, that base class also has a life integer tag as of 15w43a, which is internally the same as the life tag on arrows (except 600 ticks instead of 1200). On top of that, they all have a power list tag as of 15w43a that acts like direction but without resistance. Skylinerw (talk) 17:53, 13 November 2015 (UTC)

About These New Collapsibles[edit]

I personally find these new collapsibles to be rather annoying, a step backwards in terms of user friendliness. My main issue with it is that, when expanded, the headers and collapse buttons of each section move various distance to the right. If I open one, glance through it, and quickly decide that it isn't what I'm looking for, I'd like to be able to easily hide it without having to move the mosue. This is compounded by them not all moving the same distance to the right, so I can't simply build up muscle memory for it (yes, I visit this page enough for that to be plausible). The differing distances also make it a bit more unfriendly to navigate if I have multiple sections open at once, as I can't glance check the entity/block that the tags are referring to as easily.
I propose that they be changed to have the headers and show/hide buttons remain in the same position when expanded, like "Entity Data" and "All mobs have these additional fields:".
-- Mr Pie 5 (talk) 02:13, 1 December 2015 (UTC)

 Support, that would be a definite improvement. – Sealbudsman talk/contr 02:22, 1 December 2015 (UTC)
I agree that it's annoying, but I'm not sure what the right way to fix it is. The problem seems to be that table headers are centered by default; when collapsed, the header is the entire table, so the whole thing floats left. Once expanded, the table content is wider than the header, so the header jumps to the right to stay centered within the table. Adding style=text-align:left keeps the header on the left side of the page, but the show/hide button still moves. Forcing the table width to be constant (e.g., with width=100%) stops the jumping, but forces content to be below the entity ID tables, instead of flowing around them. Someone who's better with web design (Majr and Dinoguy1000) might have a more elegant solution. -- Orthotopetalk 03:07, 1 December 2015 (UTC)
(edit conflict)  Comment Maybe the collapsibles were added to shrink the article. Collapsibles can be done where the table shows by default, so the user can choose to hide whatever takes up space. The Blobs16px 03:12, 1 December 2015 (UTC)
 Clarification The collapsibles themselves aren't the issue (not my issue, at least), it's how the collapsibles are formatted - the headers and buttons move around the screen rather than remaining static.
-- Mr Pie 5 (talk) 03:33, 1 December 2015 (UTC)
On Majr's test page, this problem doesn't persist. I think we will eventually switch to that format, not entirely sure of the specifics of how/when we will transition. GoandgooTalk
11:26, 1 December 2015 (UTC)
It could have been implemented immediately, but there was no reply. Anyway, the issue here could easily be fixed by setting the button to be inline and setting the table header to left aligned, but it'd be better to get rid of the tables entirely. MajrTalk
05:19, 3 December 2015 (UTC)
Majr, how can I make it so the content in the "All mobs have these additional fields:" collapsible is not purple? GoandgooTalk
05:47, 3 December 2015 (UTC)
Nested treeviews are coloured purple (actually lavender), and the box itself is wrapped in a treeview for some reason. MajrTalk
10:28, 3 December 2015 (UTC)
Hi Majr, I was attempting to convert all of the mob data pages to this new format. It was displaying fine on all their respective pages, then suddenly when converting the Chunk format page to the new data include template, something seemed to fail and now nothing is templatised from below Pig all the way down. Not entirely sure what is going on/what I've done wrong. GoandgooTalk
11:51, 12 December 2015 (UTC)
The entity tree is bigger than I expected, it's exceeding the post-expand include size after only 16 transclusions. I guess we'll have to go for a revised page loader approach, so we only load it once. I've been meaning to get around to some page loader improvements anyway. MajrTalk
11:32, 14 December 2015 (UTC)
Ok, once we find a new method to the page loader, I'll try implementing it on the mob articles. In the meanwhile, should I wait for these changes or revert what is already on the page so it is readable again? GoandgooTalk
21:31, 14 December 2015 (UTC)
I've now done this. One unrelated thing I noticed, why are horses not marked as tameable? MajrTalk
09:20, 16 December 2015 (UTC)
Horses extend the "Animal" class rather than "Tameable" and thus do not have the "Sitting" tag (and have "OwnerUUID" via direct implementation, rather than from inheritance). Skylinerw (talk) 09:25, 16 December 2015 (UTC)
Can you change the data transclude template so that the correct image/link can be added without changing the name of the mob? GoandgooTalk
09:30, 16 December 2015 (UTC)
I know this is being a bit nitpicky, but is there a way that the tree can finish if the mob has no unique tags of its own? E.g. for Giant, making it so the tree doesn't extend beyond the last entry. GoandgooTalk
09:36, 16 December 2015 (UTC)
Maybe we should only list mobs with unique tags? Then just have a note, saying that "X mobs are not listed because etc." MajrTalk
09:41, 16 December 2015 (UTC)


I still think it's better to have individual pages for each entity - this was one of the main reasons for the project (from above topic) in terms of increasing readability. Previously the page had the individual tags and specified which entities they were used for, but this started to get confusing especially with the Projectiles section (where each projectile can inherit other tags that only some other projectiles share) so it was decided that each entity having it's own section is more beneficial for readers. This is not too big of an issue either, if the trees can't be changed then I think it's still ok.

Are the templates set up/ready for conversion of the other entities yet? GoandgooTalk
09:50, 16 December 2015 (UTC)

There's no simple way to do it unfortunately, as the (for example Template:Nbt inherit/entity/template) page is statically included. I'll have a think about some way to work around that, maybe a class that forces the tree to end.
Should be. MajrTalk
10:27, 16 December 2015 (UTC)
Can you change the data transclude template to allow the use of other images? This is needed for the projectiles section. GoandgooTalk
02:08, 17 December 2015 (UTC)
Majr, the ThrownExpBottle and ThrownPotion sprite icons are displaying incorrectly because their sprite uses ItemSprite rather than EntitySprite. GoandgooTalk
05:46, 17 December 2015 (UTC)
Nevermind, I fixed it. Should I be using the sprite parameter (as was what I did) or change it from entity to item for {{{1}}}. GoandgooTalk
05:55, 17 December 2015 (UTC)
They're entities, so {{{1}}} should be entity, yes. Also, they are working, the sheet is just cached with the old images. MajrTalk
06:01, 17 December 2015 (UTC)
Is there any way that the nbt inherit template can be indented on pages such as Splash Potion/ED so the indented layout of the potion/item collapsible boxes can be preserved but without using the load boxes that are there? (placing a * in front of the template doesn't work) GoandgooTalk
06:32, 17 December 2015 (UTC)
I second that. It makes it just about impossible to convert the block entities, as nearly every one has items to store.
On a related note, a few pages use multiple sprites, so would it be better to add a parameter to dump extra sprites into, or to just trim each item down to a single sprite? KnightMiner t/c 23:07, 5 January 2016 (UTC)
I have something working in my sandbox with allows indented pages, just requiring an additional parameter on {{Nbt inherit}} called {{{indented}}}, which will then be passed onto most of the subpages (eg, {{nbt inherit/item}}). The subpages can also use the parameter to load the version of the page without .treeview-continue, since the lists do not properly support adding tags after the indented treeviews (you get stacked treeview bullet points).
It also has another parameter in the preview to end a table with a nested table, though if that is not needed, the relevant styling can be switched to a class (a parameter to make the "tags common to..." use the same version of the page I mentioned above without indenting would definitely be useful though). KnightMiner t/c 18:09, 16 January 2016 (UTC)
I think your implementation of the indented boxes is pretty good. I support adding it, perhaps trial it on a couple pages to see if anything breaks first before converting them all. GoandgooTalk
21:36, 17 January 2016 (UTC)
It looks like that will work for the cases we need it for now, although I would like to eliminate limitations like not being able to have multiple levels of continuation. I think that will only be possible by not faking the list joining, but I haven't come up with a way to do the initial collapsed state with styling alone. MajrTalk
07:52, 18 January 2016 (UTC)
I implemented the changes with three parameters
  • {{{indented}}}: indents it a number of bullet points (1 will be most common used I think)
  • {{{nocontinue}}}: tells the table to not add the {{nbt continue}} template at the end.
  • {{{endlist}}}: tells the template to indent it, but exclude the bottom border.
I have implemented the three most common usages as samples to show everything works before implementing:
  • Item Frame/ED: indents and uses {{{nocontinue}}}. I am currently unsure of the easiest way to add that as default (as dozens of pages will all need the exact same check, so I want something easy to copy). In most cases you want to indent and stop the continuing, but in a few you indent and continue (an example of that is {{nbt inherit/mob}})
  • Blaze/ED: sets {{{nocontinue}}} to stop the list from continuing, but does not indent.
  • Item (entity)/ED: sets {{{endlist}}} while indented to stop the left line from appearing.
@Majr: this is a bit minor, but can we make the border on the collapsed boxes only go halfway down when {{{nocontinue}}} is set on {{nbt inherit}}? The only ways I can think of to make the line stop at 50% height causes it to be 50% height when uncollapsed as well, so something in LoadBox would have to be tweaked, such as adding a collapsed/uncollapsed state class for the CSS to use to decide to hide half the line or not.
KnightMiner t/c 16:10, 18 January 2016 (UTC)
Hold up on that. I had a proper look over it, and I realised that my original solution of using merged lists (which I dismissed due to impossible styling) can actually work, now that we're not transcluding the content. I believe I have a working version, which I will implement tomorrow. It gets rid of the need to fake the continuing and indentation as it is actually part of the list. The only thing is it requires some special cases in the page loader script to handle inline lists, but I've already written that. MajrTalk
11:25, 19 January 2016 (UTC)
Alright done, it appears to work a lot better this way. The only issue I ran into is Splash Potion/ED which has an inherited section indented within an inherited section, which will require a formatting change to support, however I don't think it's intended to be like that, because I don't understand how it would make sense. Correct? MajrTalk
06:14, 20 January 2016 (UTC)
The changes seem pretty good and seem to work better. The half dotted line for finishing trees is nice and rectifies the problem I mentioned earlier. From my understanding and what I gather (might be wrong Anomie x please confirm), the splash potion entity data is able to hold an item, with additional information under the "tag" tag. So it seems the 2nd indented one is just for "tag" tag (expand both and it should make sense). The current implementation is a little bit confusing, it would make most sense if somehow that 2nd indented tree is inside the 1st one somehow (not sure if possible).
Also, would you be able to convert all the block entity pages into this new format. GoandgooTalk
06:53, 20 January 2016 (UTC)
Hmm, that's an awkward one. Even if we were to find a way to have it inside the first one, it would only make sense if the "tag" tag was the last tag. Is there a lot of different variations of contents of the "tag" tag? If not, we could have a separate inherit template for potion items, like with {{nbt inherit/item}}/{{nbt inherit/itemnoslot}}. MajrTalk
12:07, 20 January 2016 (UTC)
There are variants of the tag tag, see Player.dat format#Item structure. Perhaps inherit templates could work for potion items still. Not sure. GoandgooTalk
11:55, 24 January 2016 (UTC)
Just to point out, there's also a slight issue with the tipped arrows (Arrow/ED), which lists the "tag" tag even though it's the tags listed inside it that are at the root (i.e. {damage:1.0,Potion:"minecraft:invisibility"} and not {damage:1.0,tag:{Potion:"minecraft:invisibility"}}) Skylinerw (talk) 13:49, 20 January 2016 (UTC)
Skylilnerw is my correction to the Player.dat format/Potion page correct? If not feel free to correct it. GoandgooTalk
11:55, 24 January 2016 (UTC)
Yep, looks good! Skylinerw (talk) 12:27, 24 January 2016 (UTC)
You're correct, Goandgoo: The entity's "Potion" field contains a potion item, and that item has a "tag" that includes "Potion" (holding the potion name) and "CustomEffects". Anomie x (talk) 12:43, 20 January 2016 (UTC)
Anything else still need to be done at this point, or can I start converting the block entities and vehicles? KnightMiner t/c 04:29, 29 January 2016 (UTC)
I implemented a way to have multiple icons, and a hack for the "tag" tag edge case, so I believe everything is cleared up for now. MajrTalk
11:02, 29 January 2016 (UTC)
Just to point out since I have no idea how to fix it while preserving other changes: the change to Splash Potion/ED causes incorrect nesting. "Tags common to all potions" is meant to be within the "Potion" compound, not at the root of the entity. Skylinerw (talk) 11:14, 29 January 2016 (UTC)
Sorry, fixed. MajrTalk
11:19, 29 January 2016 (UTC)
The page is now completely converted to the new format. Could anyone knowledgeable about the subject (Anomie x) check over the page, and make sure none of the data has been messed up in the conversion? MajrTalk
12:27, 29 January 2016 (UTC)
I've been meaning to say, this looks really slick now, seeing the outcome, it really was time well spent. Thanks! – Sealbudsman talk/contr 23:07, 24 February 2016 (UTC)

Team tag?[edit]

OK, so I'm having a little trouble understanding the full potential of the Team tag. I feel that some changes to this page on the subject would help alleviate this misunderstanding for me and I certain many others. To put it simply, what can the Team tag be used for in offline single-player if at all? It would seem that the page gives very little information on the purpose of the Team tag in this circumstance and others, (i.e. what can it do for players in a non-scoreboard multiplayer game). Simply, I, along with many others, find this tag to be lacking full explanation what when and where it can be used and to what extent outside of the PVP server field. It would be of much help to me and the rest of the community who may not yet have a full understanding of this tag or are simply new players. In that sense, this wiki in a whole does seem like it's more suited for more experienced players and doesn't really seem to pay heed to the large number of less experienced players who come to use this wiki everyday. As I have stated this, need I remind you that the sole purpose of these articles is to be informative, and to be informative, one must assume the assumption that the reader has no prior knowledge of the subject, and thus the articles should be written as such. Thus, if seemingly pointless questions are being asked, then that should be your cue to assume that an article is not written as properly needed to provide full explanation of the subject at hand. Thus, I return to my original problem, it would seem that the Team tag is not fully explained in this article which is so deigned to provide informative data in a easy to understand format, thus the Team tag should be given a greater explanation as to its full extent of capability to provide the readers of this article with the most up to date information on the contents of the subject at hand and all parts of it. Hope this helps. Rockatoa, Brickticks out! And please don't just delete this thinking your article is perfect, please note that if I or anybody else has to ask a question about this article or its contents that clearly the article is not perfect, or at least tell me who to talk to about this. And don't just redirect me to the forum, I never get answers from there. Brickticks (talk) 00:26, 25 March 2016 (UTC)

As it says, it adds the mob to the specified scoreboard team. There's really nothing more to the tag itself. If you don't understand scoreboard teams, look at the scoreboard page. Copy/pasting everything from that page onto this one is simply redundant, not to mention it's already linked. Skylinerw (talk) 01:05, 25 March 2016 (UTC)


IsVillager and VillagerProfession are no longer saved with the entity, instead ZombieType is used, but I don't know how to change this page exactly :/ FVbico (talk) 17:33, 18 May 2016 (UTC)

 Done. It was in Zombie/ED1. Generally speaking they are mostly stored in /ED subpages, and they should all be listed at :Category:Entity_data_pages. – Sealbudsman talk/contr 04:17, 26 May 2016 (UTC)

Chunk format inconsistent with minecraft classes inheritance.[edit]

The current chunk format page have many inconsistency due to a wrong layout of the entities : some are wrongly grouped, and some are not grouped at all. Here is some of the problems :

  • Some entities are not grouped : for instance, MushroomCow is a subclass of Cow, and if one day, a new tag is added to the cow, the mushroom cow will have this tag too.(On the other hand, some like Zombie and PigZombie are properly linked)
  • The projectile category does state that some of the projectiles are spread into three implementation (Throwable, ArrowBase, and FireballBase) but fail to use them, and use some ShakyProjectile and OwnerProjectile instead, that make no sense at all code wise. And obviously because of that There is many duplicates definitions and error (inGround)
  • The ArmorStand is stated as subclass of Entity, and if you search a bit you will see that it has many missing tags (like Team, Attributes, ActiveEffects, FallFlying, ...). This is because the current category "mobs" is wrong because there is in fact two layer of subclass, ArmorStand only extends one of them (This also affect the Player entity).
  • Item and XPOrb has their own category (and code wise, there is no reason to) whereas LeashKnot, Painting and ItemFrame don't.
  • Two entities can have a similar tag while not being linked at all (i.e. Fireball and Snowball).
  • Villagers should not have the InLove tag.

These problem are side effect of the current structure not following the minecraft class inheritance.The goal would be to link every entities if they have a common nbt in the game code, and correctly split tags into subcategory based on the abstract classes. Here is the class inheritance pattern of all entities :

  •  Entity: Item, XPOrb, AreaEffectCloud, EyeOfEnderSignal, PrimedTnt, FallingSand, FireworksRocketEntity, ShulkerBullet, Boat, Villager
    •  EntityLivingBase: ArmorStand, Player, EnderDragon, WitherBoss, Bat, Witch, Endermite, Guardian, Guardian, Shulker
      •  EntityLiving: Creeper, Skeleton, Skeleton, Giant, Slime, Ghast, Enderman, Silverfish, Blaze, Squid, SnowMan, VillagerGolem, LeashKnot
        •  Zombie: PigZombie
        •  Spider: CaveSpider
        •  Slime: LavaSlime
        •  Ageable: Villager
          •  Breadable: Pig, Sheep, Chicken, EntityHorse, Rabbit, PolarBear
            •  Cow: MushroomCow
          •  Tameable: Wolf, Ozelot
    •  Hanging: Painting, ItemFrame
    •  Throwable: ThrownEgg, Snowball, ThrownEnderpearl, ThrownPotion, ThrownExpBottle
    •  ArrowBase: Arrow, SpectralArrow
    •  FireballBase: Fireball, SmallFireball, WitherSkull, DragonFireball
    •  Minecart: All minecart type

Same thing for Block Entities :

  •  TileEntity: Furnace, EnderChest, RecordPlayer, Sign, MobSpawner, Music, Piston, EnchantTable, Airportal, Skull, DLDetector, Comparator, FlowerPot, Banner, Structure, EndGateway, Control
    •  Lockable: Cauldron, Beacon
      •  Trap: Dropper
      •  Lootable: Chest, Hopper

Each name represent a class, and italic names represent an abstract class

This tree was made based on the nbt structure, in reality, there is some more abstract classes, but since they don't add any common tag, there is no reason to add them now. Even if you don't really see it, most of this tree is already implemented, but some links are missing, and there are some minor mistake. The biggest part to do is to split the "Mob" category into EntityLiving and EntityLivingBase.

I'm not asking for someone to do it for me. I'm just pointing out that there is some inconsistency that should be fixed. Check any mistakes about my trees, and tell me how much of this should be done.

MrPingouin1 (talk) 03:20, 26 May 2016 (UTC)

I  Support this, definitely.
For reference, there was some discussion at User_talk:Goandgoo/Archive_4#Entities from this past November, for another user's run-down of the class structure.
Incidentally, another example of ambiguity this project would ideally solve: there was a tag added in 1.10 to EntityLivingBase which properly belongs to mobs, players and armorstands, so we can't technically just put it under :Template:nbt inherit/mob, we'd have to duplicate it on the armorstand page.
I'll try and devote some time to checking your structure. – Sealbudsman talk/contr 19:07, 8 June 2016 (UTC)

TNT and XP[edit]

How does TNT "decide" if mobs that it blows up drop XP? If it gets ignited by a player, XP drops, but if it comes from a dispenser or gets ignited by redstone, it doesn't drop. Shouldn't TNT have an NBT tag if it got ignited by TNT then? In the article there is none and entitydata also gives none. How does it work? Fabian42 (talk) 14:47, 18 September 2016 (UTC)

It get's saved in memory, not to NBT/file. FVbico (talk) 16:52, 18 September 2016 (UTC+2:00)
There are a lot of in-memory states that don't get saved to NBT, if you think about it. – Sealbudsman talk/contr 15:48, 18 September 2016 (UTC)
If I wanted to talk to you two, I could use the chat. ;) But thanks for the help. For anyone reading this at a later time: MC-69821 Fabian42 (talk) 17:40, 18 September 2016 (UTC)

More information on HandItems and ArmorItems Tags?[edit]

I'm currently experimenting around with these and I haven't been able to figure out how items have to be referenced as to give an entity an item.
Say I want to give a zombie an Iron Shovel, I do /entitydata @e[type=zombie,r=3] {HandItems:[0:{minecraft:iron_shovel},1:{}]} to add an Iron Shovel to it's main hand, this command goes through without a problem but the Item doesn't show up. On further inspection the tag seems to have changed to HandItems:[0:{minecraft:"iron_shovel"},1:{}] for some reason.
I'm gonna go ahead and test around a bit more, maybe I can find out how exactly it works. --DeutscherMiner99 (talk) 15:13, 2 January 2017 (UTC)

See the Item structure info. You want /entitydata @e[type=zombie,r=3] {HandItems:[0:{id:minecraft:iron_shovel},1:{}]}. In future, please direct your command questions to a better location, such as the related subreddit or the Discord server, rather than to the talk page of a wiki article. AjaxGb (talk) 15:22, 2 January 2017 (UTC)
I tested it out with a skeleton and found out the same as you've just told me. This should be mentioned next to the HandItems and ArmorItems sections in the Tags common to all mobs list in my oppinion. --DeutscherMiner99 (talk) 15:37, 2 January 2017 (UTC)
Agreed, that section should show an expandable item NBT section, where it literally says "item" or "items", like it does for instance on the llama's DecorItem tag, on the llama page. – Sealbudsman talk/contr 01:07, 3 January 2017 (UTC)
I just now  Did what I said above. – Sealbudsman talk/contr 18:22, 10 January 2017 (UTC)
By the way, DeutschMiner99, you also need to specify Count if you want the item to appear successfully.
- tryashtar (talk) 00:52, 10 March 2017 (UTC)

this page say that arrow entity has both Color tag and CustomPotionColor tag . is that correct?[edit]

sorry for my bad english –Preceding unsigned comment was added by (talk) at 17:49, 10 January 2017 (UTC). Please sign your posts with ~~~~

The arrow entity has a Color tag, and the arrow item has a CustomPotionColor tag. It's kind of messy, isn't it. That section could be made more clear. – Sealbudsman talk/contr 17:53, 10 January 2017 (UTC)

Updating tag information on this page[edit]

Hi, I'm stupid and can't figure out how to correct information regarding tags on this page. I was going to remove the out-of-date quote "The ThrownPotion entity will render as this stored item, no matter the item." How would I go about making this change? - tryashtar (talk) 00:42, 10 March 2017 (UTC)

ConversionPlayerLeast and ConversionPlayerMost tags[edit]

It would be appreciated if the ConversionPlayerLeast and ConversionPlayerMost tags could be added to zombies as per the 17w14a snapshot (should they get added to ZombieBase?). GoandgooTalk
07:28, 12 June 2017 (UTC)

Added to zombie villager only, decompiler shows it's in the same class as Profession and ConversionTime. – Sealbudsman talk/contr 20:34, 12 June 2017 (UTC)

Rotation format[edit]

Tests in 1.12 and the F3 debug screen suggest that 0 is south (+Z), not west (-X). Does this need fixing? - Andrio Celos (talk) 05:13, 31 July 2017 (UTC)

You're indeed correct. Fixed it. – Fusseel 05:47, 31 July 2017 (UTC)

Weird formatting outside page content[edit]

While viewing the page, I noticed the font suddenly changed somewhere in the middle of the page. I was able to pinpoint the location of where this starts to happen: Chunk_format#Vehicles, from spawner_minecart onwards. I also figured out this is caused by the div#bodyContent element terminating right there in the middle of all page content. Why this happens, I do not understand. Maybe mediawiki limits content for the body or something (unlikely). Could someone look into this maybe? – Jack McKalling (tcp) 00:06, 21 November 2017 (UTC)

Probably just an issue because of the recent migration. --Pepijn (talk) 18:03, 21 November 2017 (UTC)
I think it is due to that change on this new host, where suddenly not properly closed HTML elements are dealt with now differently, or something similar, is what I mean. See this discussion. – Jack McKalling (tcp) 18:08, 21 November 2017 (UTC)
It looks like Tidy isn't running any more, as was pointed out on Slack. Game widow confirmed on there that the configuration for it hasn't changed, but that she'd have the platform team look into it.
Given that, this case is probably (I haven't looked into it myself) caused by an unclosed tag somewhere on the page with the content for the spawner_minecart section. ディノ千?!? · ☎ Dinoguy1000 18:16, 21 November 2017 (UTC)
I guessed that with the spawner minecart, I looked myself but it's just a regular link in the article page. I didn't know why something would be "unclosed" around there. I hoped someone could look further into it, but if some software isn't running properly then the problem could lie there too, don't know. – Jack McKalling (tcp) 18:21, 21 November 2017 (UTC)
I was wrong, but only in parts. It was caused by an extra </div> on Minecart with Hopper/ED. ディノ千?!? · ☎ Dinoguy1000 18:25, 21 November 2017 (UTC)
Fixed it. Minecart_with_Chest/ED had indeed an extra closing div but Minecart_with_Hopper/ED also used the same ref name ("loot") as Minecart_with_Chest/ED which caused problems. --Pepijn (talk) 18:31, 21 November 2017 (UTC)
Hmm... that should've just caused problems with the refs, and nothing else. Weird. ディノ千?!? · ☎ Dinoguy1000 18:34, 21 November 2017 (UTC)
Ah I see, I removed the extra div on the chest page and that moved the problem to the hopper page. When I looked there you had already removed the div (without me realizing), so I edited the only thing I could think of that might possibly cause problems (the ref), but it was already fixed from your edit. --Pepijn (talk) 18:55, 21 November 2017 (UTC)
I made a null edit on the Chunk format article. It may have affected something. --AttemptToCallNil (report bug, view backtrace) 18:35, 21 November 2017 (UTC)
The problem is now fixed on the page, thanks guys. :) – Jack McKalling (tcp) 19:22, 21 November 2017 (UTC)