[Discussion] Best 1.7.x way to do configurable items

Well since 1.7 saw the deprecation of the item Id system, making an option in a config to do XXX when using a user definable item has gotten a bit difficult. Here I would like some ideas and thoughts as to what is now the best way to do so.

What I have been using in 1.6.4, etc.. is that the user can specify the item in a similar format to WorldEdit uses in the config. eg:

Code:

actionItem: '35:15'

(Set actionItem to black wool).

However using ids is deprecated so it's not good practice to use that. So lets try using the Material Enum:

Code:

actionItem: 'WOOL'

Once again we run into a problem, the user cannot define the colour of wool here and it is a nightmare for them to configure as they'd need to know the entire extent of the Material enum. eg. WOOD_STAIRS, etc..

Now we could try and fix this mess with allowing them to specify colours for the wool with such:

Code:

actionItem: 'WOOL:BLACK'

However, yet again this is less favourable as with every variation of a block, we'd have to code into our plugins to allow them to configure it. For example 'LOGS:JUNGLE', 'DIRT:UNSPREADABLE'...

So here I ask you, how, in 1.7.x, is the best way to allow the server admins to define an 'actionItem' in their configs?

 

public Wool(DyeColor color) {
this();
setColor(color);
}

DyeColor is enumclass.

 

I know, but I mean in general for items. Not just wool.

 

Honestly, I still use getTypeId() in some cases, as it's much easier to type in to config files as such.
But, if you need to convert IDs to Materials, you can use the IDAPI that adam753 made. It can be found here: http://pastebin.com/rscFbS1f

If you want (and what I did), was just put an @SuppressWarnings("deprecation") at the top. It doesn't fix it, but I'm hoping there will be an easier way in the future.

 

Yes this seems a good way to fix ID issues, but doesn't help the fact that you still cannot specify the data values (the ':15' bit)

 

In case of bukkit, API is large list of limitations, that ensure plugin compatability and stability over versions.
API not for making efficient code, it for making "safe" code.

Using data values directly not safe, cos blocks maybe reallocated, data format may change and soo on.
This is reason for special method to expose NMS objects and other stuff.

In case of private plugins, that you create for your own server or your friends, you are free to use NMS and ignore API completely, it's possible to load your plugins ignoring API completely.

In case of public plugins you create for community, you must waste your time on wrappers and follow "rules", this will ensure that your plugins wont break someone's server on update and wont stop working if some NMS class changed by mojang.

 

Just store the item with a seperate 'data' attribute. I personally use TacoSerialisation as JSON integrates perfectly into JavaScript and also isn't fussy on spacing. TacoSerialisation takes care of leather armour, books, wool etc. It's great

Useful links:
https://forums.bukkit.org/threads/r...tion-a-different-serialization-system.172099/

and a JSON generator that I wrote for visually getting what you want into JSON
http://voxelhosting.com/items

 

Looks like an interesting way to do it!

However I can't help noticing that org.bukkit.block.Block has getData() deprecated and therefore the solution doesn't quite work for all situations.

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