Oolite Bulletins

This is a snip from a thread in expansions. It's about something that should be considered and some sort of common agreement might be needed.

Smivs wrote:

Svengali wrote:

There's another showstopper - if I can't control my own settings and code runtimes anymore (OXPs are uncalled changing accuracy, energy, equipment, etc... or inject code) or entities are simply removed by other OXPs my motivation is nearly not existing anymore. We need solutions, otherwise it gets more and more pointless to write any mission related stuff.

Sorry for the thread derailment, but this is a very good point that is worth considering. I fell victim to this (twice!) with Xeptatl's Sword, which needed bugfixes to overcome problems caused by other OXPs. Specifically in my case an OXP which added a TL12 station to a TL9 system thus making equipment available that shouldn't have been available there, and another which caused a main station to be removed permanently (as in for ever, even after 'years' of travelling right round all eight galaxies). Both of these 'broke' the mission quite badly.
This is important as I think the future of OXPs probably depends more and more on mission OXPs. There are already more 'ship' OXPs than we really need, and with the promise of better 'default' models and graphics for the game, replacement texture sets etc are going to become less important. So the future probably lies more with ambience and mission OXPs.
I hope that all authors will be ever more vigilant when designing their future releases, and will keep in mind how disruptive a badly thought through (or not thought about at all!) feature could be to the work of others.

I feel that this is a mission impossible. The power of given to the oxp writers is so strong, that these conflicts just keep on coming. I'm responsible some clashes too, but none of those have been deliberate. There just are too many oxps to consider. A simple list for oxp writers of what kind of things should be avoided in scripting might be in order. These might look obvious to some, but I believe not all. List could go like this:

When creating oxps, try to avoid:

* Removing entities created by other oxps
* Tweaking entities created by other oxps
* Overwriting scripts created by other oxps
* Overwriting ship_scripts created by other oxps
* Writing mission data of other oxps
...

Then there are those cases where things are changed drastically. For example changing govType would be a change like that. These I think should be tagged with a clear warning sign that other oxps will break and should be used cautiously.

I mean this to be an opening for a discussion rather than me saying how things should be. Please consider ideas above as examples rather than propositions.

Ha, yes, mission impossible is right! I was just hoping to keep the thought alive that it is horribly easy for one OXP to mess with another, and that where possible this should be considered. I'm sure we're all guilty of a bit of carelessness sometimes, and of course some OXPs (I'm thinking of my ToughGuys here ) will always impact missions etc which rely on 'core' ships to play some part.
It's not a problem with a solution. Mitigation is the best approach, which is why all us OXPers should perhaps be asking ourselves "Could this break something else?" more often.

Smivs wrote:

Mitigation is the best approach, which is why all us OXPers should perhaps be asking ourselves "Could this break something else?" more often.

And the answer to this in most cases is: Yes.

Thanks for starting this thread off, spara.

On the specific points raised, 1.79/1.80 will include some helpful features for cooperative OXPers.

• The ship.autoWeapons parameter is basically a "does the game have permission to modify this ship's capabilities by script" flag. It defaults to false if not set; well-behaved modification OXPs should only change ships where it's true, and the core Oolite code does likewise. Skilled NPCs will have a re-release to take advantage of that; I'd strongly encourage authors of similar OXPs to do the same once it's available.
• The new system populator lets an OXP override elements of standard population, but it also lets OXPs override what population function is used for a system - perhaps to one under their sole control. So if you need to make sure no other well-behaved OXPs are also modifying a system crucial to a mission, you will be able to do so relatively easily, eventually.

If there are other types of conflict which could be avoided with better tools, I'd like to implement those tools as well.


While it's true that it's very easy for OXPs to change things in a way that other OXPs are relying on, I think it goes further than that: mission OXPs to a greater or lesser extent need a stable baseline environment. Even without adding other OXPs, we don't provide that. For a few examples:

• NPC AI and capability varies between core versions of the game, sometimes more subtly than others
• the core Nova mission can take out any Chart 4 system
• the difference in power between a ship with a cloak and a ship without is huge, if the player feels so inclined.
• the equipment of the player varies in availability and power
• even small bugfixes can make a difference to the game environment

There are quite a few OXP missions which play somewhat differently in 1.77 than in 1.76, even without any other OXPs added. If you desperately want very particular NPC behaviour you can now write it yourself with performScriptedAI, but you really have to be comfortable with vector maths and other low-level behaviour at a much more detailed level than normal.


The Nova mission is perhaps a good example. I think it's an excellent mission - by far my favourite of the ones in the core game. Very simply done, very short, perhaps one weakness in that it's a little contrived in how it makes the player interact with the situation, but (and speaking just about my personal reactions to it, here):

• The player just stumbles into it. We know from a meta-game perspective this isn't true, but they could easily have taken a different jump and only heard about it in the news a few days later, or seen fleets of refugee ships heading in-system on a nearby spacelane, or they could have been in a different chart at the time.
• As a result of that, there's no gamey "reward". 100g gemstones is a reward, but probably doesn't compensate for the value of the lost cargo. The player shouldn't care about that detail, of course.
• It was - at least for me - one of the few genuinely scary moments I've seen in a computer game. By the time you get that far, assuming you're not trying to set some record for traversing the Eight, you'll have an iron-ass, you'll probably have a Dangerous if not Deadly combat rating, and even an Anarchy spacelane after a 6.8 jump doesn't present a massive challenge. And then there's a flash of light, a sphere of plasma expanding towards you, your hull temperature rising at a rate you've never seen before, and the countdown of the galactic drive feeling very slow.
• Once you've survived the immediate aftermath, you never quite escape. I still jump on entering certain systems, where the relative positions of objects mean that the sun is right in front of you, burning brightly ... and the planet is a bit off to the side, and of course in shadow, so it takes you a while to see it's there and you haven't just jumped into another nova, too late.
• That of course is the worst of it: the Cooperative is huge, stable ... and inescapable. That one of its stars might suddenly flare up and demolish a system is unthinkable. But suddenly, it happens - and at very short notice: you might have successfully - and by sheer luck - completed the evacuation of the station, but there's no way more than a tiny fraction of the planet's billions of inhabitants were evacuated in the days - or perhaps only hours - there was to prepare. It's a tragedy in itself - but could it happen again? Are all of the Cooperative's remaining 2047 systems doomed to the same fate? It suddenly makes a volume of space that seemed so large you might not ever visit all of it feel uncomfortably claustrophobic.

Of course, from an OXP/compatibility point of view, it's a terrible mission. It can take out a random system in Chart 4 - might be a relatively unimportant one from a meta-game perspective, might be somewhere like Isma or Bien or Soenisti which drastically changes the topology if you can't jump through it, might be anywhere. It makes it impossible to reliably set a mission in that chart that relies on a particular system existing or being reachable. If it wasn't in the core game it would probably be one of the most complained about OXPs by other writers (there are anyway plenty of suggestions in the forum archives to specify which system it happens in).

So there's a fundamental problem: a "well-behaved" mission OXP would leave everything as they found it afterwards - but that limits the scope of the stories you can tell to those where nothing major was at stake in the first place, which is not, I think, a limitation suited to mission OXPs in general. Indeed, that second Xeptatl's Sword incompatibility, assuming it's the one I think it is, was the result of the player having earlier failed a different OXP mission with localised but real consequences.


So perhaps the question to ask is: can mission OXPs be made resilient to changes to other bits of the game? What tools could the core game provide to make that resilience easier to write?

cim wrote:

So perhaps the question to ask is: can mission OXPs be made resilient to changes to other bits of the game? What tools could the core game provide to make that resilience easier to write?

Faster access to System.infoForSystem() and a handler to notify OXPs about changes to system settings (name, government, etc.) would be a good start .-)

Svengali wrote:

cim wrote:

So perhaps the question to ask is: can mission OXPs be made resilient to changes to other bits of the game? What tools could the core game provide to make that resilience easier to write?

Faster access to System.infoForSystem() and a handler to notify OXPs about changes to system settings (name, government, etc.) would be a good start .-)

One of the internal caches in 1.79 for system info is now galaxy-level rather than system-level (to make the '?' highlighter run in reasonable time), so you should be able to do System.infoForSystem() and related calls much quicker than before. On my computer reading System.infoForSystem().government for all 256 systems takes 50-80ms in master (at least, once the data has been cached once it does) and 140ms in 1.77.1, so there's a definite improvement there.

The handler is tricky: it's easy to add a handler on events like someone doing systeminfo.property = value and other routes to the same effect, but system settings have the interesting property of being able to change while the game isn't even running, and to guard against that would mean dumping the full system info for all eight charts into the savefile, and then running a diff during initial startup. Maybe it's not necessary, since you can set any value you particularly care about by script, and then planetinfo.plist changes won't touch it?

Great news. For me it would be enough if the handler fires for scripted changes only.
Is it cached already when .startUp() and .playerEnteredNewGalaxy() is fired?

Svengali wrote:

Great news. For me it would be enough if the handler fires for scripted changes only.
Is it cached already when .startUp() and .playerEnteredNewGalaxy() is fired?

Partially but probably not entirely. Neither handler is particularly time-critical, though.

1.79 will include systemInformationChanged(galaxy,system,key,newValue). For safety, you can't do system.info.(property) = value inside that event handler.

The tips about OXP conflicts could be added to Wiki, methinks.