Problems with Cobra 3 shipdata.

[Smivs]

I'm currently sorting out ToughGuys OXP for Oolite v1.77 and have found a small problem.
All the Cobra 3 variants including the player Cobra 3 are like_ship-ed to the "cobra3-trader". One consequence of this is that while attempting to change aspects of the "cobra3-trader" shipdata (such as accuracy) by script these changes are also being applied to the player ship by default, even though this was not desired. As the player ship accuracy is read only this was generating log errors.
This is not a major problem and can be overcome easily enough by including a full shipdata entry for the player version in the OXP shipdata.plist (without the like_ship reference), but it is an inconvenience at best, and should probably be considered a bug.
Should future versions of Oolite have a fully defined shipdata entry for the player Cobra 3 which is not dependant on other variants?

[cim]

One consequence of this is that while attempting to change aspects of the "cobra3-trader" shipdata (such as accuracy) by script these changes are also being applied to the player ship by default, even though this was not desired. As the player ship accuracy is read only this was generating log errors.

Could you describe what you're doing in a bit more detail, please? You can't change any aspect of the "cobra3-trader" shipdata by script, only by overriding it with a shipdata.plist or shipdata-overrides.plist entry of the same name ... conversely if you're changing it by script, the fact that it's like-shipped shouldn't make any difference at all, because during game startup all the like-ship references are expanded out to give completely independent entries in the ship catalogue.

Presumably this is also a question for "asp-player" and "cobramk1-player"?

[Smivs]

Presumably this is also a question for "asp-player" and "cobramk1-player"?

Probably, yes.

I'm trying to use some of the new features in 1.77, specifically in this case changing the 'accuracy' settings of some NPCs by script, somewhat like what you did with Skilled_NPCs OXP.
When I included the cobra3_trader, I was getting log errors telling me that the script was invalid as 'accuracy' was read-only for the player ship. This confused me at first as the player ship was not included (and indeed I was not even flying a Cobra 3 at the time), but I eventually tracked the cause of the log errors down to the cobra3_trader - when I removed that part of my shipdata_overides.plist they stopped, and it was upon further investigation that I realised the like_ship reference was almost certainly the reason for this happening.

[cim]

When I included the cobra3_trader, I was getting log errors telling me that the script was invalid as 'accuracy' was read-only for the player ship. This confused me at first as the player ship was not included (and indeed I was not even flying a Cobra 3 at the time), but I eventually tracked the cause of the log errors down to the cobra3_trader - when I removed that part of my shipdata_overides.plist they stopped, and it was upon further investigation that I realised the like_ship reference was almost certainly the reason for this happening.

How are you determining the ships to change? If it's by ship.dataKey then like_ship should make no difference (as dataKey can't be like-shipped). What are you putting in shipdata_overrides.plist for these ships, if the change is being made by script?

[Eric Walch]

Smivs probably added a ship_script to the npc version, were the ship tries to change itself? In that case you could define the default script to the player version.

[Smivs]

Yes, I'm using a shipdata_overides.plist for some NPCs which increases the chance of optional equipment etc and includes a ship_script reference - the script should (I hope!) vary the 'accuracy' of the ships and apply weapons upgrades.

[cim]

Ah, that makes sense. What about this?

Code: Select all

this.shipSpawned = function() {
  if (this.ship.isPlayer) {
    return;
  }
  // do stuff
}

[Smivs]

Yes, I'd considered that, sort of. I'd actually thought aboout it backwards in the sense of specifying the roles to apply the changes to, but that is much simpler and more elegant I'll give that a go - I expect it will work OK, and makes more sense than adding a big chunk of shipdata for the player version.
I still think it would make sense to expand the core shipdata so player ships are 'self-contained' though.

[cim]

I still think it would make sense to expand the core shipdata so player ships are 'self-contained' though.

Or at least have some consistency, rather than three of them being like_ships, and seven not, certainly.

From a general style point of view, it seems a bit odd to me not to use like_ship for the player variants, since they aren't supposed to be wildly different to the NPC ships.

[Smivs]

I just think that as player ships are a special case (as in they have elements which are not writeable which NPCs have as read/write) doing this would avoid similar issues in the future.

[Smivs]

Just to confirm that your fix worked Cim Thanks for the advice (and injection of common-sense!).

[cim]

I just think that as player ships are a special case (as in they have elements which are not writeable which NPCs have as read/write) doing this would avoid similar issues in the future.

True. Perhaps the sensible thing to do would be to define:
shiptype-template: is_template: 1, just about every property
shiptype: like_ship:, shiptype-template, role:, probably nothing else
shiptype-variant: like_ship:, shiptype-template, role:, various other bits
shiptype-player: like_ship:, shiptype-template, role:, various other bits
for each ship class including a player ship. Then both the shortening and convenience of using like_ship can be combined with the convenience of the player ship not directly descending from any NPC ship.

Of course, even if we did that in the core data, you wouldn't be able to assume that it was actually true, since shipset OXPs are really popular.