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.
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.
The 'if not this.station' was early paranoia when first getting things
working with Odyssey. It prevents a relog from Horizons (i.e. different
location) from correctly picking up an Odyssey login station when
on-foot in concourse.
Also, EDSM was defaulting wrongly for this.station_marketid. Not that
the plugin even *uses* that at this time.
* monitor.on_foot is now monitor.state['on_foot'] as plugins need to
access it.
* EDDB:journal_entry() now stores that in this.on_foot to check later.
* this.on_foot checked in cmdr_data() to actually set station name from
that data if needs be. This avoids setting it to STATION_UNDOCKED if
data['commander']['docked'] is False, when we're on_foot.
FSDTarget contains the target system under `SystemAddress`, meaning that
any time you selected a star other than the current one, plugins'
`this.system_address` was updated to that target, rather than the
current system. Said updating causes the links provided from system_url
to reflect that update (for providers that support ID64s).
This changes the journal_entry behaviour to only update
`this.system_address` when the event is any of Location, Docked,
or FSDJump, all of which contain only the current system.
* Make all plugins use `requests.utils.requote_uri()`
* Make all plugins use roughly the same logic, without if/else trees
(as the bodies do a `return ...`), ending with `return ''` if input
parameters are None.
This throws away the inara fallback to `this.station or this.system` as
it's unlikely the in-plugin tracking did a better job than the
monitor.py code.
By default the ttkHyperlinkLabels for 'system' and 'station' names have
their 'url' members set to the functions in EDMarketConnector.App.
The EDDB one used to override the function as it had to do that special
name -> EDDB ID lookup from systems.p. When I changed the code to not
need that any more I didn't fully understand what these overrides were.
After updating the EDDB code I then made sure the same logic was also in
the other plugins which meant they *also* set static strings, overriding
the call to the EDMarketConnector.App functions (which chain through to
the current plugin providers).
Unfortunately I didn't quite update the EDSM code enough causing
journal_entry() code to *not* set a new system 'url' despite changing
the 'text'. This meant that only CAPI updates (so docking and login)
caused the URL to change, despite updating the 'text' to the correct
system name.
Rather than have everything setting static strings just do away with the
overrides as they're not needed!
FSDTarget contains the target system under `SystemAddress`, meaning that
any time you selected a star other than the current one, plugins'
`this.system_address` was updated to that target, rather than the
current system. Said updating causes the links provided from system_url
to reflect that update (for providers that support ID64s).
This changes the journal_entry behaviour to only update
`this.system_address` when the event is any of Location, Docked,
or FSDJump, all of which contain only the current system.
* Make all plugins use `requests.utils.requote_uri()`
* Make all plugins use roughly the same logic, without if/else trees
(as the bodies do a `return ...`), ending with `return ''` if input
parameters are None.
This throws away the inara fallback to `this.station or this.system` as
it's unlikely the in-plugin tracking did a better job than the
monitor.py code.
By default the ttkHyperlinkLabels for 'system' and 'station' names have
their 'url' members set to the functions in EDMarketConnector.App.
The EDDB one used to override the function as it had to do that special
name -> EDDB ID lookup from systems.p. When I changed the code to not
need that any more I didn't fully understand what these overrides were.
After updating the EDDB code I then made sure the same logic was also in
the other plugins which meant they *also* set static strings, overriding
the call to the EDMarketConnector.App functions (which chain through to
the current plugin providers).
Unfortunately I didn't quite update the EDSM code enough causing
journal_entry() code to *not* set a new system 'url' despite changing
the 'text'. This meant that only CAPI updates (so docking and login)
caused the URL to change, despite updating the 'text' to the correct
system name.
Rather than have everything setting static strings just do away with the
overrides as they're not needed!
* Use same state logic as Inara plugin now has.
* this.system_link for the Tk item, this.system is the system name.
* List some tests to pass (and later to be implemented as unittests).
* Be paranoid about URIs, quote them.
* Ensure station text+link set on prefs change.
* Cleans up imports.
* Fixes some '<tab># ...' to use 2 spaces.
* Add type hints to system_url().
* Always store, even if not current provider: this.{system_address,
station_marketid,system_population}
We need a better way to do provider defaults. Heck, settings defaults period.
Let's assume we'll put in place a "standard" config file once we move to one.
See issue #586 - a user had incorrect system_address set, but only sometimes.
This could possibly be due to CAPI errors/lag, so only use it as the source
when the values aren't yet set. Otherwise Journal should always have provided
the correct value in a timely manner.
* This means storing this.system_address from both cmdr_data and journal_entry. NB: If the current value in the event or data is 'None' it will retain the previous value. Without this Journal entries without SystemAddress erase the stored value.
* The station_url() fallback to system_url() similarly uses this.system_address in the call.
Addresses #512
There is one tiny regression for a very, very corner case.
In 3.46 if you use EDDB as the 'Station' provider and:
1. Dock at Station A, in System X
2. Jump out to System Y, which is also populated
3. Exit out of the game
4. (Re-)Start EDMC
5. Hit 'Update' to manually trigger CAPI data retrieval
you will see a "×" character as the Station Name, and can click on it to
take you to the EDDB *System* page. It is only there because of EDMC
using systems.p to check if System Y is populated.
With this version in that circumstance there's no way to know that
System Y is populated, so the code assumes not and doesn't show the
"×", and thus there's nothing to click to go to the EDDB *System* page
for System Y.
But so long as the user is actually running the game and EDMC together
then populated status is detected from Journal events and the "×" will
be there whenever you're undocked but in a populated system.
Caveat: We know Frontier have allowed some systems that are
technically populated, but show a Population of zero. This code assumes
that means they're *not* populated.
