Enable Oolite development (2)

[hiran]

But AFAIK Oolite is distributed as DMG for the Apple Mac. How does that work? Is that build getting signed?

As far as I can tell, no, it is not signed. Requiring code signatures for every app out there would seem rather draconian to me, even for Apple. Maybe it is only some app types (Java apps included probably) that require signing? Can't be sure without looking into Apple's app distribution guidelines in more detail.

You can distribute unsigned apps on MacOS as downloads, not via AppStore. Users will be notified that the app is not signed and that there is risk running it the first time they start it, but can start it nonetheless. It is possible to lock MacOS down to only allow signed applications, but this is not the default.

Then let's go that path - it should be fully sufficient.
If the signature is not the issue, how can we find out what is? After all Cholmonedely got the message that the DMG is broken. But what is broken?
How can I as non-Mac-user find out what we are facing?

[arquebus]

Is it possible the OXPs in question do not have a manifest.plist file?

I just checked, that's exactly what it is! The "missing" OXPs don't have manifest.plist files.

[hiran]

Is it possible the OXPs in question do not have a manifest.plist file?

I just checked, that's exactly what it is! The "missing" OXPs don't have manifest.plist files.

Ok. Cholmondely told me that a huge multitude of OXPs does not come with manifest.plist files. But no such manifest, no metadata to display. And no download_url. OoliteStarter cannot make up that information on it's own.

How do we want to handle that?

[arquebus]

Ok. Cholmondely told me that a huge multitude of OXPs does not come with manifest.plist files. But no such manifest, no metadata to display. And no download_url. OoliteStarter cannot make up that information on it's own.

How do we want to handle that?

What do you need the download_url for? If it's in the non-managed addons folder it's already been downloaded. Are you foreseeing a circumstance where a user could delete the OXP later and still have it in the list? Even so, I don't think it would make sense to have a download_url stored for OXPs. Some of them aren't as easly to download as a single click. Some of them are on cloud storage sites that require user interaction to confirm.

The name of the OXP could be taken from the directory name itself. Beyond that I'm not sure what additional information would be required. Since it's not a managed addon, the player has already made the effort to locate it and download it from the web, probably from the wiki itself, and so already knows what it does etc.

[arquebus]

Now to add an absolutely ridiculous, completely non-serious suggestion, because the effort involved is well beyond the value of the return, there is:

https://wiki.alioth.net/index.php/OXP_List

It's not complete (Contextual Jukebox isn't there, for example, and I haven't a clue how to edit wiki tables), but it does have a lot of non-managed OXPs listed, so data could be scraped from there if it were considered worth the time. Which I truly don't consider it to be. Non-managed OXPs don't really need to be embraced to the same level of detail as managed OXZs. At some point you just have to say "no."

[Cholmondely]

Now to add an absolutely ridiculous, completely non-serious suggestion, because the effort involved is well beyond the value of the return, there is:

https://wiki.alioth.net/index.php/OXP_List

It's not complete (Contextual Jukebox isn't there, for example, and I haven't a clue how to edit wiki tables), but it does have a lot of non-managed OXPs listed, so data could be scraped from there if it were considered worth the time. Which I truly don't consider it to be. Non-managed OXPs don't really need to be embraced to the same level of detail as managed OXZs. At some point you just have to say "no."

I've been thinking about this. The problem is how the OXP is identified. For the OXZ's it is easy - the manifest.plist provides the hook. For the OXPs it is less so - many lack version numbers and those which don't often have them tucked away in .plists or some such.

Hiran is talking of adding the ability to format manifest.plists to his Oolite Starter. That might allow me to start doing this. It might even be able to carry a library of OXP manifest.plists and insert them into the OXP itself! (He seems to be able to work magic on his computer. I only wish it were an AppleMac!)

The most important OXPs need adding to the Expansions Manager, anyway. Povray Planets is top of the list, I would say.

And do you have any ideas about what could go in meta-OXPs?

A second path is that of the OXPs.

The major improvements in the Vanilla game since 2015 have been graphical. This allows for major improvements regarding the oxps, if we have the skills and can be bothered. (I was thinking of a_c's addition of planet night-lights)

The main problem is the bewildering assortment of 1100 OXPs and the heavy investment of time needed to work out what is what.

I believe that what is needed is a small selection of meta-OXPs which create ready-made content-filled universes for the player.

The following seem to me to be possible candidates:
• Stranger's World (more realistic, might need minor tweaking)
• Elite Trader (just trading, but this might need no work at all)
• SOTL Exploration (needs some work - HUD, new station-ship, use of commodities to create new equipment...)
• Far Planets (seems very incomplete - needing many more systems, or am I wrong?)

Oh! And I found this lurking back in the 2010 threads:

Bear with me for a second while I air a wild and crazy idea I had back in 2008 when I first found oolite, and which I still have not yet totally abandoned: An external OXP manager app. Like, it could let you have OXP "sets", with different ones activated for different commanders, or galaxies or whatever. (Yes, I realize that not everybody plays more than one commander. Some do.) It could easily install or de-install any given OXP. It could tell you things like which ships an OXP provides. And it could, in the ideal case, let you configure various behaviors of OXPs that had them. One of the things that kept me from starting such a thing back then, and is still stopping me, is how to make something that's portable across all three of oolite's platforms. But as I said, I still haven't totally abandoned the idea.

[hiran]

Ok. Cholmondely told me that a huge multitude of OXPs does not come with manifest.plist files. But no such manifest, no metadata to display. And no download_url. OoliteStarter cannot make up that information on it's own.

How do we want to handle that?

What do you need the download_url for? If it's in the non-managed addons folder it's already been downloaded. Are you foreseeing a circumstance where a user could delete the OXP later and still have it in the list? Even so, I don't think it would make sense to have a download_url stored for OXPs. Some of them aren't as easly to download as a single click. Some of them are on cloud storage sites that require user interaction to confirm.

The name of the OXP could be taken from the directory name itself. Beyond that I'm not sure what additional information would be required. Since it's not a managed addon, the player has already made the effort to locate it and download it from the web, probably from the wiki itself, and so already knows what it does etc.

The manifest contains .more than just the download url or the expansion name. In my eyes it contains enough information so a user can take a decision.

So should we consider OXPs to be user-managed and no expansion-manager should touch them at all?
I came to think about it while creating expansion-sets. Just how strict/repeatable should they be?

[Switeck]

For additional pain, there's lots of OXPs that have seen considerable changes in their versions...often the OXPs that never became OXZs exist only as the latest/last version.

[arquebus]

The manifest contains .more than just the download url or the expansion name. In my eyes it contains enough information so a user can take a decision.

So should we consider OXPs to be user-managed and no expansion-manager should touch them at all?
I came to think about it while creating expansion-sets. Just how strict/repeatable should they be?

The thing is, the user has already taken the decision - to download the OXP manually and install it. But sometimes those OXPs will conflict with others, both managed and non-managed, and I think it's the role of an external expansion manager to make it easy to do the A/B testing necessary to find the conflicts and resolve them. That would require that the external manager handle both managed and non-managed OXPs, regardless of whether or not they have a manifest.plist. As long as it recognizes that an OXP directory exists, it should put it in the non-managed list of expansions, so that the user can turn it on or off as needed. The program can stipulate in a warning that this is *ALL* it can do: activate or deactivate. It can't provide any information about the contents of the OXP other than the name of the directory.

If you then create an expansion set that includes a downloaded OXP that the external manager cannot itself download, then when loading the set, if the manager cannot locate the OXP directory that the set requires, it can report the error: "The non-managed OXP <directory name> is not available and has not been activated."

Given that the number of expansions managed by the in-game manager is only roughly half the total number of expansions that exist, I think an external manager that does not include functionality to at least activate/deactivate non-managed OXPs would not be maximally useful to a significant number of players.

[hiran]

The thing is, the user has already taken the decision - to download the OXP manually and install it. But sometimes those OXPs will conflict with others, both managed and non-managed, and I think it's the role of an external expansion manager to make it easy to do the A/B testing necessary to find the conflicts and resolve them. That would require that the external manager handle both managed and non-managed OXPs, regardless of whether or not they have a manifest.plist. As long as it recognizes that an OXP directory exists, it should put it in the non-managed list of expansions, so that the user can turn it on or off as needed. The program can stipulate in a warning that this is *ALL* it can do: activate or deactivate. It can't provide any information about the contents of the OXP other than the name of the directory.

If you then create an expansion set that includes a downloaded OXP that the external manager cannot itself download, then when loading the set, if the manager cannot locate the OXP directory that the set requires, it can report the error: "The non-managed OXP <directory name> is not available and has not been activated."

Given that the number of expansions managed by the in-game manager is only roughly half the total number of expansions that exist, I think an external manager that does not include functionality to at least activate/deactivate non-managed OXPs would not be maximally useful to a significant number of players.

Sounds reasonable. I will try to implement such behaviour.
Thank you for that writeup.

[hiran]

For additional pain, there's lots of OXPs that have seen considerable changes in their versions...often the OXPs that never became OXZs exist only as the latest/last version.

Yup - they must be all some work in progress.
Without proper versioning it is hard to tell one from the other - but that is the user's choice as Arquaebus put it. The Starter can only point out and help if the user wants to take action.

[timer]

In parallel I am working on native packages (deb, exe, dmg). Here's a different problem:
When installing the debian package, there is no sample.properties that you could copy and edit. You just startup the application and it fails.
So thinking about alternatives anyway...

JFYI did u see this?
https://sources.debian.org/src/oolite/1.84-1/debian/

[hiran]

JFYI did u see this?
https://sources.debian.org/src/oolite/1.84-1/debian/

Not before you pointed it out. Good to know.
We are talking about two different applications though:
Oolite vs Oolite Starter. And meanwhile I have a DEB already on Github and it can be installed on Ubuntu.

Now I need to modify the application to work after having been installed via the DEB, which should resolve similar issues when installed through the other native packages.

[Cholmondely]

I notice that they have a number of different versions of Oolite:


version 1.84-1 (main) [stretch]
version 1.77.1-3 (main) [jessie, jessie-kfreebsd]
version 1.76.1-2 (main) [wheezy]
version 1.65-7 (main) [squeeze]
version 1.65-6 (main) [lenny]
version 1.65-5 (main) [etch, etch-m68k]

[timer]

Not before you pointed it out. Good to know.

it is from here
https://github.com/OoliteProject/oolite ... -137510231
the author may well still be in touch...