Oolite Bulletins

submersible wrote:

and of course that raises the question of how to stamp OXPs with that information without fully loading them first.

With the way OXP loading works, that's not too difficult. The loading manager gets an ordered list of directories containing OXP data. It then just uses that list whenever it comes up. All you'd need to do is push that list to a sort function once you've loaded the requires.plist information, and make sure you process requires.plist first.
(Writing the sort function, dependency management, loop detection, etc. would be more difficult. You'd also need a "provides" block in requires.plist so that Oolite knew which OXP folder "Cabal_Common_Comms" was, and then probably the various niceties package managers have such as >= dependencies, conflicts, etc.)

submersible wrote:

I wonder if it is important to anyone other than me.

Most dependencies between OXPs are still load-order independent (or in JS have the self-deleting startUp trick), which may be why it doesn't come up much.

Hmm, that inspires a possible solution for this case: include a small worldscript in v2, which checks on startUp and on playerEnteredNewGalaxy if System.infoForSystem(0,7).texture is the patched version, and sets it to it if not.

eg: my.oxp defines a planetinfo for Lave ; and my-v2.oxp defines it also

cim wrote:

Hmm, that inspires a possible solution for this case:.

That is no solution, because than the other texture is not shown. You can't fix a problem of two oxps defining a texture by changing the load order. You only shift the problem from one oxp to the other, as only one wil be able to add its texture.
The only solution will be to make a choice which one you install.

Or in this case, I would add a timer in my code so I run later, to switch the lave texture back to my texture in case other oxps removed my settings.

perhaps an oxp preloader could load all AddOns/*.oxp/requires.plist, do the sort then go for the oxp's themselves rather than just loading them all, using a Dict a sanitised version of the path could be used as the key so it can be fed to the proper loader afterwards.

That would have the benefit of not actually loading any that would be broken.

I'm new to the Oolite source, I'll have a look after dinner and see if i'm talking out of my ear again

or no doubt one of you nice folk would point it out here