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)

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)