Strings with the literal values "true" and "false" are mistaken with bytes when written and parsed from SNBT.

[Igrium]

If you have a string tag with the value "true" or "false" and you write it to SNBT, it's read as a byte when parsed again. This is problematic when trying to manipulate gamerules using SNBT.
Potential fix is to check if a string matches "true" or "false" when writing to SNBT and surround it with quotes if it does.

[DalekCraft2]

Bumping this, because I also experience this. At the moment, I have to use a custom static method to convert bytes into strings, but it would be safer if the issue was fixed at the source.

[LiamFry]

I'm guessing this project has been abandoned. It's 3-1/2 years since this issue was originally posted and there's been no fix. I, too, have been bitten by the "true" => 1b issue.

querz-nbt is an ever-so-slightly more recent fork of this project but it, too, suffers from the exact same bug.

The NBT => SNBT => NBT workflow is critical for what I'm doing and it remains broken.

[HoldYourWaffle]

I haven't used this library in ages, but that sounds like a wild corruption bug to go unnoticed for so long.

querz-nbt is an ever-so-slightly more recent fork of this project but it, too, suffers from the exact same bug.

As far as I'm aware my fork isn't necessarily "more recent", though there are branches with #91 and #97. You're welcome to submit a fix to my fork, but you might be interested in @ens-gijs's fork that grew out of #68 instead. I haven't used it myself (yet), but as far as I can tell it's been steadily improving upon (and diverging from) this library

[LiamFry]

... that sounds like a wild corruption bug to go unnoticed for so long.

It seems to happen at these location ...

querz/SNBTParser.java, lines 117 and 119

querz-nbt/SNBTParser.java, lines 243 and 246

The incoming NBT has a StringTag with the text "true" or "false" but the library writes it to SNBT as a "bare" true or false. When reversing the process, the SNBT parser sees something like waterlogged:true (with the "bare" true) and assumes that's a boolean so it writes a ByteTag of 1b. As @Igrium suggested - and this is how I'm working around it - I post-process the SNBT text with a global search/replace of :false with :"false" etc. This forces the SNBT parser to treat this as text and it correctly (re)writes the NBT as a StringTag.

I'll definitely look into those other forks; thanks!

As an aside - and I'm conflating issues here - for whatever reason, the compressed file produced by NBTUtil.write() is not GZip compatible! I don't think this is a library issue; the library simply uses the Java-provided GZip facilities (java.util.zip.GZIPOutputStream). I'm assuming this might be a mismatch between my Java version (21) and the gzip tools installed on my system. (The MC server shows no signs of having an issue when decompressing a file produced by NBTUtil.write() so ... I'll fret over this one later.)

[ens-gijs]

@HoldYourWaffle thanks for the ping. I've fixed this issue in my fork.

Devilish little oversight in lenient strings.