OoliteStarter

[arquebus]

Here is the log for my latest test:

https://www.dropbox.com/scl/fi/i1v7pv4t ... to7w6&dl=0

I did discover something interesting. One of the OXPs I updated was In-System Taxi. I watched the ManagedAddOns directory while updating and there was only ever one file with that name. It appears that at least for that OXP, the update was successful and correct. However! Inside OoliteStarter, on the right panel, both versions remained after the update. And if I removed the older one, it removed both (and the file in the directory as well). So at least with that OXP it's a UI glitch only.

[arquebus]

And here's another test, log and video, dealing with two specific OXPs (Laser Booster & Nuit Space Station).

https://www.dropbox.com/scl/fi/qrdx49vz ... dpmqt&dl=0

https://www.youtube.com/watch?v=vYRqwmhGGLY

As you will see in the video, in these two cases, the UI in the right side panel does not correctly update to only show the updated version. However, if I quit OoliteStarter and reload, only the updated version appears - in other words, the problem resolves on a restart of the program.

[hiran]

And here's another test, log and video, dealing with two specific OXPs (Laser Booster & Nuit Space Station).

https://www.dropbox.com/scl/fi/qrdx49vz ... dpmqt&dl=0

https://www.youtube.com/watch?v=vYRqwmhGGLY

As you will see in the video, in these two cases, the UI in the right side panel does not correctly update to only show the updated version. However, if I quit OoliteStarter and reload, only the updated version appears - in other words, the problem resolves on a restart of the program.

That is a good one. Indeed I can reproduce it. Likely, after running updates I never really checked the UI but launched Oolite instead.

Ok, I even found something and made a quick fix. Please try v0.1.34-juxtapose.1

[phkb]

We had a comment on Discord from a Mac user "BoabyBoy":

I installed the latest OoliteStarter version 0.1.34 but it was not able to find the oolite.app even I try to manually find the file or allow it to scan the file automatically. I even had finder set to show file extensions but still would not pick it up. I am on the latest MacOS Tahoe 26.2. Any ideas on how to get OoliteStarter to find the oolite.app file?

Link to comment: /https://discord.com/channels/130688495126708224/130786669027655680/1460017577127317621

[hiran]

We had a comment on Discord from a Mac user "BoabyBoy":

I installed the latest OoliteStarter version 0.1.34 but it was not able to find the oolite.app even I try to manually find the file or allow it to scan the file automatically. I even had finder set to show file extensions but still would not pick it up. I am on the latest MacOS Tahoe 26.2. Any ideas on how to get OoliteStarter to find the oolite.app file?

Link to comment: /https://discord.com/channels/130688495126708224/130786669027655680/1460017577127317621

If OoliteStarter shall juggle addons, manage savegames and launch Oolite it needs to know where all this is stored on disk. Rather than inventing new directories it can be configured to use the existing ones. Users who know what they are doing can configure each and every path manually. Those who don't, or who are too comfortable can have OoliteStarter search/guess the paths.

That is the time when OoliteStarter will search for hints of Oolite installations. So far it looked safe to scan for a folder called 'oolite.app'. I'm not a Mac guy and thus cannot verify - but if that search algorithm does not help some better procedure should be defined and implemented. In any case: If the paths cannot be computed automatically the user can control it manually, so it should not be a showstopper.

What could be a reason that 'oolite.app' cannot be found through terminal or Finder?

[mcarans]

If OoliteStarter shall juggle addons, manage savegames and launch Oolite it needs to know where all this is stored on disk. Rather than inventing new directories it can be configured to use the existing ones. Users who know what they are doing can configure each and every path manually. Those who don't, or who are too comfortable can have OoliteStarter search/guess the paths.

The modern builds of Oolite allow configuring many things by environment variable and there are some new path layouts to consider eg. for Flatpak and the MSIX. It may be able to take advantage of environment variables by setting them to OoliteStarter-defined locations instead of copying or moving folders in some cases.

I think that if OoliteStarter were updated to handle these configurations and bring them into its UI, it would be great for users.

[hiran]

The modern builds of Oolite allow configuring many things by environment variable and there are some new path layouts to consider eg. for Flatpak and the MSIX. It may be able to take advantage of environment variables by setting them to OoliteStarter-defined locations instead of copying or moving folders in some cases.

I think that if OoliteStarter were updated to handle these configurations and bring them into its UI, it would be great for users.

Sounds good to me, although it needs to be handled with care.

The modern builds are good however it does not change the officially released versions. Changing OoliteStarter should support new features but not drop the existing builds. At least that's how I would implement it.

The change is not that big either. OoliteStarter can be changed to tell Oolite which directories it uses for savegames and oxps. New versions of Oolite will respect that and old versions will not break.

Then it is just a question which directories OoliteStarter should use. Today the user is in full control on the Oolite versions tab. Each directory can be configured separately.
To make this task easier for the user OoliteStarter can scan the disk and come up with suggestions. This scan should be improved to also detect modern builds. Appimage, flatpak, whatever.

With these two changes I think OoliteStarter would support both classic and modern builds.

[hiran]

I will not implement the above change. But whoever wants to pick it up here are the locations that need to be touched:

Running Oolite (need to add env vars):
https://github.com/OoliteProject/Oolite ... .java#L766

Scanning for Oolite installations (need ability to detect modern Oolites):
https://github.com/OoliteProject/Oolite ... .java#L240

[mcarans]

The modern builds are good however it does not change the officially released versions. Changing OoliteStarter should support new features but not drop the existing builds.

This would be for when the modern build is officially released, hopefully in the not too distant future if I can get the documentation up to date. I've integrated your DOxygen documentation within readthedocs and there's also the oolite.space site to update once a release is made.

[hiran]

Completely different idea:

OoliteStarter is a wrapper for Oolite to ease savegame and expansion management.
Would it be feasible to integrate it into the msi or appimage or flatpak? Then the whole scanning process can be skipped.

[another_commander]

Completely different idea:

OoliteStarter is a wrapper for Oolite to ease savegame and expansion management.
Would it be feasible to integrate it into the msi or appimage or flatpak? Then the whole scanning process can be skipped.

Cannot integrate it into MSIX. We would need to include the entire Java runtime and any other dependencies in the package and that is not practical nor feasible as far as I can see.

But the real blocker is the MS Store rule for MSIX submissions: Only one application is allowed in a package and this has to be oolite.exe in our case.

[hiran]

Completely different idea:

OoliteStarter is a wrapper for Oolite to ease savegame and expansion management.
Would it be feasible to integrate it into the msi or appimage or flatpak? Then the whole scanning process can be skipped.

Cannot integrate it into MSIX. We would need to include the entire Java runtime and any other dependencies in the package and that is not practical nor feasible as far as I can see.

But the real blocker is the MS Store rule for MSIX submissions: Only one application is allowed in a package and this has to be oolite.exe in our case.

1st argument: We'd have to add a lot of stuff

So what? Download Oolite, OoliteStarter and a bunch of addons - whether it is one file or many does not matter any more. But it can change the user experience.
If not convinced, both bundles could be offered in parallel to see which gets downloaded more often.

2nd argument: Microsoft allows only one executable

If MSIX (or whatever that package format is called) allowed only one executable I'd be wondering much. For sure it allows only one entry point. But if that were OoliteStarter, it would run Oolite when needed.

Actially a similar concept as Flightgear uses: There is the simulator, and you might die trying to understand the command line to run it. But then there is another application allowing to configure graphically the plane, location, scenery or realism. Finally just press the 'Fly' button.

Which means I do not agree to the above points. But I do not have to prove it's possible.

[another_commander]

If you can upload an MSIX as you envision it, I can get it tested with Microsoft's App Certification Kit and see how feasible it would be to get it to the store.