An alternative to ship distribution convention

[spara]

Many shipsets are released as addition and replacement that in practice are duplicates with different shipdata.plists. Griff's latest releases follow a different distribution model that achieves the same, but has only one shipset package making the maintenence a little easier.

Based on Griff's model I propose the following alternative distribution model.

1. A shipset oxp with unique datakeys. Defines own roles or like_ships from oolite-templates.
2. A replacement oxp that like_ships core datakeys (not templates) to the shipset datakeys with shipdata.plist and suppresses roles from core datakeys (not templates) with shipdata-overrides.plist.

In practice 1. is an addition shipset and 1. + 2. is a replacement shipset.

Pros
* The actual ships are in the first oxp so maintaining is easier.
* Easier to manage dependencies in the manager. If the shipset is needed, just check the first oxp.
* No conflicts in installing addition and replacement at the same time.

[Smivs]

My first thoughts on this are both why? and what about all the problems it could cause?
The current system was discussed at length and decided upon by pretty much everybody as it addressed the problems of running multiple shipsets that were rife back then. The current system is simple, intuitive and understood by all. Until a little hiccup occured with the dependancies on the Manager, it has worked well and without problems.
The main issues as I remember things were problems caused by more than one shipset using the core names and roles (overcome by introducing the concept of 'Addition' and 'Replace' sets), and the use of shipdata in some sets that set the core names/roles to null, something you seem to be suggesting here. Now, just as then, any OXP which uses ships using core names/roles would be broken as those names/roles effectively cease to exist. An awful lot of old and possibly un-maintained OXPs would risk being compromised by this.
As you rightly say, the current convention uses almost identical OXPs with different shipdata - different names for the ships in the Addition version. This hardly makes any extra work either in the production or maintenance of the OXP.
Also, it is simple from the users' perspective - they simply download the OXP they want without the need for any dependancies. I really can't see the logic in requiring two OXPs to be downloaded (the actual OXP and the 'kill-switch' shipdata) to install a Replacement shipset.
Another small point in favour of the current system is its logical simplicity - it makes things a bit more accessible to new and novice OXP-ers.
No system is perfect, but the current one is pretty close, so I would take a lot of persuading to convince me another way is better. If there was an overwhelming case for a change, and it was agreed on by a majority then of course I would go along with it. Right now, I do have some serious misgivings.

[spara]

My first thoughts on this are both why?

Just for the sport of it, of course . Seriously though, the thought comes from the way Griff distributes his current ships and I think it has some merits. One ship resource file being the primary one.

...and what about all the problems it could cause?

Don't really see any problems other than there being two different kinds of systems for shipsets. Which is a bit of a problem naturally.

The current system was discussed at length and decided upon by pretty much everybody as it addressed the problems of running multiple shipsets that were rife back then.

Well, Oolite has changed a bit from then and at times it might be an idea to review old decicions. Even it the old one is agreed to be better.

The current system is simple, intuitive and understood by all. Until a little hiccup occured with the dependancies on the Manager, it has worked well and without problems.

I would also say that because of the roles change the number of useful shipsets has diminished tremendously in addition that the manager has very little to offer. So the problem is currently very academic one.

The main issues as I remember things were problems caused by more than one shipset using the core names and roles (overcome by introducing the concept of 'Addition' and 'Replace' sets), and the use of shipdata in some sets that set the core names/roles to null, something you seem to be suggesting here. Now, just as then, any OXP which uses ships using core names/roles would be broken as those names/roles effectively cease to exist. An awful lot of old and possibly un-maintained OXPs would risk being compromised by this.

This is not so. The old and unmaintained oxps are broken at the moment as they override the core names and roles. They should not be used before they are upgraded. What I'm suggesting should produce the same effect as the old system. One oxp adds new ships and like_ships the roles from templates. Another oxp stops the core ships from spawning and routes the datakeys to the shipset. So effectively the shipset becomes the new core set. Don't see what it breaks as the oolite-templates are not touched.

As you rightly say, the current convention uses almost identical OXPs with different shipdata - different names for the ships in the Addition version. This hardly makes any extra work either in the production or maintenance of the OXP.

I'm not maintaining any core replacing shipsets, so I'll take your word here.

Also, it is simple from the users' perspective - they simply download the OXP they want without the need for any dependancies. I really can't see the logic in requiring two OXPs to be downloaded (the actual OXP and the 'kill-switch' shipdata) to install a Replacement shipset.

The first oxp is an addition shipset, the second one converts it to a replacement shipset. Should be quite logical.

Another small point in favour of the current system is its logical simplicity - it makes things a bit more accessible to new and novice OXP-ers.

Not sure about this. At the moment there really aren't much choices in the manager so hard to say. Time will tell.

No system is perfect, but the current one is pretty close, so I would take a lot of persuading to convince me another way is better. If there was an overwhelming case for a change, and it was agreed on by a majority then of course I would go along with it. Right now, I do have some serious misgivings.

I agree wholeheartedly that there's no point in making a change just because of the change. Both systems should technically work just fine next to one another, but using two logically different systems might be a bit problematic for the casual user.

If the old system feels valid and a change to a new systems seems futile, then there's no reason for a change. But if there's need for a change, for example from the maintenance point of view, then this is about the right moment to do it as there are not many shipsets being offered in the manager yet.

[Smivs]

... the thought comes from the way Griff distributes his current ships and I think it has some merits. One ship resource file being the primary one.

I don't have a problem with the concept - HIMSN is going to do the same and it makes sense there, but for conventional shipsets it doesn't make sense. The OXP is its own resource, and is fully self-contained. To use my Classic Ships as an example, yes I could have a 'resource ' OXP with all the models, textures etc, and then two 'data' OXPs for the Addition and Replace shipdata etc, but that is to my mind un-necessary over-complication. If people want a shipset they want one OXP, not two. Also, as they will only use one there is no duplication.

...Oolite has changed a bit from then and at times it might be an idea to review old decicions. Even it the old one is agreed to be better.

Agreed. Things change and we will sometimes need to change with them. But only if the change has obvious, tangible benefits. I'm not sure I can see any in this suggestion.

The old and unmaintained oxps are broken at the moment as they override the core names and roles. They should not be used before they are upgraded.

Not really broken in the sense that they won't work as they are useable with the shipset compatibility OXP. And people will use them regardless of upgrades because they like them. Maybe in time they will fade away, or be upgraded but right now they are there, they are used and we need to accept that and work around them. It is not our job to tell people not to use something just because it is old.

Another small point in favour of the current system is its logical simplicity - it makes things a bit more accessible to new and novice OXP-ers.

Not sure about this. At the moment there really aren't much choices in the manager so hard to say. Time will tell.

What I meant was that today we have a simple system which (to most people I think) is straight-forward and logical. This makes it less intimidating to those just starting to tinker.

I agree wholeheartedly that there's no point in making a change just because of the change. Both systems should technically work just fine next to one another, but using two logically different systems might be a bit problematic for the casual user.

Agreed. Whatever eventual decision is reached, everybody should go with it.

[spara]

The old and unmaintained oxps are broken at the moment as they override the core names and roles. They should not be used before they are upgraded.

Not really broken in the sense that they won't work as they are useable with the shipset compatibility OXP. And people will use them regardless of upgrades because they like them. Maybe in time they will fade away, or be upgraded but right now they are there, they are used and we need to accept that and work around them. It is not our job to tell people not to use something just because it is old.

I was a bit harsh here I see. The only point we should say something like that is when an OXP breaks something. I hope that people don't miss the compatibility OXP, it's not very obvious when downloading old stuff from the wiki. And it still leaves addition shipsets a little broken as they don't get spawned to the new roles. Maybe I'll take that to be my next project after the big one .

[Smivs]

And it still leaves addition shipsets a little broken as they don't get spawned to the new roles. Maybe I'll take that to be my next project after the big one .

Haha, well, there is no hurry!
It is hard to know how many payers are still using some of the older shipsets isn't it. My guess is probably quite a few - maybe we ned a poll.
I'm surprised nobody else has had anything to say on this subject though.

[cim]

I'm surprised nobody else has had anything to say on this subject though.

I think you're the only two people actively working on shipset packaging...

How about:
"Assets" (contains all the models, textures, scripts, etc.)
"Replacement" (just a replacement shipdata.plist, depends on Assets)
"Addition" (just an addition shipdata.plist, depends on Assets)

You could make "Addition" conflict with "Replacement" if you wanted, but I think installing both at once is fine. 1.81's manager has automatic dependency fetching, so "Assets" being a separate package shouldn't cause too much inconvenience there.

A few more thoughts:

- The suppression model does have the potential disadvantage that if someone like_ship's a core ship without changing the roles, it then won't appear if a suppression OXP is installed. I can't see any cases where that's actually been done in existing OXPs, though, and for new ones you can like_ship the template instead. (You might not want to explicitly set roles, because you might want to pick up extra roles the core game adds automatically)

- Suppression has the advantage that if you want to likeship the shipset variant of a ship, but you don't know which of addition or replace is in use, it has a consistent data key. You could get the same effect with addition/replace by doing this:
"oolite_template_cobramk1" => "shipset_template_cobramk1" => "cobramk1" (in replace)
"oolite_template_cobramk1" => "shipset_template_cobramk1" => "shipset-cobramk1" (in addition)
People wanting to like_ship the specific model variant can then use "shipset_template" as they would use "oolite_template".
In the "addition/replace/assets" layout, you'd put the templates into the Assets OXP (and then in theory you could have an OXP which depended on the Assets OXP working even without the ships appearing in normal flight)

- I think Addition/Replacement might be the easier for users to understand when downloading in the manager, but that may just be because that's what I'm currently used to.

[Smivs]

I'm surprised nobody else has had anything to say on this subject though.

I think you're the only two people actively working on shipset packaging...

That's very likely. I've not really been keeping up, but an idea of how they stand might help us decide how to move forward with this.
What are we are looking at?
As well as the core set, there is of course The Classic Ships which is current and maintained, but what of the others?
Deepspace Ships - Deepspace has been MIA for a long time, but didn't somebody do an update?
Griff's Normal-mapped - still alive and well
Sung's - probably been 'dead' for ages?
Staer9 - again MIA but I seem to remember some updating.
Simon B (Neolites) - I think these again are being maintained on an ad-hoc basis but not by Simon.
Smivs'Shipset - now obsolete and no longer maintained - replaced by The Classic Ships.
Have I missed any?

How about:
"Assets" (contains all the models, textures, scripts, etc.)
"Replacement" (just a replacement shipdata.plist, depends on Assets)
"Addition" (just an addition shipdata.plist, depends on Assets)
You could make "Addition" conflict with "Replacement" if you wanted, but I think installing both at once is fine. 1.81's manager has automatic dependency fetching, so "Assets" being a separate package shouldn't cause too much inconvenience there.
<snip>
- I think Addition/Replacement might be the easier for users to understand when downloading in the manager, but that may just be because that's what I'm currently used to.

Re the last point, I agree this is the most 'obvious' way - it is simple and requires no thought or action by the user, and is what we are used to. The Assets,Addition,Replacement system is fairly straight-forward and might have some benefits, but it also adds a layer of complexity which in most cases is un-necessary to my mind.

A few more thoughts:

- The suppression model does have the potential disadvantage that if someone like_ship's a core ship without changing the roles, it then won't appear if a suppression OXP is installed. I can't see any cases where that's actually been done in existing OXPs, though, and for new ones you can like_ship the template instead. (You might not want to explicitly set roles, because you might want to pick up extra roles the core game adds automatically)

- Suppression has the advantage that if you want to likeship the shipset variant of a ship, but you don't know which of addition or replace is in use, it has a consistent data key. You could get the same effect with addition/replace by doing this:
"oolite_template_cobramk1" => "shipset_template_cobramk1" => "cobramk1" (in replace)
"oolite_template_cobramk1" => "shipset_template_cobramk1" => "shipset-cobramk1" (in addition)
People wanting to like_ship the specific model variant can then use "shipset_template" as they would use "oolite_template".
In the "addition/replace/assets" layout, you'd put the templates into the Assets OXP (and then in theory you could have an OXP which depended on the Assets OXP working even without the ships appearing in normal flight)

Again, benefits and disadvantages in supression. My personal view is that I don't really like the idea. It is a broad brush that could have effects that nobody has forseen - I don't have a problem with a 'Replace' set over-riding the core ships/shipdata because that's what users have chosen to do, but a blanket killing of the core datakeys and or roles could touch on almost anything, and I think that this aspect was one of the things that persuaded us to recommend against supression when we agreed the current system.

[Wildeblood]

This is nonsense. All shipsets should be published as "addition" versions only, and then there should be one, and only one, "Suppress Default Shipset" OXP that can be used with any of them, if desired. If it can't be made to work that way, because of all the templating and like_shipping and role re-assignment and whatnot, then something is broken by design and needs re-thinking.

[Norby]

Addition/Replacement might be the easier

I like these words (used in the wiki also), but the third texture-holder package named to "Resources" in Griff's shipset and Random Hits.

[cim]

This is nonsense. All shipsets should be published as "addition" versions only, and then there should be one, and only one, "Suppress Default Shipset" OXP that can be used with any of them, if desired. If it can't be made to work that way, because of all the templating and like_shipping and role re-assignment and whatnot, then something is broken by design and needs re-thinking.

That would work fine for shipsets themselves, and be absolutely horrible for anyone who wanted to make a ship based on a core ship class and have it look graphically like one of the installed shipsets (which might not include the default one, if it's suppressed). It's doable with sufficient use of the is_template flag, but would require the ship OXP to be updated every time a new shipset OXP was released.

Starting entirely from scratch the "right" approach would be to separate the plists:
- shipdata.plist: contains ship performance data, names, etc. and specifies a ship model class
- shipmodels.plist: contains model, texture, subentity, weapon position, view position, etc. for each ship model class. Multiple definitions for the same ship model class can be set up.
When adding a ship, it picks a random model for the specified ship model class (or alternatively allows picking a specific model)

A shipset OXP then just defines a set of ship models. Like_ship of a core shipdata definition will pick a random installed model automatically, because the ship model class gets copied.

I don't think there's sufficient interest in updating existing ship(set) OXPs to that way of doing things for it to be worth implementing, though - and if they weren't, and used some compatibility mode to keep working (a shipdata without a ship model class generates a private ship model class based on its own model, etc. properties), then you wouldn't get the benefit of the change.

[spara]

I think these are all shipsets out there:

* Griff's normalmapped
* Deepspace
* Neolites
* Re2dux
* Smivs'
* Sungs
* RXSoftware

It would be nice to have most of them alive. I can take a look at them more closely at some time, if no one else beats me to it. And use the preferred distribution model

[Smivs]

I'd forgotten about the wiki page linked by Norby (above). I have just edited it to add The Classic Ships (and also re-arranged the list alphabetically). It appears that they all follow the current convention of offering Addition and Replace versions.

[Diziet Sma]

It is hard to know how many payers are still using some of the older shipsets isn't it. My guess is probably quite a few - maybe we ned a poll.

I'm inclined to suspect that a poll might not be particularly representative. If there's one thing I've learned from following the Elite Dangerous bandwagon around all over the internet, it's that there are, in fact, fairly large numbers of people actually playing Oolite, the vast majority of whom have never signed up here. Perhaps they sometimes drop by to read something here (going by the way visitors often outnumbered logged-in members by 10:1 or more*) but they don't really participate. Members here tend to be mostly pretty up-to-date with the version of Oolite they play, and that would tend to influence their OXP choices too, to some extent. What's going on out "in the wild" could as easily go contrary to the poll results, as they could be in sync with them..

*<Waves hello to all the lurkers out there..> come and say g'day.. we don't bite!

[Diziet Sma]

I think these are all shipsets out there:

* Griff's normalmapped
* Deepspace
* Neolites
* Re2dux
* Smivs'
* Sungs
* RXSoftware

There's also dertien's WIP, the High Poly Classic Modset, even though it has a long way to go yet before completion.