Strict Flag: NBTData Option + Auto-Parsing

[Offroaders123]

Since some NBT file data terminates before the end of the full file itself, this has brought up the use for adding the strict flag to the reading process. I'm curious if this should also be symmetrical, in that the re-written file currently won't be the same as the input file. Should NBTify provide a symmetrical API which will give you a file with the same file length as the write output? This would require storing the strict flag somewhere in the NBTData process, and possibly the minimum file length. Should it instead be a fixed file length? I'm not sure why the nature of some files are longer than the data they actually hold, which is what would lead me to implement this in a certain way.

So if you were to open a file with the flag NBT.read(data,{ strict: false }), should this be reflected as part of the metadata for the resulting NBTData object?

While writing this, I just thought of another thing. I think this goes in hand with this feature idea (only if I do implement this symmetrical handling). If the strict-ness of the file length can be represented in the NBTData object, I think it would also be safe to start automatically reading files without strict enabled, only after parsing all of the other file types first, like it does now. So this would run after the newly-added deflate-raw handling, and it would simply pass all format options as undefined, only with strict set to false. I think that might sound a bit risky though, so I'm not sure about that one. I think a lot could go wrong there, having written that idea out. I think it might pick up on some weird data first, say if it was a non-strict file, and it was also compressed or something. The blocks might have NBT-looking data somewhere in there, and it might exit early with malformed, unexpected data.

So, having discussed that, I think auto-parsing for strict may not be viable because you can't ensure that what's coming out is indeed what it should be, unless there's another way to do this that I'm not thinking of. Oooh! This sounds horribly messy, and not worth it, but maybe if it opens the file successfully with a lot of bytes left, it will keep trying, and check against the (multiple?) read results to see which one has read the most of the file. I think that's fairly unlikely to happen, unless the data is magically synonymous with the different format options somehow, but maybe that can help ensure that it's the correct one? I feel like that could technically be incorrect in some circumstances too, though. Especially if the trailing data at the end of the file has random byte data there, it could incorrectly terminate the NBT in a different format, later in the file than where the real, shorter data is stored.

So, I will look into having a symmetrical API, see if that's viable (less likely), and secondly, go through with just letting the user know whether the resulting data was loaded non-strict-ly, through the NBTData object result. Thinking about it too, I think this could be necessary for the TypeScript-level of things too, as having two files that have the same structure, but one is loaded strict-ly, and the other non-strict-ly, they would appear the same on the type level, while they weren't actually loaded with the same format options. Saying it like that, it might not be an issue though, since they are same at the nominal-type-level anyways. I think this distinction should also probably happen at the reading level anyways, since that's where the types would differ when you pass them into the function. But then again, this would break up being able to use NBTData objects as FormatOptions objects directly, so I think this is probably necessary either way. Not having this currently limits you from being able to use them interchangeably like that.

Ok, nice rant. Also, I don't quite like the new GitHub UI layout yet. Why change it?? This time, I'm going to help myself learn to like it, because GitHub is just too darn useful to be annoyed by it. Why they gotta change it though, eeeeh. Hey, at least they're trying something? Wouldn't want the other option, GitHub to go under, and fall behind and not get 'any' updates. Ok, rant over hehe.

[Offroaders123]

Referenced above in my Bedrock-LevelDB project, I need to provide a more-public way of determining where a strict: false read process left off when it completed reading successfully.

[Offroaders123]

Removed NBTError in favor of finding a better solution, this is a breaking change for Bedrock-LevelDB as of now for this latest version.