Metadata Q&A - I wrote the Metadata API, AMA

Discussion in 'Plugin Development' started by deltahat, Apr 2, 2012.

Thread Status:
Not open for further replies.
  1. Offline


    Plugin developers,
    I've seen some questions arise so far about the new Bukkit Metadata framework released in the latest RB. As the author of Metadata, I'd like to take this opportunity to field any questions you may have about the framework.

    I am in the process of assembling an introductory help document for the Bukkit wiki showing how to use Metadata and your questions here will provide the foundation of what needs to be covered.

    Crast has set up a spreadsheet to coordinate shared metadata keys. Add your suggestions here.

    Even more details:
  2. Offline

    Don Redhorse

    nice... now all region plugins need to use it for canBuild ....
  3. Offline


    Or better yet - all permission plugins use it to expose "chatPrefix", finally ending all the existing chat prefix madness.

    Crast has a great analysis of Metadata here.

    This is what Metadata is for!

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: Nov 25, 2016
  4. Offline


    Thanks deltahat for the plug.

    On a side note, I really like what you're talking about using metadata for inter-plugin data exchange. To that extent, I propose we try to come to concensus on some of these common keys.

    To do that, I've created a google spreadsheet we can do some community editing on here:

    The idea is that if for example, we were to want to deal with the ever-present chat prefix issue that deltahat pointed out, for cooperation between permissions plugins (usually) setting it and chat plugins getting it, we'd want to standardize. It would be basically back to square one if e.g. you had one plugin setting "chatPrefix", another setting "chat-prefix" and yet another doing say, "essentials.chatprefix" due to the extra work which would be required in checking all those potential values.

    If we developed a quasi-contract on these values, at least there'd be some standardization on how they're accessed.
  5. Offline


    1) I misunderstand a feature with list of datas get from .getMetadata() method. When it's length will be higher than 1?
    2) Does .getMetadata().get(0) return different values if called from different plugins?
    3) Is it possible to use null as plugin key to set metadata?
  6. Offline


    1. getMetadata() will return a list longer than 1 when more than one plugin registers metadata with the same key.
    2. No
    3. No
  7. Offline


    And how can I know which plugin under which number is? Only loop with .getOwningPlugin()?
  8. Offline


    Yes, I believe so.

    But (IMO) it'd be better to just take the policy of taking the first value (using .value() or e.g. .asString(), .asDouble()) which matches the data type you want, rather than hardcoding it to the name of whatever plugin set the value, as this will promote better interoperability.

    In other words, you shouldn't have to care who set the value at a given key, just that the value is there and it's a useful one.
  9. Offline


    1) Is Metadata persistent? If I attach some data to a block will it stay after server restarts/crashes?

    2) If a block gets moved around, will the metadata stay with the block or will the data disappear?

    3) If a diamond block is broken down to 9 diamonds, does the metadata disappear?
  10. 1) I'd guess no.
    2) What do you mean by 'moved around' ?
    3) Since the metadata only applies for the diamond block it probably doesn't apply to the individual diamonds.
  11. Offline


    I would guess for example, a Piston pushing a block, will that block still hold the metadata
  12. Well, I guess I have no idea in that case.
  13. Offline


    No. Metadata is not attached to the identity of a Block. It is attached to the location of a Block.
  14. Offline


    Very very nice.
  15. So if a player breaks the block or if some plugin change the material type the metadata won't change/be removed, right?

    Plugins can use this for persistent storage of internal data, too (like setting "RideThaDragon.isRiding" to true when a player logs off while riding, then re-spawning the dragon, set the player a passenger of it and remove that metadata when a player logs on again)?
  16. Liking this system for its open alebilities
  17. Offline


    deltahat any plans to or thoughts on extending the metadata API to items? Seems like it would be a natural fit to store the data in the item NBT tags, which would open up a ton of possibilities for what plugins could do with items.

    There has been a longstanding desire for an API for item data , maybe your metadata API could be this API? (or at least tie into it)
  18. Offline


    This needs to be a sticky!
    ferrybig likes this.
  19. Offline


    Seems like an excellent idea. I've added metadata support to jChat (chat prefixes and suffixes) in the latest development build.
  20. Offline


    Awesome! What are your metadata keys for prefix and suffix? If they are public others can use them and they become more powerful.
  21. Offline


    I used the ones recommended in the spreadsheet, chatPrefix and chatSuffix. I updated it as well to say that jChat implements it.
    mushroomhostage likes this.
  22. Offline


    Hey, is it possible to set metadata´s also for chunks?
  23. Offline


    Not directly, but you can add metadata to a block at a known position within the chunk just the same.
  24. Offline


    yea i thought about that. =)
  25. Offline


    deltahat Can you expand on 'Marking areas of the world as “owned” by a player'?

    Would this be done on a block by block basis, or perhaps some kind of cuboid selection system?

    I guess I'm just thinking if a player owns a cuboid, marking each block is a bit overkill, unless there is some kind of area/selection system involved.
  26. Offline


    Currently there is no system for making a bulk metadata provider. It would be nice to add one. I imagine it would work as follows:

    1. Register a bulk metadata provider with the metadata framework for a given Metadatable type
    2. When a plugin asks for the metadata for an instance of a Metadatable, any registered bulk metadata providers are queried to see if they will vouch for the selected instance
    3. If the bulk metadata provider wishes to add metadata for the selected instance, it returns a metadata object which will then be attached to the instance for further reference

    Bulk metadata providers could use any mechanism for determining if a given instance has a metadata attribute.
  27. Offline

    Sagacious_Zed Bukkit Docs

    It has been brought to my attention that despite the documentation here saying offline players are metadatable
    and your demo having this following line of code
    getServer().getOfflinePlayer("deltahat").setMetadata("fromOffline", new FixedMetadataValue(this, true));
    It infact does not as of 1.2.5-R5.0 ;)
  28. Offline


    There doesn't seem to be a way to remove all of a plugin's metadata without knowing the key names? Or am I missing something?

    I'm writing a plugin that assigns a bunch of metadata to a player but the keys are not necessarily known the plugin (they come from an outside source). But the plugin needs to offer a way to "reset" the player, which means I need to remove all the metadata the plugin added before, but I don't know the keys. I can't seem to find a way to access my plugin's metadata without the need for a specific key.
  29. Offline


    If your keys are not deterministic, the only way I can think of within the formal Bukkit API is to also store a key with a known name whose value is a List<String> of all other keys you stored.

    Remember, Metadata does not persist across server restarts, so it's mostly useful for scenarios where you're going to get a known key.
  30. Offline


    I'm writing a permissions system for a custom multi-server environment. The permissions are stored in a DB and pulled by plugin through a web service. In addition to permissions, the system supports setting metadata. So the plugin doesn't "know" the metadata keys. Sure it knows the keys because it has to set them, but it doesn't remember them so they can be removed when a player logs out. I could build a list of keys and store that in a known key, but that's a kludge.

    What I'd really like is a way to remove all metadata belonging to a plugin. There are a number of other interfaces in Bukkit that have a similar design, like event listeners. I'm wondering why it doesn't exist for metadata.
Thread Status:
Not open for further replies.

Share This Page