OXP compatibility between stable versions - how much?

[cim]

Please tell me how 2 & 3 would differ for those

Okay - somewhat loosely since, as I said, these are not things I've spent any time planning out how to do them (and under an assumption for this post that we actually want to do all of this, which of course isn't necessarily true)

Hopefully this helps clear up the differences a bit more?

OXP-defined trade goods,

This is covered (very briefly) in the first example in the original post, but to expand on this particularly area. Essentially with option 3 we'd introduce a new commodities plist which allowed definition of the goods, and I think it could all be done in one version (though it and the related stuff would be a major feature for that version on the scale of the new populator/AI). With option 2, we'd introduce that plist in 1.82, run it in parallel at least to 1.84, and then once the old ways of doing things were gone, add the ability to define new goods either in that version or the next one. The tricky thing here is that an OXP station needs to be able to sensibly handle an OXP trade good without either OXP necessarily knowing about the existence of the other - that's really quite difficult (I don't actually know how it would be done at the moment) and I wouldn't want to handle that at the same time as managing compatibility with the current style of station market definition.

OXPable systems/galaxies,

The key thing that's needed for this to work at all is to get away from using the traditional algorithm to generate system data, and instead just hard-code that data into planetinfo.plist including some new properties for system coordinates ... but if you just do that, properties set as "universal" in OXPs are going to get overridden by the core data at the system level.
So, here's the stages to go through for this: (one way, plotted out on the spot, so probably flawed, and I'm skipping over a lot of details to keep it brief)

First, the preparatory work (which also has applications for some of the other suggestions)

1) add a "layer" property to planetinfo.plist, setting all the current core definitions explicitly to layer 0, making the default for OXP planetinfo to layer 1, and the default for changes by JS to some higher layer number. We also introduce a new setProperty method on SystemInfo that lets you specify the layer and pins JS-introduced changes to a particular worldscript.
2) hard-code the existing system data into planetinfo.plist (probably using some sort of helper tool that OXPers could later use to make their own galaxies), including adding some extra properties which are currently determined from the system seed number but aren't yet modifiable through the plist (e.g. sun-planet vector direction). Make SystemInfo objects outside the current galaxy readable by OXPs.
3) make SystemInfo JS objects unwritable to force use of setProperty by OXPs.

...and now we're ready to actually get started.

4) Reformat planetinfo.plist so that the contents of galaxies are separated to one file per plist (planetinfo.plist keeps universal settings, a list of which charts are defined by which plists, and can for legacy purposes still define systems 0..255 in galaxies 0..7). At this stage there's still a limit of 256 systems per galaxy and 8 galaxies, though, but some JS properties to return those limits are introduced.
5) Remove central planetinfo.plist's legacy ability to define systems.
6) Change galaxy/system IDs to be unique strings rather than numbers (so you don't get two OXPs both trying to define system 257 in the same galaxy). Name the core systems and galaxies in such a way that legacy access methods still work. Don't yet allow definition of new galaxy/system IDs.
7) Remove the limitations on systems per galaxy and galaxies per game by allowing new galaxy/system IDs; introduce some keys which define the allowed galactic hyperdrive links between galaxies;

With option 2, I think this would have to be broken down, assuming we started now, into:
1.82: step 1 and I think also step 2 could go in here; if not, it goes into 1.84 instead.
1.84: step 3
1.86: step 4
1.88: steps 5 and 6
1.90: step 7
...and in practice, actually planning features for 1.90 now would be really silly: at our current pace (which is itself a really big assumption!) that's probably a 2022 or 2023 release. We'd go for the preparatory work first, maybe building in some things which would let us do the rest later, and reassess after 1.84 where to go next and whether to try the rest at all - it's still a 3-stage project even then, which is really ambitious (and, notably, doesn't really give much benefit to the 1.86 or 1.88 releases)

With option 3 ... well, in theory it could all be done in one release, though I wouldn't like to try it!
1.82: steps 1 to 3
1.84: steps 4 to 7
would probably be the fastest I'd want to try to approach it, and even then it would need a strong consensus from the community that it was the right thing to do.

weapons adjustments,

So, this covers a range of potential ideas which have been suggested, for example:
- OXP-definable lasers
+ rebalancing the core lasers so that pulse to beam is no longer quite as big a jump
+ adjusting the core game's missile/mine set
+ making the Thargoid weapons more dangerous
- some sort of weapon that stations/capital ships can mount that's actually a reasonable threat to a smaller ship

Removing or significantly changing any existing weapon (+ rather than - bullet) is an option 3 context issue and probably not possible under option 2 - it won't break many OXPs as such, but it will need those with previously balanced-ish fights to be rewritten. (Option 3 for context is what we've effectively been doing recently, remember)

In API terms there's not a lot of difference between options 2 and 3, though - maybe if we decide that an equipment.plist reformatting is needed to do this properly, for example, there's probably the usual "one version for option 3, two versions for option 2" step there.

[Zireael]

Ok, I say option 3 simply because I want OXP-able galaxies ASAP

[Thargoid]

Speaking as the one with arguably the largest catalogue of OXP/Zs to oversee and update, for me I'd come down somewhere between option 2 and option 3, depending quite on how disruptive the specific change may be and how far-reaching it could be.

Going for something like option 3 more would in fact give a good "kick up the iron ass" to actually get things updated and done, but equally if too much is changed at once then it could get overwhelming. Plus any of the more major changes need to be into the nightlies/self-builds as early as possible and stabilised other than tweaking quite quickly so that there is enough time for OXP/Z update to keep up with it and be ready for the stable release. This will also need documentation in place on the wiki and clearly put together with examples of code. An example of that is the new JS AIs, which I'm currently working on getting my head around through the rather good documentation available. Some of it at times could perhaps do with more examples, but the parts already included in trunk are quite followable.

I'm still mulling over the question so there may be more to come as I think about it more deeply, but that's an initial impression of the options from my viewpoint.

[Switeck]

Oolite's changes...

From the point of view of OXP developer fatigue, the changes to maintain their OXPs need to be simple and quick rather than complete rewrites. Or we're going to lose a few OXP writers who have limited time and energy. Mission/campaign OXPs are a pain to create due to game balance just from equipment OXPs the player can have. Oolite changes tend to break these in many ways. They can end up almost hopeless to fix because the author's original intent can get lost due to the changes. Were certain fights meant to be nearly unwinnable and must be avoided or cheesed? (Lack a McGuffin = guaranteed loss!) Or are these missions just pre-v1.80 that expected dumb NPCs?

For me, even converting to OXZ format is annoying because I have to include information/details that I haven't even considered when creating the OXPs in the first place.
(exact filesize, website hosting exact file locations and maintenance, category/type of add-on, game balance player vs NPC vs universe, etc.)
I feel like I'll need to redo the OXZs later to fill in all the missing blanks even if Oolite remains static.

[cim]

(exact filesize, website hosting exact file locations and maintenance, category/type of add-on, game balance player vs NPC vs universe, etc.)

All of those are optional. The first three are needed (well, ish, Oolite won't care if you're a few k out on the file size - it's just to give people an idea of small/large/huge before starting a download) for addition to the OXZ manager, but you can install them manually by downloading to AddOns same as you would an OXP without needing those fields or static-url hosting.

(The balance indicators are both optional and not part of the OXZ standard)

[Norby]

1.82: steps 1 to 3
1.84: steps 4 to 7

Ok, now I see that the 3. way is the fastest, so go for it.

[Diziet Sma]

They can end up almost hopeless to fix because the author's original intent can get lost due to the changes. Were certain fights meant to be nearly unwinnable and must be avoided or cheesed? (Lack a McGuffin = guaranteed loss!) Or are these missions just pre-v1.80 that expected dumb NPCs?

Well, that largely comes down to poorly commented code.. the simple fact is, 6-12 months later, you won't remember just why you wrote something a particular way, unless you leave yourself notes in the code. There are a number of shining examples of well-commented OXPs, that would be a joy for anyone to maintain, let alone the original author.. but others.. well..

[Wildeblood]

They can end up almost hopeless to fix because the author's original intent can get lost due to the changes. Were certain fights meant to be nearly unwinnable and must be avoided or cheesed? (Lack a McGuffin = guaranteed loss!) Or are these missions just pre-v1.80 that expected dumb NPCs?

Well, that largely comes down to poorly commented code.. the simple fact is, 6-12 months later, you won't remember just why you wrote something a particular way, unless you leave yourself notes in the code. There are a number of shining examples of well-commented OXPs, that would be a joy for anyone to maintain, let alone the original author.. but others.. well..

Yup. Documentation where it matters, in the code. A line of comment above every function that says what the author thinks that function does. It's hard to see if something is doing what it was intended to do, if you don't remember what the intention was.

But once away from the JS into things like shipdata it's harder to do. We can't reasonably expect comments like "Give this ship energy recharge rate x so it can beat ship x in a fight" with every property in a shipdata file.

[Diziet Sma]

But once away from the JS into things like shipdata it's harder to do. We can't reasonably expect comments like "Give this ship energy recharge rate x so it can beat ship x in a fight" with every property in a shipdata file.

True.. but a brief comment in the header of each ship's entry would often suffice.