How to get Colored wool? Code help

Discussion in 'Spigot Plugin Development' started by talentoman, Jun 17, 2015.

  1. So i have a code when you type /get wool_blue you get blue wool, but how to use wool id in eclipse code?
    i tryed WoolBlue, Wool_Blue, Blue_Wool , its not working
  2. everytime i get just white wool
  3. There is already a thread going on about wool colors, take a look at that. :)
  4. Set it's data value.
  5. PHP:
    new ItemStack(<material>, <amount>, <data (must be short)>);
    So if you define it as
    new ItemStack(Material.WOOL, 1, (short)14);
    It will return a wool that has a data of 14. A wool with the data of 14 is equal to a red wool. Tweak the data to whatever color you need.
    • Agree Agree x 2
  6. DyeColor.BLUE.getWoolData()
  7. But this method deprecated. Alternatives?
  8. You must be new to Bukkit. The old Bukkit team deprecated things for the hell of it. It was their way of getting information out about something instead of making a PSA about it. Sadly, just as we all warned would happen, new devs don't read deprecation just like they don't read PSAs so the information is never received still. Now the new devs are left with the false belief that the methods should be avoided.

    There are no alternatives. Use the method until one becomes available, if one ever does. Most of these deprecated methods are in the works of getting undeprecated. We have a lot of work ahead of us to clean up the mess that the old Bukkit team left behind.
    • Informative Informative x 2
  9. I beg to differ.
    Code (Java):
    new Wool(DyeColor.BLUE).toItemStack()
    Edit: Yes, some cases are missing - carrots, potatoes, stone variants, but overall, I think you'll find that a LOT of the stuff people recommend using data values for can be manipulated using several variations of MaterialData.
    #9 Jikoo, Oct 15, 2015
    Last edited: Oct 15, 2015
  10. That's not an alternative, but rather a different approach altogether. You missed my entire point. :/

    *takes deep breath*

    Its ok. In time there will be proper alternatives to those deprecations that are legit. The ones not legit will be undeprecated. We just have to get through all the red tape first. Big debate going on right now about the whole thing.
  11. How would you propose to handle it then, aside from a special MaterialData? I think as far as solutions go, it's a good one, though it's certainly too obscure right now, largely because everyone just tells newcomers to just use the deprecated methods. You can get and set ItemStack MaterialData, so it's fully supported for exactly the same style usage as setType and setData.
  12. I would suggest using the deprecated methods until alternatives come along. We might not even get rid of the magic numbers in the end. Its all in the air right now. The decision to remove magic numbers was pre-Microsoft. They were supposed to be gone in 1.7 which is why they were deprecated in 1.6 but they're still here in 1.8.8 and so far are still there in 1.9.

    Your solution works, and doesn't fire any warnings. But it wastes CPU, memory, and makes the GC have more to do than it should. It creates a useless object that gets immediately discarded. Doing this for 1 wool block may be fine, but do this in bulk and it presents a problem.
  13. The Bukkit developers decided to deprecate some methods because their usage of magic values.
    For example the given method DyeColor#getWoolData() returns a byte. If (in some version in the future) Mojang decides to fully drop support for this magic values, this methods won't work any more.
    On the other hand when you use the MaterialData class and it's non-deprecated methods, your plugin is save for future minecraft/bukkit versions. Therefore you should always try to find a way without using the deprecated methods. They should only be used if not possible otherwise (e.g. a user using the ids, or for missing MaterialData classes).

    Mojang already started phasing these magic numbers out: In later versions of Minecraft blocks are internally handled with BlockStates: a birch log block facing up/down as minecraft:log with variant=birch with axis=y rather than id:17 with data:2.
  14. See, the big thing is, these methods were never supposed to be deprecated in the first place. A PSA should have been made to inform devs of the upcoming change that may or may not come.

    The deprecations should have only been introduced once replacements were made. They would have been made when the change was made and Bukkit would have had backwards compatible magic numbers for a version or two while devs transitioned over.

    The way they did it was way wrong. There's nothing to transition to yet...
  15. Fair enough, though I don't think anyone could possibly have a use case that would result in that tiny an object resulting in any serious amount of overhead. You definitely do have a valid point, but I disagree that it is worse, as it is a futureproof solution with minimal extra overhead.

    Perhaps some sort of settable enum data would be more appropriate? Again, more overhead, but it would be slightly more elegant than creating (or re-using) MaterialData.

    That said, if we're picking at inefficiencies, every single ItemStack#getItemMeta call creates a new ItemMeta, potentially containing multiple copied data elements - a new ArrayList if it has lore, etc. etc. The potential for overhead is MUCH higher, especially for any developer who does not read the Craftbukkit implementations of many things.
    For example, some old code of mine prior to reading:
    Code (Java):
        public boolean matches(ItemStack is) {
            return is != null && is.getType() == Material.BOOK && is.hasItemMeta()
                && is.getItemMeta().hasDisplayName() && is.getItemMeta().hasLore()
                && is.getItemMeta().getDisplayName().equals("Keycard");
    This code is TERRIBLE. It creates 3 useless ItemMeta objects, which are much larger than a MaterialData. The API does not make it at all obvious that this is stupid. I'm sure a lot of my older code still contains checks like this.

    I'm getting severely offtopic here, so I'll cut myself short, but my point is this: I agree that it's not as efficient as it could be, but there are implementations of the API which are far worse in the hands of an inexperienced developer. It is, in my opinion, a step in the right direction for keeping the API futureproof, though I do see why you regard it a misstep.
  16. Right. I see this type of thing all the time and I have to explain that they are obtaining copies, not references. No one usually notices until they do something like adding lore and then adding a display name, but only one (or neither) actually stuck.

    I've said it before in other threads, and to the new team, but we need to redo alot of things in the API. My vote gets outweighed, though. See, I'm in favor of breaking changes. The top dogs aren't. I like to call it "ripping the band aid off" and getting it over with. We need to dump out all this confusing stuff and put in new stuff so we can finally move forward with the new fancy things the game is capable of. This API is so stale right now, everyone is scared to touch it because it's pretty much held together with bubblegum and duct tape. But they hold strong to the notion that backwards compatibility trumps all. :(

    Sadly it just leads to improper API usage, overall confusion, and more and more devs being pushed to use NMS.

    I remember years ago a plugin would last forever before it needed an update. It was a rare thing for a plugin to use NMS or OCB methods. Now days its a rare thing to find a plugin that doesn't use NMS/OCB. Because of that pkugins die off prematurely because they can't make the updates in time or the devs have abandoned the project. Used to if a dev abandoned a project it would still work for many many versions. Now they break on the next version change and die off. :/
    #16 BillyGalbreath, Oct 15, 2015
    Last edited: Oct 15, 2015