Installer does not handle archives which upgrade the Unity version properly

[drojf]

Normally, the unity version of the game is not modified by our installer.

However, for some chapters (like Ch.8), we apply an archive which upgrades unity from version 5.6.7f1 to 2017.2.5.

What ends up happening is that the installer will assume 5.6.7f1 for the entirety of the install process, even after the upgrade to 2017.2.5, which can cause certain errors in what is installed.

I think this issue was never noticed until now because we have, over time, worked around this issue in other ways (for example, by applying the 2017.2.5 assets, even if the game is detected as 5.6.7f1).

This is the cause of the pink text issue on the French GOG MacOS/Linux version of the game: https://github.com/orian34/matsuribayashi/issues/9

• The installer recognizes the game as 5.6.7f1, so applies the update archive to upgrade to 2017.2.5
• The installer selects the correct English UI mod, because we've hard coded to install the 2017.2.5 instead of the 5.6.7f1 version in the installData.json file
• The installer finishes installing the English mod (correctly), then progress to installing the French patch
• When choosing a French UI file, the installer cannot find a 5.6.7f1 UI file, so it just uses the default (Windows-2017.2.5) file, which causes the pink text issue.

Confusingly, if you ran the installer again, the installer would then read the install as 2017.2.5, so on the second forced re-install it might work correctl...

---

Conceptually this is easy to fix, but I can imagine there being lots of edge cases, so I haven't decided how I'll fix this yet.

[drojf]

For now, I've fixed the issue in the following ways:

Unity version during the install

I have not actually made it so that the installer is aware of what the current unity version is. The only thing which relies on the unity version during the install is the translation UI file, so I have opted to just fix the logic for the translation UI file specifically, rather than make the whole installer aware of the changing untiy version (this keeps things simple).

But you can actually just re-read the 'current' unity version at any time from the resources.assets file by calling installConfiguration.getUnityVersion(self.dataDirectory, ignoreBackupAssets=True), which effectively does the same thing, rather than reading the cached unity version which was read at the start of the install.

Avoiding issues with half-upgraded systems

While unlikely, it would be possible for an install to partially extract the system archive which upgrades the unity version, resulting in a broken game.

To avoid this, commit 63097ab830e80bb23ed514db31c1f88f51655dba does the following:

• make a backup of the resources.assets file, which we use to detect the unity version, before making any changes to the game.
• prefer to take the unity version from the resources.assets.backup file (if it exists)
• delete the backup file on a successful install (.backup file is deleted before applying translations though)

This should cover all cases where the system archive is not extracted, partially extracted, or fully extracted, as when the install is restart, it will use the backed-up unity version and re-install the system archive, unless the install completely finished successfuly the previous time.

Using the correct Unity version when choosing Translation UI files

To fix this, I freshly get the unity version by calling installConfiguration.getUnityVersion(self.dataDirectory, ignoreBackupAssets=True), and use that unity version for selecting a Translation UI file.

I've fixed this redundantly (I guess to be extra sure it is fixed):

• I re-retrieve the unity version from the resources.assets file, after the resources.assets.backup has been deleted in 112f75bb09bd58f8c5d476ea564a0ba15d676374. This gets the 'upgraded' unity version during the install
• I added an extra option to ignore the backup resources.assets.backup file in 48a81ded3e2bdb49b56e0f6f5cbac49fa1c4913f, to make sure the 'new' unity version is retrieved