1. We need StarPos (as well as StarSystem)
2. Adding more state tracking in this plugin is misguided.
3. So added it in monitor instead, putting *copies* of data in the
monitor.state dictionary.
4. So we reference those, but only available in journal_entry() itself, else
we'd need to pass the whole of `state` in.
5. So instead pass in the bits of `state` only when we need them.
Also, whilst the *current* code has the 'augment files' handled last in
then if/else tree we shouldn't assume that will always be the case.
So, be paranoid and use different variables for the augment-loaded entry
and its .lower event_name.
'cos you just know one of us will trip up on it later if there's ever some
'finally' code after that conditional tree.
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.
This is a sidestep solution to #1390. It doesn't attempt to directly
resend data, only compressing with gzip over a given size. If that STILL
returns a 413, its dropped, as without introspection of the message we
cannot make it any smaller
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.
* Closes#1342 - A user had a NavRoute message with no Route array.
It's always from the file, so the file had to be missing it?
* This results in an EDDN '400', and now we'll drop such messages from
the replaylog so they're not constantly retried.
OK, it has `data` passed in, so this should be obvious, but let's make
it explicit both by name and in the docstring.
The docstring now also emphasies that *this* check **MUST** be used for
CAPI data, as it's dependent only on the availability of Horizons on the
account, and not on the `LoadGame` flags.
For consistency with the horizons flag. They *are* placed *from* the
`this` versions into `entry`, but we might as well go the direct route.
They have to be set explicitly here as we process the `entry` to make a
wholly new `message` rather than the `message` just being `entry` with
some changes.
