Talk:Java Edition data values/Pre-flattening/Entity IDs

ids up to date ?
Are entity ids up to data ? I got different information from http://wiki.vg/Entities#Objects : is armor stand 78 or 30 ?

Also see http://wiki.vg/Talk:Entities#Are_ids_up_to_date_.3F --Rom1504 (talk) 12:24, 29 May 2015 (UTC)


 * wiki.vg is wrong. According to the latest version of MCP, the armor stand's entity ID is 30. – KnightMiner  t/c 15:36, 29 May 2015 (UTC)
 * Actually, it seems alot of their object IDs are wrong, assuming those are the same as the entity IDs. They even disagree with the other entity IDs they list for mobs. – KnightMiner  t/c 15:41, 29 May 2015 (UTC)


 * So I finally checked by sending packets with my server who is wrong and who is right, and wiki.vg is definitely correct here, for example 61 is both blaze and snowball. So yes entity ids collide, that's how it is. I probably correct these ids here.
 * --Rom1504 (talk) 22:42, 16 November 2015 (UTC)


 * So you are saying your personal tests are more valid source than the game's code itself? (for the IDs I mentioned in the game code, see ) It sounds more like a flawed test, especially since the game crashes from colliding IDs, it cannot just accept them (see a lot of mod related crashes).
 * Unless of course they are referring to a different ID number on wiki.vg than the entity ID, in which case that information should not replace the information here, but rather be added to it with an explanation of what the different numbers are. – KnightMiner  t/c 04:15, 17 November 2015 (UTC)


 * I'm referring to the only way to spawn an object or a mob in minecraft protocol : by passing its type in Spawn_Object or Spawn_Mob


 * I read that file  and indeed the ids are different. I wonder where these ids get used though ? they are not in the protocol.
 * --Rom1504 (talk) 01:26, 20 November 2015 (UTC)


 * I know in the past, a bug allowed you to give yourself spawn eggs for any entity (including projectiles/vehicles/mobs without eggs) by using the entity ID as the damage value, though now only the ones available in creative work. As for what that IDs are used for now, you would have to ask someone a little more familiar with the code (such as or )
 * And I assume by Minecraft protocol you mean the client/server communications? I wonder if the protocol IDs are referenced anywhere else in the code. In any case, I wonder why Minecraft uses two completely different sets of IDs, one for protocols and one for other usage. – KnightMiner  t/c 04:44, 20 November 2015 (UTC)


 * Quickly checking the source for cases of using the ID in EntityList for 1.8 shows that it's mainly used with the mob egg mapping, which stores the numerical ID instead of the name. Entities are added to the egg mapping if color codes are supplied, which is why you can only have those select few entities available as mob eggs (and is also why some stats are missing, like "stat.killEntity.EnderDragon"; no colors are supplied for EnderDragon in EntityList and stats use the egg mapping). Cases where the egg mapping is used, such as spawn eggs and statistics/achievements, will use the ID, though it can also be used to get the name or class from the ID.


 * In 1.9, egg mapping now stores the name instead of ID (I reckon for furthering support of plugin API). As far as I can tell, a lot of support for the numerical IDs is being dropped, though Anomie has more experience with the source than I to know.


 * For 1.8 MCP, the IDs on wiki.vg are SpawnObject packets sent via  (function func_151260_c), used in   (function handleSpawnObject). They are separate numbers with different usage from what's in , so neither is wrong. Just note that SpawnObject doesn't include every entity. Skylinerw (talk) 06:59, 20 November 2015 (UTC)
 * Looking at the server code for 15w47a (I don't usually bother checking the client code), the only place I see using the numeric IDs is the equivalent of MCP's EntityAgeable. Where 1.8 did, 15w47a does effectively   (func_180122_a could be named getIDFromString) since the metadata was changed to a string. Not sure why they didn't just make a "getClassFromString" method, they have the needed mapping in the code already.
 * Of course, looking through poorly-deobfuscated code I could easily have missed something else. Anomie x (talk) 11:40, 20 November 2015 (UTC)


 * Whats about fishs, arent they entitys as well?

--79.220.206.184 23:22, 15 January 2016 (UTC)


 * Fish items are items, not entities. Skylinerw (talk) 03:39, 16 January 2016 (UTC)

So just because I'm wondering and making sure: these discrepancies between the wiki.vg numbers and our numbers are legitimate, and our using say, 25 rather than 67 as the Shulker bullet id, is in fact correct? – Sealbudsman talk/contr 07:22, 8 October 2016 (UTC)
 * As described above, network packet entity IDs and in-game entity IDs are not the same thing. Anomie x (talk) 13:19, 8 October 2016 (UTC)
 * I get that. So we have to correct our numbers?  Because right now the things labeled 'network ID' aren't the network packet entity IDs. –  Sealbudsman talk/contr 14:40, 8 October 2016 (UTC)

Lightning
So, what do you think about leaving lightning_bolt, and putting a note on it saying it's a summon alias only? That way a. people checking this page looking for the summon alias do find it, and b. the difference between that and the savegame id is illuminated a little – Sealbudsman talk/contr 03:12, 6 October 2016 (UTC)


 * I'm not sure. It would be misleading in the sense that it's not a savegame ID, which is what the list is indicating. Maybe another column for "alias"? But then it's getting pretty wide. Or perhaps a third table dedicated to those without savegame IDs but may have a relevant alias for commands? Skylinerw (talk) 18:43, 6 October 2016 (UTC)


 * I like the 'third table' idea actually. – Sealbudsman talk/contr 19:14, 6 October 2016 (UTC)


 * Alrighty, I've added the table (which is hopefully formatted correctly), as well as the upcoming llama spit entity, though there's no icon for it (which is beyond my capabilities). Skylinerw (talk) 19:30, 6 October 2016 (UTC)


 * Very nice, thanks. Me or someone will get around to doing the icon. – Sealbudsman talk/contr 20:12, 6 October 2016 (UTC)