Tested both x64 and x86 in Windows 11 Sandbox. All good, seems to be packed fine, run fine, download OXPs fine. Good stuff.
Thanks a_c.
So, does that mean we now have functional replacements for all the 1.90 release binaries/zips? Is the replacement process as simple as removing the old ones and uploading the new ones?
Edit: actually, we'd need to recreate the MD5SUM file, wouldn't we?
So, does that mean we now have functional replacements for all the 1.90 release binaries/zips? Is the replacement process as simple as removing the old ones and uploading the new ones?
Note that after updating the new deployment build to Test Release using the Windows updater utility for v1.90, the resulting executable is back to failing at downloading expansions. This is because it gets reverted to the "old" test release exe which still contains the wrong expansion index download location.
These updaters don't function correctly. They install the Test Release version of the executable in the Oolite root install folder and just make a copy of the deployment oolite.exe named oolite.exe.dpl inside the oolite.app folder.
What they should do is: The TR executable should go directly to oolite.app and there should be a backup of the original deployment exe named oolite.exe.dpl in the same folder. No executable should be placed in the root Oolite folder.
Additionally, there is no installation of the Basic-debug OXP at all. This must be included.
The file installers/win32/DeploymentToTestReleaseUpdater.nsi contains instructions on how to set up the files before running the updater generation script:
# When running this updater, the following folder structure must
# exist directly below the updater's folder:
# OoliteRootFolder
# |
# --AddOns
# | |
# | --Basic-debug.oxp
# |--oolite.app
#
# Basic-debug.oxp should contain the Debug OXP files, while
# oolite.app should contain only the Test Release executable.
# The updater will pack everything it finds below the folder
# named OoliteRootFolder, so it is important that the folder
# structure be maintained.
You should then be able to generate the updater by just running: makensis /DOOVERSION=<Maj.Min> /DOOLITEDEPLOYMENTSIZE=<bytes> /DOOBITNESS=[32|64] DeploymentToTestReleaseUpdater.nsi
where OOVERSION is 1.90 in this case, OOLITEDEPLOYMENTSIZE is the size of the deployment executable to be patched in bytes (use file properties to get that from Windows) and bitness is either 32 or 64 depending on which flavor of the updater is being generated.
