[Resource] TacoSerialization - A Different Serialization System

Discussion in 'Resources' started by KILL3RTACO, Sep 1, 2013.

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


    TacoSerialization is a serialization I made (and integrated into TacoAPI). It has some similarities and differences to how Bukkit serializes things (call .toString() on something like an ItemStack to see what I mean). But there are some differences as well.

    A plugin of mine, ItemMail, uses this serialization system to perfectly save ItemStacks so they can be sent to players without any worry of data being lost.

    Current version: 1.1

    Links? Sure :D
    Changelog? Okie dokie!
    • Initial release
    • + Added SkullSerialization
    • Like Bukkit, TacoSerialization uses JSON for its data format.
    • Many of the keys are similar
    I can't possibly list all of the differences, but here are a few:

    ItemStack serializing is a bit different. Bukkit uses the format {NAME x AMOUNT} for simple items. Also, the name is equivalent of calling .name() on the Material of the ItemStack. This means that you cannot tell the data type of the ItemStack just from that string (i.e. the color of wool). Here's an example:
    1. ItemStack items = new ItemStack(35, 1, (short) 14); //Red wool
    2. System.out.println(items.toString());
    4. //Output: {WOOL x 1}

    TacoSerialization does this differently. It gets the Material's id (slightly reducing overhead) as well as the data/damage value and amount. If you were to use the same ItemStack and serialize it with
    1. SingleItemSerialization.serializeItemAsString(items);

    You would get
    As the result. The above format is useful for SQL servers to store that data. If you want a more human readable version you can use
    1. SingleItemSerialization.serializeItemAsString(items, true);

    This method adds indents, making it easier to read.

    When you call .toString() on a Player you get this:
    Well that's not useful at all... What GameMode are they in? What's in their inventory? Are any PotionEffects applied to them? TacoSerialization fixes this. The JSONObject has numerous keys to help with this.[/spoiler]

    Other Serialization

    If you've used ChestShop before, you might know about the enchantment codes. I found the method used to generate it is a little unuseful. First of all, what if the enchantment was unsafe, and the enchantment's level was a three-digit number like 100? ChestShop would incorrectly convert the enchantments into a string simply because the enchantment's level was too high. Let me provide another scenario: what if an enchantment was added to the game whose id number had three digits? Again, the enchantments would be incorrectly converted. I wrote an extremely simple and easier to use way to convert enchantment into a string. There is also support for converting ChestShop's version of enchantment codes to the way TacoSerialization converts them.

    So what is this magical way I convert enchantments? Simply put:
    Converting PotionEffects to a string is similar to how it's done for enchantments:
    When certain areas of TacoSerialization are accessed for the first time, a config is generated. This config file is found in <plugins-dir>/TacoSerialization/. Certain keys of the serialization process can be ignored if the server owner so chooses.

    Why did I add this feature you ask?
    Let's say Steve plays on cloud server. He is on the main server and wants to go to one of the speciality servers. He types the appropriate command, and gets teleported there. In the backend, the plugin uses TacoSerialization to save Steve's data, moves him to another server (where his data is different) and then applies the previously saved data. Now Steve's inventory, health, gamemode, etc. are the same as they were before. A few things have also happened that he will not realize till later. For one thing, his ender chest is the same as the other server. Admins/the server owner may not want this. Which is why I added that config file.

    The downside to this would be that the server owner would have to change both files.

    Want to use this in Your Plugin?
    The source can be found at KILL3RTACO/TacoSerialization on GitHub (There's a handy download button on the right now :D). It is reccomended that both packages be renamed so as not to conflict with other plugins.

    Feel free to ask questions or suggest additions for this thread.


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


  3. Offline


    Well that's not good :p It's fixed now
  4. Offline


    I'm surprised this isn't very popular - amazing library. Will be using in current project.
  5. Offline


    I don't see an advantage against Bukkits ConfigurationSerializable....? toString() is not serializing and bukkit does not serialized to JSON, but YAML. It sound like you did not know this, KILL3RTACO.
    I don't want to sound rude, but that's my guess.
    This is simply not true, you are referring to toString(), the yaml serialization will perfect store all item information, including sub ids (wool color), enchantments and such
  6. Offline


    JSON is much more user friendly to write than writing the object to yml directly.
  7. Offline


    how is that more user friendly? Everything in Bukkit is based on YAML, why should switching to JSON be more friendly?
    YAML is especially designed to be human friendly: "YAML is a human friendly data serialization
    standard for all programming languages." - YAML.org

    PS: I probably sound like a jerk that is trying to argue against the library, I am not. I just want to point out that this library might be based on a wrong assumption/missing information
  8. Offline


    Maybe not for this lib or serializing smaller things but when you start serializing much more complex objects json becomes easier. Why do you think the new launcher uses json instead of yaml or straight text to serialize the information?

    Anyways both yaml and json have their uses. Both work great. Its dependent on the use and the user.
  9. Offline


    Have you seen an ItemStack serialised? It is easy for when you want to read/write things back and forth via the plugin only but when it comes to getting the user to write a config file that represents an item, the serialisation provided for Bukkit makes no sense. As Not2EXceL said, it has it's uses. If you want to just save and load ItemStacks, use Bukkit's default serialisation. If you want to store entities and ItemStacks in a readable way then use this.

    (Also, I wrote something to generate the JSON needed for itemstacks. It's quite cool! http://voxelhosting.com/items It has support for leather armor, books and their contents, and human skulls.)

    Merry christmas :)

    Did a test. Serialised item looks like this. You can't expect a user to add that extra part in.
    1. item:
    2. ==: org.bukkit.inventory.ItemStack
    3. type: POTATO
  10. Offline


    Please don't use toString() for serialization.
    Also JSON is a data interchange format; this is a great library don't get me wrong, but perhaps using JSON is not the best idea - I would personally use protocol buffer. JSON is not designed to save data, but to move data from one place to another (think web queries etc). By using JSON you are increasing the size of the serialized data quite a bit.

    Unless you have a valid reason for using human readable, serialized data, protocol buffers would probably be better. Not to mention, if you include the schema for your protocol buffer classes, other people (a la me) can use your schema then to utilize this saved data in other programs.
Thread Status:
Not open for further replies.

Share This Page