Minecraft - New Nintendo 3DS Edition Extra Data Import/Export Issues

[DeadSkullzJr]

System:
New Nintendo 3DS XL

Firmware:
11.13.0-45U

JKSM Version:
Build (20200508)

Issue:
Hello, I seem to be having an issue dealing with how the extra data is being treated for Minecraft - New Nintendo 3DS Edition when using the latest build of JKSM. The game doesn't utilize any form of save data, it instead utilizes extra data because world data is stored onto the SD card that the 3DS uses. For some reason when I export that data, it's either not displaying all of the data or it's not correctly outputting the data correctly at all. I did some investigating with the data itself and noticed that some of the information was definitely missing (the options.txt literally is blank when it should have actual options to mess with), due to the nature of the world data, I can't pinpoint what is actually missing with that data, however I know the moment I import the data back, I end up met with an error when I attempt to load the world in game. I will provide an image of the error I get, I would like to note that I don't get any other type of error from this either, and from the looks of it, the description of the error isn't exactly helpful, so unfortunately what the image shows may not be too useful sadly.

There might be a chance that importing may not be an issue, it may just seem that way because the exported data is already damaged, importing damaged data can definitely lead to the results seen below too, so it's a possibility that maybe exporting is really the only issue, some tests will have to be done in order to really find out for sure however. I did dump the game and run it on Citra to see how world data is handled there, considering data is decrypted in that environment, I am unsure if the results from Citra should match with the results of exported data via JKSM or any save manager like it for that matter. I did notice that all the data there was working correctly though, options.txt had all the options available in the text document, and the world data seemed to be intact as well (I did a test by moving the world data out of the sdmc folder of Citra and importing them back in, they worked like a charm). I tested an exported world from JKSM on Citra and I was met with a crash (no errors were given obviously).

Image:

[DeadSkullzJr]

Did some testing, I was able to successfully import the extra data (world data) into the game on the 3DS from Citra, worked without an issue. So it's definitely evident exporting the data is the problem.

[DeadSkullzJr]

Back with more information regarding this particular issue. I did much more extensive testing this time around between the respective save managers Checkpoint (3.7.4) and JKSM (20200508). Minecraft - New Nintendo 3DS Edition uses extra data rather than save data like traditional titles usually do (evident based on the title of this issue). I have generated four different worlds, two worlds were generated and played with the base version of the game (v1.0.0) and two with the latest version of the game (v1.9.19). I dumped both sets using Checkpoint and JKSM so you can get a general comparison of what's going on. The problem is JKSM isn't exporting all of the extra data correctly, and it's evident when looking at the data provided by JKSM that it's leaving multiple assets blank instead of populated with the respective data.

List of files with missing data when dumped with JKSM: (Seen in the 1.9.19 extra data contents)

• achievements.txt
• clientId.txt

In terms of missing data inside the world assets when dumped with JKSM:

• sltX.vdb (X represents the number that the world randomly uses when you save it)

Due to this being blank, this is why the game crashes when you attempt to load the world(s).

NOTE:
The world assets change constantly when saving them, the file names do not stay the same after saving, I just saved once per world during the testing phase(s), hence why the problematic blank files all happen to be slt0.vdb.

I am not sure why Checkpoint is able to dump the data correctly and not JKSM. I prefer using JKSM over Checkpoint, and it would be nice if this got fixed. Attachments to the extra data dedicated to this test is provided below. I modified any existing files that contained any identifiable or system unique information, hence why the date modified is different, everything else is untouched.

Checkpoint:
https://mega.nz/file/MQoAySAb#i2dbVzVMr6MlG0jeSc1DBL49BWtNZ1MM9TvEKkZoUAw

JKSM:
https://mega.nz/file/9VhEUAKJ#6NgQzHbWzCZGQFa8ANYh0p0A9EmNEfvAEXpiMBs7FF8