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|c) 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 MC-105922, 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 palette list with a name ID, and the array index is the numerical ID referenced in the blocks 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 MC-105922 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)

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? —munin · · 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 minecraft: as they are namespaced and technically speaking the names of the entities are minecraft:cow and not cow, even if the namespace does default to minecraft:. --Pokechu22 (talk) 06:16, 27 November 2016 (UTC)

EDIT: An additional point: Even newer entities have legacy names - there's both vindication_illager and VindicationIllager in the code. --Pokechu22 (talk) 06:24, 27 November 2016 (UTC)

2nd EDIT: Yet another thing of note: EntityHorse is actually remapped to Horse, Donkey, Mule, ZombieHorse, and SkeletonHorse. So it would need to be noted that EntityHorse was the old old name and Horse is the new old name. That's... a wee bit confusing. But worth noting. --Pokechu22 (talk) 06:28, 27 November 2016 (UTC)