Release EDDI - Windows app for immersion and more

Status
Thread Closed: Not open for further replies.
FYI, 'EDDI ship refuelled total' is reporting 'not set' following completion of a fuel scoop

This is a general issue with the VoiceAttack responder not being able to handle some of the weirder internal types (in this case, an optional type). I'll see what I can do to update this.

Please add 'EDDI docking granted station type' variable for the VA ((EDDI docking granted)) event.

Unfortunately this information isn't available in the event.
 
Unfortunately this information isn't available in the event.

I know that, we've already been through this... see comment #s 692, 693, 698, 699, and 705 for memory jog.

Clearly you're getting the station type from somewhere for the speech responder 'docking granted' event... I made an assumption (to my creaky memory, you've not elaborated on all the functions/responsibilities of the EDDI server), but you did not confirm.

It's not that I'm against using Cottle... I've printed out and studied the official manual and one scripted language is as easy as any other... I find the limited scope of the event variables within the speech responder, for example the inability to call out the landing pad location after the event has passed and variables are no longer valid, to not meet my needs/goals.

My previous request to have VA accessibility to EDDB data was with the intent to minimize/short circuit the need to make individual requests for you to incorporate/hard code niche bits of data.
 
Last edited:
jgm, is there a event.total variable for refuelling at stations you could add like there is for scooping?

I would like to implement responses for refuelling in 10% increments but for that i need a baseline for the calculations (other than a full tank as i use now).
 
EDDI says "Your connection to the companion app is good but experiencing temporary issues. Your information should be available soon." It does that for hours now, the Shipyard header is empty (no ships) and no fund information etc. Think that's the reason why my fuel script is not working. Can't even connect to my account via frontierstore.net :(

Anything I can do about that?
-
Was this issue ever solved as I am experiencing the same with regard to "... temporary issues." that never clear?
There are no ship's listed in EDDI, and all responses based on <ship name> or configuration (as in <ship module>) become generic or inoperable.
Other responses, such as location requests seem to work ok.
 
-
Was this issue ever solved as I am experiencing the same with regard to "... temporary issues." that never clear?
There are no ship's listed in EDDI, and all responses based on <ship name> or configuration (as in <ship module>) become generic or inoperable.
Other responses, such as location requests seem to work ok.

Last time when i had the same problem i made a clean reinstall of EDDI and it worked again for me.
 
Funnily enough I was just updating the docs to give a bit more of an overview of how EDDI works. It'll be merged soon, but in the meantime you can see it athttps://github.com/cmdrmcdonald/EliteDangerousDataProvider/tree/feature/docs

Very informative diagram, solidified my understanding of what/who feeds data to EDDI. Thanks.

It would be very helpful to add in the EDDI Voice Attack docs when and from where the VA data is updated.

Some are fairly easy to infer, for example it makes sense that Current System data is updated following a Jump, but from who?. EDDB, Journal, API, or a mixture? Other data sets are not as easy to ascertain.

For example, are the Current Station Variables updated from EDDB and does it occur on the 'docked' event?

If Station Type was added to the Current Stations Variables list and said variables were updated for the 'docking granted' event instead, this would solve my individual need.
 
Last edited:
Hi jgm, updated to v10 all seems ok, did you add this in ?
Also any news on detecting volcanic activity ?
-
Thank you :) o7

Yes this change went in with 2.0.10.

No news on volcanic activity; it's on the list but still fixing up the changes required by 2.2.0.2 so haven't added it yet.
 
I know that, we've already been through this... see comment #s 692, 693, 698, 699, and 705 for memory jog.

Clearly you're getting the station type from somewhere for the speech responder 'docking granted' event... I made an assumption (to my creaky memory, you've not elaborated on all the functions/responsibilities of the EDDI server), but you did not confirm.

It's not that I'm against using Cottle... I've printed out and studied the official manual and one scripted language is as easy as any other... I find the limited scope of the event variables within the speech responder, for example the inability to call out the landing pad location after the event has passed and variables are no longer valid, to not meet my needs/goals.

My previous request to have VA accessibility to EDDB data was with the intent to minimize/short circuit the need to make individual requests for you to incorporate/hard code niche bits of data.

VoiceAttack isn't a very complex system for speech templating, with all variables being simple values. This means that translating from the natural structure of objects to VoiceAttack variables is a manual process, and sometimes doesn't have any useful way of being laid out. This is why I moved away from VoiceAttack to run the scripts and went to Cottle: the more complex features such as calling functions, pulling in additional data etc. just isn't possible without manually writing a lot of code that will have a lot of hard-coded assumptions in it, and a commensurate amount of maintenance effort.

If you want to use event variables in later scripts then you can always store them in other VoiceAttack variables and access them later.
 
jgm, is there a event.total variable for refuelling at stations you could add like there is for scooping?

I would like to implement responses for refuelling in 10% increments but for that i need a baseline for the calculations (other than a full tank as i use now).

Unfortunately not.
 
-
Was this issue ever solved as I am experiencing the same with regard to "... temporary issues." that never clear?
There are no ship's listed in EDDI, and all responses based on <ship name> or configuration (as in <ship module>) become generic or inoperable.
Other responses, such as location requests seem to work ok.

It sounds like your credentials have been revoked by the Elite server but for some reason EDDI isn't picking up on it.

I'll try to update the code to spot this, and let you know that you should log out and back in to clear the issue.

In the meantime you can shut EDDI down, remove the %APPDATA%\EDDI\credentials.json file, and start it up again. You'll need to go through the authentication process again, but hopefully after that it should work.
 
If you want to use event variables in later scripts then you can always store them in other VoiceAttack variables and access them later.

Fair enough, how do you pass Cottle speech responder event specific variables to VA?

I would happily move away from VA if I could save and/or pass variables between speech responder scripts or save limited scope event variables for future use... it's not clear to me how to do that.
 
Last edited:
Very informative diagram, solidified my understanding of what/who feeds data to EDDI. Thanks.

It would be very helpful to add in the EDDI Voice Attack docs when and from where the VA data is updated.

Some are fairly easy to infer, for example it makes sense that Current System data is updated following a Jump, but from who?. EDDB, Journal, API, or a mixture? Other data sets are not as easy to ascertain.

For example, are the Current Station Variables updated from EDDB and does it occur on the 'docked' event?

If Station Type was added to the Current Stations Variables list and said variables were updated for the 'docking granted' event instead, this would solve my individual need.

The short version is that the data should be accurate for your current situation. So after you've docked the information about the current station should be available, when you undock it goes away, system information should be accurate for your current system etc.

The data comes from a combination of EDDB, The companion API, and the monitors, with different sources taking precedence at different times depending on the current information known to EDDI. If you really need to know the details it's complex enough that it won't be any simpler to explain than to point you to the EDDI code (specifically EDDI.cs).
 
Fair enough, how do you pass Cottle speech responder event specific variables to VA?

You can access VoiceAttack event variables. Anything that's listed the big VoiceAttack help file can be copied the same way as any other variable.

In fact, thinking about it I don't believe that EDDI removes the old variables so if you have two events X and Y, with Y happening after X, then you should still be able to access the event variables from X in Y. So if you want to obtain the landing pad then {INT:EDDI docking granted landingpad} will fetch whatever the landing pad was so to the last time this event occurred. Note that this will only work, however, if you have an ((EDDI docking granted)) command as EDDI won't bother to set up the variables if there isn't a command to use them.*

(*Probably. I haven't tested this as it's an unintended side-effect of EDDI not clearing up after itself. You might want to copy the variables away to somewhere safe.)
 
The short version is that the data should be accurate for your current situation. So after you've docked the information about the current station should be available, when you undock it goes away, system information should be accurate for your current system etc.

The data comes from a combination of EDDB, The companion API, and the monitors, with different sources taking precedence at different times depending on the current information known to EDDI. If you really need to know the details it's complex enough that it won't be any simpler to explain than to point you to the EDDI code (specifically EDDI.cs).

I'm sincerely not trying to be a PITA... I understand you're a busy guy and want to keep the pestering to a minimum and some understanding of how it works goes a long way. I'm very familiar with the Journal log manual, an EDDB API is pretty much (other than decoding the json's) non-existant. I have been studying your code, but I'm not conversant in .NET... Multiple degrees in electrical & computer engineering (studied C++, Java, Verilog), professional experience in FORTRAN & C (yes, I'm dating myself), but no .NET... teaching myself, but slow going.
 
Last edited:
You can access VoiceAttack event variables. Anything that's listed the big VoiceAttack help file can be copied the same way as any other variable.

Yes, I understand... I have a copies of the EDDI Voice Attack help file and the Journal Log manual on my desk and I'm very familiar with both.

We seem to be misunderstanding / talking past each other and I apologize if this is originating from my end. I will try to be more clear.

Not all the event variables available to the speech responder are similarly available to Voice Attack. For example the 'docking granted' speech responder has 'Station Type' but Voice Attack does not. If I could just call the 'Docking granted' speech responder script again (to repeat the landing pad location) via VA plugin call ('Script' = 'Docking granted', context = speech), I would do so... I tried but it doesn't work because the variables are no longer valid. Hence me asking for Station Type to be included in the VA variables for the ((EDDI docking granted)) event. Because I know just enough to be dangerous, it seems to me that if Station Type is available to the speech responder event script, then it should be available to the VA ((EDDI docking granted)) event.

This is where my line questions and requests stem.
 
Last edited:
Yes, I understand... I have a copies of the EDDI Voice Attack help file and the Journal Log manual on my desk and I'm very familiar with both.

We seem to be misunderstanding / talking past each other and I apologize if this is originating from my end. I will try to be more clear.

Not all the event variables available to the speech responder are similarly available to Voice Attack. For example the 'docking granted' speech responder has 'Station Type' but Voice Attack does not. If I could just call the 'Docking granted' speech responder script again (to repeat the landing pad location) via VA plugin call ('Script' = 'Docking granted', context = speech), I would do so... I tried but it doesn't work because the variables are no longer valid. Hence me asking for Station Type to be included in the VA variables for the ((EDDI docking granted)) event. Because I know just enough to be dangerous, it seems to me that if Station Type is available to the speech responder event script, then it should be available to the VA ((EDDI docking granted)) event.

This is where my line questions and requests stem.

Okay, so if you look at the script for in the speech responder for the Docking granted event it starts like this:

Code:
{set station to StationDetails(event.station)}

StationDetails() is a function that pulls the station details out of EDDB (well, a server that frontends EDDB with an API because themroc is allergic to REST, but hey). It returns a Station object. The problem with trying to incorporate this in to VoiceAttack is two-fold. First, there's no way of VoiceAttack running these ad-hoc functions and being able to return data. Second, even if it could then the question is how to return the data, as it's an entire object. Flattening it is one of the problems I was talking about that requires lots of work in VoiceAttack because it just doesn't have any idea of arrays or dictionaries, or anything else that would allow a complex object.

These are the types of issues that led me to give up on using VoiceAttack as the primary scripting language for EDDI. It just isn't designed with these complex use cases in mind.
 
Last time when i had the same problem i made a clean reinstall of EDDI and it worked again for me.

I've also had this happen a couple times, usually associated with computer crashes and EDDI configuration files getting corrupted. For me, just deleting the credentials.json corrected the problem.

EDIT: Lol, jgm beat me to it.
 
Last edited:
I've also had this happen a couple times, usually associated with computer crashes and EDDI configuration files getting corrupted. For me, just deleting the credentials.json corrected the problem.

EDIT: Lol, jgm beat me to it.

Had this too. This solved the problem on second try. Thanks!!!
 
Status
Thread Closed: Not open for further replies.
Back
Top Bottom