Summary: how much OXP breaking is acceptable between stable versions? "None" is a possible answer, but isn't - despite the consistent API - what the current policy provides.
Current policy
The current "stable version" policy is basically that any OXP API which was in a previous 1.xx stable version should also be in all future 1.xx stable versions. I've been thinking about this and the 1.80 release, while trying to put together a list of features to work on for 1.82.
With very few exceptions, any OXP which worked in 1.65 still has the APIs available eight years later to work in 1.80. It's quite unlikely, however, that many OXPs not updated since 1.65 would still fit in with the rest of the game and OXP set.
While the APIs might stay the same, the overall context does change - 1.80 made changes to how the core works which mean that for best performance (or in some cases even functional compatibility with new core features) the following categories of OXPs need updating:
- ships
- ship sets
- stations
- HUDs
- sound sets
This is potentially quite a mess, I think. On the other hand, the specific restriction on API changes means that introducing certain new features - even if they'd only break the API used by a couple of OXPs - is either impossible or involves having two different ways to do things available and OXPs very slowly migrating to the better one. Some of those alternative ways take up quite a bit of space in the code, are easily broken, or make the game code inefficient.
Options
So ... there are a few options for how to go forward here, and it makes quite a big difference which is chosen for what sorts of features are planned for 1.82 (and what preparation needs to be in 1.82 to put in frameworks that might become features in 1.84, for that matter)
- Prioritise OXP compatibility. No changes to what's offered to OXPs. Someone playing without OXPs won't notice much difference between 1.80 and 1.82
- Planned removal of deprecated features. Some older interfaces will be removed, and OXPs using them will no longer work. So if we do this for 1.82, you'd be notified now (at the start of the journey to 1.82) which ones are going, and have the entire 1.81 process to update and test OXPs to use the newer interfaces - which can be done without using a nightly build. Only those which have a more modern equivalent will be removed. For APIs which are used by a very large number of OXPs we might even start announcing possible 1.84 removals now.
- Planned change. As well as removal of deprecated features, interfaces will occasionally change to allow new features to be implemented. This would mean that even some OXPs written using the latest 1.80 features will need rewriting for 1.82 - again, this will be announced now and the new features will be put into nightlies as soon as possible, so you'll have, on current form, 12-24 months to (adopt and) rewrite any OXPs which should be kept going, though you'll need to use the nightly builds to test the features.
Implications
If we go for option 1, you get a very stable OXPing platform for the foreseeable future - but most new features will need to be added by OXP, with sometimes some help in the core game to add optional hooks for those features to hang from.
If we go for option 3, you can get a lot of new core game features, and some big new OXP capabilities - I have a long list of major features which people have requested at various times on the forum, most of which are impractical to do properly without a few breaks here and there to OXP interfaces - but the catch, of course, is that the community has to do a lot more work to keep OXPs from previous Oolite versions running, and there might have to be some hard choices made over which ones we have time to keep alive.
Option 2 is in-between. Most of the possible features are implementable with option 2 - but rather than being implemented in a single release, they might take two releases (anything that had to take three - unless the intermediate steps were worthwhile in their own right - would probably not happen at all). The slower implementation gives quite a bit more time to update OXPs, though.
Note that this is about the maximum amount of incompatibility the community considers acceptable. If you want option 3, that doesn't make it the default for every change or even most of them - it just makes it a possibility. Whether to go with that fast approach, or try to introduce features in a multi-stage way (option 2) or even to only introduce those parts of the feature which fit with existing OXPs (option 1) still needs to be decided on a feature-by-feature basis as part of discussing the details.
Examples
Here's an example of a few ideas from the big list of previous requests, and how - if it was selected - they might happen under each option:
Requested feature list wrote:Improve the commodities market so that all of the goods are more useful, trading is more interesting, secondary station markets are easier to balance, new commodities can be defined easily, andcommodities.plistis easier to read.
- Mostly not possible. Changes to the market prices, quantities, etc. will affect existing OXPs which expect the previous commodities data. It should be possible to add a new format for commodities.plist keys for secondary station pricing, though.
- 1.82 introduces a new property on stations to set their market prices and quantities in the new way, which overrides the 'market' property. New
trade-goods.plistintroduced but not used for core game prices, to keep older OXPs working as before.
1.84 removescommodities.plistandmarketproperty for stations, sets new prices in core gametrade-goods.plist. Ability to add new commodities enabled. OXPers have between 1.82 and 1.84 to update stations. - 1.82 introduces new
trade-goods.plistwith new market data and new shipdata property for configuring station markets. Ignorecommodities.plistand old market properties on stations, using some sensible defaults for existing stations. OXPers should be able to update OXPs to work for both 1.80 and 1.82 before 1.82 is released.
Here's an example of one which isn't really practical except with option 3.
Requested feature list wrote:Have multiple witchpoints, one for each connected system.
- Clearly not possible to do this if all existing OXP behaviour is to be preserved.
- Also not practical - the version which adds the new witchpoints is going to break OXPs which expect the player to arrive at a specific location, and it's not possible to have a version which both has one witchpoint and multiple witchpoints in the same system. There might be some multi-stage process which could cope with it, but I'm not sure what. All the solutions I can think of break something.
- Implement this, somehow. I haven't given much thought to the details, but it would probably make sense to position the sun at the origin rather than one of the witchpoints, and then rethink a little how spacelanes are defined. It might still take a couple of versions even then - one to add a set of witchpoints not at the origin, and let OXPs adapt to that, and then one to move the first witchpoint away from the origin so the sun can go there.
What next?
So, which option do you think? If you pick 2 or 3, it might also be worth mentioning if you have any personal thresholds for it - e.g. "option 3, but only if fewer than ten OXPs use the feature being changed" or "option 2, but only for Javascript, not plist keys".
(Feel free to suggest options which aren't listed above, too)
![[EliteWiki]](/images/elitewikismall.png){kind=small}
New Cargoes
