[OTR Archive] Store soh version in OTR files and verify on launch/ask to regenerate

[Archez]

This PR adds a new file in otr files to track the soh version that was used to generate them. This is valid for the oot.otr, oot-mq.otr and the soh.otr files. This is achieved by modifying the extraction process to pass the soh version as an argument through ZAPD into the OTRExporter. The OTRExporter will saved the soh version into the otr as a portVersion file. The version is stored as its individual parts (major/minor/patch) as 3 numbers, so reading the version will require reading the 3 numbers separately.

The mac and linux scripts were changed to be cmake inject-able files (.in) so that the soh version can be supplied by cmake directly and the final file will be generated to be used with in the bundling process. The cmake extract/generate steps will also pass the version through.

In the soh launch process we then are checking the soh.otr that it exists, and that it matches the running soh version exactly. If it doesn't an error message is displayed and the process killed. Then we check both the vanilla and mq otrs to see if their major version matches the running soh's major version. If it doesn't a prompt is presented asking the player to regenerate their otr file (re-run the built-in extraction process). For Wii U/Switch, instead an error is displayed and the process is killed/interrupted.

The variable type for the version numbers also needed to be changed to an explicit uint16_t so that they work properly on 32 bit devices.

Depends on Kenix3/libultraship#346 - Merged
Depends on HarbourMasters/OTRExporter#10 - Merged

Build Artifacts

• soh.otr.zip
• soh-linux-compatibility.zip
• soh-linux-performance.zip
• soh-mac.zip
• soh-switch.zip
• soh-wiiu.zip
• soh-windows.zip

[Archez]

Need to test the error handling for old/missing soh.otr and old game otr on Switch and Wii U.

[jbodner09]

Any value in also including the build name string like build.c does?

[Archez]

Any value in also including the build name string like build.c does?

Not that I can think of. The version numbers give us everything we really need from a verification standpoint. The only usefulness would be to "show" the full build string to the user in the error message, but that is not really the critical part. All the user really needs to know is that their otr is old and it needs to be regenerated.

[briaguya-ai]

couple little comments but nothing blocking

[garrettjoecox]

@Archez any reason not to merge yet?

[Archez]

@Archez any reason not to merge yet?

Needs a LUS bump first

[garrettjoecox]

Needs a LUS bump first

Want to submit it?

[Archez]

Sure. Also testing on wii u/switch would be nice. The expected behavior is an error message and the application closing/locking up I believe.

[briaguya-ai]

switch testing

just soh.nro

sulu bravo soh.otr, no oot.otr

soh.otr from this PR, no oot.otr

soh.otr from this PR, sulu bravo oot.otr

soh.otr from this PR, oot.otr from this pr

[Archez]

Wii U

Case	Image
No soh.otr
Old soh.otr
No game otr
Old game otr

[Archez]

Turns out the version ints like gBuildVersionMajor were 0 on 32 bit devices and so save files on wiiu were always 0.0.0
I've addressed this by changing the type to an explicit uint16_t so the value is accurate on 64 and 32 bit devices.