There is often discussion regarding how to run several replacement ship sets simultaneously, most recently here on Griff's thread.
The problems revolve around how to get several sets all working together, as many override the core ships, some override each other and some have their own on-board shipdata_overrides.plists.
Unless I've missed any the sets in question are:-
Deepspace Ships
Griff's ships (which are probably OK anyway)
Neolite Ships
Shady Sungs
Smivs' Shipset
I would like to suggest a solution.
Is there a case for a generic shipdata_overrides.plist (based on Griff's which as I understand it simply nullifies the default ships) which works in a similar way to 'Big Ships'... in other words is valid for all the ship sets. If the authors of the various ship sets then uniquely name their own sets, users could install any or all of the ship sets they want, which would naturally work together, and use the generic shipdata_overrides.plist if they wanted to disable the default textures. This generic plist would also allow any one of the ship sets to be used in isolation, without the default ships showing.
I accept that this will be slightly more complicated for some users (for example someone wanting to only use only one of the ship sets would also need to install the generic shipdata_overrides.plist), but the plus is that it would be simplicity itself to use some or all of the ship sets simultaneously.
This is not a unique situation in any case. I've mentioned Big Ships already, Galactic Navy requires Behemoth OXP to be installed, and Iron Raven also requires/includes the Armoured Transport OXP, so there are plenty of precedents for dependencies of this type.
The main effort would be on the part of the ship set authors to rename their ships, and we would need to co-ordinate a synchronised re-release to make this work from the off, but I for one would be happy to do this.
So, is this an idea worth considering, and would the other authors/maintainers be happy to play ball on this matter.
Running multiple ship sets
Moderators: winston, another_commander
- Smivs
- Retired Assassin
- Posts: 8408
- Joined: Tue Feb 09, 2010 11:31 am
- Location: Lost in space
- Contact:
Running multiple ship sets
Commander Smivs, the friendliest Gourd this side of Riedquat.
- DaddyHoggy
- Intergalactic Spam Assassin
- Posts: 8515
- Joined: Tue Dec 05, 2006 9:43 pm
- Location: Newbury, UK
- Contact:
Could something be done with the Oolite handling itself?
A new token that's read in from an OXP that simply states - "override core ships" TRUE/FALSE - if set to true then the core ships get over-ridden, if set to false, then even if the core-ship names are used Oolite adds a unique string to the ship names thus making them not override the core ships.
Since all the sets that can override the core ships (but probably shouldn't) can't all override the said core ships simultaneously it would be down to the OXP user to check which one of the sets they have set the flag to TRUE and the rest to FALSE...
I have no idea if this is programmatically possible, which is why it's only a suggestion...
A new token that's read in from an OXP that simply states - "override core ships" TRUE/FALSE - if set to true then the core ships get over-ridden, if set to false, then even if the core-ship names are used Oolite adds a unique string to the ship names thus making them not override the core ships.
Since all the sets that can override the core ships (but probably shouldn't) can't all override the said core ships simultaneously it would be down to the OXP user to check which one of the sets they have set the flag to TRUE and the rest to FALSE...
I have no idea if this is programmatically possible, which is why it's only a suggestion...
Oolite Life is now revealed hereSelezen wrote:Apparently I was having a DaddyHoggy moment.
If the individual OXPs are configured correctly then it shouldn't be necessary. BigShips can do it for those vessels simply as it is the populator, and was designed from the top-down to couple with external OXPs.
In the case of core replacements, then the OXPs should have a method of overriding the trunk ships (and only those) via an override plist, and then the their own ships then take over those roles. That would also allow similar OXPs to exist side by side as the overrides should be the same, and as the roles for the ships should also be the same they will form a pool rather than replacing one another.
The difficulty of course is that the various OXPs are now "in the wild", and they weren't (at least initially) designed to work together. It shouldn't be too difficult to do, but would require a little co-ordination.
So as Smivs suggests, that sort of co-ordination would be better than adding something new into trunk which is arguably unnecessary.
In the case of core replacements, then the OXPs should have a method of overriding the trunk ships (and only those) via an override plist, and then the their own ships then take over those roles. That would also allow similar OXPs to exist side by side as the overrides should be the same, and as the roles for the ships should also be the same they will form a pool rather than replacing one another.
The difficulty of course is that the various OXPs are now "in the wild", and they weren't (at least initially) designed to work together. It shouldn't be too difficult to do, but would require a little co-ordination.
So as Smivs suggests, that sort of co-ordination would be better than adding something new into trunk which is arguably unnecessary.
My OXPs via Boxspace or from my Wiki pages .
Thargoid TV
Dropbox Referral Link
Thargoid TV
Dropbox Referral Link
- Smivs
- Retired Assassin
- Posts: 8408
- Joined: Tue Feb 09, 2010 11:31 am
- Location: Lost in space
- Contact:
When I mentioned Big Ships, it was as an analogy, as the functions are clearly very different. What I am suggesting is a 'universal' shipdata_overrides.plist which can be used with any or all of the ship sets to cancel-out the default ships. This would avoid the need for ship set OXPs to include their own individual shipdata_overrides.plist, and leaves the user free to not use it if they still want the default textures to appear as well.
By removing the need for individual shipdata_overrides.plists, this should also avoid one OXP overriding others as well...they should all live harmoniously together. And of course OXP authors won't have to have more than one shipdata.plist in their OXPs. Less work for the author and less complication for the user.
By removing the need for individual shipdata_overrides.plists, this should also avoid one OXP overriding others as well...they should all live harmoniously together. And of course OXP authors won't have to have more than one shipdata.plist in their OXPs. Less work for the author and less complication for the user.
Commander Smivs, the friendliest Gourd this side of Riedquat.
- Commander McLane
- ---- E L I T E ----
- Posts: 9520
- Joined: Thu Dec 14, 2006 9:08 am
- Location: a Hacker Outpost in a moderately remote area
- Contact:
I think the problem lies a little deeper, and is mainly one of different ideas on the author's and the users' side.
Example:
The OXP author has designed a shipset as a replacement for the original set. He wants the original ships not to appear anymore.
But the OXP user wants the set as an addition to the original set. So he wants the original ships to appear alongside the new ships.
(Of course this also works the other way round, if a shipset is meant as an addition, but the player wants it as a replacement.)
There you have a conflict which isn't easily resolved. It would be easy if there was one central switch for either "addition" or "replacement". If such a switch could be scripted we would be a big step farther.
Still, the player would have to be able to use this switch correctly. For instance, he would have to understand that "replacement" automatically means that he can only install one shipset. Installing multiple shipsets would autimatically mean "addition". (Hm, there could be a third option, where you want all ships of multiple OXP shipsets to appear, but not the original ships.) So yes, it's going to be complicated.
Example:
The OXP author has designed a shipset as a replacement for the original set. He wants the original ships not to appear anymore.
But the OXP user wants the set as an addition to the original set. So he wants the original ships to appear alongside the new ships.
(Of course this also works the other way round, if a shipset is meant as an addition, but the player wants it as a replacement.)
There you have a conflict which isn't easily resolved. It would be easy if there was one central switch for either "addition" or "replacement". If such a switch could be scripted we would be a big step farther.
Still, the player would have to be able to use this switch correctly. For instance, he would have to understand that "replacement" automatically means that he can only install one shipset. Installing multiple shipsets would autimatically mean "addition". (Hm, there could be a third option, where you want all ships of multiple OXP shipsets to appear, but not the original ships.) So yes, it's going to be complicated.
- Smivs
- Retired Assassin
- Posts: 8408
- Joined: Tue Feb 09, 2010 11:31 am
- Location: Lost in space
- Contact:
It could be made much more simple though, which is the thrust of this thread.
What I envisaged is that every shipset uses a unique naming system, and that a universal shipdata_overrides.plist is made available (as a free-standing OXP) that 'switches off' the default textures. I believe Griff's set already includes such, and if we talk nicely to him...
The way this would work is that when someone installs a single shipset and nothing else, they would get the new shipset ships and the default textures. If they only want the new ships, they install the 'kill-switch' OXP to disable the default textures. If they want to use more than one shipset they simply install the other ones they want and all will appear (as they have unique names) without any further problems, and they can then optionally use the 'kill-switch' if they don't want the default textures.
This leaves all options open:-
One shipset
One shipset + default textures
Multiple shipsets
Multiple shipsets + default textures
This is about as simple as it gets, with the only slight disadvantage being for those who only want one shipset as they will also need to use the 'kill-switch' OXP as well as their chosen shipset. For all other combinations, things will be much simpler.
Oh, and of course there will be some numpty who installs the 'kill-switch' only and wonders where all the ships have gone
What I envisaged is that every shipset uses a unique naming system, and that a universal shipdata_overrides.plist is made available (as a free-standing OXP) that 'switches off' the default textures. I believe Griff's set already includes such, and if we talk nicely to him...
The way this would work is that when someone installs a single shipset and nothing else, they would get the new shipset ships and the default textures. If they only want the new ships, they install the 'kill-switch' OXP to disable the default textures. If they want to use more than one shipset they simply install the other ones they want and all will appear (as they have unique names) without any further problems, and they can then optionally use the 'kill-switch' if they don't want the default textures.
This leaves all options open:-
One shipset
One shipset + default textures
Multiple shipsets
Multiple shipsets + default textures
This is about as simple as it gets, with the only slight disadvantage being for those who only want one shipset as they will also need to use the 'kill-switch' OXP as well as their chosen shipset. For all other combinations, things will be much simpler.
Oh, and of course there will be some numpty who installs the 'kill-switch' only and wonders where all the ships have gone
Commander Smivs, the friendliest Gourd this side of Riedquat.