Efficient way to save/load inventories AND armor?

I've looked through pretty much every resource and all I've been able to find is:
- Saves/loads the inventory, but not the armor.
- Saves/loads the inventory, but doesn't apply the armor.
- Saves/loads the inventory with armor, but just uses BukkitSerialization so a full inventory takes up about 6-8KiB

The closest resource I've found to what I'm looking for is here:
http://bukkit.org/threads/serialize-inventory-to-single-string-and-vice-versa.92094/

Yet even it does not save/load armor, which is a must.
Along with that, it was written around Bukkit 1.4 which has a different NBT system then current bukkit, so it doesn't work.

The reason why I can't use BukkitSerialization is because we are allowing user created kits, which can become a problem if a players kit needs to be found in a 10MB config file. We are expecting anywhere from 200kits to 2,000 so I need this to be as future proof as possible. Preferably in a InvToString and StringToInv format so that it can be injected into a database.

I do not need code spoonfed to me, but a little guidance about making a working inventory and saving method would be a life saver. Thanks in advance.

 

@Johnzeh

Why would you store information like this in a database? It's not something that makes much sense to have in a database, and especially not as a really long String, that's not what Databases are for.

Also, I don't see the issue with a 10Mb config file, as long as you're not writing to it all the time.

The best way to go about this, I would think, would be to make a separate config file for each kit and store all of those, and in each one you can can store a kit. The kit would be something that implements ConfigurationSerializable, which will allow you to save and load it easily.

 

It would be written to every time a player decides to customize their personal kit. Each player has 3 kits but we intend on having more in the future. So yes, we would be writing to a file quite frequently. The reason why we wanted it stored into a database is because you could convert it to a string, inject it into the database, then retrieve it from the database and return it back to its normal form. This way we could write a kit loading/saving API and use it on our other servers if ever needed. If we are to make a file for every player, we would eventually have a problem where we'd have too many player folders too wouldn't we? This is a competitive PvP server so quality connection with little downtime and hiccups is the priority.

 

@Johnzeh
If you really need it stored in a database, as a string is not the best option.

 

@Johnzeh

If you want this to be accessed by multiple servers then MySQL is probably your best option.

However, this will mean that your plugin will be extremely slow, difficult to program for, difficult to extend, and likely will be less than ideal in numerous other ways.

It would be significantly faster if you had either a large YAML file or numerous smaller ones, and you wouldn't need to access the information on another thread, which is a nightmare in and of itself. Also, I don't see how you can have too many kit files, as they would be small, quick to load, and easy to cache.

If you were to do this in a database format, and this is a big "if," I would design the database such that there are tables for kits, users, and items in a kit. You would select the kit you need from the kits table, and use its ID to select from the items in kit table, each row in the items in kit table describes the material, damage, slot, and enchantment of the item.

As you can see, this is much clunkier than implementing a ConfigurationSerializable and saving it to a YAML file (although, not by much as the serializer will have to do something similar anyway).

 

I'd use this https://bukkit.org/threads/cardboard-serializable-itemstack-with-enchantments.75768/

Works great for me, and if you want to store this in SQL you can always write the bytes into a filestream and dump it in SQL as a BLOB.

 

I personally use Gson for any serializing as it does it all automatically for you. It handles both serialization and deserialization each with just one line of code, and if something doesn't serialize properly you write one typeadapter once and never look at it again.