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.
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.
Partial data is better than no data, or bad data. So if Status.json
BodyName is available, always use it. *Then* see if Journal BodyName
matches that, and if so set BodyID.
Close-orbiting bodies might therefore cause BodyName to be set without
BodyID, but then it's up to EDDN listeners to make a decision, rather
than making it for them.
* The Tracking UI is now up and running.
* Some of the tracking corrected:
- Set BodyID from ApproachBody.
- Do not clear values on SupercruiseEntry, allow either FSDJump or
LeaveBody to do this.
- Clear the values if we detect the Main Menu music track (when you
exit to the menu, not just when you look at the menu whilst
in-game).
* Various comments added to help with documenting the tracking for EDDN
uploaders.
