The literal parser behaves differently from Minecraft in some edge cases - Githubissues

vberlier / nbtlib

A python library to read and edit nbt data.

MIT License

121 stars 16 forks source link

The literal parser behaves differently from Minecraft in some edge cases #7

Closed 17183248569 closed 5 years ago

17183248569 commented 5 years ago

nbtlib.parse_nbt("{a:4000b}") return Compound({'a': Byte(4000)}) but in minecraft command , it will be Compound({'a': String('4000b')})

vberlier commented 5 years ago

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.

17183248569 commented 5 years ago

thank you so much!

vberlier commented 5 years ago

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

17183248569 commented 5 years ago

will it support .mca files？

vberlier commented 5 years ago

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.

vberlier commented 5 years ago

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

17183248569 commented 5 years ago

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

vberlier commented 5 years ago

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

vberlier commented 5 years ago

All of these should now be fixed as of bca40bc7df280d79f162f2ec0c5c41e4f46709c9.

vberlier commented 5 years ago

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

17183248569 commented 5 years ago

https://github.com/vberlier/nbtlib/issues/7#issuecomment-457895173

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

vberlier commented 5 years ago

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.