CAPI only has the Cmdr wallet value (and loan if applicable), without anything
for 'total assets'. If we send Inara setCommanderCredits without
`commanderAssets` then Inara makes a bad judgement on it and sets an
incorrect total assets value.
Also:
> Do NOT set credits/assets unless you are absolutely sure they are correct. The journals currently doesn't contain crew wage cuts, so credit gains are very probably off for most of the players. Also, please, do not send each minor credits change, as it will spam player's credits log with unusable data and they won't be most likely very happy about it. It may be good to set credits just on the session start, session end and on the big changes or in hourly intervals.
So, let's just not.
Doing so from 'Rank' means the 'Progress' event hadn't happened yet, so of
course we only ever sent all zeroes for progress.
NB: Journal-v32 doc makes *no guarantee* about the order of the events.
Is it worth trying to be paranoid about that ? For a 100% new player
everything would be "all zeroes", so we would likely need to tweak things
to store `None` as default values, and check for such.
Inara itself seems to be doing this if it has access to CAPI-sourced
Journals. If we don't send commanderAssets as part of
setCommanderCredits then it does ... something else ... and ends up with
your total assets value bouncing between what EDMC is causing and what
it sees from the CAPI-sourced journals.
So, don't send this from LoadGame any more, instead wait for Statistics,
and if it has the relevant data, also send commanderAssets.
This is old code, pre-dating the move to EDCD. We could only possibly
set the system name and address from this, and would always have already
set this from login Location event, or any jump-in event.
* If you're near a settlement on login you get an ApproachSettlement
before `monitor` has system set to pass into `journal_entry()`.
* We had a case-type of an Inara API key, so it wasn't setting the
BodyName.
* TRACE level logging of what we actually send to Inara.
The 'if not this.station' was early paranoia when first getting things
working with Odyssey. It prevents a relog from Horizons (i.e. different
location) from correctly picking up an Odyssey login station when
on-foot in concourse.
Also, EDSM was defaulting wrongly for this.station_marketid. Not that
the plugin even *uses* that at this time.
