The alpha version for this 64-bit migration is now available - https://github.com/EDCD/EDMarketConnector/releases/tag/Release/5.5.1-alpha0
See the message above for what needs testing.
See the message above for what needs testing.
Yes, this is tagged '-alpha0' for a reason.If we're just a casual user that doesn't do testing and the like, should we just leave ours alone for now?
gameversion
(we track it as state['GameVersion']
passed to journal_entry()
) so as to tell if the data is for the Cmdr's Legacy or Live profile.replay.jsonl
in the configured 'Output' file location. Unfortunately the code that writes messages to that file only stores the Commander name, schemaref and the "message". Missing from this is the EDDN "header", which is where these new gameversion/build fields go (and they'd not have been present/set in current messages anyway).eddn_queue-v1.db
in the same folder), and then the file deleted. All of these 'legacy' messages will have " (legacy replay)" appended to the EDDN header->softwareName, and will have empty strings for both "gameversion" and "gamebuild" (because there's no way to be sure of what version they came from... no I'm not going to start figuring out the date/time ranges for each just for this).Just accept the update, it'll, likely be called 5.6.0, when it becomes available sometime in the next few days (I'm hoping to get it out on Friday latest so that the weekend players pick it up).This is all too complicated for me. I use EDMC mainly just to populate EDSM. I will only be using the Live version of 4.0. What do I need to do to update EDMC, and when?
Just install the new version when it's released, and all will be taken care ofThis is all too complicated for me. I use EDMC mainly just to populate EDSM. I will only be using the Live version of 4.0. What do I need to do to update EDMC, and when?
Oh, can't I just run the update from within the opened app? That's what I normally do. It should uninstall the old one and install the new one itself, I hope?Just install the new version when it's released, and all will be taken care of
It's business as usual. As @Athan said, just make sure you install the new version when it shows up. No need to search for it on your own.Oh, can't I just run the update from within the opened app? That's what I normally do. It should uninstall the old one and install the new one itself, I hope?
Small tweak to the plan. As the underlying changes to the EDMC's eddn code are larger than "start sending gameversion" would suggest I'm waiting on the other developer to complete a code review of the changes. So, I'll put out a beta today, with the full release hopefully tomororow, Sunday latest.Major heads-up for forthcoming very necessary update to EDMC
First of all, if you've not heard the big news about Update 14, go read.
TL;DR - There'll be an EDMC update in the next few days that all users should ensure they have installed before Update 14 is deployed next week so as to ensure their data can actually be useful to EDDN Listeners.
Now, what does this mean for EDMC? For the application itself no changes should be necessary. For third-party plugins ... well if you keep track of anything per Cmdr then you'll probably want to start paying attention togameversion
(we track it asstate['GameVersion']
passed tojournal_entry()
) so as to tell if the data is for the Cmdr's Legacy or Live profile.
Any EDDN Listener is going to need to know if a message's data pertains to the Legacy or the Live galaxy. Many are probably going to choose to only process data for the Live galaxy going forwards. That means all EDDN Senders need to provider information to allow the Listeners to discern which galaxy a message is from. EDDN recently added new header fields "gameversion" and "gamebuild" for just this scenario.
Adding those fields naively to EDMC would have been easy, but there's a wrinkle when it comes to "failed on first attempt to send" and "delayed due to the setting to not send until docked" messages. Those are currently stored in a flat file,replay.jsonl
in the configured 'Output' file location. Unfortunately the code that writes messages to that file only stores the Commander name, schemaref and the "message". Missing from this is the EDDN "header", which is where these new gameversion/build fields go (and they'd not have been present/set in current messages anyway).
So, at the very least that code would have needed changing to also store gameversion/build. I decided to just go the whole hog and start storing the full, ready to send over the network, message instead. And if I was going to have to convert to a new format to cater for that I decided I might as well change it from a flat file (inefficient, only written to disk periodically, so you can lose messages if you crash) to an sqlite3 database. At startup if a replay.jsonl file is found all of its entries will be converted into the sqlite3 database (eddn_queue-v1.db
in the same folder), and then the file deleted. All of these 'legacy' messages will have " (legacy replay)" appended to the EDDN header->softwareName, and will have empty strings for both "gameversion" and "gamebuild" (because there's no way to be sure of what version they came from... no I'm not going to start figuring out the date/time ranges for each just for this).
Going forwards all EDDN messages from EDMC after version 5.5.0 (the current release) will include "gameversion" and "gamebuild" as specified in the EDDN documentation. Note what that says about the values for CAPI-sourced data, or where the version/build couldn't be determined for any reason.
NB: So as to not dump the need for a different update on third-party plugin developers this next version of EDMC will still be 32-bit. We'll handle the move to 64-bit in a later 6.0.0 release once the dust from this has settled, and third-party plugin developers have had time to react to the 5.5.1-alpha0 pre-release which is 64-bit.
I'm still waiting to hear from EDSM and Inara.cz developers to see if any changes will be necessary when sending data to their APIs.
I need to adjust the EDSM plugin code, so 5.6.0 release will be a little later today now.If no (new in this release) bugs come to light then I'll put out the full release 5.6.0 tomorrow around 12:00 UTC.
replay.jsonl
are converted at startup, if that file is present, and then the file removed.gameversion
and gamebuild
strings in EDDN message headers.replay.jsonl
format.gameversion
indicates a Live client. This explicitly checks that the game's version is semantically equal to or greater than '4.0.0'.gameversion
, in a similar manner to the EDDN header.gameversion
and gamebuild
fields in the header as per EDDN/docs/Developers.md.EDMC.EXE -n
, to send data to EDDN, was already broken in 5.5.0.EDMC.EXE
. This might break third-party use of it, e.g. Trade Computer Extension Mk.II.EDMarketConnector.exe
functions properly.gameversion
and gamebuild
as per their values in Fileheader
or LoadGame
, whichever was more recent (there are some events that occur between these).gameversion
and gamebuild
will be empty strings. In order to indicate this the softwareName will have (legacy replay)
appended to it, e.g. E:D Market Connector Connector [Windows] (legacy replay)
. In general this indicates that the message was queued up using a version of EDMC prior to this one. If you're only interested in Live galaxy data then you might want to ignore such messages.gameversion
of CAPI-<endpoint>
set, e.g. CAPI-market
. At this time it is not 100% certain which galaxy this data will be for, so all listeners are advised to ignore/queue such data until this is clarified.gamebuild
will be an empty string for all CAPI-sourced data.state
passed to plugins, IsDocked
. See PLUGINS.md for details.Wyndham Dock | MCC 549︎ | M | 1,567 Ls | 0 Ly | 36,712 | 207 Cr | 266 days ago |
Pippin Dock | MCC 549︎ | M | 2,006 Ls | 0 Ly | 44,965 | 207 Cr | 91 days ago |
Biggle Dock | MCC 549︎ | L | 1,233 Ls | 0 Ly | 25,555 | 207 Cr | 81 days ago |
Okay I've done that, thanks for the link! I am a software developer myself so please let me know if there's anything else I can do.As forbiddenlake says, there's not much I can do outside of wild guesses unless you open up a proper bug report with EDMarketConnector logs.