Oolite Bulletins

Why, exactly, are OXPs not loaded in any well-defined, user-adjustable order? It would seem like a relatively small change in the code for a great benefit to OXP developers.

This has been discussed before. There was no deliberate decision made as to why OXPs are loaded in an indeterminate order. They are simply loaded in the order the underlying filesystem APIs give them to the program logic - which tends to differ between platforms.

To change it, we would need to pre-load the OXPs (or the OXP names, or the OXP metadata, depending on the solution we picked), sort it into whatever order makes sense, and then proceed to actually load & initialise the various OXPs.

Would it be that hard just to add some code to alphabetically sort the contents of the directory?

What are you actually doing that’s load-order dependent?

(By the way, there is no “the” directory.)

Nothing personally, but it seems like a sensible thing to add. Principle of least surprise and all that.

Phantom Hoover wrote:

Would it be that hard just to add some code to alphabetically sort the contents of the directory?

Submit a patch then :p

I am not convinced it is a good idea. OXPs should be load order agnostic, and where they depend upon or override each other, this should be explicit, not encoded in file name.

Please have look at the wiki page http://wiki.alioth.net/index.php/Handli ... JavaScript that I wrote that goes specifically into that subject.

Phantor Gorth

why would it make a difference what order they load in? :-/

Because they can override each other. For instance, the orbits OXP has different behaviour if it's loaded before or after farsun.

Orbits and Farsun are both very special cases. Both can cause incompatibilities with other OXPs, so it is to be expected that they may also have problems with each other.

Altering the fundamental aspects of planetary systems in Oolite not only in one, but in two different ways at the same time cannot be guaranteed to work without glitches. So use at your own risk.

If there is JS scripting involved, you may achieve a consistent load order in the way proposed by PhantorGorth.

Well, alright, but it would be nice if there was a nicer way to express dependencies and conflicts. I mean, there's already a requires.plist in the OXP root directory—why not extend it to express inter-OXP dependencies?

Phantom Hoover wrote:

Well, alright, but it would be nice if there was a nicer way to express dependencies and conflicts. I mean, there's already a requires.plist in the OXP root directory—why not extend it to express inter-OXP dependencies?

Because there’s no good way to reliably identify another OXP without loading and running its scripts. Adding an optional means of identification wouldn’t be a general solution; a mandatory one would break backwards compatibility.

I actually intend to break backwards compatibility in quite big ways in the next development cycle, with a comprehensive solution to expressing dependencies being one minor effect, but it would be crazy to contemplate doing it before MNSR.

Guaranteed lexicographic loading order would be a possible workaround for now, but I find it distasteful because names are for naming and shouldn’t be overloaded with other semantics in user-visible ways. Design is hard, let’s go shopping!

Bonus fact: there is actually a defined partial order on loading, namely:

1. Loose files in the app’s Resources directory
2. (Mac only) Loose files in ~/Library/Application Support/Oolite/AddOns
3. Loose files in AddOns next to the application
4. (Except Windows) Loose files in ~/.Oolite/AddOns (Looking at it now, I have no idea why this is 3 while ~/Library is before, but apparently we discussed it in May and only recorded the result)
5. OXPs in the app’s Resources directory
6. (Mac only) OXPs in ~/Library/Application Support/Oolite/AddOns
7. OXPs in AddOns next to the application
8. (Except Windows) OXPs in ~/.Oolite/AddOns
9. (Mac only, I think) OXPs specified at launch time by opening them in the Finder or through other means

As far as I can see, the only cross-platform way to actually use this information is to advise the user to install stuff in Resources/. Don’t do that.[/size]