Resource 1.12-1.13 Coloured itemstack parser

Discussion in 'Spigot Plugin Development' started by Hex_27, Jul 20, 2018.

  1. Obsolete code, check here instead.

    This code was tested in both 1.13 and 1.12 briefly. It works (as far as I can see). If someone tries it and it spits an error, please reply to this thread immediately.
    Code can be found here ^

    It needs the code found here

    (Old code)
    Code (Text):
    ItemStack redWool = new ItemStack(Material.WOOL, 1, DyeColor.RED.getWoolData());
    (new code)
    Code (Text):
    ItemStack redWool = new XItemStack(XMaterial.WOOL, DyeColor.RED.getWoolData());
    Currently, it supports colours (wool, stained glass etc), log types (logs, planks, doors, fences etc) and anvil types.

    Very frankly, this code can be better, It's pretty unsustainable in the sense that it's messy to add more support for more stuff (Like let's say, all those grasses). But, it's for a fast fix to make sure plugins don't... completely fall apart when you try to run 1.13.

    I know that magic numbers are stupid. I do like the 1.13 material names. This resource is meant to be a fast fix for the 1.13 update, not as something to be used in the long run.

    New ideas are welcome, as always

    Update 20/72018
    - Fixed logic error and cleaned code slightly
    #1 Hex_27, Jul 20, 2018
    Last edited: Jul 21, 2018
    • Like Like x 1
    • Like Like x 1
  2. Tested in 1.13 with a plugin. Seems to work fine for coloured objects (specifically, wool, stained glass)
  3. Choco


    But... why would I do any of this and use a deprecated method (DyeColor#getWoolData()) when I can literally just do
    Code (Java):
    new ItemStack(Material.RED_WOOL);
    Look... I understand that people want to hold on to byte values, but it's one of the stupidest things developers could do at this point in time. With a new API, developers should be supporting nothing but 1.13, or stretch themselves thin and write an additional version for 1.8 - 1.12.2. There is absolutely no reason to use deprecated constructors or deprecated methods as a "temporary fix" for something that already has a proper alternative and makes more sense to not only developers, but players using your configuration. I, as a user, would much rather write "red_wool" than "wool:14" or whatever the value is. 14 means nothing to me... red does.
  4. "I know that magic numbers are stupid. I do like the 1.13 material names. This resource is meant to be a fast fix for the 1.13 update, not as something to be used in the long run."
    This resource is meant to buy time. It's not a good permanent replacement. In the case where someone needs more time to come up with their own version support, this can be used. I agree with you. This shouldn't be used in the long term. I use it now only as something of a transition.
    Additionally getWoolData was just used in replacement of a magic number to show how it works.
  5. Choco


    I replied because I didn't understand that sentence. How much time do you need to buy if it takes less than 3 seconds to change a 14 to a new Material constant?
  6. Buy time to make version support, not buy time to drop all support to only 1.13. The latter is pretty easy. The former may be much harder depending on how dynamic you want the support to be.
  7. For my plugins I'm using it to transition the old item id + damage value pair to the new materials, and then remove the first pair. Hence, I switch over to the new materials (as strings, instead of the integer pair). I would also recommend to others not to rely on this forever and instead use this to facilitate the transition from the one system to the other.
    #8 Staartvin, Jul 20, 2018
    Last edited: Jul 20, 2018
  8. After thinking about what Choco said, and some general observations, I want to recode the resource to fit the context of 1.13 to 1.12 instead of 1.12 to 1.13 (since 1.13 names are better). Anyone that wants to use it as it is is free to.