Release 3.44

CHANGE OF MAINTAINER

Due to a lack of time to give the project the attention it needs Marginal has handed over ownership of the EDMarketConnector GitHub repository to the EDCD (Elite Dangerous Community Developers) organisation.

Initially Athanasius will now be responsible for maintaining the code, including addressing any Pull Requests and Issues, and making releases. Unfortunately he has no access to hardware running MacOS so can't easily generate builds for that platform or test them. So for the time being releases will be for Windows 10 only. MacOS users are advised to look into running from source (see the github README).

Going forwards the intention is to move to the python 3.7 code as soon as possible. To facilitate this there will be one more python 2.7 release in addition to this one, with the main aim of that being to add code to alert the user about any plugins they use that have apparently not been updated to run under python 3.7.

See the project GitHub repository's README.md for further information.

• Version increased to 3.4.4.0 / 3.44.
• URL the application checks for updates changed to point to github,

Release 4.2.3

This release mostly addresses an issue when Frontier Authorisation gets stuck on 'Logging in...' despite completing the authorisation on the Frontier website.

• Allow edmc... argument to EDMarketConnector.exe. This should only be necessary when something has prevented your web browser from invoking the edmc protocol via DDE.

  If you were encountering the 'Logging in...' issue and still do with this release then please try running the application via the new EDMarketConnector - localserver-auth.bat file in the installation directory.

  This simply runs EDMarketConnector.exe with the --force-localserver-for-auth command-line argument. This forces the code to setup and use a webserver on a random port on localhost for the Frontier Authorisation callback, the same way it already works on non-Windows platforms.

• Add Korean translation to both the application and the installer.

Release 4.2.2

This release contains a minor bug-fix, actually properly checking a station's ships list before operating on it.

• Check that ships['shipuard_list'] is a dict before trying to use .values() on it. This fixes the issue with seeing list object has no attribute values in the application status line.

Release 4.2.1

This is a bug-fix release.

• Updated translations. Thanks once again to all those contributing as per Translations.

• PLUGINS.md: Clarify when CargoJSON is populated.

• macOS: pip install -r requirements.txt will now include pyobjc so that running this application works at all. Check the updated Running from source for some advice if attempting to run on macOS.

• JournalLock: Handle when the Journal directory isn't set at all, rather than erroring. Fixes #910 - Not launching (Linux).

• Extra logging added to track down cause of #909 - Authentication not possible (PC) . The debug log file might now indicate what's wrong, or we might need you to run

  "c:\Program Files (x86)\EDMarketConnector/EDMarketConnector.exe" --trace
  

  in order to increase the log level and gather some extra information. Caution is advised if sharing a --trace log file as it will now contain some of the actual auth data returned from Frontier.

• Ensure that 'Save Raw Data' will work. Fixes #908 - Raw export of CAPI data broken.

• Prevent EDDN plugin from erroring when we determine if the commander has Horizons. Fixes #907 - Modules is a list not a dict on damaged stations

Release 4.2.0

This release increases the Minor version due to the major change in how multiple-instance checking is done.

• Adds Steam and Epic to the list of "audiences" in the Frontier Auth callout so that you can authorise using those accounts, rather than their associated Frontier Account details.

• New status message "CAPI: No commander data returned" if a /profile request has no commander in the returned data. This can happen if you literally haven't yet created a Commander on the account. Previously you'd get a confusing 'commander' message shown.

• Changes the "is there another process already running?" check to be based on a lockfile in the configured Journals directory. The name of this file is edmc-journal-lock.txt and upon successful locking it will contain text like:

  Path: <configured path to your Journals>
  PID: <process ID of the application>
  

  The lock will be released and applied to the new directory if you change it via Settings > Configuration. If the new location is already locked you'll get a 'Retry/Ignore?' pop-up.

  For most users things will operate no differently, although note that the multiple instance check does now apply to platforms other than Windows.

  For anyone wanting to run multiple instances of the program this is now possible via:

  runas /user:<USER> "\"c:\Program Files (x86)\EDMarketConnector\EDMarketConnector.exe\" --force-localserver-for-auth"

  If anything has messed with the backslash characters there then know that you need to have " (double-quote) around the entire command (path to program .exe and any extra arguments), and as a result need to place a backslash before any double-quote characters in the command (such as around the space-including path to the program).

  I've verified it renders correctly on GitHub.

  The old check was based solely on there being a window present with the title we expect. This prevented using runas /user:SOMEUSER ... to run a second copy of the application, as the resulting window would still be within the same desktop environment and thus be found in the check.

  The new method does assume that the Journals directory is writable by the user we're running as. This might not be true in the case of sharing the file system to another host in a read-only manner. If we fail to open the lock file read-write then the application aborts the checks and will simply continue running as normal.

  Note that any single instance of EDMarketConnector.exe will still only monitor and act upon the latest Journal file in the configured location. If you run Elite Dangerous for another Commander then the application will want to start monitoring that separate Commander. See wiki:Troubleshooting#i-run-two-instances-of-ed-simultaneously-but-i-cant-run-two-instances-of-edmc which will be updated when this change is in a full release.

• Adds the command-line argument --force-localserver-for-auth. This forces using a local webserver for the Frontier Auth callback. This should be used when running multiple instances of the application for all instances else there's no guarantee of the edmc:// protocol callback reaching the correct process and Frontier Auth will fail.

• Adds the command-line argument --suppress-dupe-process-popup to exit without showing the warning popup in the case that EDMarketConnector found another process already running.

  This can be useful if wanting to blindly run both EDMC and the game from a batch file or similar.

Release 4.1.6

We might have finally found the cause of the application hangs during shutdown. Note that this became easier to track down due to the downtime for migration of www.edsm.net around 2021-01-11. Before these fixes EDSM's API not being available would cause an EDMC hang on shutdown.

• We've applied extra paranoia to some of the application shutdown code to ensure we're not still trying to handle journal events during this sequence.

  We also re-ordered the shutdown sequence, which might help avoid the shutdown hang.

  If you encounter a shutdown hang then please add a comment and log files to Application can leave a zombie process on shutdown #678 to help us track down the cause and fix it.

• We now avoid making Tk event_generate() calls whilst the appliction is shutting down.

• Plugins should actively avoid making any sort of Tk event_generate() call during application shutdown.

  This means using if not config.shutting_down: to gate any code in worker threads that might attempt this. Also, be sure you're not attempting such in your plugin_stop() function.

  See plugins/edsm.py and plugins/inara.py for example of the usage.

• Any use of plug.show_error() won't actually change the UI status line during shutdown, but the text you tried to show will be logged instead.

• Cargo tracking will now correctly count all instances of the same type of cargo for different missions. Previously it only counted the cargo for the last mission requiring that cargo type, as found in Cargo.json.

• The loaded contents of Cargo.json can now be found in monitor.state['CargoJSON']. monitor.state is what is passed to plugins as state in the journal_entry() call.

• Our logging code should now cope with logging from a property.

• Logging from any name-mangled method should now work properly.

• Miscellaneous updates to PLUGINS.md - mostly to clarify some things.