Emulator

I might be wrong on this, but I believe this would be normal behavior as a real wii will not allow you to import save data from a SD card if the related game has not been played.

JMC mentioned the same thing in #dolphin-dev:

2020-10-01 06:25:09     +JMC47  pokechu22: 12290 is invalid
2020-10-01 06:25:13     +JMC47  that's actually how the Wii works
2020-10-01 06:25:50     pokechu22       This is in Dolphin's UI, not in the Wii Menu.  I vaguely recall that being how it works in the Wii Menu but it's annoying for Dolphin
2020-10-01 06:26:06     +JMC47  yes
2020-10-01 06:26:10     +JMC47  we had to do it in Dolphin's UI
2020-10-01 06:26:16     +JMC47  because if you don't you corrupt the Wii NAND
2020-10-01 06:26:38     +JMC47  leoetlino: ^ you can explain why if you remember
2020-10-01 06:26:40     +JMC47  I don't
2020-10-01 06:44:00     Techjar yeah but doesn't betplay break that rule when copying the save from the temp nand back to the main nand?
2020-10-01 06:50:59     +JMC47  dunno
2020-10-01 06:51:03     +JMC47  probably
2020-10-01 06:51:36     Techjar i mean it doesn't seem to be breaking anything
2020-10-01 06:53:20     +JMC47  It breaks shop access
2020-10-01 06:53:25     +JMC47  and saving in certain games I think?

That said, I'm still not sure if that really means it's impossible to make importing work for Dolphin's UI (which is what I care about; doing it via the system menu shouldn't work if it doesn't work on console). And even if it is, IMO it should give a more explicit message along the lines of "Failed to import save: the game associated with the save has never been played." (Ideally, it would also include the name of the game, but I'm not sure if that's possible; I do think a game name is included in the save file since e.g. the Jodi save file has it changed from Lego Star Wars.) The current way it's failing doesn't make that particularly obvious.

I mean, we bypass it for netplay, but that's because online services and the actual structure of the NAND doesn't matter that much for a single session like that.

I'm 99% sure we did this on purpose to prevent NAND corruption - games like Dragon Quest X do not function properly with any kind of NAND malfunction.

If you remove the check (or try to play Netplay, I guess), does this bug return: https://bugs.dolphin-emu.org/issues/10234 ?

If I recall correctly, the issue is that save files don't contain a TMD that we can put in the NAND, and when TMDs are missing you can get the kinds of issues JMC is describing. I don't believe this has any relation to the Bolt issue, and I'm not sure if there is any issue with netplay. If there is an issue with netplay, that can probably be solved, but I don't think we can do anything about the save file importing issue that doesn't cause problems other than adding a clearer warning message.

The missing TMD files result in things like online services in games failing.

I do not think we should be promoting behavior that actively puts the NAND in an impossible state. Even the homebrew save importers on console won't let you do this.

What actually is responsible for writing the TMD? Does the game itself write it on startup (without actually giving a message about saving data), or does the system menu write it? If the system menu writes it, I assume Dolphin HLEs it when launching Wii games directly, in which case it might be possible to write the save file if the appropriate game is in the games list (but that might be a bit weird to do).

Neither. IOS's ES module is responsible for doing it. For disc games, this happens during the DIVerify call when a game is launched for the first time, and the title directory (where the save files are stored) is created at the same time with the correct metadata set using the TMD.

Unfortunately for us, some titles do care about the UID/GID of the title directory (games that access other games' saves, Dragon Quest X and possibly more titles we haven't heard of) and the System Menu will corrupt data if a TMD is missing.

We might be able to get away with creating the directories with dummy ownership info at save import time and reparenting when the game is actually launched, but the System Menu would probably still be broken.

leoetlino wrote:

Neither. IOS's ES module is responsible for doing it. For disc games, this happens during the DIVerify call when a game is launched for the first time, and the title directory (where the save files are stored) is created at the same time with the correct metadata set using the TMD.

Unfortunately for us, some titles do care about the UID/GID of the title directory (games that access other games' saves, Dragon Quest X and possibly more titles we haven't heard of) and the System Menu will corrupt data if a TMD is missing.

We might be able to get away with creating the directories with dummy ownership info at save import time and reparenting when the game is actually launched, but the System Menu would probably still be broken.

Does UID/GID not get created by IOS as well?

Just curious, I didn't realize pokechu had made this issue when I made https://bugs.dolphin-emu.org/issues/12372

To clarify, I was hoping we could just have a soft-launch (execute the code to create the necessary details without actually telling the rest of the Dolphin logic to launch the game?) Not sure if that's possible.

The UID is assigned by IOS but the GID comes straight from the TMD.