Talk: Java Edition data values/Archive 2

Entity 48 Mob Clarification

I cant seem to find info on entity 48. I cant produce anything in-game with it either. If someone knows anything about this please post. The link just takes you to a the mobs page which does not give info about the entity 48 at all. Did entity 48 at one time encompass all the creatures we know as Mobs? —Laige 9:15, 10 Aug 2014 (UTC)

--New findings could this be the entity ID for the this Steve the OLD Steve made by Doc? —Laige 11:01, 10 Aug 2014 (UTC)

Here's a partial view of the class inheritance, using MCP names:

• Entity
  • EntityLivingBase
    • EntityLiving
      • EntityCreature
        • EntityMob
          • EntityZombie etc.

Entity 48 corresponds to the EntityLiving class; entity 49 is the EntityMob class, which was used for the Human mob. Not sure why EntityLiving even has an ID, since it's a very generic superclass of all mobs. -- Orthotope^talk 18:48, 10 August 2014 (UTC)

Thank you for your help. Laige (talk) 22:14, 12 August 2014 (UTC)

Farmland Meta Data Out of Date

Looking into the meta data for farmland. It appears the info on this page is out of date but I want someone to confirm it. I am working off 1.7.9 with 0 for dry and 7 for wet. The distance from the water source not handled by the block meta data. But rather a count down from 7 to 0 after the water source is destroyed. As in the the farmland is drying out and then at 0 the block eventually turns into dirt. Please confirm this so we can update the page with accurate info. Meta data 8 and higher for farmland also counts down but does appear legitimately in-game. —Laige 14:15, 21 June 2014 (UTC)

--- Waited long enough. I updated the page to reflect the findings in 1.7.9 farmland metadata. I have attempted to run the same test in the new snapshot as well, 1.8 may see yet another change to farmland, I will wait for the release, retest and post those findings. —Laige 8:09, 10 Aug 2014 (UTC)

Page content restructuring

This page is way too long imo. Wouldn't it be more practical if the data/damage values of specific blocks and items were described in their respective articles? We could still link to them from the block/item ID table. —Fenhl 11:15, 28 July 2012 (UTC)

I agree, and I've been considering doing something like this for awhile now. Putting the data values in the respective articles of the items they describe may not be best, though, since in some cases the same data values apply to more than one item. --Celtic Minstrel 23:57, 17 December 2012 (UTC)

For starters, the ID colouring system seems to have gotten overly complex. It's now trying to cover several aspects of how items can be obtained:

1. With the /give command (or inventory editors); true for everything except air
2. In Creative mode via the item list
3. In Creative mode via block picking
4. By trading with villagers
5. By using enchanted tools

The default (a black ID) is presumably something like "can be obtained by mining, crafting, or killing mobs". I think it would be sufficient to reduce this to two basic things: "obtainable in Survival", and "obtainable in Creative"; that means four colours including black. Air is a single exception, so I don't think it really needs a colour of its own. Still, if others disagree, that's five colours. Then other aspects of availability (item list vs block picking, enchanted tools vs villagers vs regular tools) can perhaps be indicated in some other way. Not sure how though.

I'm currently working on a page that could go at IDs (which currently redirects here); the idea would be for the ID lists to be moved there while leaving the data values (or at least an index to them) on this page. (This page would of course link to the IDs page.) Some of the data values could also be split out into subpages (especially potions).

Any thoughts on either of these points? --Celtic Minstrel 00:52, 18 December 2012 (UTC)

In-progress split here. --Celtic Minstrel 03:00, 18 December 2012 (UTC)

Unless I have some feedback by, say, the end of December, I'm probably going to go ahead and just make this change. Basically, this amounts to moving the page linked above to IDs, removing the corresponding info from this page, and also some reorganization of this page. --Celtic Minstrel 19:42, 24 December 2012 (UTC)

I have added a section to the style guide talk about moving the data values descriptions. —Fenhl 02:39, 28 May 2013 (UTC)

As of today ( 28 Sep 2013 ) page is reorganized and for me whole usefulness is lost. All suggestions above does not give any single reason why such change must be done. My assumption is that as web development theory says - "page must be compact and scrolling should be avoided because users lost interest" ( this is not exact quote, it's my interpretation ). If we dissect above statement it has few points - 1st it was written long time ago when Internet was slow and huge pages take for ever to load. This is no more true. 2nd 'loosing interest' applies to boring data - say endless 'how great is my idea'. This page is about one of the most innovative game at this time, you can't lose interest. This wiki is for beginners mainly and having information at one place it is easier - say I have block ..ok let's see what else can I relate to it ... something for digging, something for storing, something for moving, something for covering, other for combining .. I can't even find newly reorganized articles and I know what I am searching. Do some of the folks above have any complain about 'old' page ? /* sorry for being too detailed. */--Ardour80 (talk) 21:06, 27 September 2013 (UTC)

The article was split up because the new servers can't handle such a large page -- it was timing out. It's possible that once the migration issues are settled, the new servers may be able to handle it again, but until then, something was needed.

I started a discussion below about what's the best way to split it up.

—munin · 16 px 16 px · 21:18, 27 September 2013 (UTC)

Lily pad facing direction

I would like to know which bit telly you in which direction the lily pad's facing
does anybody know that? thx for your help --Rebio 16:49, 17 September 2012 (UTC)

There isn't one; lily pads' orientation depends on their location. Other than that, I don't know the specifics of how it works. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 01:14, 18 September 2012 (UTC)

And how can you tell by its location in which direction it is located?

Is there any (secret) rule fot that?

--Rebio 16:53, 19 September 2012 (UTC)

"Other than that, I don't know the specifics of how it works." Try the Lily Pad article. 「ディノ奴千？！」^{? · ☎ Dinoguy1000} 03:07, 20 September 2012 (UTC)

I believe the biome affects the orientation. I haven't figured it out. Erich666 00:50, 1 October 2012 (UTC)

Not true. No matter in which biome you are in (or even it's a different world) the orientation is only bound to the the lily pads position in the grid. So eg. 0/100/0 has the same orientation no matter which biome you are in or world seed was used

--Rebio 20:56, 31 March 2013 (UTC)

Wither Skeleton EID

I don't see an Entity ID for wither skeletons, though 65 is missing. I understand that they share a lot of things with skeletons, but they must be defined differently somehow. Whatever the case, it should either be in the EID table, or explained nearby. Cultist O 12:11, 1 January 2013 (UTC)

Wither skeletons have the same entity ID as regular skeletons; an internal flag is used to keep track of which type it is. ID 65 is the bat, listed slightly out of order to preserve a nice distinction between hostile and passive mobs. -- Orthotope 12:48, 1 January 2013 (UTC)

Redstone Comparator (active vs. inactive)

I just played a bit with Minecrafts code and now I have a question of which I hope someone else can answer it. The Redstone Comparator has an ID of 149 (Inactive) and 150 (Active). It seems to me that the Redstone Comparator is NEVER active. The 'active' redstone comparator (I call it active when it has the red light glowing in the middle) is not 150 but rather the "1" bit of 0x8 ("0" is an inactive/not powered/no red light glowing comparator). This is not the case with redstone repeaters where there are two different ID for active and non-active.
Do I just miss something or is there really something crazy going on in the code of MC?
cheers, Rebio (20:53, 31 March 2013 (UTC))

Entity IDs

Why are firework rockets located in Blocks? Shouldn't they be in Immobile & Projectiles? --GreenStone^(cont) (ru.Wiki Admin) 19:30, 1 April 2013 (UTC)

stained hardend clay 159

add please. --209.188.41.111 19:08, 10 May 2013 (UTC)

Already did. didn't make a new data value section, because its the same as wool. Firebastard 13:00, 11 May 2013 (UTC)

Crops with data in inventory

maybe this is the wrong place to be putting this but I'm trying to get crops (the block) in my inventory, in each of its stages. I've only been able to spawn it as its first stage... Every plugin has disallowed it in any other stages (they are all textured to be items). Is it even possible to hold Crops:5 etc. in the inventory? If so, how can it be done?! 184.58.229.224 01:03, 21 July 2013 (UTC)

I suppose the principle applies that blocks which cannot be acquired with metadata in regular gameplay also can't be held in inventory with a damage value other than 0. --☺ Sven ^{? !} 20:36, 21 July 2013 (UTC)

I have been trying to do this as well. Is it just not something that can be done? Like, a vanilla restriction? Cossacksson Talk Cont 00:50, 22 July 2013 (UTC)

Seems to be. Even when I set the data value with an NBT editor, it doesn't show up in-game. -- Orthotope ^talk 02:04, 22 July 2013 (UTC)

That's disappointing. I was hoping to be able to utilize the textures of the growth stages for a custom map/resource pack duo. Cossacksson Talk Cont 09:09, 27 July 2013 (UTC)

New Potions

Would someone add the damage values for the new potions? e.g Potion of Health Boost. Yes, those potions exist--- Tonkku107 20px(User Page|Talk)20px 07:26, 12 August 2013 (UTC)

Stone Brick DV's

From testing using /give, the Stone Brick ID's for Mossy and Cracked bricks are backward. Seemingly /give player 98:1 = Mossy, 98:2 = Cracked unlike what is stated on the page. Can anybody else confirm? ~~ [Chozo4] 70.127.216.53 05:13, 29 August 2013 (UTC)

Confirmed, fixed. -- Orthotope ^talk 05:52, 29 August 2013 (UTC)

Update

The new biome ID's aren't in the biome ID table, please fix Mokiki 19:24, 5 September 2013 (UTC)

It was fixed Mokiki 04:23, 8 September 2013 (UTC)

Article split

Some aspects of the recent split need cleaning up, but there seems to have been very little discussion preceding this split so I don't know what the end goal is here. Is it the intent that other ID sections also be moved to subpages? Should item data value details be moved to Data values/Item IDs, etc.?

There was a discussion about moving the IDs to IDs, and there was a discussion about transcluding block/item data value details into their own articles, but I don't see anything about moving ID sections to subpages.

Personally I find it very useful to have all the ID tables on a single page, and having the data value details right on the same page is also convenient. Is this split necessary?

—munin · 16 px 16 px · 21:11, 26 September 2013 (UTC)

Okay, I found the impetus for the split. Alright, if a split is necessary, let's consider how all this should be organized.

1. By data structure

Put all the ids in IDs and leave data values in Data values.

2. By in-game type

Move block ids and data values to Blocks (there are already a lot of block ids there), item info to Items (almost a stub article right now), entity info to Entities. Biome, Enchanting, and Status effect already contain the information here. Leave data values as a stub navigation.

I like #2 myself. Any other ideas?

—munin · 16 px 16 px · 23:09, 26 September 2013 (UTC)

I would favor #2 as well. Since the style guide was updated to include a Data values section for articles on blocks and items, it would be unnecessary to have them on this page as well. They just need to be moved over first. —F‌enhl 06:33, 28 September 2013 (UTC)

Third (obvious) option:

3. Retain current organization

Just use LoadBoxes in data values to allow readers to load the ID info they want. This is the current trend and isn't too bad.

I'm kind of hoping that these server issues will be reduced with further patches (we're currently on MediaWiki 1.19, and I'm expecting us to get at least to 1.21 within a few months), which may allow us to put the article back the way it was before the migration.

—munin · 16 px 16 px · 18:17, 28 September 2013 (UTC)

The use of many complicated templates is what is bringing us down. Lua will greatly reduce this issue. –Matt ᐸ Talk
Contribs ⎜ 21:04, 28 September 2013 (UTC)

The parts that take up the most space ("block data") are the parts that have been left as part of the normal page, while the more often used (I would imagine, at least) parts (basic block/item IDs) have been put into annoying click to load things. I would think the other way round would be better. Also, do we really need "minecraft:" to be there for every block/item name? It's always the same, so just mention that at the top. That would save a lot of space and make it more readable (closer to the nice compact format it had before the names were added...) Bah 19:11, 21 October 2013 (UTC)

Hex/Binary IDs

Why even have these on a page? They dont even work. 96.60.242.215 00:25, 7 December 2013 (UTC)

Hay Bale missing

Just noticed Hay Bale is still missing. Like Logs it's got 3 different facings plus a "side texture on all 6 faces" version. Damage values 0, 4, 8 and 12. –Preceding unsigned comment was added by WildBluntHickok (talk • contribs) at 06:30, 11 January 2014‎ (UTC). Please sign your posts with ~~~~ (archival note: this unsigned was added far later --Pokechu22 (talk) 06:59, 18 March 2017 (UTC))

-I'm not sure how long the above statement was here or who wrote it, but I want to clarify that the "all sides" of hay bale meta data of 12 is no longer available and hasn't been since the block-states were added. Previously however the Hay Bale did follow the same format as Log and Log2 Laige 01:21, 17 October 2015 (UTC)

Thanks, that's great, I've made note of it on the Hay Block history section, and on the 14w17a page where it was removed. – Sealbudsman ^talk/_contr 13:46, 17 October 2015 (UTC)

JSON api down

just noticed that the JSON api link gives a server not found --MasterX244 (talk) 13:12, 19 January 2014 (UTC)

Daylight sensor tile entity

The block list says that daylight sensors have a tile entity, but there doesn't seem to be any information about what's stored in it at Daylight Sensor, Block entity or Chunk format#Tile Entity Format?

—munin · 16 px 16 px · 10:49, 20 February 2014 (UTC)

It was added by an anonymous editor here, with no explanation given. Removed. -- Orthotope^talk 03:15, 21 February 2014 (UTC)

Checking NBT structure, the block is in fact listed under "Tile Entities", but there's nothing there apart from its tile ID and XYZ coordinates. Images example: https://web.archive.org/web/20190712162021/http://i.imgur.com/sa8NdoM.png I have no idea why it needs to be stored as a tile entity, so hopefully somebody can enlighten us. Skylinerw (talk) 06:25, 21 February 2014 (UTC)

It doesn't store any data. As far as I can tell, the tile entity only exists to get world updates every tick, which it uses to force the daylight sensor block to update its output level once per second. -- Orthotope^talk 06:51, 21 February 2014 (UTC)

I did some testing with the daylight sensor and the inverted version of it. I used Mcedit to delete the Tile Entity (TE) which froze the block in the state it was in. As in it no longer updated it data value with the day change. I think that the TE is completely responsible for the updating of the block. It seems to me that mojang did it that way for speed and reliability. I don't know if this is even important to you guys anymore? but you can try it out for your self. —Laige 9:15, 30 Dec 2014 (UTC)

Needs Serious Updating

The whole 'numbers for IDs' thing has been taken out of Minecraft for quite a while. Should we just update all of the page, or delete it all together? (Of course, remove the picture.) -OR- just leave it as it is, and notify viewers that it's now unimplemented/removed? --SniffietComa5 (talk) 02:29, 2 March 2014 (UTC)SniffiestComa5

I can't tell if you've seriously proposed deleting this page, but… This page isn't about commands, it's about documenting values, numeric or alpha. While support for numeric block ids in commands has been removed in the snapshots, they are only a small portion of this article, and will still be of use to third-party editors, etc. —munin · 16 px 16 px · 19:29, 3 March 2014 (UTC)

I think they're referring to :File:DataValuesBeta.png, which is getting out of date. However, the current release version (1.7.5) still supports numeric IDs, so I don't think that image needs to be removed yet. -- Orthotope^talk 19:41, 3 March 2014 (UTC)

Script error, out of memory?

This page is getting script errors in the various templates starting at #Coal. It is at a memory peak? If so I would suggest attempting to split the page, or linking to various articles for the Data Values. --KnightMiner ^{(talk|contribs)} 02:53, 20 May 2014 (UTC)

This is the coal table code:

	DV	Description
	0	Coal
	1	Charcoal

This is what the code looks like (with spaces added) :

{ { : Coal /DV } }

When you click on certain occurrences of the red error text, it says something about Lua (which is a programming language), which might be how it retrieves the data table or whatever. If the tables were inserted into the article itself, then I think that the problem may be solved. 23:14, 25 May 2014 (UTC)

Pressure Plate Block Data Description Inaccurate

The block data section for Pressure Plates is inaccurate. This does not function as a bit flag which is flipped on/off, but merely toggles between values 0x1 and 0x0, ignoring any existing metadata values. Not sure if this is important to note here, since there aren't supposed to BE any other data values, but advanced texture pack authors need to be aware that this will destroy metadata because it doesn't function as a true bit flag. –Preceding unsigned comment was added by Graagh1 (talk • contribs) at 05:10, 7 July 2014 (UTC). Please sign your posts with ~~~~

Script Errors

This page is full of script errors. I would appreciate it if someone who knows how to use scripts would fix them. Thanks!

--saanoth 11:54, 8 July 2014 (UTC)

It can't be. This page is simply using too many individual templates. –Matt ᐸ Talk
Contribs ⎜ 12:13, 8 July 2014 (UTC)

But we can't keep it like this, as there are errors showing up. What about splitting it? --saanoth 12:16, 8 July 2014 (UTC)

That works as a temporary solution. I might be able to reduce the amount of templates by removing the pretty useless hexadecimal and binary conversions from {{dvt}}, but otherwise the "table of templates" parts really need to be converted into a more efficient single module. The problem with lua is it has a memory limit, and lots of #invoke calls cause a lot of memory overhead, so you don't want lots of templates calling small lua scripts, rather a few templates calling large lua scripts that do that same work as all the small ones. –Matt ᐸ Talk
Contribs ⎜ 12:30, 8 July 2014 (UTC)

Didnt understand to much of that, but I was thinking could we use the "Load page" things, being used on the Development versions page, to solve this problem? I am aware that they shouldn't to often, but this is one of the longest pages on the wiki. What do you think? --Sanoth^t|c 12:41, 8 July 2014 (UTC)

It actually seems to be fixed by just removing the templates from {{dvt}}, which has significantly reduced the memory usage (only 28/50 MB). I doubt the hexadecimal and binary data values were even at all useful to anyone. –Matt ᐸ Talk
Contribs ⎜ 12:44, 8 July 2014 (UTC)

Yeah seems solved. Nice! Thanks! --Sanoth^t|c 12:46, 8 July 2014 (UTC)

We hae a "hazy" problem

I know the name for sand is minecraft:sand, but what is the name for red sand? Red sand seems to be the only block not listed on the chart. What gives?!

98.21.246.64 18:10, 6 September 2014 (UTC)SquareMan78649

The little S next to the block name means that additional block data is required to fully define the block. Regular sand is minecraft:sand with a block data value of 0, and red sand is minecraft:sand with a block data value of 1. These data values are described further down the page. —munin · 16 px 16 px · 18:27, 6 September 2014 (UTC)

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)

Block/item data

We should migrate block and item data to a separate page, as not only does it not make sense to list those and not block states or chunk format here, but it also is currently being phased out, and it being on its own page would be better for history's sake (no point in stating "over half this article is outdated, but the rest is still fine").

—KnightMiner ^(t|c) 03:43, 9 October 2014 (UTC)

I'd be fine with moving the IDs section to IDs or Identifiers (maybe try seeing if it will load without LoadPage-ing). I wouldn't say it's outdated quite yet, since it's still visible to players with F3+H.

Honestly, now that we're starting to get all this information into articles, I'm using the master lists less and less. —munin · 16 px 16 px · 05:34, 9 October 2014 (UTC)

Structured data

I have extracted part of the data present on that page (and on some other pages) and stored it in a structured way (json) in that repository . For example items.json was extracted from Item_IDs and the infoboxes.

Would it be a good idea to add a link to this repo somewhere on the Data_values page for people interested in using structured data ? –Preceding unsigned comment was added by Rom1504 (talk • contribs) at 8:01, 28 May 2015 (UTC). Please sign your posts with ~~~~

I cannot see it helpful to anyone reading the wiki, as the data in json format is really only useful for a program. I would suggest you post in on the [[forum:|forums]] as the people there might find it more useful. –KnightMiner ^t/_c 16:06, 28 May 2015 (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)

dragon_breath not dragon's_breath

The in-code name for Dragon's Breath is listed incorrectly in the item ids list. It's supposed to be dragon_breath not dragon's_breath. Spent 20 minutes trying to figure out the error in my drop tables before I noticed that (checked using auto-complete). –Preceding unsigned comment was added by WildBluntHickok (talk • contribs) at 11:04, 23 October 2015 (UTC). Please sign your posts with ~~~~

Fixed. The ID names are added automatically here by making the name lowercase and replacing spaces with underscores, and it seems someone forgot to set dragon's breath as an exception to that rule. –KnightMiner ^t/_c 13:36, 23 October 2015 (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)