Adding support for arbritrary NBT tags

[12xx12]

see #4179

Added Compound and types
Added Conversion for cParsedNBT and cFastNBT

[12xx12]

AAAAAAAAAA - this compiles in MVSC :/

[peterbell10]

A list isn't just an array of tags, all the entries need to have the same tag type.

[tigerw]

cNBT::Push enforces this I believe

[12xx12]

Actually yes, BUT you can create a cList object and create a cNBT from this and have a list with various types of entries

[12xx12]

i tried to fix this

[12xx12]

Hm. Clang doesn't like the circular behaviour.

I'd suggest creating a cCompound class that stores dynamically allocated cNBT objects in a map. Directly using a unordered map works too but then the user has to keep track of the memory leaks. I'd rather use the cCompound to take care of this

[tigerw]

What's the issue with circular things? We shouldn't need any sort of inheritance right?

[12xx12]

We have compounds including cNBT objects

And we have cNBT objects containing the variant containing compounds

[tigerw]

It should just work, I think. I.e. with the example in the other PR this compiles:

    NBT Root{
        NBT::Compound{
            { "a", { NBT::List() } },
            { "b", { 5 } }
        }
    };

[tigerw]

Of course it depends on undefined behaviour of std::map accepting incomplete types; so we should probably look to storing a std::unique_ptr in an unordered_map for your solution

[12xx12]

ok - i made the variant contain a pointer to cCompund. Now the default constructor of cNBT creates a cCompund with new and deletes it

[12xx12]

I think i'm gonna hide some things in the private parts (yeah sorry) of the cNBT class

[12xx12]

wrong pr

[12xx12]

Maybe a pointer to cNBT would be better to assure safety even for nested lists

[12xx12]

I'm trying to use a smart pointer but that blows up :/

[tigerw]

There was discussion on your forum thread (https://forum.cuberite.org/thread-3325.html), the main outcome was storing a std::variant containing every thing we need (as objects) into cItem, for better type safety and more ergonomic field accesses. If we do that a cNBT class isn't immediately required anymore.

[12xx12]

But how do we access the values in the vector of variants - do we set constant indexes for certain values? Or do we actually map values from string to values?

[tigerw]

We can say std::get<PropertyClassHere>(Item.Properties)

[12xx12]

Didn't know this works on a vector of variant? What is the behaviour if there are multiple values of the same type?

[tigerw]

Oh I see what you mean, we do a linear search and the first variant that matches counts. A map/set is conceptually more appropriate but I'd say is too high overhead for a couple largely fixed values.

[12xx12]

Yeah this makes more sense - there won't be that many entries in the vector so that linear search wont be that slow

[12xx12]

Closed in favour of #5454