We'll definitely want to query against `cmdr`, and possibly `created`.
We shouldn't need to against other fields, they'll just be checked during
processing of an already selected message.
* sqlite3 open, and creation of table.
* Change `load_journal_replay()` to `load_journal_replay_file()` and change
the semantics to just return the `list[str]` loaded from it. It also now
catches no exceptions.
* Remove the "lock the journal cache" on init as it's not necessary.
There's still a lot more changes to come on this.
The EDDN schema is still a work in progress, unsure if we'll use the same
one for both Journal and CAPI sourced data, or separate schemas.
But, so far, this works.
This can simply occur if the *first* load of `NavRoute.json` soft-fails,
meaning the plugin is receiving the bare Journal-file event, which has no
`Route` array.
This has been missed, based on Journal examples, and has been causing issues
at least for `ApproachSettlement`.
So, `filter_localised()` now used in:
`export_journal_navroute()`
`export_journal_approachsettlement()`
`export_journal_fssallbodiesfound()`
* Need to remove `event`, `horizons` and `odyssey` per signal.
* It's lower case `horizons` and `odyssey` in a(n augmented) journal event.
* It's `event`, not `entry` that `export_journal_entry()` will look for.
* Move call to `export_journal_fsssignaldiscovered` to top-level of event
processing. This ensures we'd still have the *previous* system tracked
when running under Odyssey.
Also, we can't return any result from this, as we'd still need to process
things like `Location` otherwise.
* Use `logger.trace_if("plugin.eddn.fsssignaldiscovered", ...)`
* Perform all sanity checks, elisions and augmentations in the "not
FSSSignalDiscovered event" sending code.
On checking, all of the events valid for the journal schema (and CodexEntry
has its own schema and separate EDMC code) already contain SystemAddress, so
it would never be added as an augmentation.
Instead, turn this into a sanity check.
* A login-time `ApproachSettlement` happens before `Location`, if
appropriate.
* Also add a future comment about FSSSignalDiscovered, for if EDDN ever adds
the schema.
It turns out some of the other strings, that do not have minLength=1 in the
schema, can be empty and that's OK. i.e. NearestDestination.
So, let's only check for the actual minLength=1 things. Which is a few
top-level key:values, and then the contents of the Traits array.
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.
* 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.
Athanasius
Chris Henning
Gareth Harper