I would have added these during a mypy cleanup, but it turns out they're both
not necessary *and* it actually prevents the EDSM Settings tab from properly
populating.
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.
1. EDDB plugin tracked this for keeping the Station link text up to date.
* So moved it to monitor.state['SystemPopulation'].
* PLUGINS.md updated to cite this.
* PLUGINS.md also updated to note state entries that are set to None if
remote multi-crew is detected.
1. EDDB plugin needs to track the system name, but we're moving all of that
into monitor.py.
2. monitor.py was tracking this in monitor.system, but it needs to be in
monitor.state['SystemName'] in order for plugins to access it.
So, move monitor.system to monitor.state['SystemName'] and update all uses.
* 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.
As we're experimenting with per-plugin frames up a level `parent.children`
would need to be `parent.parent.children`, but this way it will Just Work
without knowledge of the hierarchy.
* `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 556ace5306bebbcf34c1a56a9023a822218a73f1 .
* 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.
