BGS and new backgrounds

[phkb]

I've been getting under the hood of Oolite recently (I kind of feel like Han Solo and the Millenium Falcon!), creating a new set of interface screen backgrounds to make a new, fresh look. I was originally just putting the images into the BGS images folder, but that means that each time a new version is released I have to update the images again. So I created a new OXP, and put my images in there, and with a plist file and a little scripting, I have everything the way I want it. I have my screens, but I also have the other benefits of BGS (better launch, docking and wormhole animations in particular, but also the LRC overlays).

My question is: In order to get my images to take precedence I had to make sure the name of my OXP folder comes after the BGS folder. I think if I keep my OXP in my addons folder, and BGS stays in the managed addons folder, this will always be the case. But, if I were to ever release my OXP as a managed addon I have a problem. "phkb" comes before "Svengali", which means my OXP would never work as a managed addon in conjunction with BGS.

This isn't a big problem, but I'm curious if there's any way I can force my OXP to take precedence over BGS with regard to a screenbackgrounds.plist file, without creating a new user ID that comes after "S".

[Wildeblood]

My question is: In order to get my images to take precedence I had to make sure the name of my OXP folder comes after the BGS folder. I think if I keep my OXP in my addons folder, and BGS stays in the managed addons folder, this will always be the case. But, if I were to ever release my OXP as a managed addon I have a problem. "phkb" comes before "Svengali", which means my OXP would never work as a managed addon in conjunction with BGS.

This isn't a big problem, but I'm curious if there's any way I can force my OXP to take precedence over BGS with regard to a screenbackgrounds.plist file, without creating a new user ID that comes after "S".

(1) No, you need yours to load after BGS. Windows will load them in alphabetical order, Macs won't. So you're working from a flawed premise there.

(2) You can use any identifier for an oxp, it doesn't need to begin oolite.oxp.phkb. So if you do want to manipulate an entry's position in the big, merged manifest or the file's name in managed add-ons, for whatever reason, try aaa.phkb or zzz.phkb. But, see point 1, whatever the reason, it can't be controlling load order.

(3) Co-incidentally, I had the same problem just last night. Read the description of AI Trading with Yoda in the download manager.

[Ranthe]

My question is: In order to get my images to take precedence I had to make sure the name of my OXP folder comes after the BGS folder. I think if I keep my OXP in my addons folder, and BGS stays in the managed addons folder, this will always be the case. But, if I were to ever release my OXP as a managed addon I have a problem. "phkb" comes before "Svengali", which means my OXP would never work as a managed addon in conjunction with BGS.

This isn't a big problem, but I'm curious if there's any way I can force my OXP to take precedence over BGS with regard to a screenbackgrounds.plist file, without creating a new user ID that comes after "S".

(1) No, you need yours to load after BGS. Windows will load them in alphabetical order, Macs won't. So you're working from a flawed premise there.

Does Linux follow the Windows or the Mac order for loading? I've found that Zireael's "Jameson Faces" OXP doesn't seem to work for me since I moved to Linux v1.80, and the "Jameson Faces" OXP has neither .plist or script entries.

[phkb]

What determines the order OXP's are loaded on a Mac, if not alphabetical?

[Smivs]

I believe Linux also loads in a random order.
Over-riding other OXPs has been discussed here recently I think, although I can't remember the subject now. My first thought is that it could be seen as a bit rude to just over-ride somebody else's work - they obviously put a lot of work and effort into their product, so it is a delicate matter that requires some thought and consideration.
Also, I think we are approaching this issue from the wrong direction. There are two problem areas as I see it.
The first is that an OXP does something that is un-helpful (perhaps in the context of an OXP you are developing) and you need to put things right. An example of this is a problem I had when a piece of equipment was made available where it shouldn't have been - a TL 9 planet had an OXP station with TL 12 - and this broke a mission I was working on. I had to remove all OXP stations from the system in question to make my mission work.
The second problem is the one described here, where you want to overide one element of a multi-function OXP while leaving the others in place, and this is much harder to deal with.
In both cases the 'problem' actually lies with the original OXP, not the one you are working on. It is the responsibility of OXP authors to ensure that their work does not break crucial elements of the core game (such as effectively changing a system's TL as in the first example) and to ensure that flexibility is not denied as in the second example - in a case like this i would favour separate OXPs for each function, so that alternative OXPs can be used for any function without any fuss and bother.
So the best solution really is not to try to overide other things or work around them, but for authors to be more mindful when designing OXPs in the first place.
Welcome to cloud-cuckoo land!

[Norby]

the "Jameson Faces" OXP has neither .plist or script entries.

The problem is similar with the .png files (which is defined in a plist within BGS). I think a proper solution if the BGS would be splitted into parts (images, sounds, tunnels...) and if somebody wants to publish an alternative then must make a full set of that part and set the new package to conflicting with the original part.

Jameson Faces OXP use the worst way: redefining a few images only create a big problem at the moment, and Tricky will start to hit his head into the nearest wall imho if everybody will start to request special BGS splits for the variously selected image replacements.

[Smivs]

...everybody will start to request special BGS splits for the variously selected image replacements.

I don't think anyone expects Tricky to supply various image packs within BGS.
If the BGS background images were self-contained, and distinct and separate from everything else, then any other background OXP (Jameson Faces, Better Screens etc) could just be installed as an alternative, and will work without any problems to itself or the other BGS elements.
The same is true for the sound packs.

[cim]

The load order is:
- core data
- Managed AddOns, in filesystem order of identifier
- AddOns, in filesystem order of OXP folder name

Filesystem order of identifier is alphabetical on Windows, random on Mac, and usually random on Linux unless you do something weird like create a fat32 filesystem just for your AddOns folders.

Managed AddOns are all loaded first to make it easy for people to create personal overrides for any of them by putting the relevant files in their AddOns folder.

If you want to distribute an override then this needs thinking about a bit more. We do add features with every version to make it easier for OXPs to coexist - some of the design of the new system populator in 1.80 was directly inspired by the station/mission conflict Smivs mentions, for instance - but where two OXPs provide the same file (or for plists, the same key) there's not much can be done.

In this particular case a potential solution to allow OXPs to override selected images (but not necessarily all) from BGS is:

• BGS uses setScreenBackground() and setScreenOverlay() rather than the plists for setting backgrounds - i.e. doing in JS what Oolite normally does in core - and provides a default list
• BGS provides a mechanism in JS for other OXPs to alter its default background file list
• OXPs wishing to use that mechanism add images under unique names (so file loading order doesn't matter). The usual mechanism for ensuring BGS' startUp is run first can be used.

Not all plists can be overridden this way by script, but most can.

(Sound is different - there are problems with allowing OXPs to override customsounds.plist from script which I've not yet thought of a good solution for)

[Svengali]

BGS uses JS only for things which can't be done via plist (e.g. handling the situation if the player died while on Status screen). There are also screens which can't be set via JS, while others can only be set via JS. It's not different to the situation with all other plists and the question is (for me) a general plist handling question. Personally I don't see why an AddOn should move everything into JS if a plist for these things exists.

btw: The alphabetical stuff should be answered in these posts https://bb.oolite.space/viewtopic.php?f= ... &start=303 and https://bb.oolite.space/viewtopic.php?f= ... &start=307.

[PhantorGorth]

This wiki page I wrote may help:

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

Phantor

[ffutures]

BGS uses JS only for things which can't be done via plist (e.g. handling the situation if the player died while on Status screen). There are also screens which can't be set via JS, while others can only be set via JS. It's not different to the situation with all other plists and the question is (for me) a general plist handling question. Personally I don't see why an AddOn should move everything into JS if a plist for these things exists.

btw: The alphabetical stuff should be answered in these posts https://bb.oolite.space/viewtopic.php?f= ... &start=303 and https://bb.oolite.space/viewtopic.php?f= ... &start=307.

Reading this entirely out of context...

If the player died while on Status screen I'd imagine that his or her heirs will have other things to worry about, with Oolite a fairly low priority!