Improve NBT editor

[Podshot]

Reworked the NBT editor to use an abstracted representation of a NBT structure instead of actual NBT objects. This allows for much cleaner handling of adding/removing items from container types (TAG_Compound/TAG_List), as well as simplifying the UI code to reduce the need to handle edge cases.

Changes:

• Input NBT objects are parsed to a representation format that keeps track of the parent containing it
• Tree building logic is less complex and cleaner
• NBT editing/adding dialogs are separate from each other
• Removed the need for a callback (current NBT state can be accessed via the .nbt property)

[gentlegiantJGC]

You can just re-define __slots__ as ("_value",) and it will extend the parent

[gentlegiantJGC]

I think this might break with the python version of the nbt library. Please can you test all of this with the python version as well

[gentlegiantJGC]

There are still some issues that need ironing out but it does look good.
I re-added the old example nbt because you had it linked to a file on your PC but the old NBT cannot be displayed.
For some reason it cannot display non-container data that is either the root or in the first level.
This NBT viewer should be able to display any valid nbt or NBTFile

[gentlegiantJGC]

The tree should really have one root node and all of the NBT should be a sub-entry under that node.

[gentlegiantJGC]

Bugs:
These things cannot be displayed

nbt.TAG_Compound({})  # This shows nothing
nbt.TAG_String("hello")  # This causes a crash
nbt.TAG_Compound({"str": nbt.TAG_String("hello")})  # This causes a crash

I cannot edit arrays.
Not really a bug but I intuitively double click on items to edit them. I don't think that should be too difficult to add.
wx assertion error when deleting the "root" compound tag (note this is not actually the root of the NBT)
The add nbt tag window is not big enough by default to see the save/cancel buttons
The icons in the new tag window could be closer to the radio button they are associated with. It currently looks like they are associated to the one to the right not the left.
Creating a tag in a list asks me for a name. Tags in lists do not have names
I am able to create tags of different types in a list. NBT can only have one type in a list
I can create two tags in a compound with the same name

[Podshot]

This is an invalid NBT bytestring, since the TAG_String is not wrapped in a TAG_Compound, which is the reason this string crashes the UI

[gentlegiantJGC]

No that is a valid nbt format.
The first byte (0A) is the start of the compound tag

[gentlegiantJGC]

And a tag string can be standalone in the binary format it just isn't used

[Podshot]

I thought all valid NBT had to be wrapped in a TAG_Compound? The NBTFile object shouldn't be acting as that TAG_Compound

[Podshot]

I'm referencing this page for whether the byte string is valid NBT or not: https://wiki.vg/NBT#Specification

[gentlegiantJGC]

I think you are misreading it a bit. I assume you are referring to this line:
Every NBT file will always implicitly be inside a tag compound, and also begin with a TAG_Compound. The main word being implicitly

Normally a dictionary will own the keys and store the values under those keys. Binary NBT is defined a bit backwards.
Instead of the compound tag owning the keys, the tag itself owns the keys. This is because the root tag also has a name.

The implicit compound tag is there to store the leading name however it is only used in Java level.dat files. Everywhere else it is blank. The NBTFile class is just there to handle the leading name if it isn't blank.

It is a bit complex. I am not sure if I explained it that well

[gentlegiantJGC]

The level.dat file in Java has a double nested compound tag which might be where the confusion is coming from. Try loading up a bedrock level.dat file. I think those only have one compound tag

[gentlegiantJGC]

This is the code you will need to read a bedrock level.dat file

with open(path, "rb") as f:
    f.read(8)
    dat = f.read()
    level_dat = nbt.load(
        dat,
        little_endian=True
    )

[gentlegiantJGC]

Also while doing some debugging I realised our nbt library cannot de-serialise binary root tags that are not compound tags. This isn't really an issue though since I don't think it is ever used but they can be constructed either from SNBT or by directly using the classes so the viewer should be able to display them.

[gentlegiantJGC]

Two solutions to this are allowing the NBTFile to contain all tag types and
a) make the API less specific and have code get the actual nbt object
b) modify the API to pass all calls to the actual object
or just mark the issue as won't fix and leave NBTFile as handling just compound tags

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ gentlegiantJGC
❌ Podshot
_{You have signed the CLA already but the status is still pending? Let us recheck it.}