With the tracking now being in monitor.py this needs to be ASAP after the
local copies of the tracking have been updated.
Below the possible `this.status_body_name` blanking, in case that's hit.
* Typod '.status' instead of 'state'.
* Bring in some sanity-checks and comments from eddn.py to monitor.py.
* Have a 'pass' elif for 'supercruiseentry' so as to comment why we do NOT
use this to blank out body state.
* Bring in the 'if we exit to main menu, blank body state' from eddn.py.
* Remove checks from eddn.py that are now in monitor.py.
* Have a disctinct 'docked' event check in eddn.py for triggering the
"Now we're docked, so the Delay sending until docked is satisfied"
sending of messages.
* Minor grammar edit only in PLUGINS.md (I was checking if it explicitly
stated what data is expected in the synthetic 'StartUp' event, it doesn't).
* First changes to move some monitor properties into the monitor.state
dictionary. This is for system or body data.
* Re-factored the generation of 'StartUp' event into
`EDLogs.synthesize_startup_event()`. It's done in two places, so was
anti-DRY.
* In general any bulk setting of system & body data is now done in the
same order for comparison clarity.
* A little of the location tracking has been duplicated from plugins/eddn.py.
This is with a view to switching *it* to using the state version.
* eddn: Needs to find status text, although really there should be a helper
function for this.
* Removed commented out references to same in edsm and inara.
* `logger.INFO` will, at best, be a constant, it should be `logger.info()`.
* When we're not interested in the `new_data` 2nd part of the tuple from
`killswitches.check_killswitch()` we can't use `_` as there's a potential
class with the `l10n.py` injection of `_()` as a builtin.
And you can't declare types withing first-use in a return-tuple. So, declare
them on their own lines, with throwaway default values instead.
* Added `capi.request.<endpoint>` killswitches at appropriate call points.
* Added `eddn.capi_export.<type>` killswitches. This allows for killing
just the EDDN export of such CAPI-derived data, without stopping the actual
queries, as other plugins/functionality might still have harmless use of
the data.
* PLUGINS.md: Actually describe the contents of `data` passed to plugins, and
point out it might not always contain market or shipyard data. This is
not only because of the new killswitches, but could already have happened
if the station/port docked at didn't have the services.
* Some misc typing cleanups.
* eddn: Don't schedule `queue_check_and_send()` if EDMC_NO_UI.
* `export_(commodites|outfitting|shipyard)` lost the `is_odyssey` argument
in 556ace5306 .
* EDDNSender: Helper `set_ui_status()` in which the check for EDMC_NO_UI
is performed. Used in `send_message()`. In the EDMC_NO_UI case it will
INFO log the text instead.
* This did, however, remind me that the `data` passed into `cmdr_data()`
is an amalgam of `/profile`, `/market` and `/shipyard` queries.
This means that the data.source_endpoint is **not correct for all of
the data and its use**. As such I had to pass 'hard coded' values into
the function from the various CAPI export functions. They know what it
is they're exporting.
* As this reminded me that "CAPI `data` is actually a `CAPIDATA`", I've
documented that in PLUGINS.md, but with a dire warning against relying on
any of the extra properties.
Whilst setting it to the same "CAPI-<endpoint>" string as `gameversion` in
these cases would probably be OK, that's not the intent of the EDDN
documentation, which has now been clarified.
* In case of apparent issues, have a `--trace-on` to better see what's (not)
happening.
All the old DBEUG logging, even if commented out, is now under this.
* Also added some INFO level logging for the legacy replay.jsonl conversion,
as it should be one-time per user.
* Some additional DEBUG logging for closing down.
* An aborted attempt was made to use a thread worker, but:
1. sqlite3 doesn't allow cross-thread use of the same sqlite3 connection.
2. Having an on-going query on one cursor, e.g. gathering all the
outstanding message `id`, whilst trying to DELETE a row hits a
"database is locked" error.
* So, back to tk `after()`. `send_message_by_id()` has been audited to ensure
its boolean return is accurate. So there shouldn't be any way in which to
get hung up on a single message *other than if the EDDN Gateway is having
issues, and thus it should be retried anyway*. Any reason for a 'bad
message' will cause `True` return and thus deletion of the message in
*this* call to `queue_check_and_send()`.
* There is a new `reschedule` parameter to `queue_check_and_send()`. If
`True` then at the end it should re-schedule.
There is a check in `journal_entry()` for the `Docked` event, and if this
occurs it will schedule `queue_check_and_send()` with `reschedule` set to
`False` so that we don't end up with multiple parallel schedulings.
It's still possible for a docking to have coincided with a scheduled run
and thus cause double-rate sending to EDDN, but we can live with that.
* The same scheduling mechanism is used, with a much smaller delay, to
process more than one queued message per run.
Hence the `have_rescheduled` bool *in* the function to indicate if a 'fast'
reschedule has already been set. This prevents the slow one *also* being
set in this scenario. The latter will be scheduled when the fast one
found no more rows to process.
* Erroneously used 'CAPI-commoodity' when it's 'CAPI-market' (name of the
CAPI endpoint, not anything to do with EDDN schema names, and '-commodity'
would also be wrong for that).
* Set `header` for (CAPI) `export_commodities()`.
* The eddn parts of the OUT_EDDN_DO_NOT_DELAY -> OUT_EDDN_DELAY change. This
includes the 'sense' of it being inverted from what it was.
* EDDN.REPLAY_DELAY is now a float, as it's used with `time.sleep()`. *This*
is the 400ms value for inter-message cooldown.
* EDDN.REPLAY_PERIOD is still an int, used with tk `after()`. This is how
often we attempt the queue.
* EDDN.session is no longer a thing, move that part of EDDN.close() to
EDDNSender.close().
* EDDN queue DB has `id`, not `message_id`.
* Now *looping* in the queue sender, not only sending the oldest message.
* Now that we're not trying to do "did we just/are we know docked?" in this
code it turns out that both CAPI and Journal messages can use the same
function for this.
* And as it's no longer journal-specific `EDDN.export_journal_entry()` has
been renamed to `EDDN.send_message()`.
This whole branch now needs to actually implement sending queued messages
when docked, and periodically in the case of initial failures.
* `EDDN.sendreplay()` is no longer used.
* In `prefsvarschanged()` there was a reference to `eddn.replayfile`, so as
to grey out the "Delay sending..." option if the file wasn't available.
So that's moot and also removed, but also...
* Comment the purpose of that line in `prefsvarchanged()` because it's not
immediately obvious.
In some cases the check might already have been done, but if not then this
is the last easy place to perform it.
NB: Unlike the old code this does *not* attempt to check "are we docked
*now* ?" for triggering sending of previously queue messages. That's
going to need a thread worker.
It's easier to check "should we send this message at all?" earlier. Currently
all of the following ('station data') do so:
* CAPI commodity, outfitting (also fcmaterials) and shipyard.
* Journal commodity, fcmaterials, outfitting, and shipyard.
This flag controls whether commodity, outfitting or shipyard schema messages
are sent. Thus 'MKT' ('market') is misleading. Rename it so the intent when
used is clear.
Athanasius
aussig
Athanasius
Philipp Trulson