Release Elite Dangerous Market Connector (EDMC)

Latest Python releases no longer support Windows 7

I've been made aware that all Python 3.9 releases state " Note that Python 3.9.4 cannot be used on Windows 7 or earlier. " or similar. Ref: https://www.python.org/downloads/windows/

The upcoming EDMC 5.0.0 will be using Python 3.9.4 and as such, according to that quote, will not work on Windows 7, but will continue to work with Windows 8/8.1 and Windows 10.

In the long-term I expect a future Python release to drop support for Windows 8/8.1, and possibly at some point only support Windows 10 versions newer than some release.

Whilst it's definitely still possible to upgrade a Windows 7/8/8.1 install to Windows 10 for free I'm aware that for some people there's hardware incompatibility that prevents this.

We could try to put out separate installers using latest Python 3.8 for the build, but at some point Python 3.8 will no longer be supported, and sooner than this we'll likely start using Python 3.9+ specific features in the code.

I'd appreciate comments from anyone still on Windows 7 who currently uses EDMC.
As far as I know Python support for windows 7 is discontinued for one reason only, Windows 7 itself is no longer supported.
I do not write a lot of Python and I am surprised that I need to apply any special abilities to this project which cannot work with Python 3.6.
Maybe these are some specific networking functions.
 
As far as I know Python support for windows 7 is discontinued for one reason only, Windows 7 itself is no longer supported.
Oh, indeed, and I would have preferred we drop anything but Windows 10 (still supported builds) for EDMC in the past year. However Frontier themselves still list "OS: Windows 7/8/10 64 bit" for the game on both their own store and Steam (and presumably Epic as well), so I felt we still had to make best efforts to match that.

Given the on-going efforts to clean up and modernise the EDMC source code I am not willing to hold things back to Python 3.8 at best.

Someone did try out 5.0.0-beta6, where we're building with Python 3.9.4, on their Windows 7 install and said "Nope. Crashes on startup. "api-ms-win-core-path-l1-1-0.dll" is missing. I believe that's a Windows 8 file." We will not start messing with trying to ship that ourselves (without trying it there's no guarantee the DLL will work with Python 3.9).

I do not write a lot of Python and I am surprised that I need to apply any special abilities to this project which cannot work with Python 3.6.
Maybe these are some specific networking functions.
I'm not quite sure what you mean by this. Until recently the EDMC source should have worked with any Python 3.x, but we have started (at least) using the new-in-Python3.8 'walrus' operator ":=" so that's definitely the minimum. Some upcoming code will also start using some 'future' imports that mean we need Python 3.9+.

In general there should be an expectation that EDMC will move to the latest stable release of Python as it's available (perhaps skipping X.Y.0, and certainly there'd be a delay until we actually have a need for a new release otherwise). At some point the current Windows 8/8.1 support will also drop.
 
Oh, indeed, and I would have preferred we drop anything but Windows 10 (still supported builds) for EDMC in the past year. However Frontier themselves still list "OS: Windows 7/8/10 64 bit" for the game on both their own store and Steam (and presumably Epic as well), so I felt we still had to make best efforts to match that.

Given the on-going efforts to clean up and modernise the EDMC source code I am not willing to hold things back to Python 3.8 at best.

Someone did try out 5.0.0-beta6, where we're building with Python 3.9.4, on their Windows 7 install and said "Nope. Crashes on startup. "api-ms-win-core-path-l1-1-0.dll" is missing. I believe that's a Windows 8 file." We will not start messing with trying to ship that ourselves (without trying it there's no guarantee the DLL will work with Python 3.9).


I'm not quite sure what you mean by this. Until recently the EDMC source should have worked with any Python 3.x, but we have started (at least) using the new-in-Python3.8 'walrus' operator ":=" so that's definitely the minimum. Some upcoming code will also start using some 'future' imports that mean we need Python 3.9+.

In general there should be an expectation that EDMC will move to the latest stable release of Python as it's available (perhaps skipping X.Y.0, and certainly there'd be a delay until we actually have a need for a new release otherwise). At some point the current Windows 8/8.1 support will also drop.
I try to avoid the use of lambda, let me write a little more when it looks more understandable.

P.S. And I'm not quite sure what you're using from 3.9.x because 3.8.x still supports Windows 7
 
Last edited:
With the announcement of Odyssey PC Launch on 19th May the more people we have testing the 5.0.0 betas now the less likely it is we'll have to scramble to fix bugs when that's released as the new stable version, which will be before Odyssey launches.

Currently we're waiting for Phase 4 of the alpha in order to be sure of what the state of Journal and CAPI data is for our added support. 5.0.0 betas already run without errors with Odyssey.
 
Anyone has any idea how to make EDMC to stop constantly asking for login? When I start the program it asks me to log into Frontier, and again as I start the game, and every now and then during the game. I thought it might have been the Canonn plugin, but disabling it didnt help.
 
Anyone has any idea how to make EDMC to stop constantly asking for login? When I start the program it asks me to log into Frontier, and again as I start the game, and every now and then during the game. I thought it might have been the Canonn plugin, but disabling it didnt help.
Assuming you did actually login the once then this is a bug, please report it - and, yes, we really do need all the information that the template asks for.
 

As of release 5.0.0 (including betas) we no longer support Windows 7. This is due to moving to Python 3.9.x, which itself does not now support Windows 7. The application (both EDMarketConnector.exe and EDMC.exe) will crash on startup due to a missing DLL.


Pre-Release 5.0.0-beta7

  • More work has been done for Odyssey, with extra and expanded Journal events now available. Suits and their Loadouts will track better now, although we still require a CAPI data pull (an 'Update') to be guaranteed data about them.

Plugin Developers​

  • The state passed to plugins has for a long time had a 'Credits' member, but until now no effort was made to keep this record of the credits balance up to date after the initial LoadGame event. This has now been addressed, and the balance should stay in sync as best it can from the available Journal events. It will always correct back to the actual balance on each CAPI data pull.
  • Suits and SuitLoadouts in state will now always be a dict, even if the array is not sparse, and will never be None. This allows for consistency in how you access the members. Note that the id field found on e.g. weapon details in suit loadouts may be None if we got the data from the Journal rather than the CAPI data.
  • BackPack items will now track better. However note that the lack of a Journal event when throwing a grenade, along with no BackPackMaterials event if logging in on-foot means that we can't track this inventory perfectly.
  • Ship Cargo in state now takes account of any CargoTransfer events. This was added to the game in the Fleet Carriers update, but also covers transfers to/from an SRV.
 

Pre-Release 5.0.0-beta8

  • If the application detects it's running against a non-live (alpha or beta) version of the game it will append " (beta)" to the Commander name on the main UI.
  • Don't assume some Journal events always have a 'Cost' value.
  • Removed a stray piece of code relating to the aborted systray implementation. This would have caused minimising of the application to hide the window. Only triggered if you'd tried our develop branch whilst the systray code was active, and left the option "Minimize to systray" active.

Plugin Developers​

  • monitor.state['OnFoot'] is now set True for a DropshipDeploy event.
  • Better detect that we're back on-foot from Disembark on a station.
  • Better Docked event processing to cater for the more limited form of this event in an Apex taxi.
 

We intend to release this version as the final 5.0.0 by 12th May 2021 latest unless major issues come to light. The current release 4.2.7 will NOT work well with Odyssey. It is in everyone's interests to test this version and get bugs fixed before Odyssey launches.


Pre-Release 5.0.0-rc1

Python 3.9​

  • We now test against, and package with, Python 3.9.5.
    As a consequence of this we no longer support Windows 7. This is due to Python 3.9.x itself not supporting Windows 7. The application (both EDMarketConnector.exe and EDMC.exe) will crash on startup due to a missing DLL.
    This should have no other impact on users or plugin developers, other than the latter now being free to use features that were introduced since the Python 3.7 series.
    Developers can check the contents of the .python-version file in the source (it's not distributed with the Windows installer) for the currently used version in a given branch.

Changes and Enhancements​

  • If the application detects it's running against a non-live (alpha or beta) version of the game it will append " (beta)" to the Commander name on the main UI.
  • Updated translations. Once more, thanks to all the translators!
  • We now sanity check a returned Frontier Authentication token to be sure it's for the current Commander. If it's not you'll see Error: customer_id doesn't match! on the bottom status line. Double-check you're using the correct credentials when authing!
  • New 'Main window transparency' slider on Settings > Appearance.
  • New command-line argument for EDMarketConnector.exe --reset-ui. This will:
    1. Reset to the default Theme.
    2. Reset the UI transparency to fully opaque.
    3. The intention is this can be used if you've lost sight of the main window due to tweaking these options.
  • New CL arg for EDMarketConnector.exe --force-edmc-protocol. This is really only of use to core developers (its purpose being to force use of the edmc:// protocol for Frontier Auth callbacks, even when not 'frozen').
  • Linux config will be flushed to disk after any change. This means that EDMC.py can now actually make use of the latest CAPI auth if it's been updated by EDMarketConnector.py since that started.
    If you want to run multiple instances of the application under Linux then please check the updated Troubleshooting: Multi-Accounting wiki entry.
  • Linux and macOS: You can now set a font name and size in your config file. Ensuring this is a TTF font, rather than a bitmap font, should allow the application UI scaling to work.
    1. 'font' - the font name to attempt using
    2. 'font_size' - the font size to attempt using.
    3. There is no UI for this in Preferences, you will need to edit your config file to set or change it, and then restart the application.
    This is not supported on Windows so as not to risk weird bugs. UI Scaling works on Windows without this.
  • We now also cite the git 'short hash' in the version string. For a Windows install of the application this is sourced from the .gitversion file (written during the build process).
    When running from source we attempt to use the command git rev-parse --short HEAD to obtain this. If this doesn't work it will be set to 'UNKNOWN'.
  • We have added a 'killswitch' feature to turn off specific functionality if it is found to have a bug. An example use of this would be in an "oh ! we're sending bad data to EDDN!" moment so as to protect EDDN listeners such as EDDB.
    If we ever have to use this we'll announce it clearly and endeavour to get a fixed version of the program released ASAP. We will NOT be using this merely to try and get some laggards to upgrade.
  • Our logging code will make best efforts to still show class name and other such fields if it has trouble finding any of the required data for the calling frame. This means no longer seeing ??:??:?? when there is an issue with this.
  • macOS: We've managed to test the latest code on macOS Catalina. Other than keyboard shortcut support not working it appears to be working.
  • We've pulled the latest Coriolis data which might have caused changes to ship and module names as written out to some files.

Odyssey​

Every effort was made during the Odyssey Alphas to ensure that this application will continue to function correctly with it. As always, make a Bug Report if you find anything not working, but be sure to check our Known Issues first.
  • A new UI element 'Suit' now appears below 'Ship' when applicable. It details the type of suit you currently have equipped and its Loadout name. This UI element is collapsed/hidden if no suit/on-foot state is detected, e.g. not playing Odyssey.
  • Note that we can only reliably know about Suits and their Loadouts from a CAPI data pull (which is what we do automatically on docking if configured to do so, or when you press the 'Update' button). We do attempt to gather this data from Journal events as well, but if you switch to a Suit Loadout that hasn't been mentioned in them yet we won't be able to display that until the next CAPI data pull.
If anyone becomes aware of a 'suit loadouts' site/tool, a la Coriolis/EDSY but for Odyssey Suits, do let us know so we can add support for it! We're already kicking around ideas to e.g. place JSON text in the clipboard if the Suit Loadout is clicked.

Bug Fixes​

  • Fix ship loadout export to files to not trip up in the face of file encoding issues. This relates to the 'Ship Loadout' option on the 'Output' tab of Settings/Preferences.
  • Ship Type/Name will now be greyed out, and not clickable, if we don't currently have loadout information for it. This prevents trying to send an empty loadout to your shipyard provider.
  • Bug fixed when handling CAPI-sourced shipyard information. This happens due to a Frontier bug with not returning shipyard data at all for normal stations.
    It has been observed that Frontier has fixed this bug for Odyssey.
  • Don't try to get Ship information from LoadGame event if directly in CQC.
  • Inara: Don't attempt to send an empty setCommanderReputationMajorFaction API call. This quietens an error from the Inara API caused when a Cmdr literally has no Major Faction Reputation yet.

Code Clean Up​

  • Code pertaining to processing Journal events was reworked and noisy logging reduced as a consequence.
  • A little TRACE logging output has been commented out for now.
  • The code for File > Status has been cleaned up.
  • Localisation code has been cleaned up.
  • Code handling the Frontier Authorisation callback on Windows has been cleaned up.
  • A lot of general code cleanup relating to: Inara, outfitting, Frontier CAPI, hotkey (manual Updates), dashboard (Status.json monitoring), commodities files, and ED format ship loadout files.

Plugin Developers​

  • The files stations.p and systems.p have been removed from the Windows Installer. These were never intended for third-party use. Their use in core code was for generating EDDB-id URLs, but we long since changed the EDDB plugin's handlers for that to use alternate URL formats based on game IDs or names.
    If you were using either to lookup EDDB IDs for systems and/or stations then please see how system_url() and station_url() now work in plugins/eddb.py.
    This change also removed the core (not plugin) eddb.py file which generated these files. You can find it still in the git history if needs be. It had gotten to the stage where generating systems.p took many hours and required 64-bit Python to have any hope of working due to memory usage.
  • All static data that is cleared for use by plugins is now in the file edmc_data.py and should be imported from there, not any other module.
    The one thing we didn't move was the 'bracket map' dictionaries in td.py as they're for use only by the code in that file.
    All future such data will be added to this file, and we'll endeavour not to make breaking changes to any of it without increasing our Major version.
  • config.appversion() is now a function that returns a semantic_version.Version. In contexts where you're expecting a string this should mostly just work. If needs be wrap it in str().
  • Example plugin plugintest updated. This includes an example of how to check core EDMC version if needs be. This example is also in PLUGINS.md.
  • config.py has undergone a major rewrite. You should no longer be using config.get(...) or config.getint(...), which will both give a deprecation warning. Use instead the correct config.get_<type>() function:
    • config.get_list(<key>)
    • config.get_str(<key>)
    • config.get_bool(<key>)
    • config.get_int(<key>)
    • Setting still uses config.set(...).
  • We now change the current working directory of EDMarketConnector.exe to its location as soon as possible in its execution. We're also paranoid about ensuring we reference the full path to the .gitversion file.
    However, no plugin should itself call os.chdir(...) or equivalent. You'll change the current working directory for all core code and other plugins as well (it's global to the whole process, not per-thread). Use full absolute paths instead (pathlib is what to use for this).
  • The state dict passed to plugins in journal_entry() calls (which is actually monitor.state in the core code) has received many additions relating to Odyssey, as well as other fixes and enhancements.
    1. Support has been added for the NavRoute (not Route as v28 of the official Journal documentation erroneously labels it) Journal event and its associated file NavRoute.json. See PLUGINS.md:Events documentation
    2. Similarly, there is now support for the ModuleInfo event and its associated ModulesInfo.json file.
    3. state['Credits'] - until now no effort was made to keep this record of the credits balance up to date after the initial LoadGame event. This has now been addressed, and the balance should stay in sync as best it can from the available Journal events. It will always correct back to the actual balance on each CAPI data pull or game relog/restart.
    4. state['Cargo'] now takes account of any CargoTransfer events. This was added to the game in the Fleet Carriers update, but also covers transfers to/from an SRV.
    5. state['OnFoot'] is a new boolean, set true whenever we detect the Cmdr is on-foot, i.e. not in any type of vehicle (Cmdr's own ship, SRV, multi-crew in another Cmdr's ship, Apex taxi, or a Dropship).
    6. state['Suits'] and state['SuitLoadouts'] added as dicts containing information about the Cmdr's owned Suits and the Loadouts the Cmdr has defined to utilise them (and on-foot weapons).
      Note that in the raw CAPI data these are arrays if all members contiguously exist, else a dictionary, but we have chosen to always coerce these to a python dict for simplicity. They will be empty dicts, not None if there is no data.
      We use the CAPI data names for keys, not the Journal ones - e.g. slots for weapons equipped, not Modules.
      The id field found on e.g. weapon details in suit loadouts may be None if we got the data from the Journal rather than the CAPI data.
      NB: This data is only guaranteed up to date and correct after a fresh CAPI data pull, as the current Journal events don't allow for updating it on the fly (this should change in a future Odyssey patch).
    7. state['SuitCurrent'] and state['SuitLoadoutCurrent'] contain the obvious "currently in use" data as per the Suits/SuitLoadouts.
    8. Tracking of the new Odyssey 'Microresources' has been added:
      1. Component - dict for 'Ship Locker' inventory.
      2. Item - dict for 'Ship Locker' inventory.
      3. Consumable - dict for 'Ship Locker' inventory.
      4. Data - dict for 'Ship Locker' inventory.
      5. BackPack - on-foot inventory, a dict containing again dicts for Component, Item, Consumable and Data. However note that the lack of a Journal event when throwing a grenade, along with no BackPackMaterials event if logging in on-foot means that we can't track the BackPack inventory perfectly.
    9. See the updated PLUGINS.md file for details.
  • Note that during the Odyssey Alpha it was observed that the CAPI data['commander']['docked'] boolean was always true if the Cmdr was in their ship. This is a regression from pre-Odyssey behaviour. The core EDMC code copes with this. Please add a reproduction to the issue about this: PTS CAPI saying Commander is Docked after jumping to new system.
 

Release 5.0.0

Python 3.9​

  • We now test against, and package with, Python 3.9.5.
    As a consequence of this we no longer support Windows 7.
    This is due to Python 3.9.x itself not supporting Windows 7.
    The application (both EDMarketConnector.exe and EDMC.exe) will crash on startup due to a missing DLL.

    This should have no other impact on users or plugin developers, other than the latter now being free to use features that were introduced since the Python 3.7 series.
    Developers can check the contents of the .python-version file in the source (it's not distributed with the Windows installer) for the currently used version in a given branch.

This Update Is Mandatory​

This release is a mandatory upgrade for the release of Elite Dangerous Odyssey. Any bug reports against earlier releases, pertaining to Odyssey or not, will be directed to reproduce them with 5.0.0 or later. There are also minor bugs in 4.2.7 and earlier that have been fixed in this version. There will NOT be another 4.2.x release.
The major version has been incremented not for Odyssey support, but because we have made some minor breaking changes to the APIs we provide for plugin developers.
Due to these plugin API changes (see below) users might need to update their plugins. A check of all the Plugins we know about only found one with an issue related to the move to edmc_data.py, the developer was informed and the issue addressed.
Other plugins should, at most, log deprecation warnings about the config changes (again, see below).
In the first instance please report any issues with plugins to their developers, not us. They can contact us about EDMC core code issues if they find such in their investigations.
All plugin developers would benefit from having a GitHub account and then setting up a watch on EDMarketConnector of at least 'Releases' under 'Custom'.
NB: If you had any beta or -rc1 of 5.0.0 installed and see anything weird with this full release it would be advisable to manually uninstall, confirm the installation directory (default c:\Program Files (x86)\EDMarketConnector) is empty, and then re-install 5.0.0 to be sure you have a clean, working, install. Anyone upgrading from 4.2.7 or earlier shouldn't see any issues with this.

Changes and Enhancements​

  • If the application detects it's running against a non-live (alpha or beta) version of the game it will append " (beta)" to the Commander name on the main UI.
  • Updated translations. Once more, thanks to all the translators!
  • We now sanity check a returned Frontier Authentication token to be sure it's for the current Commander. If it's not you'll see Error: customer_id doesn't match! on the bottom status line. Double-check you're using the correct credentials when authing!
  • New 'Main window transparency' slider on Settings > Appearance.
  • New command-line argument for EDMarketConnector.exe --reset-ui. This will:
    1. Reset to the default Theme.
    2. Reset the UI transparency to fully opaque.
    The intention is this can be used if you've lost sight of the main window due to tweaking these options.
    There is a new file EDMarketConnector - reset-ui.bat to make utilising this easy on Windows.
  • New CL arg for EDMarketConnector.exe --force-edmc-protocol. This is really only of use to core developers (its purpose being to force use of the edmc:// protocol for Frontier Auth callbacks, even when not 'frozen').
  • Linux config will be flushed to disk after any change. This means that EDMC.py can now actually make use of the latest CAPI auth if it's been updated by EDMarketConnector.py since that started.
    If you want to run multiple instances of the application under Linux then please check the updated Troubleshooting: Multi-Accounting wiki entry.
  • Linux and macOS: You can now set a font name and size in your config file. Ensuring this is a TTF font, rather than a bitmap font, should allow the application UI scaling to work.
    1. 'font' - the font name to attempt using
    2. 'font_size' - the font size to attempt using.
    There is no UI for this in Preferences, you will need to edit your config file to set or change it, and then restart the application.
    This is not supported on Windows so as not to risk weird bugs. UI Scaling works on Windows without this.
  • We now also cite the git 'short hash' in the version string. For a Windows install of the application this is sourced from the .gitversion file (written during the build process).
    When running from source we attempt to use the command git rev-parse --short HEAD to obtain this. If this doesn't work it will be set to 'UNKNOWN'.
  • We have added a 'killswitch' feature to turn off specific functionality if it is found to have a bug. An example use of this would be in an "oh ! we're sending bad data to EDDN!" moment so as to protect EDDN listeners such as EDDB.
    If we ever have to use this we'll announce it clearly and endeavour to get a fixed version of the program released ASAP. We will NOT be using this merely to try and get some laggards to upgrade.
    Plugin Developers: See Killswitches.md for more information about this.
  • Our logging code will make best efforts to still show class name and other such fields if it has trouble finding any of the required data for the calling frame. This means no longer seeing ??:??:?? when there is an issue with this.
  • macOS: We've managed to test the latest code on macOS Catalina. Other than keyboard shortcut support not working it appears to be working.
  • We've pulled the latest Coriolis data which might have caused changes to ship and module names as written out to some files.

Odyssey​

Every effort was made during the Odyssey Alphas to ensure that this application will continue to function correctly with it. As always, make a Bug Report if you find anything not working, but be sure to check our Known Issues first.
  • A new UI element 'Suit' now appears below 'Ship' when applicable. It details the type of suit you currently have equipped and its Loadout name. This UI element is collapsed/hidden if no suit/on-foot state is detected, e.g. not playing Odyssey.
  • Note that we can only reliably know about Suits and their Loadouts from a CAPI data pull (which is what we do automatically on docking if configured to do so, or when you press the 'Update' button). We do attempt to gather this data from Journal events as well, but if you switch to a Suit Loadout that hasn't been mentioned in them yet we won't be able to display that until the next CAPI data pull.
If anyone becomes aware of a 'suit loadouts' site/tool, a la Coriolis/EDSY but for Odyssey Suits, do let us know so we can add support for it! We're already kicking around ideas to e.g. place JSON text in the clipboard if the Suit Loadout is clicked.

Bug Fixes​

  • Fix ship loadout export to files to not trip up in the face of file encoding issues. This relates to the 'Ship Loadout' option on the 'Output' tab of Settings/Preferences.
  • Ship Type/Name will now be greyed out, and not clickable, if we don't currently have loadout information for it. This prevents trying to send an empty loadout to your shipyard provider.
  • Bug fixed when handling CAPI-sourced shipyard information. This happens due to a Frontier bug with not returning shipyard data at all for normal stations.
    It has been observed that Frontier has fixed this bug for Odyssey.
  • Don't try to get Ship information from LoadGame event if directly in CQC.
  • Inara: Don't attempt to send an empty setCommanderReputationMajorFaction API call. This quietens an error from the Inara API caused when a Cmdr literally has no Major Faction Reputation yet.

Code Clean Up​

  • Code pertaining to processing Journal events was reworked and noisy logging reduced as a consequence.
  • A little TRACE logging output has been commented out for now.
  • The code for File > Status has been cleaned up.
  • Localisation code has been cleaned up.
  • Code handling the Frontier Authorisation callback on Windows has been cleaned up.
  • A lot of general code cleanup relating to: Inara, outfitting, Frontier CAPI, hotkey (manual Updates), dashboard (Status.json monitoring), commodities files, and ED format ship loadout files.

Plugin Developers​

  • The files stations.p and systems.p have been removed from the Windows Installer. These were never intended for third-party use. Their use in core code was for generating EDDB-id URLs, but we long since changed the EDDB plugin's handlers for that to use alternate URL formats based on game IDs or names.
    If you were using either to lookup EDDB IDs for systems and/or stations then please see how system_url() and station_url() now work in plugins/eddb.py.
    This change also removed the core (not plugin) eddb.py file which generated these files. You can find it still in the git history if needs be. It had gotten to the stage where generating systems.p took many hours and required 64-bit Python to have any hope of working due to memory usage.
  • All static data that is cleared for use by plugins is now in the file edmc_data.py and should be imported from there, not any other module.
    The one thing we didn't move was the 'bracket map' dictionaries in td.py as they're for use only by the code in that file.
    All future such data will be added to this file, and we'll endeavour not to make breaking changes to any of it without increasing our Major version.
  • config.appversion() is now a function that returns a semantic_version.Version. In contexts where you're expecting a string this should mostly just work. If needs be wrap it in str().
    For backwards compatibility with pre-5.0.0 you can use:
from config import appversion

if callable(appversion):
edmc_version = appversion()
else:
edmc_version = appversion
  • Example plugin plugintest updated. This includes an example of how to check core EDMC version if needs be. This example is also in PLUGINS.md.
  • config.py has undergone a major rewrite. You should no longer be using config.get(...) or config.getint(...), which will both give a deprecation warning. Use instead the correct config.get_<type>() function:
    • config.get_list(<key>)
    • config.get_str(<key>)
    • config.get_bool(<key>)
    • config.get_int(<key>)
    Setting still uses config.set(...).
    So:
    1. Replace all instances of config.get() and config.getint() as above.
    2. For ease of maintaining compatibility with pre-5.0.0 versions include this code in at least one module/file (no harm in it being in all that manipulate plugin config):
from config import config

# For compatibility with pre-5.0.0
if not hasattr(config, 'get_int'):
config.get_int = config.getint

if not hasattr(config, 'get_str'):
config.get_str = config.get

if not hasattr(config, 'get_bool'):
config.get_bool = lambda key: bool(config.getint(key))

if not hasattr(config, 'get_list'):
config.get_list = config.get

  • Utilising our provided logging from a class-level, i.e. not a solid instance of a class, property/function will now work.
  • We now change the current working directory of EDMarketConnector.exe to its location as soon as possible in its execution. We're also paranoid about ensuring we reference the full path to the .gitversion file.
    However, no plugin should itself call os.chdir(...) or equivalent. You'll change the current working directory for all core code and other plugins as well (it's global to the whole process, not per-thread). Use full absolute paths instead (pathlib is what to use for this).
  • The state dict passed to plugins in journal_entry() calls (which is actually monitor.state in the core code) has received many additions relating to Odyssey, as well as other fixes and enhancements.
    1. Support has been added for the NavRoute (not Route as v28 of the official Journal documentation erroneously labels it) Journal event and its associated file NavRoute.json. See PLUGINS.md:Events documentation
    2. Similarly, there is now support for the ModuleInfo event and its associated ModulesInfo.json file.
    3. state['Credits'] - until now no effort was made to keep this record of the credits balance up to date after the initial LoadGame event. This has now been addressed, and the balance should stay in sync as best it can from the available Journal events. It will always correct back to the actual balance on each CAPI data pull or game relog/restart.
    4. state['Cargo'] now takes account of any CargoTransfer events. This was added to the game in the Fleet Carriers update, but also covers transfers to/from an SRV.
    5. state['OnFoot'] is a new boolean, set true whenever we detect the Cmdr is on-foot, i.e. not in any type of vehicle (Cmdr's own ship, SRV, multi-crew in another Cmdr's ship, Apex taxi, or a Dropship).
    6. state['Suits'] and state['SuitLoadouts'] added as dicts containing information about the Cmdr's owned Suits and the Loadouts the Cmdr has defined to utilise them (and on-foot weapons).
      Note that in the raw CAPI data these are arrays if all members contiguously exist, else a dictionary, but we have chosen to always coerce these to a python dict for simplicity. They will be empty dicts, not None if there is no data.
      We use the CAPI data names for keys, not the Journal ones - e.g. slots for weapons equipped, not Modules.
      The id field found on e.g. weapon details in suit loadouts may be None if we got the data from the Journal rather than the CAPI data.
      NB: This data is only guaranteed up to date and correct after a fresh CAPI data pull, as the current Journal events don't allow for updating it on the fly (this should change in a future Odyssey patch).
    7. state['SuitCurrent'] and state['SuitLoadoutCurrent'] contain the obvious "currently in use" data as per the Suits/SuitLoadouts.
    8. Tracking of the new Odyssey 'Microresources' has been added:
      1. Component - dict for 'Ship Locker' inventory.
      2. Item - dict for 'Ship Locker' inventory.
      3. Consumable - dict for 'Ship Locker' inventory.
      4. Data - dict for 'Ship Locker' inventory.
      5. BackPack - on-foot inventory, a dict containing again dicts for Component, Item, Consumable and Data.
        However note that the lack of a Journal event when throwing a grenade, along with no BackPackMaterials event if logging in on-foot means that we can't track the BackPack inventory perfectly.
    See the updated PLUGINS.md file for details.
  • As Status.json, and thus the EDMC 'dashboard' output now has a 'flags2' key we have added the associated constants to edmc_data.py with a Flags2 prefix on the names.
  • Note that during the Odyssey Alpha it was observed that the CAPI data['commander']['docked'] boolean was always true if the Cmdr was in their ship. This is a regression from pre-Odyssey behaviour. The core EDMC code copes with this. Please add a reproduction to the issue about this: PTS CAPI saying Commander is Docked after jumping to new system.
 
Hi, I have a sort of interrogation.

I have checked in option to automatically update data when docking and delay until docking is fully completed.
If I buy a certain material quantity, when I am leaving the station the new available quantity for this material is not updated in eddb right ?
Will it be more logical that the update data is processed when you take off from the station ? (If for example I buy all quantity available for one material, another player may travel to the station for nothing).

Thanx a lot for the update too (y)
 
Hi, I have a sort of interrogation.

I have checked in option to automatically update data when docking and delay until docking is fully completed.
If I buy a certain material quantity, when I am leaving the station the new available quantity for this material is not updated in eddb right ?
Will it be more logical that the update data is processed when you take off from the station ? (If for example I buy all quantity available for one material, another player may travel to the station for nothing).

Thanx a lot for the update too (y)
Three things can trigger sending of commodity data:

1. Have 'Automatically update on docking' set - EDMarketConnector.exe will pull Frontier CAPI data when it sees the 'Docked' journal event and send this out.
2. If you either don't have that active, or wait out the 1 minute cooldown you can press 'Update' to cause the same thing.
3. Opening the Commodities screen in-game will write a Market.json file and the application will send that data.

Note that in all cases if the data hasn't changed from what is stored internally then this duplicate data is not sent, i.e. if you auto-updated on dock and then open Commodities only the CAPI-sourced data is sent, assuming nothing has changed on the station between.

So, no, buying from the market will not cause new data to be sent out. We literally can't send the state of the market after you undock because you're no longer docked. We don't trust the CAPI data in this situation (it would require more fragile state tracking than we currently have to handle edge and corner cases) and as you're undocked you can't open the Commodities screen.
 
I got an "update available" message yesterday. My Antivirus blocked the download of the actual .msi from Github. Saying it is infected by Gen:Variant.Bulz.466715.
Can u please check?

Thanks for yur great work on EDMC!

Regards, Gluthor
 
Thanx Athan after any shopping I will do a manual update on EDMC or reopen the commodities market ;)
It's not really necessary to do this because commodities will get restocked over time. There must be a really high player trading-traffic (eg a trading CG) to make a difference.
 
Top Bottom