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.
* If you request docking successfully then show the station namd and
have the link work.
* This is then only undone if you:
1) Dock and undock
2) Supercruise away
3) Jump away
It is *not* undone if you simply cancel the docking request.
Tested only with same provider for system and station for each of the
three, not the other 6 combinations.
* 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!
I had to pull a diff out of the old branch, apply it, and reverse things
like the addition of logging. This needs to be the minimum change for
the fix.
Tested with a quick login, then spamming market buy/sell orders. They
were correctly queued and then sent after 30s since previous API calls.
* Use same state logic as Inara plugin now has.
* this.system_link for the Tk item, this.system is the system name.
* Ensure station text+link set on prefs change.
# Add a set of future TODO items.
* 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.
* Track all of: this.system_address, this.system_population,
this.system_marketid
* Use this.system_address if set (only from journal) for no-dupes Inara
system URL.
* Added the "'x' if undocked and show system info" functionality from
EDDB plugin.
* This version will set target station name/link if you request docking
with it, whether that succeeds or not. Cleared not only on Undock, but
also FSDJump and SupercruiseEntry (in case you never actually docked).
* No longer bothering setting system and station URLs from Inara API
response as we have working ones anyway. So even those without Inara
API Key set get the functionality now.
* Artie added a 'by-systemaddress' system lookup, use it.
* This means we probably no longer need to update URLs in the
inara_notify_location() function.
* 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}
This works by checking on _any_ event the status of the cargo vs the
current stored version. If the live cargo differs from the updated
cargo, _and_ we have not sent any update in the past 45 seconds (as this
would have contained the cargo anyway), we queue an actual send to the
API.
This unfortunately isn't checked only when docked, but on the plus side
miners will be happy to have their cargo updated relatively often.
Fixes#477. Possibly not quite what they wanted, but its about as close
as this will get
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.
The UI for setting the 'anonymous' option was removed in
f17f5d3f257e2359d4728ce8c296d70dc5e7609f ("PKCE OAuth2 access to cAPI").
Since then there's been no way for a user to set, or unset, this option
(and the associated custom uploaderID). However anyone with the registry keys
still set would have had them take effect.
This commit removes the last bits of code that were making use of it.
Note that the EDDN Relay anonymises all uploaderID values, so no listener
has been seeing the 'raw' values for a long time now.
close#575
* 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.
EDDB station link now triggers off this.system_population, which is
received via monitor passing 'Population' through in Startup, Location,
FSDJump and CarrierJump events.
One fewer use cases for systems.p (populated status in this case).
This shouldn't actually be necessary, the marketid shouln't change
because of a jump, and would have been picked up from the other events
anyway, but it should do no harm to set it again from this.
* Adds monitor.station_marketid, tracked at the same points as
monitor.station (name).
* Changes EDDB plugin to also track its own this.station_marketid so
that it can be used in /market-id/ EDDB URL.
This removes a use case for stations.p file.
* new class `PrefsVersion` in prefs.py. A singleton `prefsSaved` (note
case) is created.
* When new preferences are added and require defaults on first run the
code should use:
`if prefsVersion.shouldSetDefaults(<prior release version>, [<optional old test>]):`
to check if defaults should be set in preferences. So if prior release
was '3.4.6.0' and you've added a new preference with defaults you should
call this with '3.4.6.0' as the first argument.
The <optional old test> is really only for historical purposes, as a
fallback in case no 'PrefsVersion' has yet been set in the user's
Registry/settings file.
* Any code that adds such a new preference **MUST** make changes to the
`versions` dictionary in the PrefsVersion class.
1. Add the predicted next version to the dictionary, with number one
higher than 'current'
2. Set 'current' equal to that new value.
Obviously if other post-last-release code has already done this then you
don't need to.
Failure to update the versions dictionary in this manner will lead to an
Exception being raised, and the code the preferences are for failing
(i.e. EDDN means no EDDN tab on Settings).
Closes#407
Change Output and EDDN options to only get set to defaults if key 'PrefsDidSave' is not present and true. This gets a value of 0x1 saved any time preferences are applied.
The issue was that if you had sufficient options set such that the saved 'output' value was 0x0 then that would evaluate to false and cause the defaults to get set.
Fixes#407
*) Code and imports brought in line with edsy plugin
*) 'Coriolis' now appears in Settings > Configuration > Shipyard
dropdown
*) Confirmed that with this active a valid build opens on coriolis.io
This came to light due to python3 not liking try['StarPos'] =
list(this.coordinates) if this.coordinates was None. As the comment
says these three fields are mandatory, ensure we can actually set them
appropriately, and display an error if not.
