Separate Ship and Player

[robn]

Right now Ship has too much knowledge and too many methods that are player-specific and should live in Player. Two examples:

• SetNavTarget & SetCombatTarget aren't required by NPCs; they're strictly UI functions. This is reinforced by the fact that these methods cause a sound to be played
• AddMoney and friends. NPC ships don't need money; they'll be equipped as necessary by ships. Indeed, Player should probably be a MarketAgent, but Ship should not.

Someone needs to go through and check and move things out of Ship into Player as appropriate. I think a good rule-of-thumb is that if it is a UI function in any way, then it belongs in Player. Another test might be to simply remove it from Ship and see if the code compiles.

[robn]

On further thinking, there shouldn't be any UI stuff in Player. For example, SetNavTarget should not play a sound. That should instead happen in the click handler. However, SetNavTarget would still belong in Player, as a NPC ship has no concept of a navigation target (an AI target is set explicitly when the AI is activated). Down the track, a script may want to forcibly set the player's navigation target. That is still a Player function, but should not trigger a sound.

[PinBlacniP]

I might suggest that a small "structure" modification in / Pilot ship relationship, might make it easy to have multiple ship ownership! Location of "dock" or just orbit co-ordinates referencing a body ... might need a private beacon to allow listing of location? This could lead on to eva ... Space suit as internal ship, sort of re-attachable escape pod?

[robn]

That might come later, but right now there is no pilot - the player is the ship. Its reasonably easy to fake ship ownership through a script - you just have a script keep a list of ship attributes and swap them in and out as necessary.

[PinBlacniP]

OFF Topic!

I had been looking at the 'Date' functions in utils.cpp, and written and
tested a possible substitution. I saw your replacement in the alpha-10,
whilst considering how to submit! EXCELLENT work, I am much impressed, with
this
quality of contribution, I can only hope the project continues --> and
expands to populate the Galaxy.

In the original 'Elite Frontiers', I had a game that spanned nearly 30,000
game years. (sad)

Regards

Francis Ball

[robn]

Thanks for the kind words! @dsalt is the fellow responsible for this change and a massive amount of code cleanups for alpha 10. He's done a brilliant job.

I see you adding a lot of stuff to issues lately. We greatly appreciate the input (and a few of your new issues are proper bugs that haven't been dealt with yet) but please remember that this is not a forum. If you want to discuss the game, use the forums. If you want to contact the devs directly, use the mailing list.

[PinBlacniP]

Sorry! If you can let me know which comments are discussion rather than
report, I'll try to Keep it appropriate!

[robn]

See also #307.

[robn]

Some work has been done on this in #485. I still want Ship and Player checked to make sure that the split between them is sane. I'm still not sure about how to best separate Player from the UI, but that might be out of scope for this issue and its something I'm slowly coming to grips with on a branch anyway.

[impaktor]

I might suggest that a small "structure" modification in / Pilot ship relationship,
might make it easy to have multiple ship ownership!

I think/hope sooner or later someone will implement this, so one ship can be stored in a station somwhere. Also, since this issue was opened the project has taken many steps away from Frontier, where ship really was the player. If possible, having multiple ship ownership might be worth keeping in mind when restructuring the code.

NPC ships don't need money

Maybe it is just me, but I imagine the closer we make NPC to an actual player the more realistic we can make them. Although, with added complexity comes an increase to the number of dimensions in bug-space, since instead of cheating and having NPC do the observed behaviour "D", we would simulate the entire decision process and have the NPC do A so he could do B, then C and finally "D" which is the only outcome the player would observe.

[fluffyfreak]

Yes the player should really have a ship and not be a ship.

[walterar]

It's a shame that after all this time no one has been interested in solving this. :(

Specifically.
What is needed is:

ship:SetNavTarget (target)
target = ship:GetNavTarget ()

ship:SetCombatTarget (target)
target = ship:GetCombatTarget ()

ship:SetHyperspaceTarget (target)
target = ship:GetHyperspaceTarget ()

And, very important to add:

ship:UnsetNavTarget (target)
ship:UnsetCombatTarget (target)

Many "interesting" things could be done if we had this.

[salborrelli]

@walterar FYI I've already "promised" to take a look at this one as soon as I have some time, see PR #3618 😄