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)

"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	„
	— #mcdevs 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 MC-105922 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. HaydenBobMutthew (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? —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)

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 • • 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. – ITechieGamer^tce 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 N/A in the numberic ID row? Actually I just want to add new things quickly! --Lxazl5770 zh.admin（论 • 功） 13:27, 18 February 2018 (UTC)

Lxazl5770 (talk • contribs • logs • block log) We may completely rewrite this article later… HaydenKenMutthew 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 java -cp minecraft_server.jar net.minecraft.data.Main --reports 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? HaydenKenMutthew 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. –Preceding unsigned comment was added by 139.47.29.138 (talk) at 2018年7月21日 (六) 01:13 (UTC). Please sign your posts with ~~~~

 Support. See also 1.13/Flattening.--SolidBlock (not good at English!) 01:59, 15 August 2018 (UTC)

 Support archiving pre-1.13 data from this page and making a new one under this name. --AttemptToCallNil (report bug, view backtrace) 08:17, 15 August 2018 (UTC)

 Support. That's what I hope so.--Lxazl5770 zh.admin（论 • 功） 09:02, 15 August 2018 (UTC)

I'm refraining, but I'd like to say that following the creative search tab will be better than alphabetical.

Also note that the wiki generally does not have info from old versions except in history sections, the wiki is supposed to describe the game as it is right now, and old data doesn't really have a place in that. FVbico (talk) 13:26, 16 August 2018 (UTC)

 Support keeping copy of old data, since it's needed to properly migrate to the new format (for the same reason Java edition data values/Indev is kept). It's not useful to keep, say, 1.11 since the 1.12.2 data includes that fully, but 1.13 basically removes the equivalent data so keeping an archived copy is useful IMO. --Pokechu22 (talk) 15:41, 16 August 2018 (UTC)

Question

That's the difference between Data values, Block data, and Block data value? — RDmitriyS (talk) 17:25, 28 August 2018 (UTC)

He probably means "What's the difference ..." --AttemptToCallNil (report bug, view backtrace) 17:31, 28 August 2018 (UTC)

Data values include IDs and alike.

Block data is mostly referring to the NBT data

Block data values refers to the metadata. FVbico (talk) 09:47, 16 September 2018 (UTC)

Data values include IDs? Not removed since 1.13? --SolidBlock (not good at English!) 09:31, 4 October 2018 (UTC)

Yes, it's still a data value, it still a value in the block's data. FVbico (talk) 10:49, 4 October 2018 (UTC)

Order of blocks, items, and enchantments

Now that numeric IDs are removed (or hidden or volatile or whatever), what is significant about the way blocks, items, and enchantments are ordered in this article? If the answer is "creative inventory", then how are the "cannot be obtained in inventory" items ordered? an_awsome_person (talk) 07:44, 24 September 2018 (UTC)

Just at the bottom of the list.

I do think we need a bit clearer ordering though... FVbico (talk) 07:52, 24 September 2018 (UTC)

What do you mean? Which article do you want me to look at? I didn't see anything about ordering at the bottom of any list in this article. an_awsome_person (talk) 08:09, 24 September 2018 (UTC)

Sorry, small correction: Creative inventory, and the answer to "then how are the "cannot be obtained in inventory" items ordered?" is "just at the bottom of the list". FVbico (talk) 08:32, 24 September 2018 (UTC)

If there are multiple items at the bottom of the list, then how are those ordered? an_awsome_person (talk) 17:56, 24 September 2018 (UTC)

What about ordering blocks as they are in debug worlds? GammaMicroscopii (talk) 23:43, 5 October 2018 (UTC)

Personally, I would just order alphabetically by their internal ID. Keeps it consistent and simple. If you want, maybe divide into obtainable and not, but that is complicating things a bit. –KnightMiner ^t/_c 22:37, 6 October 2018 (UTC)

I don't think it's good to list as tables

The three-column tables are not convenience to read. Also, it appears badly in mobile view. --SolidBlock (not good at English!) 09:31, 4 October 2018 (UTC)

Should namespaces be shown?

Should prefix "minecraft:" be shown before each id, such as "minecraft:wool"? Also, should vanilla recipe, loot table, advancements and structure ids list in the page? --SolidBlock (not good at English!) 09:33, 4 October 2018 (UTC)

Namespaces are not shown on the wiki for vanilla content anywhere; showing it here would be inconsistent and redundant.

As for recipes, loot tables, advancements and structures, they are already listed on their corresponding pages (all advancement IDs are on the advancement page, all loot tables on the loot tables page, etc.), not saying it's not a bad idea, just saying that those IDs are already collected on more respective pages. FVbico (talk) 10:45, 4 October 2018 (UTC)

Sort alphabetically?

I think this page should sort it's tables alphabetically by name ID, this is the only order that remains consistent in the game, in the command suggestions.

Right now, it's by numeric ID/creative inventory, but those listing methods will both be incomplete, as it doesn't cover 1.13+ blocks (numeric ID) or doesn't cover blocks that have no item form/are only obtained with commands (creative order).

Also in order to do this, the separate tables for entities should be merged, as an additional argument, it's about the data values not the entity type.

Any opinions? FVbico (talk) 13:15, 26 December 2018 (UTC)

 Support --HaydenBobMutthew ^{(talk, contribs)} 14:58, 26 December 2018 (UTC)

I don't think this is a good approach, since you can just sort the table by yourself (by clicking the up-down arrow). I would think categorize them, with no header, on the same table, but sorted alphabetically on each category. E.g (sorting from A, B, and F as for Air, Bed, and Food): (I'm kinda mixing up blocks with items here, but you get what I mean)

• Air
• Cave Air
• Void Air
• Black Bed
• Blue Bed
• Brown Bed
• ...
• Yellow Bed
• Apple
• Baked Potato
• Beetroot
• ...
• etc. – ItsPlantseed ⟨₰|₢⟩ 15:38, 26 December 2018 (UTC)

I'd find this actually more confusing than it's current way already, as some items/blocks can be classified in several categories. FVbico (talk) 16:15, 26 December 2018 (UTC)

Fair point. If that's not the way it is. Sorting alphabetically would be doing just fine nonetheless. – ItsPlantseed ⟨₰|₢⟩ 17:33, 26 December 2018 (UTC)

 Mixed Support. I think it's worth noting that the ID-based sort actually does still work (there is an order still, as used over the network, which can be seen using the Data Generators system, which was actually expanded further in 1.14 to include additional numeric registry IDs (side note, I still need to get interwiki stuff with wiki.vg set up)). However the IDs themselves are definitely not worth including since they all are dynamically allocated per version and do shift when some blocks are changed. On the other hand, there is a much easier way to see the sort for blocks: the Debug mode world. Everything in there is sorted the same way as would be seen in the creative inventory, ignoring MC-122412. I'm not sure whether or not it makes sense to change the sort for blocks and items as such. (Other things such as entity IDs definitely can be alphabetized; their registries are already mostly alphabetized and it's not something that is normally exposed in any other manner (but I think them being split like they are in the article currently is fine)). --Pokechu22 (talk) 19:52, 26 December 2018 (UTC)

Numerical sorting has been obseolte since 1.13 and to find any information currently you have to have good knowledge of the inventory layout. – Nixinova 23:17, 20 January 2019 (UTC)

Any further opinions on this? If not, I guess the tables will get sorted alphabetically, but the entities table not merged. FVbico (talk) 22:57, 31 March 2019 (UTC)

Air Available ?

Should the Air not be greyed out as well? Uncovery (talk)

IMO no. Since ~1.10 (I think) there's a concept of empty item stacks which are effectively air, and air is technically an item as well as a block (even though that doesn't persist to saving). It could probably go either way, though. --Pokechu22 (talk) 02:34, 20 February 2019 (UTC)

Phantom Spawn egg id typo

Phantom spawn egg is is phantom _spawn_egg instead of phantom_spawn_egg Uncovery (talk)

Fixed. Possibly a leftover from a table where spaces were added to do word-wrapping (in those cases I'd recommend using the wbr tag now, but not everyone did that and those spaces are sometimes still copied). --Pokechu22 (talk) 02:34, 20 February 2019 (UTC)

Dragon Egg

Should there be not a dragon egg in blocks? Uncovery (talk)

Fixed. --Pokechu22 (talk) 02:34, 20 February 2019 (UTC)

Knowledge Book

I am missing the Knowledge Book in the item list. 203.116.71.188

Particle IDs

Added them. But should they be accompanied with descriptions or textures? There's only 1 column now and looks kinda bland. Luotiansha (talk) 15:23, 15 October 2019 (UTC)

Both would be good, otherwise its not clear what each means without testing in game. –KnightMiner ^t/_c 16:18, 15 October 2019 (UTC)

Just an in-game screenshot, like on particles should suffice. FVbico (talk) 16:23, 15 October 2019 (UTC)

Does advancements need an ID list?

They seems have internal IDs. Luotiansha (talk) 18:28, 19 October 2019 (UTC)