Release EDDI 3.3 - Bring your cockpit to life

EDDI version 2.4.5
VoiceAttack version 1.6.9
Elite Dangerous version 2.4.09 (Horizons)
Microsoft Windows 10 Home version 6.2.9200.0

Full Hardware Survey:

I had mentioned latest version, but I understand needing more specific details to troubleshoot. Thank you very much for your help. A bit of additional info, those modules (and their vertical position in the modules list) are not in the correct places as they are on the ship itself.

Here's a pic of Modules 1-10 as they actually are... note for the example, "standard docking computer" is NOT in the top 10, I believe it's module 19 or something in actuality:
https://i.imgur.com/yoq0qye.png
EDDI parses compartments in the order provided by FDev (which is not necessarily in order of power consumption like you see in your right hand screen).
It may be possible to change this in the future but as you say we've already got plenty on our plates with the new journal changes.
 
Last edited:
Various things:

Star Report is not working for me, whichever script I try always get the typical "not sure which star are you asking about".

Another thing, I assume Body Report and Star Report work same way: entering normal space in the proximity of that body, similarly Station Report takes its info when docking in.
It would be possible to force Eddi to have access to that info anywhere? I mean, we already have those data in the ingame system map, so could we "cheat" Eddi to access them (instead of logs) just to target a body/star/station and report its info? Or a least in the proximity of the target to get the info when landing on a planet (but still in supercruise) or when landing on a station (but not docked yet).
 
Last edited:
Various things:

Star Report is not working for me, whichever script I try always get the typical "not sure which star are you asking about".

Another thing, I assume Body Report and Star Report work same way: entering normal space in the proximity of that body, similarly Station Report takes its info when docking in.
It would be possible to force Eddi to have access to that info anywhere? I mean, we already have those data in the ingame system map, so could we "cheat" Eddi to access them (instead of logs) just to target a body/star/station and report its info?

Those two scripts are subroutines written to avoid duplicating large amounts of code and are not set up to be called directly. That said, those of you who run EDDI under Voice Attack may have options in this area that I’m not aware of.
 
Last edited:
Those two scripts are subroutines written to avoid duplicating large amounts of code and are not set up to be called directly.

Which two scripts are you refering to? Because Body Report works (at least the one I have) called directly, just entering normal space near a planet testing the script offers the desired info, on the other hand Star Report does not (it seems it only works on a recently scanned star).
Regarding to Station Report (and in fact the other Body and Star) , I'm not talking about Voice Attack, I mean if there's any way to change the sets and states in order to force Eddi to "lock" those targets so it knows which object is the one to retrieve info of.
Sorry if I'm not explaining well and/or if I'm not getting what do you mean.
Thanks in advance.
 
Last edited:
Which two scripts are you refering to? Because Body Report works (at least the one I have) called directly, just entering normal space near a planet testing the script offers the desired info, on the other hand Star Report does not (it seems it only works on a recently scanned star).
Regarding to Station Report (and in fact the other Body and Star) , I'm not talking about Voice Attack, I mean if there's any way to change the sets and states in order to force Eddi to "lock" those targets so it knows which object is the one to retrieve info of.
Sorry if I'm not explaining well and/or if I'm not getting what do you mean.
Thanks in advance.

I’m away from my PC and thus working from memory, but I’m fairly certain the “Test” button in the UI feeds the same canned data to the script regardless of where you are, specifically the data stored as “SAMPLE” in the source code for that class. This may have given you the wrong impression.

Perhaps one of my colleagues who is in front of their PC can give a definitive answer.
 
Hmmm, I use test button with game running in the specific location i want to test, that takes the real data, not the sample ones.
However not always use that test (it just saves time), and most of them I trigger the scripts in the normal way. Just said the test stuff to clarify this is all Eddi concerned and not VA, but see I messed up my explanations even further xD
 
Last edited:
Hmmm, I use test button with game running in the specific location i want to test, that takes the real data, not the sample ones.
However not always use that test (it just saves time), and most of them I trigger the scripts in the normal way. Just said the test stuff to clarify this is all Eddi concerned and not VA, but see I messed up my explanations even further xD

The `Body report` script reacts to variables that are set during the `Body scanned` event. Specifically:
Code:
{SetState('eddi_context_body_system', system.name)}
{SetState('eddi_context_body_name', event.name)}

Likewise, the `Star report` script reacts to variables that are set during the`Star report` script:
Code:
{SetState('eddi_context_star_system', system.name)}
{SetState('eddi_context_star_star', event.name)}

To understand how these variables are set, please review the documentation on the `SetState()` function.
 
Last edited:

That's a bit chinese for me. I have no clue about Cottle, just Basic (yes, I'm old xD), barely enough to understand how a script works.
Anyway, you all are quoting me a lot but not really answering the quotes. Not pretending to sound rude, not my intention. I'll requote myself to clarify:

Regarding to body, star and station report... "It would be possible to force Eddi to have access to that info anywhere?" I mean, inside a system, be able to get the system's star, planets and stations info just targetting, even in supercruise, without needing to be docked in that station, or enter normal space near the planet.
So, the key question is if we could do something like {SetState('eddi_context_last_action', 'target')}, or whatever we need to tell Eddi the contextual object is the targeted one, and grabbing the info from our old scans, dockings or even EDDN (don't mind if is unaccurate data).
 
That's a bit chinese for me. I have no clue about Cottle, just Basic (yes, I'm old xD), barely enough to understand how a script works.
Anyway, you all are quoting me a lot but not really answering the quotes. Not pretending to sound rude, not my intention. I'll requote myself to clarify:

Regarding to body, star and station report... "It would be possible to force Eddi to have access to that info anywhere?" I mean, inside a system, be able to get the system's star, planets and stations info just targetting, even in supercruise, without needing to be docked in that station, or enter normal space near the planet.
So, the key question is if we could do something like {SetState('eddi_context_last_action', 'target')}, or whatever we need to tell Eddi the contextual object is the targeted one, and grabbing the info from our old scans, dockings or even EDDN (don't mind if is unaccurate data).
Yes, it's possible. In fact, that's typically what is already happening on a scan in-game. The 'BodyDetails()' function in both the 'Star report' and 'Body report' scripts pulls data from a server and by setting variables like you see in the 'Body scanned' and 'Star scanned' scripts, you can control which data gets pulled (as long as the data is present on the server, the in-game scan is not even necessary - you can even pull data on places you've never visited before).
 
EDDI parses compartments in the order provided by FDev (which is not necessarily in order of power consumption like you see in your right hand screen).
It may be possible to change this in the future but as you say we've already got plenty on our plates with the new journal changes.
It turns out that one of the journal changes deals directly with this. No promises / guarantees, but by the time we finish incorporating all of the changes this may be included. :)
 
Yes, it's possible. In fact, that's typically what is already happening on a scan in-game. The 'BodyDetails()' function in both the 'Star report' and 'Body report' scripts pulls data from a server and by setting variables like you see in the 'Body scanned' and 'Star scanned' scripts, you can control which data gets pulled (as long as the data is present on the server, the in-game scan is not even necessary - you can even pull data on places you've never visited before).

Oooook, that's a clear answer! [yesnod] Thanks.
So... the one million question: How? What's the magical SetState to set x object as "targetted one", or even "selected one" (in map)?
 
Oooook, that's a clear answer! [yesnod] Thanks.
So... the one million question: How? What's the magical SetState to set x object as "targetted one", or even "selected one" (in map)?
FDev doesn't publish anything that we can reference when you target or select a body, so we can't set a variable based on that.

The closest you could probably get to what you are asking would be to program a command in VoiceAttack indicating which of the system bodies you are interested in learning about. e.g. 'Tell me about the 3rd planet in this system'. You could then use `SystemDetails()` to index through the bodies (perhaps by distance from your arrival point or by taking clues from the name of the body) and identify the body that you are interested in. Once you have the body name and system name, you could drop those into the `BodyDetails()` function and pull the complete details.
 
Hmm, the most direct procedure I can imagine is maybe using VA commands to "say" the name of the planet and saving that into a string variable that could be exported to Eddi as body.name.
The most direct procedure but not the easiest programming, at least for me xD
Besides, planets names are not common words that the TTS could catch well. Mmmmm, maybe in dictation mode... Don't know, and anyway I can set the theorics, but practise is another thing xD However I guess at least it deserves a try.
 
Last edited:
thanks for this nice tool. Is there an easy way to use eddi as two plugins in va? I'm trying out the beta and want to have a different config so my beta trips and ships are not exported to edsm ,... .
 
thanks for this nice tool. Is there an easy way to use eddi as two plugins in va? I'm trying out the beta and want to have a different config so my beta trips and ships are not exported to edsm ,... .

No need for that. EDDI recognizes when you’re in elite-beta and will not send data.
 
Can EDDI see if a module is powered up? I’m trying to get EDDI to check what modules you have installed and let you know which ones are power up when you perform a specific event. (ie you touchdown on a planet and get told that you have an SRV hanger installed but it’s powered off). Is that even possible?
I can’t work out how to get EDDI to give me a list of what modules are fitted either. All help and points in the right direction gratefully received. Thank you.
 
Can EDDI see if a module is powered up? I’m trying to get EDDI to check what modules you have installed and let you know which ones are power up when you perform a specific event. (ie you touchdown on a planet and get told that you have an SRV hanger installed but it’s powered off). Is that even possible?
I can’t work out how to get EDDI to give me a list of what modules are fitted either. All help and points in the right direction gratefully received. Thank you.

FD are adding this info to the Loadout event in v3.0 of the game, at which point EDDI will get access to it. Just a little while longer...
 
FD are adding this info to the Loadout event in v3.0 of the game, at which point EDDI will get access to it. Just a little while longer...

Actually, even though the data from the Frontier API is less reliable than what we'll be able to do with the Loadout event in 3.0, we can get this sort of information from the Frontier API now. It'll just become substantially more reliable with the improvements coming in 3.0. Here's my version of a script for this:
Code:
{if len(ship.model) > 0:
    {set installed to 0}
    {set enabled to 0}
    {set bays to 0}


    {for compartment in ship.compartments:
        {if compartment.module.name = "Planetary Vehicle Hangar":
            {set installed to 1}
            {if compartment.module.enabled:
                {set enabled to 1}
            }
            {if compartment.module.class > 0:
                {set bays to compartment.module.class / 2}
            }
        }
    }


    {SetState("srv_installed", installed)}
    {SetState("srv_enabled", enabled)}
    {SetState("srv_bays", bays)}
}
To use this, place this code into a script and call that script to update the state variables. If you call your script `SRV check`, you could put something like this in your `Touchdown` event:
Code:
   {_ SRV Check _}
   {F("SRV check")}
   {Pause(2000)}
   {if state.srv_installed && state.srv_enabled:
      SRV Ready {Occasionally(2, "for deployment.")}.
   |elif state.srv_installed:
      If you are planning an excursion, please enable the Planetary Vehicle Hangar.
   |else:
      No planetary vehicle hangar has been installed.
   }
 
Actually, even though the data from the Frontier API is less reliable than what we'll be able to do with the Loadout event in 3.0, we can get this sort of information from the Frontier API now. It'll just become substantially more reliable with the improvements coming in 3.0. Here's my version of a script for this:
Code:
{if len(ship.model) > 0:
    {set installed to 0}
    {set enabled to 0}
    {set bays to 0}


    {for compartment in ship.compartments:
        {if compartment.module.name = "Planetary Vehicle Hangar":
            {set installed to 1}
            {if compartment.module.enabled:
                {set enabled to 1}
            }
            {if compartment.module.class > 0:
                {set bays to compartment.module.class / 2}
            }
        }
    }


    {SetState("srv_installed", installed)}
    {SetState("srv_enabled", enabled)}
    {SetState("srv_bays", bays)}
}
To use this, place this code into a script and call that script to update the state variables. If you call your script `SRV check`, you could put something like this in your `Touchdown` event:
Code:
   {_ SRV Check _}
   {F("SRV check")}
   {Pause(2000)}
   {if state.srv_installed && state.srv_enabled:
      SRV Ready {Occasionally(2, "for deployment.")}.
   |elif state.srv_installed:
      If you are planning an excursion, please enable the Planetary Vehicle Hangar.
   |else:
      No planetary vehicle hangar has been installed.
   }

Aaaand this is why I love my colleagues.
 
Back
Top Bottom