Should be done now.

Any reason to do this over just a one time clearing/transforming of the old CVars via the config migrator? Seems like the migrator would serve this purpose better.

It felt like overkill to use a migrator version just for a single wipe like that. Unless I'm missing something and we can version CVar subsections like the audio editor group.

That being said, if we don't care about frequently updating the migrator version (and bloating the code with single-line migrations like that), I don't mind changing the approach.

Versions are free. It's just a number, making it big is fine

Honestly, it's more the migrator function bloat I'm worried about. I wish we had a better way of handling that.

Versions are free. It's just a number, making it big is fine

In that case it may be a good idea to also change the quest stuff in the save files; currently instead of questId, we're still using isMasterQuest and n64ddFlag to represent a save file's quest.

That would be a different migrator, honestly. Probably needs a new SaveManager load function version, unfortunately.

I'm sure there's a way to clean up the bloat. I'd be more worried about having support for old configs living in places other than migrations than bloat (because at least with bloat there's just one bloated thing to clean up)

We could have a minimum supported version for upgrading.
For example if the current save file version is 5, trying to load a save file older than 3 would not work and instead show a message in the file select screen saying that the save file is too old and that they need to use an older version of soh to incrementally update it (like when the latest save file version was 4).
Minecraft does this for example, current versions can't upgrade worlds made prior to 1.6 I believe but you can first upgrade it to an intermediary version and then to the latest.

We could have a minimum supported version for upgrading.

I'd prefer we avoid this. I remember pushing to have the logic be

• We're on version 5, trying to load from version 1
• backup of V1 file is saved
• V2 loader loads V1 from disk into memory
• V3 loader loads V2 from memory into memory
• V4 loader loads V3 from memory into memory
• V5 loader loads V4 from memory
• V5 config is saved to disk

this aligns with how database migration scripts work

I'm also in favor of incremental upgrades but I think that at some point we should remove support for old versions (for example remove the v1-v2 & v2-v3 convertors and give an error on the file select screen if a v1 or a v2 is attempted to be loaded).
The reason I think that'd be a good idea is that those old convertors aren't used very often and if we make new save file versions frequently (or some versions only exist on develop for a few weeks before the next one is made), it could get out of hand.

Alright, it's a migrator now.