Question about oxz's and updating oolite

[FSOneblin]

Hello! I've got another question concerning these fancy new-fangled oxz's and the fancy self-installing oxz feature that the young people love.

If I update to a 1.83 trunk build, would I need to re-install all oxp's I downloaded with the "manage expansion pack" feature?

Sorry if the answer is somewhere already, I am not able to find it. I haven't been able to find much ever since the first "the player is the ship" war.

[Cody]

You should be able to copy them over from your current installation (I've done that before with no problems), but you may have to create the ManagedAddOns folder (or download just one OXZ, which will create it for you). ~:\Oolite-Trunk\oolite.app\GNUstep\Library\ApplicationSupport\Oolite\ManagedAddOns


I am one with my ship!

[FSOneblin]

You should be able to copy them over from your current installation (I've done that before with no problems), but you may have to create the ManagedAddOns folder (or download just one OXZ, which will create it for you). ~:\Oolite-Trunk\oolite.app\GNUstep\Library\ApplicationSupport\Oolite\ManagedAddOns


I am one with my ship!

It worked perfectly! Thanks!

[Fritz]

I'll recycle this thread because it fits better than the Spicy Hermits thread...

I've installed version 1.83 (Windows 64 bit) and copied all the OXPs. I now have two separate Oolite folders, d:\oolite\ and d:\oolite-1.83\. So far, so good.

Version 1.83 seems to run, but I noticed that the log file is written into the log folder of my 1.82 installation. That's not too bad, but I wonder if it should be like this and if there will be similar effects with OXPs, i.e. if I remove one from my 1.83 folder, will version 1.83 use OXPs in the 1.82 folder? Or does it even take all OXPs from the older installation, ignoring the OXPs in the 1.83 folder? Why does it even know the old folder? I didn't find anything useful concerning Oolite in the Windows registry.

The log file contains some errors about missing manifest.plist files in OXPs. I thought they are only necessary for OXZs? The corresponding OXPs still seem to work though.

[Cody]

The two installations should be completely independent - mine are. For reference, I have E:\Oolite and E:\Oolite-Trunk - no mixing occurs.

[Fritz]

Hm... I think I know what it is: I copied the icon, because the setup didn't create one. I changed the exe path, but not the execution folder (which still is D:\Oolite\oolite.app instead of D:\Oolite-1.83\oolite.app).

Edit: Yes, that was the problem. I just crashed into a space jelly because Oolite 1.83 now uses the original keyboard layout. I'll probably have to copy some files, or - better - only the modifications I made.

[another_commander]

@Fritz: You can have multiple installations of the game with all referencing the same set of OXPs if you want. To do this, you only need the oolite.app folder and everything below it. To avoid unintended interference by oxzs, a good practice would be to extract each oxz to the AddOns folder and remove it from the managed expansions folder ("x" key in the Expansion Manager screen for extracting selected oxps, then remove option). This helps also if you are tweaking oxps a lot.

In my tests, I have multiple game versions running. See below screenie for how it's set up:

In this example, oo64, oocameyo, oogit, oolite-1.80, oolite-1.82, OoliteTrunk32.app and OoliteTrunk64.app are all different versions of the game and they all share the same AddOns folder at the top. Inside each of these folders you will find a structure similar to oolite.app of the standard installation. None of these folders contains any managed oxps - only AddOns contains oxps and anything that gets downloaded from the manager is unzipped in AddOns and used from there. When I want to run a version, I just go in its folder and run its corresponding executable.

To extract oolite.app from the trunk installer, you can open the installer using 7-zip or any (de)compression utility that understands LZMA compression. Then you just navigate to the $_OUTDIR\oolite.app folder and select and drag its contents to wherever you want (pic below):


With this, you have a perfectly runnable version of the game without even having to run the installer itself. It's very useful if you are running tests, especially if you want to compare trunk versions against each other or trunk against official 1.82 etc. As for the registry, the installer will only put there information that is required for uninstalling, like the game's original install location. It will not place anything that is needed for running the game there.

Oolite is designed to be portable and, as a result, everything that it needs will be found under oolite.app. It will not look outside that folder for any information, except for the AddOns folder of course. I hope this helps and will let you do your tests more efficiently. If anything is unclear, feel free to ask.

[Cody]

Oolite saves are forwards compatible, but not (guaranteed to be) backwards compatible. Hmm... did I get that right? <chortles>

[another_commander]

Yes sir, you did!

[Fritz]

I hope this helps and will let you do your tests more efficiently. If anything is unclear, feel free to ask.

Yes, thank you, that was very helpful!

I think I'll keep two different sets of OXPs, one for playing and one for testing, so I would need two AddOns folders, d:\Oolite\AddOns and d:\Oolite-1.83\AddOns. But what I don't understand is how the "valid" AddOns folder is found, if there are two of them, like I would like to have, or only one, like in your example. This folder is outside the execution directory ("oolite.app"), so there must be some rules how to find it, and rules that define which one has priority if there is more than one. In your example, there is only \OoliteProject\AddOns. But what would happen if \OoliteProject\Oolite-1.80\AddOns and/or \OoliteProject\Oolite-1.82\AddOns existed as well?

The save folder seems to be managed independently by the preferences file in "\oolite.app\GNUstep\Defaults" (sadly the screenshot function ignores this), but I didn't find anything similar for the AddOns folder.

[another_commander]

But what I don't understand is how the "valid" AddOns folder is found, if there are two of them, like I would like to have, or only one, like in your example. This folder is outside the execution directory ("oolite.app"), so there must be some rules how to find it, and rules that define which one has priority if there is more than one. In your example, there is only \OoliteProject\AddOns. But what would happen if \OoliteProject\Oolite-1.80\AddOns and/or \OoliteProject\Oolite-1.82\AddOns existed as well?

Nothing would happen. The only folder that is looked up for locating OXPs (excluding the managed ones) is the one named "AddOns", found one level up from the location holding the game executable. This is why the AddOns in my screenshot is "seen" by all test versions of the game, it is one level up from all of them.

The save folder seems to be managed independently by the preferences file in "\oolite.app\GNUstep\Defaults" (sadly the screenshot function ignores this), but I didn't find anything similar for the AddOns folder.

That is correct and something I forgot to mention earlier. This is the only other case that the game tries to look outside of its "home" for files, but this of course is upon the request and full control of the user. But yes, the AddOns location is very specific in relation to where the game executable is and does not change.

If you would like to have two sets of OXP folders, you could have an AddOnsPlay and an AddOnsTest folder above oolite.app and activate the one you would like to use each time by renaming it to AddOns. This could be done by either script or maybe some SymLink magic, but I have not tried it yet so can't be more specific.

[Fritz]

One level up and always called "AddOns", that's the rule I was looking for! So it should work how I have located my folders (and it seems to work). Time will show if it's the best way to do it. If I start using 1.83 for playing as well, I'll probably switch to your configuration.