Oxp interaction

[spara]

I would like to start a debate, should/could something could be done about interacting oxps. Here's an example:

Thargoid Carrier destroys a Sothis Station. Dock, save, load and Sothis is back. Maybe Sothis should understand that it was destroyed? Maybe core game should note that an oxp station was destroyed and not allow it to be spawned? Maybe there could be an entry in shipdata that would tell how long it takes to repair it?

Another kind of examples can easily be found from all the market changing oxps.

The more oxps there are, harder it gets. For players and oxp makers.

[Diziet Sma]

Very interesting idea.. me likes.

[Svengali]

Yes, that stations are just reappearing is somewhat ... disturbing.
What OXPs can do is to offer something (like a small API). What they can't do (without causing problems) is to force other OXP(er)s to do things in a specific way. I'd stick with the first thought - offer a way. This leaves room for older OXPs and doesn't touch mission related stuff as well. It also leaves room for multiple APIs in the same area.

I'd think if such a mechanism is available a few OXPers will use it immediately. And the remaining OXPs can be ignored safely (because it wouldn't clash). Users may request changes in OXPs as well and over time more OXPs will use your API. A pragmatic way.

[cim]

For any individual pair of OXPs, it's usually straightforward to make them cooperate if both OXP writers work on it. Even possible with more than 2 (e.g. HyperCargo, Illegal Goods Tweak, Ship Storage Helper and New Cargoes are all mutually compatible despite all messing with the player's hold data) with a bit of thought. For the record, I'm always happy to put that thought in with my own OXPs.

However, in some cases they're incompatible by necessity (for example, replacement shipsets) and the player has to be responsible for not installing both.

On the examples you've given...

System population ... this is a tricky one because so many OXPs do it. I've mentioned before that I want to do some work on a new system populator, and my current draft for that would make it a lot easier for OXPs to cooperate on this sort of thing. However, that still relies on all the OXPs being updated to use the new system populator (which there'll not be much urgency to do so since system.addShips, or even the old legacy script ship addition, will still work "fine"). Once we get out of feature freeze I'll tidy up the design doc and post it up.

Markets ... again, some can be made compatible by arrangement, while others can't. I think this is just an area where if two OXPs want to do similar things and be compatible, the OXP writers need to cooperate.

The more oxps there are, harder it gets. For players and oxp makers.

True. Players ... the biggest help would probably be an AddOns manager program, which handled dependencies, conflicts, updates, downloads, etc. The biggest challenge in writing it is not writing the program (though that's not straightforward) but getting OXPs to all conform to a standardised packaging scheme.

For OXP makers I don't think there's a general solution, but if there's an area in which the existing tools for allowing OXPs to work together are inadequate, that would definitely be something to look at.

[spara]

I'd think if such a mechanism is available a few OXPers will use it immediately. And the remaining OXPs can be ignored safely (because it wouldn't clash). Users may request changes in OXPs as well and over time more OXPs will use your API. A pragmatic way.

You mean something like Big Ships oxp is? It could work like a database, where oxp stations could write when they are destroyed. When they are about to spawn, they could check should they or should they not.

For any individual pair of OXPs, it's usually straightforward to make them cooperate if both OXP writers work on it. Even possible with more than 2 (e.g. HyperCargo, Illegal Goods Tweak, Ship Storage Helper and New Cargoes are all mutually compatible despite all messing with the player's hold data) with a bit of thought. For the record, I'm always happy to put that thought in with my own OXPs.

I always _try_ to put some thought in, but there are so many oxp out there already (and more coming) so it's getting harder.

However, in some cases they're incompatible by necessity (for example, replacement shipsets) and the player has to be responsible for not installing both.

Yes. For shipsets, there's a nice agreement. That's a good thing.

Once we get out of feature freeze I'll tidy up the design doc and post it up.

Sound like something to look forward to.

Markets ... again, some can be made compatible by arrangement, while others can't. I think this is just an area where if two OXPs want to do similar things and be compatible, the OXP writers need to cooperate.

The trouble here is that the number of market affecting oxps is growing quite fast. It's really getting hard to keep up.

For OXP makers I don't think there's a general solution, but if there's an area in which the existing tools for allowing OXPs to work together are inadequate, that would definitely be something to look at.

If there was an easy solution, it would probably have been found.

[Svengali]

You mean something like Big Ships oxp is? It could work like a database, where oxp stations could write when they are destroyed. When they are about to spawn, they could check should they or should they not.

Yes, a simple storage mechanism for dates or times with unique IDs. It doesn't even require a database if you leave the spawning to the OXPs itself, only checking against current stored values and it also doesn't need to be updated for every new OXP. Scripting should be simple, requires not much maintenance and reduces your todos in the long term .-)

Depending on your choice for the format (date, time, ID, whatever) it may also be super easy and straightforward to use for OXPs and you can easily implement features like the 'how long it takes to repair it' you've mentioned above.

[Wildeblood]

Some OXPs are very good. Some OXPs are utter crap. Some OXPs are a lot of good work, spoiled by one or two stupid mistakes. Some OXP authors are friendly and helpful. Some OXP authors are complete arseholes. Oolite's developers have made some... incomprehensible... decisions that make things harder than they could be, and have missed some opportunities to improve the situation. The idea that it is all going to just work smoothly is very naive.

Where's the frustration emoticon? There is so much I could write about this subject, but nothing much that wouldn't offend someone or other, so I "can't". At some time you ought to have a discussion about balancing the desire to be the friendliest board this side of Riedquat against the utility of calling stupid mistakes what they are.

(I started to write an essay here, about all the things that ought to be different, but had second thoughts.) [Essay deleted.]

[JensAyton]

Please keep in mind that OXPs are fundamentally a hack, the easiest way to add support for modding without modifying the app, which has since grown organically. I doubt Giles at any point sat down and thought about how best to support 500+ OXPs gracefully. (At the time, he probably didn’t expect more than 20 or so would be made.) I certainly didn’t – at least before I started to think about Oolite 2, and a rewrite spanning several years wasn’t a realistic proposition.

[Eric Walch]

Thargoid Carrier destroys a Sothis Station. Dock, save, load and Sothis is back.

I think this is up to the OXP to deal with it. Look for example at the current [wiki]Pirate_Coves_OXP[/wiki]. When you destroy that station, it will stay away for 20 days before it gets re-spawn in that system.

No, that is a lie. I added that functionallity in version 1.4, some months ago (October 2012), but it seems I never uploaded that version properly.
Although I provided a link to it at that time.

[Wyvern Mommy]

there's no point in a core change to make OXPs behave in a prescribed way. how an OXP behaves is up to the OXP developer, including interaction with other OXPs. there will always be OXPs incompatible one way or another with other OXPs. you can't really expect OXP devs to take into account -every- other OXP, present and future.

if you don't like how an OXP behaves, on it's own or in relation to another, don't install it.

[spara]

you can't really expect OXP devs to take into account -every- other OXP, present and future.

Of course not, but there can be some common agreements and practices. ATM the agreement on replace and addition ship sets is one example and the bigShips oxp is another. I think that this station spawning thing needs a common agreement.

[Commander McLane]

For me, the problem with the specific situation described by spara lies somewhere else.

The specific situation was: a station got destroyed (it could be any other major change to a system as well; it's not really the stations that are at the centre of the issue), the player docks at the main station, saves and quits the game. Later he reloads, launches, and finds the system outside back at its default state (for instance with all the secondary stations intact, including the one that got destroyed before).

The problem is that Oolite doesn't save the current state of the current system when quitting the game. Thus, the previous state isn't restored on reload. Instead the system is created from scratch. The spawning of all entities, disregarding their previous fate, is only one symptom of this issue. For secondary stations that are spawned randomly (as opposed to pseudo-randomly), it can even be worse. They could be there when you save, but not be spawned at all when you reload. Or vice versa. Floating debris fields are gone after a reload. Randomly spawned asteroid fields have changed their position, or disappeared completely, or appeared out of nothing. Depleted police patrols and station defenders are in their full numbers again, but have turned from Vipers into Interceptors or vice versa. Etc, etc.

If we're after complete consistency, then (1) the issue of magically re-constructed stations is only one speck out of many, and (2) we'd need a game solution, not an OXP-based one. Note that many of the issues I mentioned above (like the populator choosing another ship to fill a role) have nothing to do with OXPs, but would happen in the vanilla game as well. The Ooniverse isn't consistent between saves and reloads.

Personally, I think that saving and reloading happens rarely enough that I can live with that inconsistency. The alternative would be to save the complete current state of the system, and re-instate it on startup, thereby overriding the populator and all addShip commands in scripts (to be precise, and because most OXP don't spawn things on startup, the addShip commands on the first launch after a startup would have to be overridden and ignored).

[spara]

@Commander McLane: You are absolutely right about the save/load thing. If we forget the save/load cycle and only look at the Witchspace jumps, then the resurrecting stations are the most notable consistency killer. At least for me.

[Commander McLane]

@Commander McLane: You are absolutely right about the save/load thing. If we forget the save/load cycle and only look at the Witchspace jumps, then the resurrecting stations are the most notable consistency killer. At least for me.

For me it's not so bad with witchspace jumps, because those take time. Usually it will take at least a few days until I jump into a system again. Thus the reappearance of a station isn't so blatant. This is of course different for back-and-forth milkrun trading between two close systems.

[Wildeblood]

That's why I think game saving would be better done at witchspace jumps, rather than while docked at a station. Then there is not the problem of the reloaded game not re-creating the entire system as it was before, and only major changes like the sun going nova or stations being destroyed need to be recorded in the saved file. It also neatly side-steps the issue of one particular station in multi-station systems being the magic game-saving station.