cItem: Store custom data

[NiLSPACE]

I know it's gonna sound weird coming from me, but would it make sense to make the m_ItemMeta member contain a JSON object? It could be made transparent to Lua (so one could set "m_ItemMeta = LuaTable") and it would be much easier to work with on the C++-side.

I can't think of a reason why not.

One thing though - how will we decide what properties get parsed into their specific member variables, and what properties stay in the ItemMeta object?

You mean what is an NBT-tag and what isn't? I'd say we move all NBT tags over to the ItemMeta object. So things like Lore, CustomName, Enchantments and so on.

[xoft]

Exactly: Enchantments - do we keep them parsed as they are now, or do we just add them to the JSON data? Or both? There are data members that are in between and we will have a hard time deciding what to do with them.

[NiLSPACE]

I suppose there is no nice way to keep both in sync somehow where once I update the m_Enchantments member the m_ItemMeta automagically updates with it.

Or is it perhaps possible using the __index and __newindex metamethod. If the enchantment member doesn't exist in the metadata it looks inside m_Enchantments.

[xoft]

It's not only about the Lua side of things, it would have to be done in C++, and it would be a mess.

[Seadragon91]

Spawn eggs also have NBT, they can have lots of information: Custom name, health, item drop, speed and much more. I would say move everything to JSON, on c++ side, too.

[coding.solo]

JSON Metadata would be exceptionally useful.  Has there been any additional work on this?

[peterbell10]

Doesn't storing NBT as JSON lose type information?  I suppose this would either break world compatibility or require extra handling for each item.

[xoft]

It does. We'd have to add some form of support so that Cuberite or its plugins could indicate the NBT type for specific values, if desired.
I imagine there are two use-cases for custom data:
- implementing stuff that is in Vanilla, such as the spawn eggs etc.
- just using it to store custom value that the plugin can then use
For the first one, we'd need explicit type information, so that vanilla compatibility is achieved. For the second, we don't care, as long as the plugin handles whatever it needs. The question is, do we want both of these use-cases to go through the same storage mechanism, or do we want to separate them?

[peterbell10]

In the end it will all have to stored in NBT anyway so I can't see any way to separate them.  However, storing as JSON and finding a way to attach extra type metadata sounds backward to me.  JSON::Value is just being used as a poor man's variant.

[xoft]

The custom values for plugins' use could be stored as a single json blob, so it could still benefit from the no-type-requirement usecase.