Re: Death Comms OXP
Posted: Wed Sep 09, 2015 4:59 pm
It's worth saying I think that compared with a lot of game addon architectures, the OXP architecture as designed by Giles is already very good at avoiding conflicts compared with a lot of other games
- you can save your game, add, remove and upgrade lots of OXPs, load your game, and have it work
- you can do this repeatedly, while incrementally upgrading the core game, for years
- as a player you basically never have to care about load order; as an OXP developer, rarely
It's also worth noting that a lot of types of OXP conflicts are inevitable due to resource conflicts - a planet can only have one diffuse map, a ship can only have one AI - or due to conceptual conflicts - OXP A removes all stations from a system; OXP B expects the player to dock there.
In this particular case, I would recommend that Death Comms checks the
The exceptions are the ship script and the ship AI script.
The AI script should only be listening for events so that it can execute its AI code, so it shouldn't need multiple listeners for one event - you can replace the entire script, of course, if you want it to listen to different events and do different things with them.
The ship script so far hasn't been worth writing exceptions for because it's very rare in practice that an OXP writes to the ship script of a ship it doesn't own - but also, it's the area for which technical and conceptual conflicts are most likely to occur, so just allowing a slightly nicer way for two OXPs to define independent handlers for the same event on the same ship isn't going to solve any of the underlying issues. There are ways to implement Death Comms, for example, which don't involve editing the ship script at all (they're more complicated and slower, but it could be done) and they'd still have the same issue of "what if that ship's owning OXP already defines a death message for it?".
There is also a compatibility issue: with very limited exceptions we try to ensure that any OXP which worked in stable version X will also work in stable version X+1 - rewriting how event handlers are applied to ship scripts would break a lot more OXPs than I would be willing to do without a very strong case for its necessity.
- you can save your game, add, remove and upgrade lots of OXPs, load your game, and have it work
- you can do this repeatedly, while incrementally upgrading the core game, for years
- as a player you basically never have to care about load order; as an OXP developer, rarely
It's also worth noting that a lot of types of OXP conflicts are inevitable due to resource conflicts - a planet can only have one diffuse map, a ship can only have one AI - or due to conceptual conflicts - OXP A removes all stations from a system; OXP B expects the player to dock there.
In this particular case, I would recommend that Death Comms checks the
ship.autoWeapons setting as a general "permission granted to apply global effects to this ship" flag.Essentially for almost all cases this is already available - most script types are defined such that every OXP can set up multiple scripts which are independent of each other and of scripts in other OXPs, and add event handlers to each. (World scripts are the main type which actually uses this feature)popsch wrote:but why not internalize this in Oolite by registering and de-registering listeners for events?
The exceptions are the ship script and the ship AI script.
The AI script should only be listening for events so that it can execute its AI code, so it shouldn't need multiple listeners for one event - you can replace the entire script, of course, if you want it to listen to different events and do different things with them.
The ship script so far hasn't been worth writing exceptions for because it's very rare in practice that an OXP writes to the ship script of a ship it doesn't own - but also, it's the area for which technical and conceptual conflicts are most likely to occur, so just allowing a slightly nicer way for two OXPs to define independent handlers for the same event on the same ship isn't going to solve any of the underlying issues. There are ways to implement Death Comms, for example, which don't involve editing the ship script at all (they're more complicated and slower, but it could be done) and they'd still have the same issue of "what if that ship's owning OXP already defines a death message for it?".
There is also a compatibility issue: with very limited exceptions we try to ensure that any OXP which worked in stable version X will also work in stable version X+1 - rewriting how event handlers are applied to ship scripts would break a lot more OXPs than I would be willing to do without a very strong case for its necessity.
![[EliteWiki]](/images/elitewikismall.png){kind=small}
Death Comms