Proposals for Oolite 1.79/1.80, 5 of 5: Shipdata organising

[cim]

Last one of the five proposals, and probably the least interesting to most people, but if you were thinking of putting together a full or partial shipset OXP, then you might want to give this a more detailed look.

Shipdata Reorganisation
A reorganisation of the Oolite shipdata.plist file.

Problem
Shipset OXPs are very popular, but the current best practice way of doing them makes it extremely difficult to make changes to the core shipdata.plist and have them reliably do anything. There have been several discussions on the board about changes which could be made, including:

• Adjust roles to allow other ships to be low-chance escorts, or to allow differentiation within roles
• Change the player Cobra III's speed back to 0.3 LM
• Reduce the Anaconda's cargo capacity
• Give police ships escape pods

Not all of these changes have consensus that they are good ideas, of course, and this is not the place to discuss the merits of particular changes, but the practical inability for the development team to usefully make even those changes we agree with or initiate is a problem (e.g. weapon_facings).

Additionally, the way in which player ships are specified in the shipdata.plist is inconsistent. Some are like_ship's of the NPC version; others just copy all the parameters.

Proposal
The aim of this proposal is to make it possible to write shipset OXPs in a better way than the current core shipdata.plist allows, both simplifying the writing of shipsets, and making it more practical to make adjustments to the core shipdata.plist in future.

Convert all primary entities in shipdata.plist (i.e. not subentities) into the following format:

• A ship-template entry, which contains almost all parameters for the NPC ship (and "harmless" player parameters like view positions), and the is_template flag.
• One or more ship entries for NPC ships, like_ship'd to the template, with necessary modifications to AI, weapons, etc. For backward compatibility, these will keep the inconsistent names (cobramk1 vs cobra3-role) of the current list.
• One ship-player entry, like_ship'd to the template, with minor changes as needed (e.g. Cobra III)

Addition shipsets would then like_ship the template as the core game does to add new variants on that ship type.

Replacement shipsets would overrule the NPC/player entries, adding extra lines for model, materials, shaders, and other differences, but would not touch the template definitions, nor should they needlessly replicate them.

If there is a need to add extra ship variants to the game (for a silly example, an escort variant of the Anaconda) then these could first be added as like_ship's of an existing ship, so that they were initially compatible with replacement shipset OXPs (additions, however, would not be covered). They could then be moved to be properly like_ship'd directly from the template in later releases.

Deployment Considerations
This proposal, to be of practical benefit, requires rewrites of the replacement and addition shipsets by the shipset OXP maintainers. The agreement of those maintainers who are still active that this proposal is correct is therefore essential.

Older shipsets which are not being maintained would still work but would eventually diverge from the main game ships. This is unavoidable however we choose to make changes to the core shipdata.plist

The changes would be made in 1.79. To allow for testing, shipset maintainers would be encouraged to release shipsets using the new formats. However, as these shipsets would not be compatible with 1.78 or earlier, it would be understandable for shipset maintainers to instead wait until 1.80 was released so that they only needed to support one version of their OXP.

[JazHaz]

Surprised no-one responded to this, but your proposal sounds good to me, Cim.

[Zieman]

Ditto.

[Bazabaza]

Indeed ditto