Release Elite Dangerous Market Connector (EDMC)

Status
Thread Closed: Not open for further replies.

Release 5.1.2

  • A Journal event change in EDO Update 6 will have caused some translated suit names to not be properly mapped to their sane versions. This change has now been addressed and suit names should always come out as intended in the EDMarketConnector.exe UI.
  • There is a new command-line argument to cause all Frontier Authorisation to be forgotten: EDMarketConnector.exe --forget-frontier-auth.
  • Situations where Frontier CAPI data doesn't agree on the location we have tracked from Journal events will now log more useful information.

Bug Fixes​

  • The code should now be robust against the case of any Journal event name changing.

Plugin Developers​

  • We now store GameLanguage, GameVersion and GameBuild in the state passed to journal_entry() from the LoadGame event.
  • Various suit data, i.e. class and mods, is now stored from relevant Journal events, rather than only being available from CAPI data. In general, we now consider the Journal to be the canonical source of suit data, with CAPI only as a backup.
  • Backpack contents should now track correctly if using the 'Resupply' option available on the ship boarding menu.
  • We now cache the main application version when first determined, so that subsequent references to config.appversion() won't cause extra log spam (which was possible when, e.g. having a git command but using non-git source).
 
NB: I've not yet set 5.1.2 to be visible to the auto-updater, that might not happen until tomorrow.
I have now updated the relevant file to cause 5.1.2 to be offered as an update within EDMarketConnector.exe. So the next time it checks automatically, or if you perform a manual check you should be offered the new version. There might be a small delay whilst this propogates around GitHub's content delivery network.
 
Oh, I totally forgot to call out that I also updated translations in 5.1.2, so thanks again to all the translators!
 
After update 5.1.2, MS Defender is quarantining EDMC.exe and/or the MSI file on the grounds that it contains a Trojan
 
After update 5.1.2, MS Defender is quarantining EDMC.exe and/or the MSI file on the grounds that it contains a Trojan
See the post I made on the release day. Yes, we have a bunch of false positives again. There's nothing we can do about these other than play whack-a-mole with reporting the false positives as they happen and that is far too large a burden for an open source project. As soon as it's more than a handful it becomes onerous for us to keep on defending ourselves.

However, as it's Microsoft, I'll go submit both the MSI and the EDMC.exe (virustotal is now saying there are different detections across those two files) to them for further analysis, and try yet again to point out that in all likelihood they're flagging them due to us using py2exe to build the executables, with some malware authors doing the same for their software. All the AV vendors need to start specifically identifying the py2exe parts as just that and not as an indication, in and of itself, of something malicious.

There'll be the same issue for other methods of building python code into executables.

At this rate I might start seriously considering looking into what would be necessary in order to just ship a minimal python interpreter and have everyone actually running from source (which would possibly have some knock-on effects like not having a program specific icon, unless we can adjust things without breaking python licensing).
 

Release 5.1.3

  • Attempt to flush any pending EDSM API data when a Journal Shutdown or Fileheader event is seen. After this, the data is dropped. This ensures that, if the user next logs in to a different commander, the data isn't then sent to the wrong EDSM account.
  • Ensure a previous Journal file is fully read/drained before starting processing of a new one. In particular, this ensures properly seeing the end of a continued Journal file when opening the continuation file.
  • New config options, in a new Privacy tab, to hide the current Private Group, or captain of a ship you're multi-crewing on. These usually appear on the Commander line of the main UI, appended after your commander name, with a / between.
  • EDO dockable settlement names with + characters appended will no longer cause 'server lagging' reports.
  • Don't force DEBUG level logging to the plain log file if --trace isn't used to force TRACE level logging. This means logging to the plain log file will once more respect the user-set Log Level, as in the Configuration tab of Settings.
    As its name implies, the debug log file will always contain at least DEBUG level logging, or TRACE if forced.

(Plugin) Developers​

  • New EDMarketConnector option --trace-on ... to control if certain TRACE level logging is used or not. This helps keep the noise down whilst being able to have users activate choice bits of logging to help track down bugs.
    See Contributing.md for details.
  • Loading of ShipLocker.json content is now tried up to 5 times, 10ms apart, if there is a file loading, or JSON decoding, failure. This should hopefully result in the data being loaded correctly if a race condition with the game client actually writing to and closing the file is encountered.
  • config.get_bool('some_str', default=SomeDefault) will now actually honour that specified default.
 
Sorry if this has been asked but I can't seem to find a definitive answer when I google it. Is EDMC supposed to upload my data to EDSM in real time. I checked off automatically update when docking thinking this would delay any data going to EDSM until I arrive at a station. However it seems to be going to EDSM whenever I search something, previously systems I searched did not show up.
Edit: I think I found that it has to be set on the EDSM public profile settings actually.
 
Last edited:
Sorry if this has been asked but I can't seem to find a definitive answer when I google it. Is EDMC supposed to upload my data to EDSM in real time. I checked off automatically update when docking thinking this would delay any data going to EDSM until I arrive at a station. However it seems to be going to EDSM whenever I search something, previously systems I searched did not show up.
Edit: I think I found that it has to be set on the EDSM public profile settings actually.
The EDMC 'Delay sending until docked' is about sending to EDDN. And, yes, you need to combine this with the EDSM option as well in order for any discoveries to not become public on EDSM itself. If you only do the latter then, because you're still sending to EDDN, and uploaderID is anonymised in EDDN messages, EDSM considers the data public and will show it anyway.

Also, in general EDMC's sending of data to your EDSM profile via EDSM API isn't real-time. There's a small set of Journal events that will trigger sending whatever has been queued up. This appears to be the current implementation of "EDSM API has a rate limit, we don't want to bust through that and get access denied, so only send sometimes". We have plans to change this to a more friendly timer-based queue that will also pay explicit attention to the headers EDSM sends back to inform us of the current state of our quota. Ref: https://github.com/EDCD/EDMarketConnector/issues/662
 
The EDMC 'Delay sending until docked' is about sending to EDDN. And, yes, you need to combine this with the EDSM option as well in order for any discoveries to not become public on EDSM itself. If you only do the latter then, because you're still sending to EDDN, and uploaderID is anonymised in EDDN messages, EDSM considers the data public and will show it anyway.

Also, in general EDMC's sending of data to your EDSM profile via EDSM API isn't real-time. There's a small set of Journal events that will trigger sending whatever has been queued up. This appears to be the current implementation of "EDSM API has a rate limit, we don't want to bust through that and get access denied, so only send sometimes". We have plans to change this to a more friendly timer-based queue that will also pay explicit attention to the headers EDSM sends back to inform us of the current state of our quota. Ref: https://github.com/EDCD/EDMarketConnector/issues/662
Thanks for the detailed reply. I still feel like something is off. My EDDN settings are set to delay sending until docked in EDMC, as well as my EDSM public profile "Delay scanned celestial bodies until docked?" is set to ON. But even a system that didn't show up on EDSM search that I was heading to immediately showed up as soon as I jumped into it.
 
Thanks for the detailed reply. I still feel like something is off. My EDDN settings are set to delay sending until docked in EDMC, as well as my EDSM public profile "Delay scanned celestial bodies until docked?" is set to ON. But even a system that didn't show up on EDSM search that I was heading to immediately showed up as soon as I jumped into it.
Do you use any other utilities, like EDDisovery? Maybe one of those is reporting back.
 
Thanks for the detailed reply. I still feel like something is off. My EDDN settings are set to delay sending until docked in EDMC, as well as my EDSM public profile "Delay scanned celestial bodies until docked?" is set to ON. But even a system that didn't show up on EDSM search that I was heading to immediately showed up as soon as I jumped into it.
To see if it's you sending things over EDDN check the system via the filter on https://ross.eddb.io/eddn/log and see if any messages match the time (check your Journal log, the message timestamp should match, but the gateway timestamp will likely be a few seconds later at the very least) you jumped into the system.

Also, just in case, the EDMC option is explicitly delay sending until docked. If you dock, the messages will be sent, and that includes on a Fleet Carrier.
 
To see if it's you sending things over EDDN check the system via the filter on https://ross.eddb.io/eddn/log and see if any messages match the time (check your Journal log, the message timestamp should match, but the gateway timestamp will likely be a few seconds later at the very least) you jumped into the system.

Also, just in case, the EDMC option is explicitly delay sending until docked. If you dock, the messages will be sent, and that includes on a Fleet Carrier.
Ok thanks will take a look there. Definitely haven't docked anywhere (in over a year).
 
Is there an issue with the current assets value? EDMC is uploading values of ~6,800,000,000cr to my Inara profile, but the direct FD link to Inara and the in game figure itself are about 7,100,000,000cr.

First noticed a discrepancy on July 28/29 if that helps. (Looks like the Inara figure jumped up then but not the EDMC figure, don't know what changed.)
 
Is there an issue with the current assets value? EDMC is uploading values of ~6,800,000,000cr to my Inara profile, but the direct FD link to Inara and the in game figure itself are about 7,100,000,000cr.

First noticed a discrepancy on July 28/29 if that helps. (Looks like the Inara figure jumped up then but not the EDMC figure, don't know what changed.)
There's a historical (i.e. before I took over as maintainer) 'latch' in the code that means EDMC won't report a greater credit balance to Inara unless it's at least 5% more than the last time.

Obviously this is ridiculous when someone has billions of credits. I'll open an issue for us to look at this check either being taken out (we batch updates to Inara anyway), or at least making it "5%, or at least X credits".
 
Just FYI - this morning Norton 360 woke up and decided to remove EDMC.exe for me! I know it'll be one of those false positives, but as Norton had been happy with it to date, just thought I'd let you know...

edit:... annnd now it just straight up blocks me from restoring/ reinstalling it. grrr.
 
Last edited:
Status
Thread Closed: Not open for further replies.
Top Bottom