Load order of OXPs

[DaddyHoggy]

In this thread:

https://bb.oolite.space/viewtopic.php?t=8674

the load order issue raises its head once more and I still find this issue a little peculiar and the fix (AAA or ZZZ'ing the files) a little clunky.

Would it be possible for Oolite to create a file (first time of running) that dumps the load order of OXPs to this text readable file on a line by line basis.

On subsequent runs of the game, if Oolite detects that this file exists it loads the OXPs in the order they're in this file.

With this in place the user could then reorder files in this list (without renaming them) and Oolite would then load them up in this new order?

Just a thought.

DH

[Micha]

and the fix (AAA or ZZZ'ing the files) a little clunky.

Not just clunky, it won't (necessarily) work.

Renaming the OXP directories does NOT GUARANTEE that OXPs are loaded in any particular order.

It depends purely on the OS (and/or the filesystem) as to what order the OXPs are loaded in. It may well be the case that under Windows the directories are processed in alphabetical order (I can't remember), however that is not something that OXP writers should rely on as it WILL break on other systems.
The most likely enumeration order is in the order the directories were created.

We -could- add guaranteed alphabetical load order to Oolite, but at present that is not the case.



An alternative to DaddyHoggy's suggestion might be to add some sort of priority field to OXPs. OXPs of the same priority are loaded in arbitrary order, OXPs of higher priority last, lower priority first.
That way the highest priority OXPs overload the lowest priority ones.

This approach has the benefit of the OXP author being able to say 'this OXP overrides such-and-such, so needs to be higher priority', and should hopefully work when the OXP is installed.

DaddyHoggy's approach means that everybody would have to edit their OXP Loading Order every time they install a load-order critical OXP (and would have to be aware of the fact that they had done so in the first place!).

[Switeck]

And my game mod would qualify as an example OXP that needs such critical ordering, as it changes native settings...which are likely changed as well by other OXPs.

[Mauiby de Fug]

Renaming the OXP directories does NOT GUARANTEE that OXPs are loaded in any particular order.

It depends purely on the OS (and/or the filesystem) as to what order the OXPs are loaded in.

As evidenced in my own log file:

Code: Select all

[log.header]: Opening log for Oolite version 1.74.2 (x86-32 test release) under Linux at 2010-11-02 04:41:10 +0000.
2 processors detected.
Oolite options: procedural planet textures, docking clearance, wormhole scanner, target incoming missiles, spoken messages, JavaScript console support, OXP verifier, localization tools, debug GraphViz support.

Note that the contents of the log file can be adjusted by editing logcontrol.plist.

[joystickHandler.init]: Number of joysticks detected: 0
[display.mode.list.native]: X11 native resolution detected: 1440 x 900
[dataCache.rebuild.explicitFlush]: Cache explicitly flushed with shift key. Rebuilding from scratch.
[searchPaths.dumpAll]: Unrestricted Mode - Resources paths:
    /usr/lib/GNUstep/Applications/oolite.app/Resources
    ~/.Oolite/AddOns
    ~/.Oolite/AddOns/Target Autolock Plus 1.10.oxp
    ~/.Oolite/AddOns/tori.oxp
    ~/.Oolite/AddOns/Ste3cV1.4.oxp
    ~/.Oolite/AddOns/Galactic_Navy 5.2.2.oxp
    ~/.Oolite/AddOns/Snoopers2.0.8.oxp
    ~/.Oolite/AddOns/YOUR_AD_HERE_set_E.oxp
    ~/.Oolite/AddOns/YOUR_AD_HERE_set_C.oxp
    ~/.Oolite/AddOns/BGS-A1.2.oxp
    ~/.Oolite/AddOns/Superhubv1.2.oxp
    ~/.Oolite/AddOns/wolfmk2.oxp
    ~/.Oolite/AddOns/Lave Academy 1.20.oxp
    ~/.Oolite/AddOns/Dictators v1.4.oxp
    ~/.Oolite/AddOns/diamondback.oxp
    ~/.Oolite/AddOns/thargoid_wars 4.5.oxp
    ~/.Oolite/AddOns/System_Redux.oxp
    ~/.Oolite/AddOns/Commies.oxp
    ~/.Oolite/AddOns/Lave.oxp
    ~/.Oolite/AddOns/werewolf.oxp
    ~/.Oolite/AddOns/Tori2.01.oxp
    ~/.Oolite/AddOns/Rock_Hermit_Locator1.3.2.oxp
    ~/.Oolite/AddOns/PAGroove_Stations_v1.2.2.oxp
    ~/.Oolite/AddOns/captKev_dodo.oxp
    ~/.Oolite/AddOns/Anarchies2.3.oxp
    ~/.Oolite/AddOns/MilHUD-v3.4.oxp
    ~/.Oolite/AddOns/Deep Horizons - Lights Down.oxp
    ~/.Oolite/AddOns/isisinterstellar.oxp
    ~/.Oolite/AddOns/YOUR_AD_HERE_set_A.oxp
    ~/.Oolite/AddOns/spyhunter 1.1.oxp
    ~/.Oolite/AddOns/military Fiasco 2.5.oxp
    ~/.Oolite/AddOns/gwxstations.oxp
    ~/.Oolite/AddOns/longway 1.1.oxp
    ~/.Oolite/AddOns/buoyRepair1.02.6.oxp
    ~/.Oolite/AddOns/black_baron.oxp
    ~/.Oolite/AddOns/wolfwoods_variants.oxp
    ~/.Oolite/AddOns/BlOomberg Markets v2.2.oxp
    ~/.Oolite/AddOns/Blackjacksbullion js v1.24.oxp
    ~/.Oolite/AddOns/Taranis 1.2.oxp
    ~/.Oolite/AddOns/Tianve1.3.oxp
    ~/.Oolite/AddOns/reduxed.oxp
    ~/.Oolite/AddOns/The Feudal States v1.9.3.oxp
    ~/.Oolite/AddOns/supercobra 1.4.2.oxp
    ~/.Oolite/AddOns/Diso.oxp
    ~/.Oolite/AddOns/BountyScannerv2.0.oxp
    ~/.Oolite/AddOns/Saleza v2.2.oxp
    ~/.Oolite/AddOns/YOUR_AD_HERE_set_D.oxp
    ~/.Oolite/AddOns/Welcome Mat 1.10.oxp
    ~/.Oolite/AddOns/YOUR_AD_HERE_set_F.oxp
    ~/.Oolite/AddOns/ionics-1.3.oxp
    ~/.Oolite/AddOns/AsteroidStorm 4.0.oxp
    ~/.Oolite/AddOns/YOUR_AD_HERE_set_B.oxp
    ~/.Oolite/AddOns/behemoth 2.5.4.oxp
    ~/.Oolite/AddOns/globestation2.0.oxp
    ~/.Oolite/AddOns/tgy_dev.oxp
    ~/.Oolite/AddOns/neocaduceus.oxp
    ~/.Oolite/AddOns/griff_shipset_dizzy's_all_in_1.oxp
    ~/.Oolite/AddOns/DeepspaceShip.oxp
    ~/.Oolite/AddOns/PlanetFall 1.30.oxp
    ~/.Oolite/AddOns/RandomHits1.4.5.oxp
    ~/.Oolite/AddOns/FTZ v0.15.oxp
    ~/.Oolite/AddOns/YOUR_AD_HERE.oxp
    ~/.Oolite/AddOns/vamp3a.oxp

and so on. I have yet to work out any reason why these load in the order that they do. It is always the same order, though.

The scripts are however displayed in alphabetical order:

That oxp's can load in non-alphabetical order is new to me. I assume its the OS that determines the order in which the files are offered to Oolite.
For the scripts its more clear, Oolite does:
Code:
[displayNames sortedArrayUsingSelector:@selector(caseInsensitiveCompare:)]
Just before listing them in the log. So its explicit sorting them in alphabetical order. Its is very easy to also log the OXP's alphabetical by inserting above sorting command, but I think its better to show the actual loading order as it now happens.

[Kaks]

What Micha said!

Adding a load_order setting inside requires.plist for 1.75 sounds like the most sensible approach.


Might be a pain to code right, though...

[another_commander]

I just want to comment that indeed the solution of renaming folders AAA.oxp or ZZZ.oxp is just a quick hack and it is not to be relied upon, as Micha said. Whenever it has been proposed, it was done to resolve a very particular situation quickly and it does not mean that it will work in cases other than that particular one for which it was proposed. More imporantly, OXPs released officially by their authors with default names like ZZZZWhatever.oxp or AAAAWhateverElse.oxp are ususally the ones whose presence in the AddOns folder creates the most obscure problems.

Even if we classify OXPs by priority, there could still be conflicts between OXPs of equal priority status or simply an OXP author could decide that their OXP is the most important of all and has to be overriding everything else, without that being the case. Before we know it, we might start seeing all OXPs released with their priority attribute set to 'high'. In short, I do not think that it is something that we can fully control.

In my opinion, the best thing one can do is try to know what they are installing. The diversity of OXPs does not necessarily mean that they all should be present in every Oolite installation, quite the opposite actually. So, install your OXPs one at a time, know what you want to install and you should be able to avoid most of the potential problems that could crop up.

It has to be also noted that the conflicts between OXPs situation is especially evident with the localization OXPs due to the way most of them are written. Using override plists should overcome most of the conflicts issues, but this means that most localization OXPs will have to be updated by their respective authors for full compatibility both with the latest Oolite version and with the rest of the OXP world.

[Darkbee]

How do you determine priority?

Does this really solve the problem? If several OXPs all have the same priority, they will still be loaded arbitrarily and you're back to square one.

Just playing devil's advocate... don't shoot!

[Kaks]

well, a numerical load_order should help a bit. If oxp makers fail to excercise restrain and all of them have load_order = 99999999, at worse we're back to the situation as it is now, but hopefully sanity will prevail.

The sane ooniverse theory could lead to the majority of oxps having a load_order between 1(loaded first, will be overridden by most in case of conflict) and 9 (will override the majority of oxps in case of conflict)!

But it's only a dream, at least for now...

Cheers,

Kaks

[Darkbee]

At the bare minimum you could assign priority by OXP type e.g. huds can be loaded first, ships next, missions last (purely example only). I'm not sure what this buys us, but it's a start. So lowest priority to highest, but the problem still stands, if you have several mission OXPs you need to determine the order among those.

It's good to dream.

[Micha]

The idea of the load-order priority would be that:

1. If load-order is unimportant for an OXP, nothing is specified and Oolite chooses the middle value of a pre-arranged range. eg. 0 from -100 to +100.

2. If load-order -is- important, the OXP author will have hopefully chosen a reasonable value, ideally by collaborating with the authors of the OXP(s) with which it needs to work with.

3. In the case of an actual conflict on a particular setup, the person installing the OXP can adjust the priority for that OXP which WILL work (for them) unlike the folder-renaming which may or may not. Hopefully feedback is also given to the OXP author if a better priority value can be found.

So no, the proposal is not a magic bullet, but it's better than the not-quite-working renaming of OXP folders which we have now.

And yes, as A_C mentioned, knowing what you're installing and how it may interact is important too. Unfortunately it gets very complex very quickly, so if we can come up with a relatively simple way of distilling the collective experiences and knowledge of the comoonity that would be just grand.

[DaddyHoggy]

I don't see how getting OXPs authors to choose a priority is any more sustainable than my suggestion. In fact if you go back a few post to A_Cs suggestion, which is know your OXP and know what they do - a load order list (created initially by Oolite itself) could be left alone if all your oxps work happily together, but could quickly edited to move around an OXP just to check that it is indeed a load priority/overwrite issue, since a quick resolution to some of these issues is all we want... (or a quick confirmation of conflict at the very least)

[CheeseRedux]

Just for the sake of completeness: This thread looks at the problem from another angle, discussing out-of-the-game workarounds.

[maik]

In my opinion, the best thing one can do is try to know what they are installing. The diversity of OXPs does not necessarily mean that they all should be present in every Oolite installation, quite the opposite actually. So, install your OXPs one at a time, know what you want to install and you should be able to avoid most of the potential problems that could crop up.

This advice is sound but only the engineer types of gamers will actually follow it. Looking at the 70 odd OXPs that I have in my box.net, most people seem to download around 50 of them at a time. And I doubt they install them one by one.

I don't see how getting OXPs authors to choose a priority is any more sustainable than my suggestion.

OXP authors tend to be a lot more knowledgable about OXPs then most players. Yes, the forum regulars pick up a lot of information here, but we are a minority. Take a look e.g. at the number of requests of the new OXP List on the wiki. It has not been up for a long time but already been accessed more than 6000 times. This seems to indicate that there are a few more people than just us.

In fact if you go back a few post to A_Cs suggestion, which is know your OXP and know what they do - a load order list (created initially by Oolite itself) could be left alone if all your oxps work happily together, but could quickly edited to move around an OXP just to check that it is indeed a load priority/overwrite issue, since a quick resolution to some of these issues is all we want... (or a quick confirmation of conflict at the very least)

I think this is asking too much. Asking OXP authors to think about what the priority seems reasonable and probably takes us a long way.

[Svengali]

PhantorGorth has found another approach (-> https://bb.oolite.space/viewtopic.php?t=3243&start=278) which is working pretty well.

It's easy to use and requires only a few additional lines of code in the scripts.

[PhantorGorth]

I have now added a page to the wiki for handling this sort of issue:

http://wiki.alioth.net/index.php/Handli ... JavaScript