* Call it system_name in `export_journal_fssdiscoveryscan()`, as `system`
could be amigbuous.
* Might as well use `system` passed in to `journal_entry()` when calling
`export_journal_approachsettlement()`.
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.
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
* 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.
This still logs them, at DEBUG, which will get spammy as such messages
accumulate.
Uncommenting the:
`# return # Pretend it went OK so this message isn't retried`
at line 291 in EDDN.sendreplay(), in the:
`except requests.exceptions.HTTPError as e:`
block would cause them to not stay in the replaylog.
Currently Live EDDN doesn't yet have the new schemas such as navroute,
so will complain. Rather than leaving such messages in our EDDN replay
queue and getting an error every time that is run, detect this error
case and drop the messages.
