Release EDDI 3.3 - Bring your cockpit to life

I have some problems with EDDI since yesterday.
Not only the rc versions are affected. At the moment the latest b1 is installed and it also makes problems.
The first time I jump into a system, the population is not announced to me. The second time then already. And known/discovered objects in the system are not recognized.
Could this be related to the API ? I noticed this only now with the rc2 version, but as I said with the previous this problem also exists. If it is an EDDI problem, I would have definitely noticed it with the other versions.

🤔🤔🤔

Translated with www.DeepL.com/Translator (free version)
 
I have some problems with EDDI since yesterday.
Not only the rc versions are affected. At the moment the latest b1 is installed and it also makes problems.
The first time I jump into a system, the population is not announced to me. The second time then already. And known/discovered objects in the system are not recognized.
Could this be related to the API ? I noticed this only now with the rc2 version, but as I said with the previous this problem also exists. If it is an EDDI problem, I would have definitely noticed it with the other versions.

🤔🤔🤔

Translated with www.DeepL.com/Translator (free version)
I had something similar yesterday, when it told me I was first to discover an already inhabited system in Colonia, and said it was my first visit in a system I know I've been to several times. I had assumed it was something to do with EDDI being beta/release candidate, and not reporting/reading the info from some of the data sources. I may have to have a more thorough check later, just in case...

EDIT: I just logged into EDDI and found that the Frontier API had been logged out, so that may have been my cause.
 
Last edited:
I had something similar yesterday, when it told me I was first to discover an already inhabited system in Colonia, and said it was my first visit in a system I know I've been to several times. I had assumed it was something to do with EDDI being beta/release candidate, and not reporting/reading the info from some of the data sources. I may have to have a more thorough check later, just in case...

EDIT: I just logged into EDDI and found that the Frontier API had been logged out, so that may have been my cause.
Yes, mine was too. After logging in, the problems persisted. There is one more problem. There are also no stations announced on a first visit.

I have found a cause for the incorrect object detection. Only objects that can be detected by oneself are listed in the Journal.log. Objects that are already known from the beginning are no longer entered. Thus the calculations are no longer correct.

The variable of the population comes with the ED event FSDJump. In the EDDI script "FSD engaged" this is however already queried. There has changed apparently in the journal with the events something.
 
Last edited:
@nepomuk @Darkcyde
I'm speculating here but these sounds like issues which might be traceable to the EDSM API being unavailable (the site is currently under maintenance... was it under maintenance during your play sessions too?).

EDIT: EDSM downtime was announced on 1/10/2021 on EDSM's Discord.
"We will conduct some maintenance starting today and shut down our current server. Some services will take some weeks to be up to date to new versions that hopefully will help improve some things. No ETA on migration time."
Unfortunately, this shut down comes as a surprise to us. We don't yet know when the API will be back online.
 
Last edited:
@nepomuk @Darkcyde
I'm speculating here but these sounds like issues which might be traceable to the EDSM API being unavailable (the site is currently under maintenance... was it under maintenance during your play sessions too?).

EDIT: EDSM downtime was announced on 1/10/2021 on EDSM's Discord.
"We will conduct some maintenance starting today and shut down our current server. Some services will take some weeks to be up to date to new versions that hopefully will help improve some things. No ETA on migration time."
Unfortunately, this shut down comes as a surprise to us. We don't yet know when the API will be back online.
I have listed here what I noticed yesterday and today. I don't think this is related to EDSM. Or maybe it is if maybe the API of FD is changed. The entries in the journal were, in my opinion, already changed. But have a look yourself.
(Tests with EDDI v.3.7.1 - v.3.7.2-rc2)
  • Population readable with the jumped script, was with me always in the "FSD engaged" script. There now always zero, in the "Jumped" script it works
  • Number of stations (orbital and planetary) NOT readable anymore ( len(reportsystem.stations) always zero)
  • "Market information updated" is no longer triggered
  • Objects that were known in the first place are no longer recognized as known (Entry in journal "WasDiscovered") , not so dramatic
  • Home system and home station cannot be entered

Translated with www.DeepL.com/Translator (free version)
 
Last edited:
I just experienced a bug when I docked back at Li Yong Rui power, EDDI tells me I can save money by swapping out the fuel scoop here but it didn't. It's the exact same price.
 
I have listed here what I noticed yesterday and today. I don't think this is related to EDSM. Or maybe it is if maybe the API of FD is changed. The entries in the journal were, in my opinion, already changed. But have a look yourself.
(Tests with EDDI v.3.7.1 - v.3.7.2-rc2)
  • Population readable with the jumped script, was with me always in the "FSD engaged" script. There now always zero, in the "Jumped" script it works
  • Number of stations (orbital and planetary) NOT readable anymore ( len(reportsystem.stations) always zero)
  • "Market information updated" is no longer triggered
  • Objects that were known in the first place are no longer recognized as known (Entry in journal "WasDiscovered") , not so dramatic
  • Home system and home station cannot be entered

Translated with www.DeepL.com/Translator (free version)
The implications of not having access to the EDSM API are far reaching, unfortunately.
Population is not available from the player journal during the FSD engaged event. Without the EDSM API, it only becomes available with the Jumped event.
Most of what we know about stations also comes from the EDSM API. The player journal provides almost no data until you actually dock at those stations.
Even entering home system and home station data uses the API to prompt the user with system and station names.
 
I just experienced a bug when I docked back at Li Yong Rui power, EDDI tells me I can save money by swapping out the fuel scoop here but it didn't. It's the exact same price.
If you're expecting that you'd be able to sell your old module for a small profit, it doesn't work that way. The station will not offer you more for your module than the posted sale price. You'd have to sell elsewhere then return to the discounted station to be able to earn a profit from the exchange.

The main reason to swap to cheaper modules is to reduce your insurance bills.
 
If you're expecting that you'd be able to sell your old module for a small profit, it doesn't work that way. The station will not offer you more for your module than the posted sale price. You'd have to sell elsewhere then return to the discounted station to be able to earn a profit from the exchange.

The main reason to swap to cheaper modules is to reduce your insurance bills.
I wasn't trying to profit, that alert made me think oh that means my scoop isn't bought from LYR so if I sell it here, I will sell it at the 100% price, then buy at 85% price of the same scoop thereby lowering my rebuys. But when I went to sell it, it sells it at the 85% price. So why did the voice prompt said "profit"? Just weird.
 
I wasn't trying to profit, that alert made me think oh that means my scoop isn't bought from LYR so if I sell it here, I will sell it at the 100% price, then buy at 85% price of the same scoop thereby lowering my rebuys. But when I went to sell it, it sells it at the 85% price. So why did the voice prompt said "profit"? Just weird.
I agree the wording might be misleading. Happy to receive proposals for alternate wording.
 
I agree the wording might be misleading. Happy to receive proposals for alternate wording.
Perhaps, "You can lower your ship insurance by swapping out your {item} at this station". I still think it might be a bug, I am pretty sure I bought and fit that ship at LYR. It's an AspX I bought and fit after coming back in October for engineering mats gathering, by that time I was focused on the discount. Anyway, if it's not a profit we shouldn't say profit :) As you know in Elite, profit is a strong word haha. Thanks man, get the guys to vote on different wordings maybe?
 
The implications of not having access to the EDSM API are far reaching, unfortunately.
Population is not available from the player journal during the FSD engaged event. Without the EDSM API, it only becomes available with the Jumped event.
Most of what we know about stations also comes from the EDSM API. The player journal provides almost no data until you actually dock at those stations.
Even entering home system and home station data uses the API to prompt the user with system and station names.
Aha, that explains a lot! I had no idea how and where the API of EDSM intervenes. Many thanks for the clarification! (y)

Is the API of EDSM that meaningful ? Couldn't one also use the API of eddb.io ?
Sorry for the naive question, but the API is still a bit of a mystery to me. :oops:;)
 
Last edited:
Does a variable related to EDSM successful access exists? It could be used in the scripts to conditionally skip some phrases if that data aren't available.
There is already a script where the API is queried beforehand, the "Launchbay report". But it is probably too time-consuming now to provide all the places in the character with a query for the API.
 
I've spoken with EDSM's developer. Barring any complications, the majority of the EDSM API (less cube and sphere searches) should be restored within the next two days. Sphere and cube searches (which are used by some routing functions in EDDI) may take more time before becoming available again.
 
Does a variable related to EDSM successful access exists? It could be used in the scripts to conditionally skip some phrases if that data aren't available.
There is already a script where the API is queried beforehand, the "Launchbay report". But it is probably too time-consuming now to provide all the places in the character with a query for the API.
The Launchbay report script uses a variable to determine whether a connection to the Frontier API exists. It doesn't check the connection to the EDSM API.

There is no specific variable for the connection to the EDSM API but if you try to retrieve SystemDetails() for a system you haven't visited in the past hour then we would use the EDSM API to retrieve them. If the resulting object has no data other than the system name (if there are zero bodies in the system for example) then you can conclude that the connection to the backing API failed.
 
Aha, that explains a lot! I had no idea how and where the API of EDSM intervenes. Many thanks for the clarification! (y)

Is the API of EDSM that meaningful ? Couldn't one also use the API of eddb.io ?
Sorry for the naive question, but the API is still a bit of a mystery to me. :oops:;)
EDDB has no API though it does have data dumps.
There are a couple of other sites that could be used to provide data but the API endpoints wouldn't be the same and the data available from those endpoints might not match. While swapping to a different API is possible, it would be a significant undertaking.
In spite of the current hiccup, the EDSM API is still one of the best options available and I'm grateful to Anthor over at EDSM for sharing his API with us. :)
 
The Launchbay report script uses a variable to determine whether a connection to the Frontier API exists. It doesn't check the connection to the EDSM API.

There is no specific variable for the connection to the EDSM API but if you try to retrieve SystemDetails() for a system you haven't visited in the past hour then we would use the EDSM API to retrieve them. If the resulting object has no data other than the system name (if there are zero bodies in the system for example) then you can conclude that the connection to the backing API failed.
Would'nt be worthy to have a "EDSM_data_access" flag available and already set (and somewhat updated) in the scripts?
Just wondering.
 
Top Bottom