I created this page because the Player and Item formats are linked to from multiple unique sources, and having duplicate information lead to constant inconsistency. LB 17:59, 3 July 2012 (UTC)
Dyeing[]
This page says dyeing is most commonly used for coloring leather armor, but the small amount of testing I did seems to suggest it only effects leather armor. If nothing else can be dyed, shouldn't that be reflected here? Firebastard 04:55, 30 September 2012 (UTC)
- Sheep and wool can also be dyed. 「ディノ奴千？！」? · ☎ Dinoguy1000 06:14, 30 September 2012 (UTC)
- Yes, I was referring to items using the tag in question in the item format. Giving color tags to other items seems to have no effect, but I only tested blocks appled to the head, like pumpkins, TNT and the like. Firebastard 02:55, 4 October 2012 (UTC)
Dimension[]
I guess Dimension could be removed here, because its also (at least according to this wiki) in the Entity structure. --Quurks 20:32, 6 October 2012 (UTC)
- I'm not too keen on doing that quite yet; it doesn't make sense for entities to have that tag in the first place because entities are only saved in the files for the dimension they are in. In other words, it may change soon. LB(T|C) 23:09, 6 October 2012 (UTC)
Crafting Table GUI[]
Anyone know where the crafting table GUI is? I notice the brewing stand one is in the player info but no mention of crafting table. I was hoping to create custom crafting recipes in vanilla minecraft using command blocks but it looks like I'll have to use chests or droppers or something instead of a crafting table. (oh god first post in 18 months? not a good sign) 24.68.154.229 06:15, 19 December 2013 (UTC)
- I don't know what you mean. For one thing, the Crafting Table inventory is a virtual inventory and is not saved with the level (which is why you can't leave items in it), and for another, crafting recipes have nothing to do with the Crafting Table. There is no Vanilla way to add, change, or remove crafting recipes, smelting recipes, potion recipes, etc. - you have to do it with command magic and hopper magic (or give in and install a mod). LB(T|C) 19:14, 19 December 2013 (UTC)
CustomPotionEffects Tag-Type Changed?[]
TL;DR: This page lists the "Id", "Amplifier", and "Ambient" tags under the "CustomPotionEffects" tag as Byte, but is found as Integer in-game. Need confirmation or if it's a quirk with the /give command.
Messing about with the /give and /effect commands and checking NBT tags using NBTExplorer. On the Chunk Format page, the "Id", "Amplifier", and "Ambient" tags under the "ActiveEffects" tag are labeled as type "Byte", which I can confirm is correct. When the /effect command applies an effect greater than 127, the number is switched over to -128 and decreases for each level above 128 (meaning using the /effect command to apply an amplifier of 255 would set the "Amplifier" tag to -1).
However, when creating a custom potion ITEM through /give, it seems that the "Id", "Amplifier", and "Ambient" tags under the "CustomPotionEffects" tag are all set to Integers. Trying to apply a custom potion with an "Amplifier" tag greater than 127 does not work, and setting the "Amplifier" tag to a negative doesn't work either, essentially barring the capability of supplying potions with effects greater than 127, while the /effect command is capable of doing so.
So I'm just looking for confirmation that the "Id", "Amplifier", and "Ambient" tags are now Integers for the "CustomPotionEffects" (still Bytes for entities), or if it's just a strange quirk with the /give command, as custom potions can't be obtained in vanilla to check. If clarification is needed, I'll try to rephrase.
Skylinerw (talk) 05:37, 29 December 2013 (UTC)
- One of the patches introduced a change that allows the game to load tags that are not of the correct type as long as the types are compatible. The types listed on the wiki are the types that Minecraft uses by default when saving natural information that has not been tampered with, and/or the types explicitly written in the decompiled code. LB(T|C) 07:00, 29 December 2013 (UTC)
"ShowParticles" for Potion Items?[]
While the "ActiveEffects" tag allows you to use the new "ShowParticles" tag, it seems that, up to 14w06b, attempting to use this tag in "CustomPotionEffects" does not apply any tags from it. This is both from /summoning a potion or splash potion and /giving an item with these tags. These methods insert the wrong tag-type, though I am uncertain if that has any bearing on the outcome. I've also tried to manually apply the tag with the correct tag-type to a potion, and there was no effect upon using. It seems the "ShowParticles" is restricted to the "ActiveEffects" tag, or is there something different that needs to be done? Need confirmation of some sort before adding the tag.
Commands attempted:
/give @p minecraft:potion 1 16420 {CustomPotionEffects:[{Id:14,Duration:100,ShowParticles:0}]}
/give @p minecraft:potion 1 16420 {CustomPotionEffects:[{Id:14,Duration:100,ShowParticles:0b}]}
Note that appending with a "b" doesn't make a difference, as behind-the-scenes the tag is given the incorrect type of "integer". If it's appended with any value, it turns into a string. See the bug report here: https://bugs.mojang.com/browse/MC-44282
And again, attempting to apply the correct tag and tag-type with an NBT editor still doesn't produce the effect of hidden particles.
Skylinerw (talk) 23:26, 6 February 2014 (UTC)
- It works perfectly fine on non-splash potions in 14w06b, and I have particles turned on:
/give @p minecraft:potion 1 100 {CustomPotionEffects:[{Id:1b,Amplifier:0b,ShowParticles:0b,Duration:100000}]}
- That's reason enough to include it in the article, perhaps with a footnote on the bug that it won't work with splash potions. The same is true for Ambient.
- I can't confirm your claim that "0b" is a String. In NBTExplorer, it's clearly serialized as a Byte, even when I use the exact same command you used. Also, it doesn't matter if it's an Integer instead of a Byte; it's merely good practice to give things the correct type (most NBT deserializers, including the ActiveEffects deserializer used when applying potion effects, will accept Integer in place of Short/Byte and I think even Float/Double). This issue strictly only applies to splash potions; I suggest you revise your ticket and remove the Integer/Byte/String parts and make it strictly "Splash potions ignore Ambient and ShowParticles flags". --WolfieMario (talk) 01:37, 11 February 2014 (UTC)
- Correction: Byte-vs-Integer does matter for Amplifier and Ambient because they are resolved to Boolean rather than Number. That means that they are only accepted as 0b, 1b, true, or false. Nonetheless, the heart of your issue wasn't NBT formatting (sticking to the format achieves the desired results for non-splash potions). --WolfieMario (talk) 01:44, 11 February 2014 (UTC)
Empty lists, such as EnderItems[]
The page says,
> EnderItems: If there are no items in the player's Ender chest, this is a list of Byte tags with size 0. If there are items, this is a list of Compound tags.
This doesn't seem to be correct. I have a level.dat that contains the following:
45 6e 64 65 72 49 74 65 6d 73 00 00 00 00 00 E n d e r I t e m s Ty < size >
Where Ty is the tag type of things inside the list, here, 0 or TAG_End. A list of TAG_End makes no sense, although I'm hoping this only ever shows up in empty lists.
Note that I also see this with the "Inventory" attribute on a player too, if it is empty.
Saw this in a vanilla 1.7.10 world, as well as a somewhat modded 1.7.10 world; broke my NBT parser.
—Deathanatos (talk) 03:42, 19 August 2014 (UTC)
- Ah, yes this was a change made in an update a while back that broke some tools - this page just hasn't been updated. I'm still yet to understand why empty lists have a different type from their non-empty forms, but I assume it's because the type is autodetected in Mojang's NBT implementation. LB(T|C) 18:41, 20 August 2014 (UTC)
XpTotal vs Score[]
What is the difference between XpTotal and Score entries? It seems both are reset when I die, and neither are altered when I use Anvil or Enchanting Table. Are both *always* equal, or are there situations when they can be different? MestreLion (talk) 05:07, 28 December 2014 (UTC)
RootVehicle[]
In 15w41a, the RootVehicle tag was introduced. It contains, within a sub-tag, a full copy of the NBT of whatever the player is currently riding (example). Obviously it's meant to be a replacement for the Riding tag, of sorts, but it only appears on the players.
Now, the reason that I'm writing this talk topic about it is simple. I don't know anything about wiki formatting, or wiki etiquette, or anything like that. I am, you could say, a completely inexperienced wiki-editor. However, this is a very useful tag that is missing from this page, so I'm asking that someone that DOES know how to use this wiki properly add it. - 162.194.30.93 11:09, 8 October 2015 (UTC)
Spawn eggs[]
I tried to add spawn eggs to the armor stand section as they have EntityTag in the snapshots but because I am not logged in (I might register, I seem to editing here a bit) it was mrked as section removal and not done.
Here's what I tried to add:
==== Armor Stands and Spawn Eggs<sup>(since [[15w33a]])</sup> ====
[[Armor stand]]s and [[Spawn Egg]]s<sup>(since [[15w33a]])</sup> may contain potential entity data.
<div class="treeview">
* {{nbt|compound|tag}}: The '''tag''' tag.
** {{nbt|compound|EntityTag}}: Stores entity data that is applied to the armor stand when placed or entity when spawned.
*** See [[Chunk format#Entity_format|Entity Format]].
Thanks to whoever adds this. 203.219.222.79 06:28, 17 November 2015 (UTC)
- Taken care of! Thanks for the format, I'm terrible at wiki styles. Qwertyuiopthepie (talk) 22:59, 8 January 2016 (UTC)
- It appears that armor stands do not in fact apply any data from the EntityTag tag, at least in 1.11.2. Further testing should be done in regards to this tag. Firebastard (talk) 06:31, 18 February 2017 (UTC)
Organizing and examples[]
I just noticed that the German wiki page is a lot better organized and has a lot more useful examples than the corresponding English pages. Could someone who knows both languages maybe change that? It would already help if there was one list for player data instead of people having to refer to multiple lists. For example in chunk format it's very well done how one can expand the "Inventory" tag to directly see the possible item data. But I think that could even be expanded to have to fully recursive abilities of items represented (like for example all the JSON components of a tellraw command in a command block in a chest in a chest in a chest in the player's inventory or something like that). Would loading a page take infinitely long if the Inventory tag list could be recursively expanded? If not, then I think having the item tag template reference itself would be a good idea. Fabian42 (talk) 10:41, 21 July 2017 (UTC)
BlockEntityData[]
I consider this one of the most important pages on the wiki, so I obviously take it very seriously when I edit it (especially because I'm still somewhat new). There was a statement claiming that BlockEntityData is ignored when you place a block in any gamemode other than Creative, this is no longer the case. I tested this, but to make sure that I didn't slip up I'd like to share my test method:
- Place a regular chest and fill it with some items.
- While in Creative 'pick click' on the chest (control + middle mouse button on Windows) to pick it up with its contents.
- Switch back to Survival mode and place the chest.
You'll notice that the chest still contains all its items. If you double-check using MCEdit to inspect the players inventory prior to them placing the chest you'll notice that BlockEntityData was definitely in effect. - ShelLuser (talk) 16:33, 11 August 2017 (UTC)
- There are still some cases where BlockEntityTag is ignored when not OP'd, but only for specific items IIRC (command blocks being one of them, though I'm pretty sure it wouldn't matter if the player were in creative mode or not, just if they're not OP'd). I'm not in a position to verify all cases myself, though. Skylinerw (talk) 18:58, 11 August 2017 (UTC)
Shield slot number[]
Rather than think about the shield slot number as -106, I like to think of it as 150 - it's stored as a byte, so both values are stored the same. I think 150 makes more sense as far as a number Mojang would pick, since the armor slots start around 100. NickNackGus (talk) 14:02, 2 September 2017 (UTC)
- As far as the source is concerned, it is indeed set to 150 just before being saved to NBT. However, the slot numbers on the page refer to their values within the
Slotbyte tag, so they would need to reflect what they're actually saved as. Skylinerw (talk) 14:26, 2 September 2017 (UTC)
- Agreed. The NBT Byte tag does not store the sign. You can consider it stored as either, and it is displayed as signed when displayed in JSON format. I'm fine with going with what is displayed, and maybe put the value 150 as an alternative in the trivia section? –Preceding unsigned comment was added by NickNackGus (talk • contribs) at 14:32, 02 September 2017 (UTC). Please sign your posts with ~~~~
Damage property moved into tag in 1.13[]
It seems the 'damage' field is no longer part or the base Item structure. It is now a member of the 'tag'. I tested this in the current snapshot 18w11a. The 'data get' command prints the following structure for a damaged flint and steel:
Item: {id: "minecraft:flint_and_steel", Count: 1b, tag: {Damage: 1}}
This article seems to mention multiple 1.13 changes already, but not this one. I don't trust myself to update the article myself.
Not sure if relevant for this article: This allows us to specify the damage when using the 'give' command. The 'give' command no longer has a damage parameter and only allows custom nbt for the tag, not the base item. This means 'give @s minecraft:flint_and_steel{Damage:1}' works.–Preceding unsigned comment was added by 84.136.90.221 (talk) at March 22, 2018 (UTC). Please sign your posts with ~~~~
Player Heads[]
It seems the compound tag "SkullOwner" doesn't actually work with the "Name" element to give yourself another player's head. You have to use "SkullOwner" as a string. Here's what I'm trying based on the wiki page:
/give @p minecraft:player_head{SkullOwner:{Name:"SullyTheUnusual"}} 1
And here's what works:
/give @p minecraft:player_head{SkullOwner:"SullyTheUnusual"} 1
Can anyone else confirm this?
- You're not adding the texture data, so it shows no texture. Simple, you need the texture data, and the name or uuid. FVbico (talk) 20:05, 13 August 2018 (UTC)
- What I'm trying to say is that the "SkullOwner" tag doesn't work the way the wiki currently reflects. It works as both a compound tag (used in the way you're referring to, needing texture data in addition to Name and/or Id), and it works as a string which will simply give you the head of the player referred to in the string. I'm sure you're not suggesting that in order to use /give to receive another player's head, we need to start hunting down and providing a ridiculously long string of texture data instead of simply supplying the player name as I've outlined above, right? Disciple218 (talk) 20:43, 13 August 2018 (UTC)
- Ok, thanks for pointing that out. It was a bit frustrating trying to get it to work. :) --Disciple218 (talk) 21:14, 13 August 2018 (UTC)
what is "brain"?[]
Jmooroof (talk) 22:19, 23 December 2021 (UTC)
Some "Common to all entities tags" never apply to the player[]
Since the player's NBT cannot be affected by commands, several tags are never present, such as HasVisualFire, NoGravity, Glowing, and this page incorrectly lists that they do. It seems more complicated to fix than I know how to, but I'm sure someone can figure it out. These tags should be moved out of 'Common to all entities" and into "non-player entities", if such a category exists. If not it should be created.
Please note that this is not an exhaustive list, there are more.
Default for CustomModelData[]
I feel like this information should be added on the CustomModelData field. When an item has no CustomModelData, is the CustomModelData 0, or does the field not exist?
87.123.206.150 13:33, 31 December 2022 (UTC)