Closed jason-green-io closed 6 years ago
1.13 of what?
1.13 of Minecraft
Thanks for reporting this.
I'm currently not actively playing Minecraft, so development on NBT is slow. That said, I think this should take priority. If you have an example file and/or pointers to the changes in the chunk format, that would be appreciated.
Here's some details on the changes: https://www.minecraftforum.net/forums/minecraft-java-edition/recent-updates-and-snapshots/2894808-minecraft-1-13-new-chunk-format-fully-decoded-read
I'll upload a r.0.0.mca a bit later.
On May 13, 2018, at 6:09 PM, Freek Dijkstra notifications@github.com wrote:
Thanks for reporting this.
I'm currently not actively playing Minecraft, so development on NBT is slow. That said, I think this should take priority. If you have an example file and/or pointers to the changes in the chunk format, that would be appreciated.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
Thanks @jason-green-io. I just pushed a branch dev-long-array based on on https://minecraft.gamepedia.com/NBT_format.
Basically, it seem the new part is an array with longs (32-bit integers). Since I have not tested this (and I don't know if these 32-bit integers are big endian or little endian, I am not confident yet to push it to master.
I'll give it a go
On May 13, 2018, at 6:40 PM, Freek Dijkstra notifications@github.com wrote:
Thanks @jason-green-io. I just pushed a branch dev-long-array based on on https://minecraft.gamepedia.com/NBT_format.
Basically, it seem the new part is an array with longs (32-bit integers). Since I have not tested this (and I don't know if these 32-bit integers are big endian or little endian, I am not confident yet to push it to master.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
I think you forgot to add the tag to TAGLIST :)
Yup, but it seems that the Long array is actually just a minor thing from last year which wasn't used in practice. The 1.13 NBT change seems unrelated and much deeper.
Yup, I'm still getting errors on parsing regions.
Unfortunately, it is getting late in my time zone, and will be busy with work coming week. I'll try to look later, but all suggestions and code contributions are welcome.
Cool, I'll see if I can get my head around the region format.
On May 13, 2018, at 8:23 PM, Freek Dijkstra notifications@github.com wrote:
Unfortunately, it is getting late in my time zone, and will be busy with work coming week. I'll try to look later, but all suggestions and code contributions are welcome.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
Here some source code for a tool that can read the new region format, it's one of the links on the planet minecraft link I posted in comments earlier.
http://www.mediafire.com/file/ji4smccr99i7lqo/Minecraft_Tools_Source_Code_(12-05-2018).zip
Minecraft Tools/Substrate_Jupisoft/AnvilSection.cs
That is probably what you want
I spotted my error: I defined the type of NBT long
as a Struct long
. That's wrong. a NBT long is 8 bytes, a struct long
is 4 bytes. I needed to pick the struct long long
.
Unfortunately, some more fixes need to be made. It still raises a ValueError. I'll see if I can upload my test scripts too. I'm a bit hesitant to put them in the examples because they are not very common.
Looking at the examples directory mostly makes it clear to me that NBT still need the overhaul I once planned. It took me 28 lines of code to reliably open both compressed and uncompressed .dat (NBT) files.
@jason-green-io it should work now.
Please test it, and if it work for you as well, I'll update the version and push it to the master branch.
Unfortunately, I was bitten again by the poor (unpythonic) API of NBT: a lot of __init__()
methods take a lot of optional parameters, and there is a lot of logic to guess by which value a user is trying to instantiate an object. The last error was in that logic. It would be much better to write multiple factory methods, one for each way to instantiate an object (by bytes, by value, etc. for NBT_Tags, by filename, fileobject, etc. for NBTFile
, etc.). Unfortunately, that would require a backwards incompatible API change, although it would eliminate a lot of unnecessary code and complexity.
That works! Thanks!
On May 14, 2018, at 2:59 PM, Freek Dijkstra notifications@github.com wrote:
@jason-green-io it should work now.
Please test it, and if it work for you as well, I'll update the version and push it to the master branch.
Unfortunately, I was bitten again by the poor (unpythonic) API of NBT: a lot of init() methods take a lot of optional parameters, and there is a lot of logic to guess by which value a user is trying to instantiate an object. The last error was in that logic. It would be much better to write multiple factory methods, one for each way to instantiate an object (by bytes, by value, etc. for NBT_Tags, by filename, fileobject, etc. for NBTFile, etc.). Unfortunately, that would require a backwards incompatible API change, although it would eliminate a lot of unnecessary code and complexity.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
NBT 1.5.0 is released, both on Github as well as on Pypi. The release notes are updated on the wiki as well.
I think either the mca file format or the chunk format changed, any chance we can get nbt working again with 1.13?