The literal parser behaves differently from Minecraft in some edge cases about nbtlib HOT 12 CLOSED

Fixed in 841030a. I'll make a release later with several other fixes.

from nbtlib.

Not really. nbtlib focuses on implementing generic nbt utilities and even though .mca files contain nbt data, they're a file format of their own. This is out of the scope of this project but you can still use nbtlib to parse the nbt sections of .mca files.

from nbtlib.

Interesting. I just tested it and it seems like minecraft falls back to string whenever the value of the number exceeds the range allowed by its type. I'll fix this asap.

from nbtlib.

thank you so much!

from nbtlib.

will it support .mca files？

from nbtlib.

Closing the issue as the fix is now in release 1.3.0.

from nbtlib.

I just found that minecraft falls back to string if it is not an integer but end up with a integer type suffix as well.
here are some examples:
3.3s
4e-3l
4e3l
03b

from nbtlib.

Okay so it seems like there's several things that I'll need to take into account:

• Parsing an integer tag should fall back to string if the constructor raises a ValueError
• Include scientific notation in the grammar for floating point tags
• Adjust the grammar such that integer tags can't start with a 0

from nbtlib.

All of these should now be fixed as of bca40bc.

from nbtlib.

Just released v1.4.5 with the three fixes, closing the issue.

from nbtlib.

#7 (comment)

I just found out that there is a built in OverflowError. Don't need to creat a new one.

from nbtlib.

Not sure, the built-in OverflowError is meant to be raised "when the result of an arithmetic operation is too large to be represented". The documentation says it's "sometimes raised for integers that are outside a required range" but only for historical reasons (i.e.: not a recommended practice). I think using a custom error is more appropriate in this case.

from nbtlib.