Item ID to Material

My question is simple, really.
Since the newer (I am not sure since which one as I haven't been coding with Bukkit for some time) update(s) the methods to get a material via ID have been deprecated. I can not find a function in the Material class that I can use to somehow get the name (string) or material.

Is there a method to do this or do I require all my users to edit their files to make it work with the new update?

 

Isn't there a getItemById() method?

Try it, might work.

 

getItemID is the method that is deprecated in the ItemStack class.
getID is deprecated in the instantiated Material class (ie: getType from an ItemStack).
getItem(id) is deprecated from the static Material class.

Basically the whole ID thing has been throw out the window as far as I can see right now...

I just searched through Github for the change and I found it here: https://github.com/Bukkit/Bukkit/co...3dc625e#diff-5c7316dd5813bc0535d4c7bff4a51053
Just search for "Material.java" on that page. This is the response somebody got with the same question I had: "You should start mapping IDs to Materials now."
I don't really get what he means with this though.

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

I think that's a pretty accurate assessment, actually. The idea is to move away from item ids completely.

I am honestly not sure what the recommended alternative if for storing or configuring materials is. Personally I've switched to using the enum name (usually lowercased for readability). Serializing the Material enum seems a little overkill to me, and I feel like neither is a future proof solution unless bukkit promises to never change that enum at all.

 

Well the problem I have is that I load the ID's from a file, so I'm guessing I'll need to have everyone change their configs then... Quite a bothersome thing, but if there's no alternative, it must be done.

If anyone does know an alternative, do let me/us know here, it'd save me from changing a lot of code and (false) bug reports!

Also, I've been thinking a little about what the guy said over at Github.
From what I understand, they want the ID's to stop being "magic numbers" by binding an ID to a material. This would mean you should be able to get the ID via the ItemStack's material, right? That method is also deprecated.

And now that I think about it, how exactly are the ID's magic numbers? I mean, you could get the ID from a material, and they are always set to that material. They are not random, arbitrary numbers as far as I can see. Mmm...

EDIT by Moderator: merged posts, please use the edit button instead of double posting.

 

Randy Schouten
See, what I don't understand in this is why there is something wrong with the 'magic numbers'. It is far safer, more accurate and easier to store numbers than strings, so why is Mojang changing the system?

My advice: If you are really concerned about it, offer support for ID's and strings in your files for the time being. That way people who use your plugins can use both for the time being, hopefully with the knowledge that numbers might not work eventually. Then if Item Id's do break, it's not a horrible problem for you.

 

Well I found out why they are going to remove them. From what I've read, every world have different ID's the same block. For example, in world 1 the ID for dirt is 1, in world 2 it is 84934. That's why they remove the whole system and that's why ID's will not be usable anymore in some time.

In other words, everybody's going to have to switch to text instead of ID's eventually.

 

Hmmmm - can you link to where you read that?

I could imagine how this could be very cool.... Custom item and block types?!

 

Read through this a little: https://twitter.com/Dinnerbone/status/383725505805307904

 

Thank you for that link, Randy!

Wow... the more I think about it, the worse this sounds (well, and the better, in a lot of ways!) :\

I think this reply hit it on the head:

If material id's become unique per-world numbers, how are schematics going to work? Presumably any schematics created prior to this change will be broken, or at least need some kind of migration... I'm guessing like the new NMS Worlds they would have to have a "dictionary" of unique id's to material keys (presumably we'll all be dealing with some kind of string-based key that is the same from world to world and server to server). So a schematic would have to be loaded and translated from its legacy id-based format to something that has such a dictionary, so we can tell what types the blocks are by looking up the material keys- and the key would now have to be used to import all the blocks, instead of the int id's since those are now meaningless.

This all sounds way more flexible, but (as is often the case) at a potentially large expense (having an extra lookup everytime I want to get or set a block does not sound too great for what my plugin does).

I guess at least on Bukkit's side, we will hopefully not have to worry about it too much if they're able to make their Material system work with the new system, and then we just deal with the enums, and Bukkit translates from World to World for us... that would be ideal, and I'd honestly have to take back everything I ever said about how annoying it is that Bukkit is trying to make us all switch over

But, still.. yikes... if Dinnerbone is getting that much backlash from the Vanilla admin community (command blocks, etc) - we can only imagine the firestorm he'll get from the mod community once everyone is fully aware of how big of a deal this is! And I also note that tweet is from Sept, and references this change as "half a year away" ... intriguing

Well at least we've had Bukkit poking us with the deprecated tag for a while now- I know it's convinced me to mostly switch over (still not sure what to do with those data bytes), perhaps we'll all be prepared when the time comes... but I'll bet there are some mod developers out there that will get totally blindsided by this change!

 

Well, the thing we need to do now is instead of referencing from an ID, reference from a string. It doesn't really sound like a big deal, but the problem is that a lot of plugins did use that method to look up items and such. I myself have already programmed my plugins so they use a string instead of an ID, but still, this is a pretty major change. The biggest problem would come from developers who don't update their plugins anymore and did not release the source.

But then again, they did mention Mojang didn't know how they'll handle this problem, so Bukkit preemptively set the methods to deprecated to get people to change to an alternative method. But, there's no alternative in terms of ID lookup...

The only thing we can do really is look how it'll pan out. Maybe it won't be as bad as we think!

 

NathanWolf If this is about per-world block ids, the data types shouldn't be an issue because they're used on a per-block basis.

 

http://jd.bukkit.org/rb/apidocs/org/bukkit/Material.html#getMaterial(int)

 

I think it's extremely unlikely that vanilla item ID's will ever be different from server to server. That's work that Mojang simply doesn't need to make for itself, or its users.

The real point of deprecating the use of raw item ID's is for the upcoming modding API, where it will be possible to define new items and blocks; by ensuring that modding code never needs to work with raw item ID's, but only ever material names (e.g. 'minecraft:stone' or 'mystarwarsmod:lightsaber'), the problem of clashing item ID's simply doesn't materialise (ha ha). The mapping of material names to raw ID will be defined on a per-server basis and will be pretty much irrelevant to regular players. You'll notice that Mojang themselves are busy phasing out the use of item ID's in the various vanilla Minecraft commands too; it's just something that all Minecraft players need to get used to, not just CraftBukkit users.

As far as the Bukkit API goes, any methods dealing with item ID's are indeed deprecated, but they won't be going away any time soon. Try to avoid them where possible, but don't panic about them in your existing code. You have plenty time to decide how you want to move away from using them (and moving to using material names instead of material ID's in your config files is probably a good idea).

There are certainly big gaps in the Bukkit API right now which the deprecation of the various raw-ID methods has exposed - in particular, more MaterialData subclasses are needed, along with ways to get and set a block's type/data via MaterialData instead of a Material and byte. These things will come in time, I'm sure.

 

It's deprecated though...

 

That's exactly what I thought, right up until I read that "thread" on Twitter (I guess I need to follow Dinnerbone now...)

I mean, how do you read that? It sounds crazy, I know- but that really makes it sound like every world (or maybe server, whatever) is going to dynamically build a dictionary of ids to some abstract material definition as the server needs it, right?

 

OK, yeah, that will definitely break a lot of plugins (including some of mine ) Dynamically altering vanilla item ID's does sound a bit a daft, but if that's way Mojang are doing it, I guess we'll all have to adjust...

 

Not entirely daft, your sentence makes it sound like they would intentionally make sure they were different, but realistically it's probably more like a randomly populated array. You just don't know what ordinal it will fall at and there is no guarantee because they stopped tracking them numerically. That is why Magic Numbers are evil and should never be used.