I'm writing an Inventory Editor (C++, Win32 / 64).
The app opens the GZipped level.dat successfully, I parse it using my own parser and succeed to fill the Inventory Editor with the correct items.
But when I save the result file (and then pack it back with the GZip and return to the MCFT Save/World folder), the MineCraft doesn't find it no more as well as the NBTExplorer.
There is no relation to the GZip ZLIB I use - that was tested. So the problem source has to be the generated unpacked level. file which was generated by my app.
I compared the file my app generates with the equal level generated by the MCJE app (same empty slots, same items / Count / Damage in the Slots etc.) and I found some interesting differences.
At some 'Slots' the following 'id' marker is followed by a different byte-long symbol, which value may change every time the file is saved with no relation to the Slot ID, the Item which sits inside etc.
For example:
0x08 : 0x00 : 0x02 : i : d : 0x00 : <?strange byte?> : m : i : n : e : c : ... then goes the minecraft:<item id>
In most of the cases the "strange byte" was equal to 0x15. But when I set it to be the default value, that made the problem I've described (level.dat no longer identified by MCJE / NBTExplorer etc.).
- The "strange byte" values can be 0x14, 0x0F, 0x1A etc. I found no consistent pattern or regularity.
- Once again - found no relation to the Slot ID where the Item sits, or to the Item, or to the Count or Damage or else.
Good day.
I'm writing an Inventory Editor (C++, Win32 / 64).
The app opens the GZipped level.dat successfully, I parse it using my own parser and succeed to fill the Inventory Editor with the correct items.
But when I save the result file (and then pack it back with the GZip and return to the MCFT Save/World folder), the MineCraft doesn't find it no more as well as the NBTExplorer.
There is no relation to the GZip ZLIB I use - that was tested. So the problem source has to be the generated unpacked level. file which was generated by my app.
I compared the file my app generates with the equal level generated by the MCJE app (same empty slots, same items / Count / Damage in the Slots etc.) and I found some interesting differences.
At some 'Slots' the following 'id' marker is followed by a different byte-long symbol, which value may change every time the file is saved with no relation to the Slot ID, the Item which sits inside etc.
For example:
0x08 : 0x00 : 0x02 : i : d : 0x00 : <?strange byte?> : m : i : n : e : c : ... then goes the minecraft:<item id>
In most of the cases the "strange byte" was equal to 0x15. But when I set it to be the default value, that made the problem I've described (level.dat no longer identified by MCJE / NBTExplorer etc.).
- The "strange byte" values can be 0x14, 0x0F, 0x1A etc. I found no consistent pattern or regularity.
- Once again - found no relation to the Slot ID where the Item sits, or to the Item, or to the Count or Damage or else.
- The thing is not documented anywhere.
Is it a trap?..