* 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.
Yes, there's some lovely mis-match between Mapping and Dict type to work
around. Mapping complains about lack of __delitem__, so saying it's a
Dict instead and ensuring that matches at the call site.
* As we're now not sending *all* journal events on the journal schema
this refactors only the actual sending in export_journal_entry(), with
the other functionality in export_journal_generic(), so that the new
export_journal_fssdiscoveryscan() can use export_journal_entry() as
well.
In the future EDDN will move to a schema per event type, so we'll lose
_generic(). Factoring out some things like augmentations into their own
functions will come next.
This also entailed slightly reworking the way the EDDN code uses this
URL. It was very generalised, so as to allow for the debug "just send
and log locally" code, but as the only URL is the 'upload' one much of
that seemed un-necessary.
So that code has been simplified.
This should have been set from the latest Journal file, and the
key/value is in LoadGame in Odyssey. It's only documented as:
"Whether the sending Cmdr has an Odyssey expansion."
in the current EDDN Journal schema. Thus sending this as False if the
Cmdr last logged into Horizons/base game should be OK.
Athanasius
A_D