Talk:Java Edition data values/Archive 3

Can you remove the numeric IDs?
Numeric IDs is not supported now. Remove the numeric IDs from 1.8 blocks. --221.221.214.248 13:05, 3 September 2014 (UTC)


 * Externally they are unsupported, internally they are still used. We will keep them around until they are no longer used internally. --KnightMiner  (t 13:12, 3 September 2014 (UTC)


 * As of 1.10, numeric ID's are no longer internally, used. The only place they're used is when saving chunks, but Grum mentioned they're going to remove ID's from chunk saves in the very near future (no date or ETA given) and replace them with string ID's using a format similar to the Structure Block save format. According to, blocks with meta data are also going to be split up into individual blocks so that each block with meta-data will be its own block. This change means that orange wool and green wool will be treated both in-game and in saves as as their own block. Given this, should numeric ID's still be tracked on the wiki? Jocopa3 (talk) 02:44, 18 March 2017 (UTC)


 * It's still an important concept, networking-wise. Even after grum's changes, the IDs will be needed in some way, at least over the network - they might save strings, but they won't be sent over the network, for obvious reasons.  (And I'm pretty sure that the global palette changes that will be made are still going to have some reliance on these IDs).  At minimum, the IDs shouldn't be removed until we know how the changes will work, and even then, it'll be useful for historial background (because they're not going to disappear from networking for old versions). --Pokechu22 (talk) 02:54, 18 March 2017 (UTC)


 * Grum has stated that they already use the new method for sending blocks over the network. While yes, ID's are used if there are more than 256 unique blocks in a single subchunk, that's the only edge case that they are used, and that edge case is rarely ever met. Users won't need the block ID's except for legacy reasons, and modders don't need to worry about block ID's for 1.10+ either. If that edge-case is "fixed", then servers won't need to worry about them either, thereby removing any need for block ID's. Jocopa3 (talk) 05:32, 18 March 2017 (UTC)


 * Blocks will still have numeric IDs in chunk files. But the system they're creating will cause these numeric IDs to potentially be different on a per-world basis, and if that's the case then tracking them here on the wiki wouldn't work. The Structure block file format has a good example of the number to name designation, where relevant blockstates in the structure are saved in the  list with a name ID, and the array index is the numerical ID referenced in the   list. Skylinerw (talk) 02:58, 18 March 2017 (UTC)


 * I'm very aware of palettes (see the wiki.vg article I wrote and linked), but it's important to note that currently there's also the concept of a "global palette" where chunk sections with too many different blocks use the full ID instead of a palette (otherwise, they use a palette). It's possible that that'll be removed later, but I think it's unlikely (as there are performance reasons for it); if it isn't removed, then there still will be IDs the article will need to list. Of course, we can't know that yet; we just know that it will be changed in some way. --Pokechu22 (talk) 03:06, 18 March 2017 (UTC)


 * The new chunk format Grum is developing means they no longer rely on ID's, and only need them for legacy reasons or in the edge case where there are more than 256 unique blocks in a given chunk. Also, the palette is not a per-world basis, but a per subchunk basis; the numeric ID's in the palette system aren't really Id's, but just pointers to an index in the palette. They are extremely close to removing ID's entirely, as the only thing that keeps them from removing them entirely is that single edge case (256 block limit) with subchunks. Second, when is "fixed", meta-data for blocks will be removed in a future update. Essentially, all blocks with meta data variants will be treated as their own block, thereby removing the need for block meta-data ID's from the game. Unfortunately, I can't offer a public source for this change, as it was mentioned in private. Jocopa3 (talk) 05:32, 18 March 2017 (UTC)


 * "Essentially, all blocks with meta data variants will be treated as their own block, thereby removing the need for block meta-data ID's from the game" - that part is already somewhat public:
 * "2017-02-03 08:49:54	+Grum	pokechu22: and a heads up for the next iteration, when this code reaches releasability, the ids are going to not have the metadata 4 bits 'padding' any longer"

- log 110 (public)


 * I also disagree with your claim that the palette is only on a chunk section basis. There is what I've been referring to as a "global palette".  That's basically just all states, with metadata combined with IDs (more or less, what you're already referring to), just that currently there are gaps in it.  You don't ever deal with that normally, but you don't ever deal with most data values normally; the information is for the few who do need to deal with them.
 * So, the question becomes: how do we define a block? I believe the term "block state" works well; it's a possible valid state in the world, currently defined by a block ID and metadata but eventually unique.  There'll still be a main block and subblocks in the future (unless the refactoring is far larger than I'm expecting, to the point that everything gets a full name and the block state information is removed, which I doubt; that'd not fix  really either).  And the second question would be: will the IDs shift frequently?  If they're mostly static, then they should probably be documented on the wiki.  If they're something that'd shift when values are added in the middle (which is entirely possible, and currently happens with numeric sound IDs (betcha' didn't know those were a thing) - sample), then it's probably better to put them in automatically generated documentation (such as with burger (sample).
 * Do realize that people write custom server implementations from scratch (I've contributed to several), and need numbers to send. Hiding those numbers doesn't change the fact that there are numbers. --Pokechu22 (talk) 06:43, 18 March 2017 (UTC)
 * Block and item ID is removed as the "flattening", in 17w47a. Haydkenmutthew (talk) 15:10, 28 December 2017 (UTC)

My point about them being used in the network still stands. Numeric item IDs and block state IDs are still present (and there is one instance of block IDs) over the network, and there are a few uses internally (those don't matter as much). Here's what should be an exaustive list as of 17w50a:


 * Block IDs
 * The block action packet (e.g. playing note blocks)
 * Internally, something with block coloration


 * Item IDs
 * The jukebox effect (uses record's ID)
 * The cooldown packet
 * Literally every packet that writes an item (still uses the numeric ID, though no more metadata)
 * A few internal things (which are internal enough that they need not be documented):
 * To key and sort a lot of internal search trees (e.g. statistics, recipes)
 * Acting as keys for certain rendering maps
 * Acting as a seed for some item entity RNG
 * In the crash report for adding an item to a player's inventory


 * Block state IDs
 * The block break block effect
 * Falling sand in the spawn object packet
 * Minecart display tiles
 * Any entity metadata that takes a block state
 * The block change and multi-block change packets
 * Chunks serialized over the network (for all palette implementations)
 * Particles that use a block state

Here is a burger page of the flattening, sorted by new numeric ID (though note that the new numeric ID is no longer hardcoded, instead it's dynamically generated incrementally). It also includes block state IDs (well, the range they take, not all the ID combinations). So far, there have been no shifts of IDs, although a few IDs have been swapped around (fences specifically) in a few snapshots. Of course, everything has a new ID post-flattening.

I still think there is value in listing numeric IDs, at least until they're gone from the protocol (which can definitely happen for block IDs and item IDs, though state IDs are probably going to stay forever because sending strings in chunks wouldn't be good). Oh, and there are definitely other numeric IDs, such as those for entities, which are still present. --Pokechu22 (talk) 22:16, 31 December 2017 (UTC)

Plains M
It seems there is an ID missing for Plains M biome. –Preceding unsigned comment was added by 93.103.92.1 (talk) at 19:50, 06 September 2015 (UTC). Please sign your posts with


 * Fixed, plus made the table used the same one from Biome. – KnightMiner  t/c 21:35, 6 September 2015 (UTC)

There is no "Plains M" biome in the Minecraft code. The mutated variant of plains is "Sunflower Plains". Biome ID 128 is unused. 91.44.216.151 01:51, 17 June 2016 (UTC)

Jukebox Before Beta 1.6
Before Beta 1.6 The Jukebox did not have a Tile entity. The data Value goes as follows 0 being empty 1 having music disc "13" contained and 2 having music disc "Cat" Contained. Upon updating the player would lose the disc contained in the Jukeboxes. I changed the History section of Jukebox the reflect when the Tile Entity was added; and am posting here so anyone who might need this info can find it. Laige 04:40, 17 October 2015 (UTC)


 * That's great. What do you mean by "upon updating"?  Block update, or game upgrade? – Sealbudsman talk/contr 14:26, 17 October 2015 (UTC)


 * Updating to the next beta version would cause the music disc to be lost. There was no special code in the following version to try to save any disc that were in the jukebox  Laige  19:22, 28 March 2016 (UTC)

In-code names
The status effect and water and lava sections mention "in-code" names. Are these names actually exposed in localization files or something, or are these just names that have been assigned in Forge or something? &mdash;munin &middot;  &middot; 18:25, 30 July 2016 (UTC)


 * Looks like internal block IDs to me, same ones used in commands. The in code variables from MCP would be similar but are not worth mentioning (then again, that whole comment seems out of place, just mentioning they use a separate block ID for flowing would be sufficient. (these days they use all caps for some odd reason) – KnightMiner  t/c 01:57, 31 July 2016 (UTC)

Old entity names
Now that 1.11 is released all the pre-1.11 data is just gone from the page. As not everyone uses 1.11 (most modded players use 1.7.10 or 1.10) the page should also list the old entity names. Maybe behind a spoiler below like the old xp level info is on the experience page. WildBluntHickok (talk) 02:52, 27 November 2016 (UTC)
 * Agreed. Those legacy names are still stored in the code, and are used in a few places - they should be kept for reference purposes at least.  (One place where they're used, at least if I recall correctly, is with translations).
 * Also, the 1.11 names need to be prefixed with  as they are namespaced and technically speaking the names of the entities are   and not , even if the namespace does default to  .  --Pokechu22 (talk) 06:16, 27 November 2016 (UTC)
 * EDIT: An additional point: Even newer entities have legacy names - there's both  and   in the code.  --Pokechu22 (talk) 06:24, 27 November 2016 (UTC)
 * 2nd EDIT: Yet another thing of note:  is actually remapped to ,  ,  ,  , and  .  So it would need to be noted that   was the old old name and   is the new old name.  That's... a wee bit confusing.  But worth noting.  --Pokechu22 (talk) 06:28, 27 November 2016 (UTC)

crops with a data value of 0xF have been spotted
What does the word "spotted" means? I'm trying to translate this sentence into Chinese, but I don't understand this word.'''SteveZihang zh.Patroller 06:07, 27 June 2017 (UTC)
 * It just means it may exist. It may be outdated though – Nixinova • Grid_Book_and_Quill.png Grid_Diamond_Pickaxe.png Grid_Map.png • 06:12, 27 June 2017 (UTC)
 * Since there's not a blockstate corresponding to anything beyond age, I think it's safe to say it's outdated. – Sealbudsman talk/contr 06:29, 27 June 2017 (UTC)
 * To answer your question directly, "spotted" means "seen" or "encountered", ie "People have seen crops with a data value of 0xF". That said, that specific sentence probably shouldn't be tranlsted. --Pokechu22 (talk) 07:28, 27 June 2017 (UTC)

Hopper is collectible
I have noticed that the image containing all the blocks and items says that the hopper (ID 154) is uncollectible. This could be because it is the block and the item is collectible, but I can't find the item. What's wrong? –Preceding unsigned comment was added by 145.90.86.59 (talk) at 15:04, 15 January 2018‎ (UTC). Please sign your posts with
 * The item in the inventory is the hopper block itself (ID 154), but it has a two-dimensional inventory icon. Therefore, it should say that it is collectible. – ITechieGamertce 15:15, 15 January 2018 (UTC)

1.13
As the numeric IDs have been completely removed, there is a problem happened. How to add the additions introduced in 1.13? Is it just type  or   in the numberic ID row? Actually I just want to add new things quickly! -- Lxazl5770 zh.admin （ 论 • 功 ） 13:27, 18 February 2018 (UTC)


 * We may completely rewrite this article later… Hayden Ken Mutthew   Talk  05:57, 13 June 2018 (UTC)


 * I previously commented on the "Can you remove the numeric IDs" section that I didn't want the information to be removed. However, I wrote that before something important happened; 18w01a exposed data generators.  Running   gives the same protocol-usable data for current versions, and is directly intended for developers; all the dynamic numeric IDs can probably be hidden from the article.  However, data generators are new to 1.13; the information about numeric IDs should not be deleted, only archived as it is still needed for prior versions and the same documentation can't be obtained there.  Probably, this should be done as an /unflattened/ subpage (similar to indev and classic).  Information about metadata should also be transcluded there (since that is no longer valid for 1.13) and this article should transclude block state info instead.  --Pokechu22 (talk) 06:25, 13 June 2018 (UTC)


 * Normally what I do when there are this type of major changes is make a subpage article with the new version (something like Java Edition data values/1.13) with all the new information. When the update releases I move that to the article and add a different subpage with the old information that is linked from the history section (something like Java Edition data values/Before 1.13, see Trading). – KnightMiner  t/c 15:02, 13 June 2018 (UTC)

Easter egg
ID 451 didn't exist, as the devs intentionally skip 451. This may be a reference of Fahrenheit 451. How do you think? Hayden Ken Mutthew  Talk  13:35, 19 June 2018 (UTC)


 * I remember looking at the line number table and there being a missing line there, possibly where an item was commented out. I don't think it's a reference to anything specific, just something they had but disabled before release.  However, I don't think that blank line exists anymore as of 1.13 (after all the refactorings), which is interesting...  --Pokechu22 (talk) 14:33, 19 June 2018 (UTC)

Dealing with 1.13 (suggestion)
Now, 1.13 has just been released, and, due to the massive refactorings Mojang made to be sure that they can keep adding blocks to the game ("The flattening"), this article has become obsolete. I think updating this article is just not worth it. As this wiki still keeps information from versions from 2009 and 2010, removing all of the data values-related outdated info that apply from Infdev all the way to release 1.12.2 is not justified. So I suggest to rename this article to "Java Edition data values/Before 1.13", remove all 1.13 information that it contains (like the new enchantments and biomes), change the tense to past perfect and create a NEW article called "Java Edition data values" to have all the current data values. As 1.13 removed all the numeral IDs for blocks and items, I think the list of those should be sorted alphabetically in the new article.