Generic Readers and Writers for Non-Root Tags

[Offroaders123]

Potentially could also be related to #47, there does seem to be a requirement that I thought wasn't very common, where one might need to parse standalone tag types, ones that aren't directly nested inside a plain root tag type, or complete NBT file. This brings to reason how NBTify function calls could be helpful to build new parsers from scratch with it's underlying implementation.

I initially decided to not worry about this kind of feature to start with, since it does bring the complexity up a bit. Seeing more and more what people hope to build with it though, NBTify isn't holding up to their needs of wanting to build parsers that do such.

The main use for this is for NBT packet handlers, for making servers and parsers for reading data that goes over the network. Some of the format for those isn't stored with plain NBT like they tend to be in the files, where it is an object or list at the root. The packets could have their own individual need of being parsed, because the format doesn't explicitly package them together very nicely. So exposing a set of APIs for parsing non-root tags (with explicit format options) seems like a nice way to go.

That has been part of my concern too, initially I didn't want to break my auto format detection with unexpectedly accepting non-root tag types at the top of regular files, since those are expected (for the most part) to be a root tag type. Maybe it could make sense to just add a flag to the root tag type check? That actually makes a lot of sense, and it wouldn't make the API too complex either. We'll see. It would work awesome with the auto-detection too, I'd heavily recommend passing in explicit format options though, especially for custom formats like Bedrock uses.

Another portion to this, I've been meaning to implement for myself too, in regards to standalone SNBT tags, this would be for SNBT value editing in Dovetail's tree view. When you click on a key to edit it's value, you would get the SNBT for that single tag in the input, and editing that on it's own will change the value in the tree once you exit the input. That would involve allowing the parsing of non-root tags as well, since those could be any of the tag types specifically.

[Offroaders123]

Funny how the time for this is all messed up, I did this during the time change, it says "opened this issue in 17 minutes", because it was from last hour, but we added an hour, so GitHub is confused. But the 'reference' above says 1 minute ago, so it was placed first in the order.

[Offroaders123]

From Discord:

Ok exploring things a bit

Just using the CLI to demo it easily, it works great for parsing arbitrary tag types.

What do you think makes more sense, for adding a flag to read() specifically for something to the effect of rootCheck: false, or should it be a new function you import called readTag()? It would likely be a better name but yeah.
It would be to the concept of having NBT.readFile() or NBT.readTag().

Do you know if there are any occurences where the standalone non-root tags have compression?
Because this demo handles that, but it might just be overboard.

This is an example of why it could make sense for having a standalone function for it, because doing this accidentally is a big deal for sure ("successfully" reading the contents of a tag, but it happens to work in another format, even though the intended information is different, the bytes just might happen to work properly when parsing the other way around).