Talk:Chunk format

Disk Usage

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

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

Not having a lot of file handles open would increase efficiency, though, and having nearby chunks in one single could increase locality of the data on disk and reduce seek times. –Preceding unsigned comment was added by 174.5.64.175 ^(Talk) 19:29, 1 December 2012 (UTC). Please sign your posts with ~~~~

It is correct, "disk usage" is usually used to refer to the seek time, whereas "disk space" is of course for space. LB^(T|C) 23:32, 1 December 2012 (UTC)

Deleting Chunks

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

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

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

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

Confusing format

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

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

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

See Development Resources where it says "Notch's notes on NBT format files.", that explains the TAG_Madness that you see. LB 20:11, 21 June 2012 (UTC)

Actually, I made an article: NBT Format. LB 01:39, 22 June 2012 (UTC)

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

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

InGround tag

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

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

Entity format

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

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

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

Move to Chunk format

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

Missing entities

The entities section misses the folloing entities:

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

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

128 or 256

Are they in 16x128x16 or 16x256x16 since the last update??? –Preceding unsigned comment was added by Addamondes ^{(Talk|Contribs)} 04:26, 6 March 2012. Please sign your posts with ~~~~

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

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

Merge with Anvil file format

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

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

Outdated information

The information for the NBT Structure of a chunk is outdated. Tile Tick information is correct, but I see some changes to the rest:
File:NewChunkStuff.png
I'm going to try and update the information, especially seeing as it still discusses file names for the chunks.
LB 03:23, 22 June 2012 (UTC)

I'm almost done updating and filling in all information. The page has undergone quite a transformation as I test each and every aspect and find better ways to organize everything. Be on the look out for typos... LB 02:30, 3 July 2012 (UTC)

Head data

I hope someone figures out the information for the Head block - I'm guessing it's using tile entities for orientation and even type (I'm not seeing the head type in the data value, despite what's listed at Block_ids). Erich666 13:04, 14 September 2012 (UTC)

You're right; I thought they each used a block ID and the data value for orientation like signs, but it is indeed a tile entity. I've added it for you ;) LB^(T|C) 23:47, 14 September 2012 (UTC)

On the topic of riding

Obviously entities can, under the right circumstances, ride other entities; e.g. Skeletons riding Spiders, Players riding Pigs. Is this in any way part of the Mob Entity ID, and if so, can it be manipulated? For example, via NBTedit or some such, could you make a Mob Spawner spawn a Zombie Pigman w/ an enchanted sword and armor riding a Ghast w/ Regen potion effect? I'm just wondering because I would like to make a challenge map in which Skeletons ride Blazes, etc. 216.9.31.209 07:06, 29 October 2012 (UTC)

Sadly, no. You could ask Dinnerbone. You may notice that if you save and reload with a spider jokey that the skeleton dismounts the spider. There is no saved form of mounting mobs. You could use some Bukkit plugins, though, or a mod. LB^(T|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

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

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

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

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

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

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

MobSpawner EntityId and SpawnData

There was an edit war about what these tags do. I've decided to put both of these explanations on the page, to hopefully stop this edit war. If you have any proof for either explanation, post it in here. --93.73.186.104 21:27, 12 April 2013 (UTC)

With experience from dealing with spawners a lot, I can tell you that the game does not overwrite EntityId and SpawnData when the spawner is loaded. It determines the next spawn, which is also the entity you see spinning in the cage; this is its entire purpose in the game. It is only overwritten when the game checks the SpawnPotentials list for a new entity - it will always spawn from the current SpawnData before doing this if it exists. If SpawnData does not exist and a spawner is loaded, its next spawn will be a generic entity of EntityId type. If SpawnPotentials does not exist, the game will create it when it needs to spawn a new entity - the generated SpawnPotentials will be based on the current EntityId and SpawnData. Therefore, the second explanation is closer to correctness - The tags are not deprecated, and are very much still in use. You can test this yourself; have a spawner with a single SpawnPotentials for a mob renamed "Two", and have SpawnData contain a mob renamed "One". When you load the world, the first mob to spawn will be One, and all subsequent mobs will be Two. --WolfieMario 04:10, 13 April 2013 (UTC)

I figured presenting it in this form may help people understand:

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

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

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

"SpawnData" Mob Spawner Additional field crashes Minecraft and corrupts save

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

See the above conversation Talk:Chunk format#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.--67.1.213.18 03:27, 18 April 2013 (UTC)

Rounding decimals

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

"ownerName" tag

According to the code, exp bottles, thrown potions, and snowballs also have the "ownerName" tag (eggs too, but they're not saved). --mister_person 22:40, 29 June 2013 (UTC)

Tested in 1.6.1 and confirmed for ThrownExpBottle, ThrownPotion, and Snowball. Others not tested. LB^(T|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

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

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). -- Orthotope^talk 06:54, 15 December 2013 (UTC)

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

Merge request discussion

About this request.

I would like to vote against the merge. The section belongs with the rest of this page - the fact that using the commands requires you to look at this page doesn't mean we should merge the pages, as the command syntax is quite unrelated to the NBT structures described here. LB^(T|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"???

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

What confuses you? If you know how to program in Java, the pseudo code on this page should almost nearly be copy-paste-able. We intentionally tuned it to Java instead of C/C++ because we knew more people used Java for Minecraft-related things. LB^(T|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, 64.180.204.56 Gary Koopa

Your questions don't make sense. How much programming experience do you have? You can't try to go into this with little to no programming experience. LB^(T|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 64.180.205.211 01:05, 10 July 2014 (UTC)

Since the code snippet in question makes no reference to any aspect of Minecraft, it doesn't matter where you use it. LB^(T|C) 19:57, 10 July 2014 (UTC)

How do you access datatags?

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

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

Category Tags

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

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

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?

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. -- Orthotope^talk 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. Kavukamari^talk 12:28, 19 August 2014 (UTC)

chested horse tag

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

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.) 50.107.185.191 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

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 · · 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 · · 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

Inherited 

View at: User:LB1/treeview LoadBox [edit]

• • 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…

• root
  • child 1

    • child 1a 

      View at: Talk:Chunk_format/treeview_LoadBox2 [edit]

    • child 1b 

      View at: Talk:Chunk_format/treeview_LoadBox2 [edit]
  • child 2

That works surprisingly well. I don't think we would need to get rid of the bold.

Wiki tables don't seem to play nice in lists though. —munin · · 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 

    View at: User:LB1/Zombie LoadBox [edit]
  •  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 · · 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 

  View at: User:LB1/Zombie LoadBox [edit]
  •  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.

–Majr ᐸ Talk
Contribs ⎜ 09:17, 8 September 2014 (UTC)

Planning

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

• Chunk format - the current page
  • Chunk format/Entity - contains the tree from the Entity format section
  • Chunk format/Mob - contains the tree from the Mobs section and inherits Entity
  • Chunk format/Breedable - contains the tree from the "Additional fields for mobs that can breed" section
  • Chunk format/Tameable - contains the tree from the "Additional fields for mobs that can be tamed by players" section
  • Chunk format/Projectile - contains the tree from the "Projectiles have these additional fields:" section and inherits Entity
  • Chunk format/ShakyProjectile - inherits Projectile and adds the "shake" tag from the "Projectiles except..." section
  • Chunk format/Vehicle - contains the tree from the Vehicles section and inherits Entity
  • Chunk format/Hangable - contains the tree from the "Paintings and Item Frames share these additional fields" section and inherits Entity
  • Chunk format/TileEntity - contains the tree from the Tile entity format section
  • Chunk format/CommandStats - contains the "CommandStats" tag from Control and Sign
  • Chunk format/Items - contains the "Items" tag used by multiple tile entities
  • Chunk format/Lockable - contains the "Lock" tag from the "Various containers may have these additional fields" section
  • Chunk format/Nameable - contains the "CustomName" tag from the "Various containers may have these additional fields" section
  • Chunk format/Every entity - a page for all of the entity types in all the tables (even ones without their own unique tags), all inheriting from the correct templates as described on the page currently (LavaSlime should inherit from Slime)

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 · · 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 · · 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 · · 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 · · 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 · · 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 · · 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 http://minecraft.gamepedia.com/Commands 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?

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) ^t/_c 05:16, 20 May 2015 (UTC)

There are already a few /ED pages, Bat/ED, Zombie/ED, Bat/ED1, Mobs/ED and 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) ^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 · · 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. —  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)? –Goandgoo ᐸ Talk
Contribs 23:57, 7 November 2015 (UTC)

Actually using the collapsible tables from below is probably better, although perhaps the wikitext is not as elegant. –Goandgoo ᐸ Talk
Contribs 00:03, 8 November 2015 (UTC)

Update

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? –Goandgoo ᐸ Talk
Contribs 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)

Subpage sandbox

• Entity 

  View at: Chunk format/Entity [edit]

Creeper
Chunk format/Creeper

Banner
Chunk format/Banner

Chest
Chunk format/Chest

Control
Chunk format/Control

Do armor stands count as mobs?

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? 62.252.243.68 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

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?

86.182.4.59 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

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

Chested Horse Crash Bug APPEARS NOT TO EXIST

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? 50.107.185.191 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.	„
	— Dinnerbone

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. 67.86.187.137 05:36, 29 May 2015 (UTC)

Updating NBT data from snapshots?

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

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

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. –Goandgoo ᐸ Talk
Contribs 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. –Goandgoo ᐸ Talk
Contribs 01:25, 8 August 2015 (UTC)

Minecraft 2.0 April Fools Entity Tags

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

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. –Goandgoo ᐸ Talk
Contribs 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? –Goandgoo ᐸ Talk
Contribs 04:08, 7 November 2015 (UTC)