Release Elite Dangerous Market Connector (EDMC)

Status
Thread Closed: Not open for further replies.
 
  1. 5.1 or later could stop working on Python 3.8, depending on what new Python 3.9/3.10 features we start using.

I don't understand why you need new Python versions to write a program that reads a logfile and uploads it to a server. EDMC works fine as it is and doesn't need any more "features." "New features" only break things. Do you really really need the new framework to allow EDMC to read Odyssey log files? Anyway, sad to see it go.
 
sad to see it go.
I will also be sad to see your files go when a security incident happens due to you using an unpatched OS with unpatched software on it. Take my advice, upgrade to Win10 or any OS that is officially supported right now and use a version of EDMC that uses a updated and patched python. Cause no one will look at this thread when a python security issue causes EDMC to be hijacked into mining crypto on your system.
 
I will also be sad to see your files go when a security incident happens due to you using an unpatched OS with unpatched software on it. Take my advice, upgrade to Win10 or any OS that is officially supported right now and use a version of EDMC that uses a updated and patched python. Cause no one will look at this thread when a python security issue causes EDMC to be hijacked into mining crypto on your system.
1. https://www.python.org/ 3.8 end support 2024-10
2. I gave the link to the discussion above because it was explained to me last time. There is nothing in the program that does not work on version 3.8. Maybe something has changed since then.
3.I think you should just take the source code and run it with python 3.8, if the author does not want to support the version of Windows 7, which is still listed as supporting the game itself
 
Sure, uninstall from Windows Settings > Apps, download https://github.com/EDCD/EDMarketConnector/releases/tag/Release/4.2.7 , install 4.2.7. But 4.2.7 won't work very well with Odyssey when it goes live.

Better to figure out why something (probably anti-virus) on your system won't let you install/use EDMC.exe. See https://github.com/EDCD/EDMarketConnector/issues/1058 for some information about the 3 or 4 vendors I reported it to. At least two have gotten back to me saying it's now whitelisted. Which A/V are you using ?
I use mcaffe. However, my issue seems different to those discussed on https://github.com/EDCD/EDMarketConnector/issues/1058. I run the msi without warning messages. The problem is the EDMC.exe file does not "appear" in the folder until I run EDMarketConnector.exe and then it stays there for a while before dissapearing again.

Thanks for your help btw!
 
I use mcaffe. However, my issue seems different to those discussed on https://github.com/EDCD/EDMarketConnector/issues/1058. I run the msi without warning messages. The problem is the EDMC.exe file does not "appear" in the folder until I run EDMarketConnector.exe and then it stays there for a while before dissapearing again.

Thanks for your help btw!
That might just be McAfee operating slightly differently. At least one of the reports we had said that the trigger for the .msi being a problem was specifically the EDMC.exe file. It disappearing again implies something is probably (re-)quarantining it. So, perhaps have a good look through the McAffee UI for "Quarintined Files" and if there's an option to submit it for further analysis then please do that.
 
That might just be McAfee operating slightly differently. At least one of the reports we had said that the trigger for the .msi being a problem was specifically the EDMC.exe file. It disappearing again implies something is probably (re-)quarantining it. So, perhaps have a good look through the McAffee UI for "Quarintined Files" and if there's an option to submit it for further analysis then please do that.
Sure! I'll do that and report back
 
I will also be sad to see your files go when a security incident happens due to you using an unpatched OS with unpatched software on it. Take my advice, upgrade to Win10 or any OS that is officially supported right now and use a version of EDMC that uses a updated and patched python. Cause no one will look at this thread when a python security issue causes EDMC to be hijacked into mining crypto on your system.
The bit about an unpatched OS is understandable, but bear in mind that Python 3.8 support doesn't end until 2024. To me, the choices are an unsupported OS, or an OS with built-in malware. Regardless, I can't upgrade to W10 due to hardware issues with my current PC. Building a new PC is proving problematic due to video card availability/pricing. I'll simply continue to use EDMC for as long as I can make it work. When I can't, I'll have to stop using it-no big deal.
 
I observe that according to the EDDN Software stats the Windows version of EDMarketConnector 5.0.0 is now responsible for around 94% of messages (of all EDMarketConnector Windows versions). Obviously this is only a very rough proxy for actual telemetry (which we don't have), but it does suggest that a majority of EDMC users on Windows are happily using 5.0.0.
 
I spent quite a bit of time last week looking for an alternative. I wound up at the EDDLite discord, only to find out EDDLite/EDDiscovery can't work with Inara on W7. Luckily, I was given a link to the EDMC run-from-source page. From there, I got EDMC working, and learned quite a bit as I did so.

I'm very happy with EDMC 5.0.0.
 

Release 5.0.1


The main reason for this release is to add an 'odyssey' boolean flag to all EDDN messages for the benefit of listeners, e.g. eddb.io, inara.cz, edsm.net, spansh.co.uk, etc. Please do update so as to make their lives easier once Odyssey has launched!
  • Translations have been updated again. Thanks to all the contributors. See wiki:Translations and Translations welcome for links and discussion if you want to help.
  • Changed the error message "Error: Frontier server is down" to "Error: Frontier CAPI didn't respond" to make it clear this pertains to the CAPI and not the game servers.

Killswitches​


In the 5.0.0 changelog we said:

We will NOT be using this merely to try and get some laggards to upgrade.

However, from now on there is an exception to this. After this release any subsequent -beta or -rc versions will be killswitched after their full release is published.

For example, if we put out a 5.0.2-beta1 and 5.0.2-rc1 before the full 5.0.2, then when 5.0.2 was published we would activate all available killswitches for versions 5.0.2-beta1 and 5.0.2-rc1. In this example 5.0.1 would not be killswitched as part of this policy (but still could be if, e.g. a data corruption bug was found in it).

In general please do not linger on any -beta or -rc release if there has been a subsequent release. Upgrade to the equivalent full release once it is published.

Plugin Developers​

  • Please make the effort to subscribe to GitHub notifications of new EDMarketConnector releases:
    1. Login to GitHub.
    2. Navigate to EDMarketConnector.
    3. Click the 'Watch' (or 'Unwatch' if you previously set up any watches on us). It's currently (2021-05-13) the left-most button of 3 near the top-right of the page.
    4. Click 'Custom'.
    5. Ensure 'Releases' is selected.
    6. Click 'Apply'.
    7. This way you'll be aware, as early as possible, of any -beta and -rc changelogs and changes that might affect your work.
  • state passed to journal_entry() has a new member Odyssey (note the capital O) which is a boolean indicating if the LoadGame event both has an Odyssey key, and if so, what the value was. Defaults to False.
  • PLUGINS.md updated to document the state['Horizons'] flag that has been present in it since version 3.0 of the game.
  • The stations.p and systems.p files that were deprecated in 5.0.0 have now also been removed in git. As this release is made they will no longer be in the develop, main or stable branches. If you truly need to find a copy look at the Release/4.2.7 tag, but do read the 5.0.0 changelog for why we stopped using them and what you can change to also not need them.
 
For future releases, would it be possible to announce if any Python 3.9.x specific functions are being used? Doing so would be very helpful to those of us who are stuck with Win7. I'd like to avoid the process of setting up run-from-source on any future releases that are just going to fail.
 
For future releases, would it be possible to announce if any Python 3.9.x specific functions are being used? Doing so would be very helpful to those of us who are stuck with Win7. I'd like to avoid the process of setting up run-from-source on any future releases that are just going to fail.
Possible? Sure. Will we definitely remember? Quite likely not. Given our official stance is that we're now targeting Python 3.9.x it won't be in mind.

We probably need someone to "keep us honest" on it, which would entail them following the "develop" branch and testing it often with Python 3.8. I might be convinced to see if we can set up some GitHub workflow automation for this. In saying that I'm hoping it would be enough to have a workflow that performs flake8 and mypy checks on "develop" once a day. It's not the same as actually running the code but it does load it all in almost the same manner.

Of course even this is then putting extra load on the (two person for the most part) development team, which is what we're trying to avoid with insisting on using Python 3.9.

Again, whilst we could back out to Python 3.8 currently that then just stores up all the same issues for 2-3 years from now. At some point python.org will shift Python 3.8 to source only distribution which makes it a pain to test with on Windows. I personally do not want to freeze us on one Python minor (Major.Minor.Patch) now and then have to play catch up of 2-3 versions later.
 
To add to that. As I already mentioned, we do not have any actual telemetry in the application. The closest proxy is the EDDN Gateway stats of softwareName + softwareVersion.

Looking at this for so far today, and only 'E:D Market Connector [Windows]' we have 5.0.1 on 75.8% and 5.0.0 on 18.8% for a total of 94.6% of messages so far today. If we assume that messages are roughly shared between users then you can see why I'm reluctant to go to extra effort in order ro support what will be less than 5% of the user base. Many people won't have updated to 5.0 yet, but will do so in the next couple of weeks (as I keep saying, experience during Odyssey Alpha tells me that 4.2.7 will have issues with it). We generally reach around 98% take up of the latest version within a month or so of its release.

I suspect that far from all of the users still on 4.2.7 are using Windows 7, so the number of users this issue affects is going to be smaller than the EDDN stats suggest.

We'll ignore all the users who are on positively ancient versions (not even the last Marginal release, 3.43 !), they obviously don't pay attention or care if they're running buggy software.
 
Sure! I'll do that and report back
That might just be McAfee operating slightly differently. At least one of the reports we had said that the trigger for the .msi being a problem was specifically the EDMC.exe file. It disappearing again implies something is probably (re-)quarantining it. So, perhaps have a good look through the McAffee UI for "Quarintined Files" and if there's an option to submit it for further analysis then please do that.
You were right. McAfee quarentined and re-quarentined EDMC.exe. I restored it and the problem was solved. However there is no option (or at least I couldn't find it) to submit the file for further analysis, I am afraid.

Thanks for your help!
 
We still have no plans to support 5.0, or later, on Python 3.8, but I am now considering the following to make it easier for those unable to use other than Windows 7 to possibly run the latest version.

Have an automated attempted build of our "stable" branch (which is almost always exactly what we release, but might be slightly ahead or behind at times) under Python 3.8 on either a daily basis, or when changes are made to that branch.

We would not support use of this version in general. Any bug reports using it without the requested log files will be absolutely ignored. If the logfiles don't make it clear that the issue pertains to a bug in our code, rather than an OS issue or similar, we will request the bug be reproduced under the latest supported build. We won't even guarantee that installations using these builds will work. If the build breaks it won't be a priority to fix it. If we make code changes that cause Python 3.8 to no longer work, then this not-really support will end.

It will take some developer time in order to set this up, so don't hold your breaths. Our policy is still to recommend all users of the EDMC Windows builds be using a Microsoft Supported OS, with Windows 7 not counting, even if you actually paid for their extended support.
 
To talk about something other than Windows 7 for a moment...

With the release of Journal Doc v31 there will definitely be some more work to do on EDMC core code. I don't think anything will break tomorrow if you're using 5.0.1, but we can definitely use the changes in that version to improve things like when we can show the Suit/Loadout on the UI, and the tracking of Odyssey inventory for plugins' benefit.

What I'm trying to say is that there will definitely be at least a 5.0.2 by the end of the week. We'll need Odyssey to be launched and stable enough to test these forthcoming code changes.
 
We still have no plans to support 5.0, or later, on Python 3.8, but I am now considering the following to make it easier for those unable to use other than Windows 7 to possibly run the latest version.

Have an automated attempted build of our "stable" branch (which is almost always exactly what we release, but might be slightly ahead or behind at times) under Python 3.8 on either a daily basis, or when changes are made to that branch.

We would not support use of this version in general. Any bug reports using it without the requested log files will be absolutely ignored. If the logfiles don't make it clear that the issue pertains to a bug in our code, rather than an OS issue or similar, we will request the bug be reproduced under the latest supported build. We won't even guarantee that installations using these builds will work. If the build breaks it won't be a priority to fix it. If we make code changes that cause Python 3.8 to no longer work, then this not-really support will end.

It will take some developer time in order to set this up, so don't hold your breaths. Our policy is still to recommend all users of the EDMC Windows builds be using a Microsoft Supported OS, with Windows 7 not counting, even if you actually paid for their extended support.

I don't see a reason to significantly increase the workload for Python 3.8. That's time better spent on actual development. Python 3.9 was adopted now so it won't be difficult later- makes perfect sense to me. Anyone using Windows 7 today should be getting used to finding work-arounds by now (I am). Running from source is better for me regardless, it makes debugging easier.
 
Hi, I have a problem here.
Version is
1621373401233.png

I have CSV market data saving set and the error message is :

1621373490489.png

This bug didn't appear before latest update.
Edit : No problem appeared in another station What's wrong with this name ...

Regards
 
Last edited:
Status
Thread Closed: Not open for further replies.
Top Bottom