List of Planets used in OXPs

[Smivs]

Thinking about it the wiki page that Smivs has started could benefit from, when near complete, a list of impacting OXPs for reason of clashing Planetary System changes. There would be different levels of impact such as:

1) Minor - Changes to systems in OXP A are updated in OXP B.
2) Medium - Changes to systems in OXP A are not updated in OXP B but does not stop either OXP from working.
3) Major - OXP A is not compatible with OXP B.

The point of the list though is to give authors the ability to avoid clashes altogether.
I was developing an OXP which will place a few entities in specific locations around the Eight. I was very keen that my OXP did not affect any others, and vice-versa. After many hours picking through two or three other OXPs which I knew made similar changes, it became clear that the task of avoiding clashes would be enormous and very time consuming. It struck me that the only realistic way authors could make these checks is if a table of all the planets affected by OXPs existed. The rest, as they say, is history.
It is worth noting that currently there do not seem to be any significant clashes. This is no doubt in part due to others checking as best they could like I did, but also blind luck and the huge planet pool must have played a part in this.
Hopefully, with the aid of the list, this 'ideal' situation can now be preserved.

[PhantorGorth]

The point of the list though is to give authors the ability to avoid clashes altogether.
I was developing an OXP which will place a few entities in specific locations around the Eight. I was very keen that my OXP did not affect any others, and vice-versa. After many hours picking through two or three other OXPs which I knew made similar changes, it became clear that the task of avoiding clashes would be enormous and very time consuming. It struck me that the only realistic way authors could make these checks is if a table of all the planets affected by OXPs existed. The rest, as they say, is history.
It is worth noting that currently there do not seem to be any significant clashes. This is no doubt in part due to others checking as best they could like I did, but also blind luck and the huge planet pool must have played a part in this.
Hopefully, with the aid of the list, this 'ideal' situation can now be preserved.

I am not going against that aim at all. Though eventually it will become harder and harder to avoid clashes. Your Xepatl's Sword OXP involves to going to many different systems. Say someone writes an OXP that randomly destroys one of those worlds or makes it a Thargoid hive system. Then (I assume) your mission may no longer work. Maybe the developer could write they OXP to exclude your systems (amongst others) until your mission is complete. But what about players who installs your OXP after that world is altered? Clashes are less likely as long as developers never do anything drastic which is limiting or as long as very few system altering OXPs exist. This is not a sustainable situation.

The only way out of this is for all mission OXPs to check if anything has changed that stops their mission from working and disabling their mission in that save game. Not an easy task.

That aside, listing incompatibilities will let the appropriate developer the know that their OXP could do with altering if possible.

[Smivs]

I am not going against that aim at all. Though eventually it will become harder and harder to avoid clashes. Your Xepatl's Sword OXP involves to going to many different systems. Say someone writes an OXP that randomly destroys one of those worlds or makes it a Thargoid hive system. Then (I assume) your mission may no longer work. Maybe the developer could write they OXP to exclude your systems (amongst others) until your mission is complete. But what about players who installs your OXP after that world is altered? Clashes are less likely as long as developers never do anything drastic which is limiting or as long as very few system altering OXPs exist. This is not a sustainable situation.

The only way out of this is for all mission OXPs to check if anything has changed that stops their mission from working and disabling their mission in that save game. Not an easy task.

That aside, listing incompatibilities will let the appropriate developer the know that their OXP could do with altering if possible.

Well my hope is that common sense will prevail, and that with the aid of the list authors can be active in not affecting the work of others.
The fact is in most cases OXPs can 'share' planets quite happily. As you point out Xeptatl's Sword does involve visiting a lot of planets (perhap I was a bit greedy using so many ), but that's all that happens...they get visited. So it would be nice if they don't get destroyed. But there is no reason at all why other OXPs shouldn't also involve visiting them, or even making some small, subtle changes to them. By using the list they will know that the planet is also used by others and could then take this into account when deciding how to use it.
The real problems would arise if, for example, two OXPs both over-rode some details using perhaps a planetinfo.plist. In this situation only one would be applied, thus breaking the other OXP. And this is the real value of the list. If an author wanted to say add an entity to a system and change it's description by planetinfo.plist, he could check on the list. If the planet had already been used and altered with a planetinfo.plist, then the author would be in no doubt that if he went ahead and altered the same planet his OXP would either not work or would break somebody elses OXP.
And if somebody really needed to destroy a planet for their OXP, again they could check the list. If their 'target' planet was not listed that would suggest that it is OK to go ahead and destroy that planet. They could then add the planet to the list as altered by script or planetinfo and thereafter others would know that the planet may not be suitable for use in a future OXP.

[Pleb]

I am not going against that aim at all. Though eventually it will become harder and harder to avoid clashes. Your Xepatl's Sword OXP involves to going to many different systems. Say someone writes an OXP that randomly destroys one of those worlds or makes it a Thargoid hive system. Then (I assume) your mission may no longer work. Maybe the developer could write they OXP to exclude your systems (amongst others) until your mission is complete. But what about players who installs your OXP after that world is altered? Clashes are less likely as long as developers never do anything drastic which is limiting or as long as very few system altering OXPs exist. This is not a sustainable situation.

I have to agree that it shouldn't become the case where we have to restrict what an OXP can and can't do. Agreed not all OXPs are going to be accepted or liked by all, but people are still free to do what they like with their own OXP. For example, I am planning an OXP that will make a few systems in Galaxy 8 go Nova, which is why I wanted this list so that I know which planets are safe to do so. If the player manages to complete the OXP successfully the systems will go back to normal eventually but if they fail a number of systems will fall forever. I understand some people would object to that, but surely thats my right as an OXP writer to take? I had originally intended it to scan for other known OXPs in Galaxy 8 and wait till they were completed but as PhantorGorth pointed out if they are installed after and the player has failed it kind of messes it all up...

[Smivs]

I see a lot more planets have now been added to the list and I am very grateful for this. Thanks go to everybody who is contributing to this.

Just one gripe though. The Galaxy lists are supposed to be alphabetical.
This is mainly to make them easy to use - if the planet you want to check starts with 'A' it will be at the start of the list, if it starts with 'Z' it will be at the end etc.
Also by keeping them alphabetical it will be easy to see planets which are already 'shared', which is useful in all sorts of ways.
For example I've just had a quick scan at the G2 list and seen at least one problem-waiting-to-happen.
The planet Soorte (1 42) appears to be used by Ionics and Famous Planets and both alter it with a planetinfo.plist. This means one of these OXPs is going to be over-ridden or broken.
There may well be others, and this will be far easier to detect if the lists are kept alphabetical.

On the subject of Famous Planets, there do seem to be lot of entries for this OXP, all of which are using planetinfo.plists. I'm not here to judge what makes a planet 'Famous', but I can't believe there are really more than maybe a dozen which are genuinely Famous in the sense that nearly everybody has heard of them.
I also hope that it is recognised that by applying planetinfo.plists to so many planets these planets are effectively being denied to other OXP authors, which seems a bit unfair.

[another_commander]

The discussion is interesting and I was expecting it to take place earlier than just now. I think that what we are facing here is inevitable: clash of expansions on a game with Oolite's expandability. Sooner or later it will have to happen, as the OXP population increases and people come up with more and more bold and ambitious ideas.

You know what I believe? Yes, of course the OXPers need to tread carefully and consider what their changes will do to other people's expansion packs and that's not only correct, but it's also good manners. But, in my opinion, there is one other class of people who have the ultimate responsibility for what's happening: Players.

It's the player who decides that OXP A goes in their game and OXP B doesn't. I think it would be a good idea for players to get out of the "I'll just throw whatever I find inside AddOns, it's quicker this way" mentality and start reading the ReadMe files. In a well designed and documented OXP, changes to the game's behaviour resulting from using said OXP, together with potential conflicts, would be written in the documentation and a player who takes the time to read the documentation would not have to waste time later by inserting in their game an OXP that is known to interact badly with another OXP or even with the core game itself.

With OXPs changing planets, HUDs, bounties, ship stats etc, there is really precious little that can be done to avoid clashes. The final word is up to the players and if they do their part I think it will result in a lot less maintenance work for everyone.

My 2Cr.

[Cody]

... there is one other class of people who have the ultimate responsibility for what's happening: Players.

Speaking as one of the so-called other class... yep!

[Smivs]

Further to my post above, as well as trying to keep the lists alphabetical, can we also try to maintain the correct layout in terms of the number of columns, please. Just leave a column blank/empty if it does not apply to your OXP.

It's starting to look a bit of a mess already

[Cody]

... trying to keep the lists alphabetical

<is puzzled> I just sort the lists for that - is that not enough?

[Smivs]

... trying to keep the lists alphabetical

<is puzzled> I just sort the lists for that - is that not enough?

Smivs hadn't noticed that the lists had been made sortable Thanks whoever did that but can they not default to alphabetical anyway as that is going to be most useful, specially for those who don't know (or didn't notice ) that they are sortable.

[Fatleaf]

Smivs hadn't noticed that the lists had been made sortable Thanks whoever did that

Points to Cim! It woz im

[cim]

Regarding tidyness, I can easily write a text processor to one-off clean up the table markup - alphabetise, fix columns, etc., but I'll wait a few weeks for the page to settle down first. In the meantime, yes, the tables are now sortable in case someone needs to check right now.

On the subject of Famous Planets, there do seem to be lot of entries for this OXP, all of which are using planetinfo.plists. I'm not here to judge what makes a planet 'Famous', but I can't believe there are really more than maybe a dozen which are genuinely Famous in the sense that nearly everybody has heard of them.
I also hope that it is recognised that by applying planetinfo.plists to so many planets these planets are effectively being denied to other OXP authors, which seems a bit unfair.

Actually, thinking about it, I'm not sure Famous Planets belongs in that list at all. It makes no {1} non-cosmetic changes to systems (see also System Redux, Povray Planets, etc.). A mission OXP can safely override its provided descriptions without breaking Famous Planets, just as it can give a planet a specific texture without breaking System Redux. You wouldn't want to install Famous Planets at the same time as (the hypothetical) Descriptions Redux OXP, but there's not otherwise an important conflict.

Conversely "Commies", or "Anarchies", for instance, make noticeable changes to over 300 systems ... and this is the first mention they get in this thread. The Anarchies Sentinel/Renegade stations certainly have potential to interfere with other OXPs, though - to take a random example. The page could probably do with a section on "OXPs which make changes to system by pattern", rather than listing every communist system separately as "scripted change by Commies", listing every system with a Constore, etc.

My opinion on good practice:
"cosmetic" changes should be made through planetinfo.plist. If two try to change the same thing, only one wins, but they're only cosmetic so it's not a big deal.
"mission" changes should be made through system.info or other scripting support. If OXPs wish to "mission" change the same system, the OXP written second can use the list page to find out about the first one, and the OXP writer can use the scripting capabilities to resolve the issue as many OXPs now do to interact with the built-in Nova mission (depending on how they want to resolve it, it would often be polite to talk this through with the writer of the first OXP, of course).

One OXP may make changes of both types, of course. For example, my Rescue Stations OXP makes cosmetic changes to two planetinfos. If another OXP overrides those for mission purposes, there are basically no consequences, and I don't care. Rescue Stations also adds a new dockable object to around 256 systems for mission purposes. Removing these can interfere with Rescue Stations missions. On the other hand, keeping them might interfere with another OXP's mission. So in that conflict I would hope the writer of the other OXP would talk to me and we could work something out between the OXPs to manage the conflict. Only in the worst case would the OXPs have to be declared incompatible.

A lot of OXPs are using planetinfo to make "mission" changes at the moment, which isn't ideal, but is manageable.

{1} Well, okay, Sori in the current version. Ignoring that one...

[Smivs]

My opinion on good practice:
"cosmetic" changes should be made through planetinfo.plist. If two try to change the same thing, only one wins, but they're only cosmetic so it's not a big deal.
"mission" changes should be made through system.info or other scripting support. If OXPs wish to "mission" change the same system, the OXP written second can use the list page to find out about the first one, and the OXP writer can use the scripting capabilities to resolve the issue as many OXPs now do to interact with the built-in Nova mission (depending on how they want to resolve it, it would often be polite to talk this through with the writer of the first OXP, of course).

What about situations which are a bit more than 'cosmetic', but less than 'mission', such as where entities are added as well?
My WIP actually works the same way as Galactic Navy - It adds an entity to the system and adds mention of the entity to the planet decription, just like the Sec-Com stations in GN. Both OXPs do this via the planetinfo.plist. using 'script_actions' to add the entity
Therefore another OXP also using a planetinfo.plist for the 'target' planet could break this.
In a sense neither my WIP nor Galactic Navy are 'mission' by this definition but clearly go beyond 'disposable cosmetics'. The point is they could be broken and I don't think we should trivialise this. I wouldn't want them over-ridden - to me that would be a big deal!

[cim]

What about situations which are a bit more than 'cosmetic', but less than 'mission', such as where entities are added as well?

Hmm, okay, that wasn't quite clear of me. Replace "cosmetic"/"mission" with "cosmetic"/"functional", then, which is closer to what I actually meant.

Those changes and the GalNavy changes would be "functional", and should I think be managed through Javascript so that if there is a conflict with another OXP something can be done about it by either your OXP or the other OXP in a mutually acceptable fashion.

Adding an entity other than a planet or moon is always "functional", in my opinion. It may not be the sort of "functional" that people need to work around very often, depending on where it's added, but you never know what might happen.

For an example: ITHA Escort Contracts can go very badly wrong very quickly if they go near a Renegade Station from Anarchies OXP. This particular case is the player's responsibility to manage (and there are a variety of ways to do so). But if you were writing a one-off escort mission through an Anarchy system, as part of a mission OXP, then this could potentially be a much more serious conflict (to which there are numerous possible solutions to keep the OXPs compatible, of course).

As for script_actions, that and other legacy scripting functionality really shouldn't be used at all in new OXPs, if at all possible. (If it's not possible to avoid it, that implies a hole in JS functionality, which needs fixing)

[Smivs]

What about situations which are a bit more than 'cosmetic', but less than 'mission', such as where entities are added as well?

Hmm, okay, that wasn't quite clear of me. Replace "cosmetic"/"mission" with "cosmetic"/"functional", then, which is closer to what I actually meant.

Those changes and the GalNavy changes would be "functional", and should I think be managed through Javascript so that if there is a conflict with another OXP something can be done about it by either your OXP or the other OXP in a mutually acceptable fashion.

Adding an entity other than a planet or moon is always "functional", in my opinion.

As for script_actions, that and other legacy scripting functionality really shouldn't be used at all in new OXPs, if at all possible. (If it's not possible to avoid it, that implies a hole in JS functionality, which needs fixing)

I had a bad feeling you'd say that
<Goes off to start a complete re-write of his WIP...>