Oolite Bulletins

I spent several hours this weekend getting my neglected OXP folder back into shape. Sometime during this process - probably around the time I first noticed Smivs' spinning Cobra instead of the familiar Neolite one - it occured to me that we're beginning to get quite the collection of OXPs that don't quite play nice with each other.
The most obvious of these are, quite naturally, the shipsets. At present there are 6 different replacement shipsets, most of which will seek to override the standard set.
Other common objects - stations, pods, escape capsules, asteroids etc - also exist in several versions.

If I install all of them, will they live happily side by side, or will one suppress the others? If the latter, which one?
Or will some of them co-exist, others not?

For a lot, if not most, of the forum regulars, the answers to those kind of questions are trivial. But for someone new to the OXP scene, these things are far from obvious. For someone totally green, they may not yet even have picked up enough of the inner workings of things to even ask those questions, but be asking things like "New OXP installed, nothing happened, WTF?"or "New OXP installed, old one disappeared, WTF?"

I therefore think that a page listing OXPs that don't play nice, and, where appropriate, how to make them play nice, would be a useful addition to the wiki.

CheeseRedux wrote:

For a lot, if not most, of the forum regulars, the answers to those kind of questions are trivial.

I dont think they are trivial, in fact Im not sure it is even obvious to the authors of the OXPs themselves where possible incompatabilitiies might lie.

It would be useful to have information on known incompatabilities, for example OXPs which both try to change the planet skins but I think I would prefer to see this on a page for the OXP itself, as it may well not be simple tabular data, we may need to give info on what kinds of inconsistencies there are, for example mission breaking or cosmetic, and which versions they are fixed in, etc.

I agree it's useful information. Instead of having a separate Wiki page for this, there is also the option to include it in the respective OXPs' Wiki pages. This is the way I just chose a few days ago when I started picking up this information from discussions on the BB, see e.g. the wiki page for the assassins guild.

Wherever the information ends up, the biggest trouble is finding out about these incompatibilities. Once someone mentions it I can pick it up and add it to the Wiki. But most just go unmentioned...

CheeseRedux wrote:

I therefore think that a page listing OXPs that don't play nice, and, where appropriate, how to make them play nice, would be a useful addition to the wiki.

Great idea, in theory...not so easy in practice as there are so many potential conflicts, some being almost un-predictable until they happen.

With regard to the shipsets, to the best of my knowledge all OXPs are loaded alphabetically and where there is a conflict the last one wins, which is why you're seeing my Cobra. 'S' comes after 'N' in the alphabet. Simple as that.
This is one problem of having lots of replacement sets. I suppose like most authors I saw mine as a straight replacement for the 'in-built' textures and therefore keeping the ships' names was entirely logical, particularly as I used the in-built models. Same ships, just better looking.
Deepspace's shipset uses the same approach.
Neolytes (and others) replace the models as well, as do Griff's, but Griff has called his (I believe) Griff ship and uses an override propertylist so his both replace and supersede the original ships.
One obvious solution is for 'non-core' shipsets like Neolyte to re-name the ships to say 'Neolyte Cobra' then they would be treated differently and there would be no conflict, but I'm not going to tell other authors how to detail their work.
The spinning Cobra is another case altogether, as I believe this is hard-coded to show the player Cobra, which in your case is my version as that OXP has precedence due to it's alphabetical position.
This thread deals with this issue from the other direction and might be worth a read.

As for the planet retexturing OXPs, I have something in the works to help address this situation, but it will require a minimal buy-in (effort, not cash) from the other authors. When I get a bit closer to finished, I'll be contacting Capt Kev and DrBeeb with details and then public announce sometime after.

Some good points here. If you'll allow me to comment in semi-chronological order:

When I was talking about trivial questions, I was referring to my shipset examples, which have been discussed several times in numerous threads. I therefore assumed this to be fairly common knowledge on the board.
I guess the thing I was trying to convey was that the more familiar you are with a subject matter, the more difficult it can be to imagine yourself knowing nothing about it. I've several times come across situations where vital information has not been passed on to the "new guy" because it had become as natural as breathing to the "old guy".

At least some OXPs have incompatibilities listed on the wiki page and/or in the readme file. I do believe, however, that some redundancy is in order here. It is, after all, far easier to check one page of known problems than to check each individual page/readme.

And yes, presenting this in tabular form would probably not be a viable approach. But since the conflicts are likely to form clusters, with missions colliding with missions and shipsets colliding with shipsets while missions and shipsets live happily together, it should be possible to deal with them section by section.

Anything that uses/changes part of the core game should be a prime candidate for conflict testing. As Smivs mentioned, last one in wins. This is why RS used a bunch of Zs in the folder name in order to ensure nothing would sneak in after and overwrite stuff.

Some testing I imagine to be quite easy. Again returning to the shipsets, an easy first test would be to install them all, then see which version(s) turn up. Then uninstall the one that seems to suppress the others (hint:look at the spinning Cobra). Rinse and repeat until left with the basic core shipset.
A similar test could be done with the ones that replace other core elements (stations, pods, escape capsules, asteroids etc), but would likely require spawning stuff to save time.

I dont think those are the compatabilities we need to worry about. I think it is far more important to identify subtle problems such as missions that become impossible or equipment that doesnt work (lets say you have an ecm system that is unable to identify some OXP missiles).

I dont think redundancy is good, as this is likely to lead to one or both sources becoming outdated, but if you think its worth doing, then Id just go ahead and add the pages.

Cmdr James wrote:

I dont think those are the compatabilities we need to worry about. I think it is far more important to identify subtle problems such as missions that become impossible or equipment that doesnt work (lets say you have an ecm system that is unable to identify some OXP missiles).

You are of course absolutely right that problems affecting gameplay are more important than those that are purely visual. I used the retextures as an example as they are easy to spot for the layman. Fortunately this is not an either/or situation; If we so choose, we can have our cake and eat it.

Cmdr James wrote:

I dont think redundancy is good, as this is likely to lead to one or both sources becoming outdated, but if you think its worth doing, then Id just go ahead and add the pages.

With the fairly low number of people actually having access to editing the wiki, I think it should be possible to keep the information in two places. If that proves not to be the case, then having the list link to the OXP page (or the other way around) for details is another usable solution.

If the OXPs get loaded, but superseded then presumably they are still taking up memory? Or are they only in memory once they are called, which the overridden ones won't be? There could be some potential performance issues, if nothing else then simply an increase in loading time of Oolite.

I think a general Wiki page giving potential broad issues to consider might be useful. e.g. Ship-sets might override other ship-sets according to alphabetical naming preference etc.

In an ideal world someone would right an OXP redundancy check that would flag such potential issues. (I love how ideas are so easy to proclaim without any thought or regard of implementation)

Sorry if this has been covered, I read through this thread very quickly.

Darkbee wrote:

If the OXPs get loaded, but superseded then presumably they are still taking up memory? Or are they only in memory once they are called, which the overridden ones won't be? There could be some potential performance issues, if nothing else then simply an increase in loading time of Oolite.

No, they're not taking up memory after Oolite is finished setting up the cache.

Yes, having 2 or more oxps overriding each other will increase the time it takes to create the cache (Something that happens when an oxp is added or removed, or when shift is pressed while Oolite is launched).

The major drawback is the extra amount of disk space used...

Darkbee wrote:

In an ideal world someone would right an OXP redundancy check that would flag such potential issues.

That shouldn't be too difficult to implement into the core game - should it?

Lestradae wrote:

Darkbee wrote:

In an ideal world someone would right an OXP redundancy check that would flag such potential issues.

That shouldn't be too difficult to implement into the core game - should it?

Yes it should.

another_commander wrote:

Lestradae wrote:

Darkbee wrote:

In an ideal world someone would right an OXP redundancy check that would flag such potential issues.

That shouldn't be too difficult to implement into the core game - should it?

Yes it should.

For sure my innocent imagination again.

For things like ship keys, equipment keys, textures, music or sound files, etc., shouldn't it be possible to make Oolite flag double or multiple occurences of them into the log, thus signalling potential conflicts?

I am aware that not every overwriting is a conflict, and it sure wouldn't be possible to find mission clash conflicts that way, but it would help.

That was what I meant - still "yes it should"?

Cheers,

L

Well, the question is different now. You are asking if it is possible to flag things, so the answer to that is "Yes, it is possible". Everything is possible. But is it complicated? Oh, yes it is. Does it need a lot of time to implement? Yes it does. Does the time needed to do it justify its usefulness? That's debatable.

To expand on what A_C just said: the very way OXPs work is by overriding standard settings. You start with the stuff in Resources, add oxp 1 to the mix, then add oxp 2, etc, etc.

By the time you're loading oxp 2 it's impossible to tell which bits of the mix actually came from resources and which from oxp1, and if you got 55 - or more - oxps Oolite does this 'mixing' process 55 times, then only uses the resulting mix. The only way you can spot conflicts is if you keep a separate copy of each of the changes in memory at all times, complete with a look up table to say where it's coming from and as you load a new oxp, check it against all previous oxps, to see if there's a conflict somewhere, then write down which oxps are doing what. Highly time consuming and very memory intensive.

In that ideal world scenario someone could write a separate program to do just that, then people could feed it the AddOns directory and go make a cuppa or 3 - or 10 - until it's finished digesting the lot...

Even with that, you still won't be able to tell the whole story. There's a few oxps that do opposite things, on purpose - you'd have to invent an expert system from scratch just to be able to tell the potential for conflict: say one makes it a bit harder to lose your bounty after each jump and another makes it a bit easier, this is normally done by adding a big of code to one of the jump events. Anyone who can come up with an expert system to figure all the possibilities for conflict within Oolite OXPs has got a brilliant future in the field of expert systems and artificial intelligence. I'd go as far as to say they might well be able to achieve singularity !

L, think of the kittens!