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.
0
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?..