libnbtplusplus
libnbtplusplus copied to clipboard
ljfa-ag
Little endian negative long encoding doesn't match Minecraft
I've found that Minecraft Bedrock Edition encodes negative little endian longs different than expected:
For example, creating a level with seed -123456789 will encode it in level.dat as EB 32 A4 F8 00 00 00 00, which is read by this library as 4171510507.
The same can be seen with the worldStartCount value in level.dat, on a newly generated world it's encoded as FE FF FF FF 00 00 00 00, apparently meaning -2.
With positive values, such as any positive seed, or the timestamp in LastPlayed it seems to work correctly, presumably because they values themselves aren't bigger than 32-bit.
tl;dr:
| name | value in level.dat | read by minecraft | read by libnbtplusplus | correct? |
|---|---|---|---|---|
RandomSeed |
EB32A4F800000000 |
-123456789 |
4171510507 |
👎 |
RandomSeed |
15CD5B0700000000 |
123456789 |
123456789 |
👍 |
worldStartCount |
FEFFFFFF00000000 |
-2? |
4294967294 |
👎 |
LastPlayed |
CF94015B00000000 |
2018-05-20 |
1526830287 |
👍 |
This is based on level.dat files from different versions of Minecraft 1.2 to 1.4 for iOS and Windows 10. It seems Minecraft is treating the 64-bit long as 32-bit, and ignoring the rest, it seems related to this minecraft bug: https://bugs.mojang.com/browse/MCPE-7091?jql=text%20~%20%22TAG_Long%22, which was ultimately resolved by limiting the seed to 32 bits.
More puzzlingly, this only happens in level.dat: the NBTs with players seem to encode it correctly; at least instances of -1 are encoded as FFFFFFFFFFFFFFFF.
Well that seems more like a problem on Minecraft Bedrock Edition's side. I'm not sure if I should accommodate to that.
I guess you can just cast to int32_t to get the right value.
