Morning/afternoon all (dependent on your location/perception). I've been banging my head against a virtual brick wall trying to get VA to be able to detect my manually selected destination system (not a mission destination) and hoping I can get some help. I am building a script to pull up the navigation panel after jumping to the destination system. I am using @Darkcyde 's VA profile as a base.
I am running a simple test script to see if it is captured, but I just can't get the wording down.
Any help is greatly apppreciated
I am running a simple test script to see if it is captured, but I just can't get the wording down.
Any help is greatly apppreciated
Attachments
Hi,
I'm glad you've found my profile to be a useful start for your own.
Looking at your attachment, I noticed that you are missing an 'e' off the end of 'state' in 'EDDI state routedetails_destination'. Hopefully that's what is causing your problem.
DC
Well... s**tHi,
I'm glad you've found my profile to be a useful start for your own.
Looking at your attachment, I noticed that you are missing an 'e' off the end of 'state' in 'EDDI state routedetails_destination'. Hopefully that's what is causing your problem.
DC
Sadly, that's not it either. I tried about 20 different state variables over the past few days. I am assuming that they are all triggered by the Route Details event in EDDI, but that only appears to be mission based, not "oh look, a shiny spot in the cosmos routing" that I have been doing. Basically, for example, I manually set a route to one of the engineers, I am looking for the variable that stores Deciat/Khun/etc to do a textcompare against the current system. In my mind:
Begin text Compare: [CurrentSystem] Equals [DestinationSystem]
Open Navigation Panel
End Condition
I have a few other profiles (KICS, ASTRA) that I have tried out, but yours is far more fleshed out IMO, specifically the mission routing. So thanks for your work on that!!
Thank you.
The missions routing was something started by myself and another commander a few years ago, using just the scripts themselves, and VA was used mainly to save routes between game sessions. It was eventually added into the EDDI program by the team, and has been considerably enhanced further by them since then. I just like to keep my own little embellishments in my profile scripts. So, I think I see what you're after, if I'm understanding you correctly. However, if you manually set a destination in-game (by selecting a body from the left nav panel, or a system from the GalMap), there is no way for EDDI or VA to know that you have done so, and as such no variables can be set. The game just doesn't write this info to any files, so there is nothing for EDDI to read.
The RouteDetails() function can only create routes (and associated variables) for the following types:
Encoded, Facilitator, Guardian, Human, Manufactured, Raw, Expiring, Farthest, Most, Nearest, Next, Route, Scoop, Set, Source, Update
These are all known values (i.e. the nearest materials trader). So if you're looking to make a route to a trader, or a scoopable star, etc, this is possible, but if you want to make a route to a random star system, then I'm afraid you're out of luck.
I've toyed with the idea of being able to tell EDDI to set a route to a system that I name via speech in VA, but it's much more difficult than I had imagined to convert speech to a valid system name, and so I kinda shelved the idea.
Last edited:
Thank you.
So, I think I see what you're after, if I'm understanding you correctly. However, if you manually set a destination in-game (by selecting a body from the left nav panel, or a system from the GalMap), there is no way for EDDI or VA to know that you have done so, and as such no variables can be set. The game just doesn't write this info to any files, so there is nothing for EDDI to read.
The RouteDetails() function can only create routes (and associated variables) for the following types:
Encoded, Facilitator, Guardian, Human, Manufactured, Raw, Expiring, Farthest, Most, Nearest, Next, Route, Scoop, Set, Source, Update
These are all known values (i.e. the nearest materials trader). So if you're looking to make a route to a trader, or a scoopable star, etc, this is possible, but if you want to make a route to a random star system, then I'm afraid you're out of luck.
I've toyed with the idea of being able to tell EDDI to set a route to a system that I name via speech in VA, but it's much more difficult than I had imagined to convert speech to a valid system name, and so I kinda shelved the idea.
Gotcha,
Thanks for that. The nearest event that comes close is the Next Jump event, as it can give the number of jumps to the final destination, but the destination variable in that one is the next system in the manual route.
It's been a while since I looked at using VA to set a destination. If you can get it to work, you could get VA to set a variable to a converted spoken system name, and then pass that to EDDI RouteDetails() using the 'set' route type. In the EDDI help for this function, it says you can use it like this:
{RouteDetails("set", "Achenar", "Macmillan Terminal")}In your case you would need to set the system name to a spoken value, "Achenar" in this example, and then run the RouteDetails("set", VA_system_variable) to achieve what you are looking for. The hardest part of that though, will be getting VA to recognise the system name you say accurately enough to be valid.
When they released the update that added Bookmarks to the Galaxy Map, I started using voice macros to plot a route to one of them, and a means to add/remove bookmarks with VA - imho that is the only reliable method to set a route by voice, since so many of the other listings in menus are dynamic, and variable by system or region. Making the means to add a new bookmark by voice a faster than manual input procedure has allowed me to do that same thing of "oh look, go there" with manually selecting something in the navigation panel, and then get back on course to other preset waypoints in my exploration route, such as the system I started at when I looked for things to go to... like having a branching path in the forest, but placing a marker at the fork so you can come back and try each path.
Since so many system names are not favorable to voice input (unless already saved as a voice command, 'hard set' for recognition) I will fumble for the keyboard while in VR just to tap in a new system bookmark name, but I've been playing with a letters/numbers typing script, too (needs work).
There are some things that are perfectly "Star Trek" when using VA with ED, but other times there are those hard limitations. Don't give up, outside the box thinking is the only way to reach that end goal you have, and if you keep pursuing other methods or means when you hit one wall, you may be able to get around it (maybe). Making the impossible possible is just a matter of time and effort, and how much of each you are willing to put into it (though sometimes it's just not worth the effort to 're-invent the wheel' just so it can have prettier spokes). Best wishes and good luck, whatever you do!
@Don_Chooluvit I've opened a Feature Request on the EDDI Github, with a possible solution that could be implemented.
github.com
Auto generate a RouteDetails() from the NavRoute.json file · Issue #2108 · EDCD/EDDI
What happens now To generate a route, and have the variables set to the route details, we need to manually invoke a RouteDetails() with the relevant route type. This can currently only be done with...
github.com
Hoping someone can assist me.
I was wondering if its at all possibke to write a script to give a warning when you are say, 12 seconds (as in actual time, not light seconds/distance) away from a target in super cruise.
I'm basically wanting a voice prompt to tell me that I need to begin slowing down when approaching a destination in supercruise before it gets to the 7 second mark.
I'm very new at this, but I'm usually competent (or persistent) but could use a point in the right direction.
I was wondering if its at all possibke to write a script to give a warning when you are say, 12 seconds (as in actual time, not light seconds/distance) away from a target in super cruise.
I'm basically wanting a voice prompt to tell me that I need to begin slowing down when approaching a destination in supercruise before it gets to the 7 second mark.
I'm very new at this, but I'm usually competent (or persistent) but could use a point in the right direction.
I don't believe this would be possible. EDDI only responds to events in the player journal, and also obtains information from the games API. There is no way for EDDI to tell when you are any distance, or time, away from a target as this isn't provided by either source.
That being said, there is an in-game module you can buy that can help in this situation. It's called the 'Supercruise Assist' and will help by automatically slowing you down. It's not as efficient as doing it yourself, but if you need a helping hand, it will work fine. It's pretty cheap too, at around 8.5K Cr depending on where you buy it from.
Yeah I'm aware of the supercruise assist, it's too damn slow though lol.
I'm fine with using supercruise, I just get distracted on discord or looking through panels and tend to miss the slow down make and overshoot.
I had hoped there might have been a way to use the "entered supercruise" event as a trigger and then possibly monitor the time from target, perhaps with something like a 'while' command.
Guess not though, pity as I think that'd be useful.
Also was hoping for a prompt for killwarrant scanners for targetting a ship that's already been kw scanned, and a voice prompt when the scan completes, but I don't believe there's any events for the KW scanner
The event for that is 'Ship targetted', as this deals with ship scanning. Within that, it adds any wanted ships scanned, to a list, and then ignores them if scanned again. Without looking at it too in-depth, I'd say it's possible to change this so it will always say if the target is wanted, whether you've already scanned them or not.Also was hoping for a prompt for killwarrant scanners for targetting a ship that's already been kw scanned, and a voice prompt when the scan completes, but I don't believe there's any events for the KW scanner
I think if you change this code:
Code:
{set wanted_list to split(state.eddi_context_wanted_list, "+=")}
{if find(wanted_list, event.name) < 0:
{event.name} {OneOf("has a bounty", "is fair game", "is a legitimate target")}.
{if len(wanted_list) = 0: {set sep to ""} |else: {set sep to "+="}}
{set wanted_list to cat(wanted_list, [event.name])}
{SetState('eddi_context_wanted_list', join(wanted_list, sep))}
}to this:
Code:
{event.name} {OneOf("has a bounty", "is fair game", "is a legitimate target")}.
{if len(wanted_list) = 0: {set sep to ""} |else: {set sep to "+="}}
{set wanted_list to cat(wanted_list, [event.name])}
{SetState('eddi_context_wanted_list', join(wanted_list, sep))}EDIT: Ah, I've just re-read you post, and I think my answer might actually be irrelevant after all. Still, it's worth a try, to see if it works.
I usually bind the KWS to a weapon where I can just hold down a trigger long enough to complete the scan (using engineering to modify the scanner for fast scanning) then just let it scan as I shoot. If a ship ends up being scanned more than once then that's fine with me. I hardly have to think about scanning while I'm engaged in combat.Also was hoping for a prompt for killwarrant scanners for targetting a ship that's already been kw scanned, and a voice prompt when the scan completes, but I don't believe there's any events for the KW scanner
If you were to take this approach, I don't think there would be any value in appending the value to the list so you could shorten the entire script toThe event for that is 'Ship targetted', as this deals with ship scanning. Within that, it adds any wanted ships scanned, to a list, and then ignores them if scanned again. Without looking at it too in-depth, I'd say it's possible to change this so it will always say if the target is wanted, whether you've already scanned them or not.
I think if you change this code:
Code:{set wanted_list to split(state.eddi_context_wanted_list, "+=")} {if find(wanted_list, event.name) < 0: {event.name} {OneOf("has a bounty", "is fair game", "is a legitimate target")}. {if len(wanted_list) = 0: {set sep to ""} |else: {set sep to "+="}} {set wanted_list to cat(wanted_list, [event.name])} {SetState('eddi_context_wanted_list', join(wanted_list, sep))} }
to this:
(just removing the initial 'set' and 'find' code, plus the corresponding end } ) will most likely do what you want. I've not tried it, so I can't guarantee it, but I think it should work.Code:{event.name} {OneOf("has a bounty", "is fair game", "is a legitimate target")}. {if len(wanted_list) = 0: {set sep to ""} |else: {set sep to "+="}} {set wanted_list to cat(wanted_list, [event.name])} {SetState('eddi_context_wanted_list', join(wanted_list, sep))}
EDIT: Ah, I've just re-read you post, and I think my answer might actually be irrelevant after all. Still, it's worth a try, to see if it works.
Code:
{_ Ship targeted }
{_ Triggered when the player selects a target }
{_ event Parameters: targetlocked - bool (ie false when losing target) _}
{_ If target locked: name (of ship), scanstage (ie 0, 1, 2, 3) _}
{_ If Scan stage >= 1: name (of pilot), rank (of pilot) _}
{_ If scan stage >= 2: shieldhealth, hullhealth (both 0-100) _}
{_ If scan stage >= 3: faction, power (if player is pledged to a power), _}
{_ legalstatus (ie clean, wanted, etc), bounty (if applicable), _}
{_ subsystem (ie FSD, power plant, etc), subsystemhealth (0-100) _}
{_ Context }
{SetState('eddi_context_last_subject', 'ship')}
{SetState('eddi_context_last_action', 'targeted')}
{if event.targetlocked && event.scanstage > 2 && !event.subsystem:
{set legalstatus to event.legalstatus}
{if legalstatus = "Wanted" || legalstatus = "Wanted Enemy" || legalstatus = "Warrant":
{event.name} {OneOf("has a bounty", "is fair game", "is a legitimate target")}.
}
}It isn't implemented but you aren't the first to request something like that. See https://github.com/EDCD/EDDI/issues/197
Hey guys n gals, sorry for al the questions, ive gotten most of my EDDI scripts organised how I want, but I am struggling to make sense of the scanning scripts.
I am trying to figure out how the various body scan scripts interact with each other so that I can figure out which ones need to be changed.
What I'd like:
Discovery scan:
if system already scanned then do nothing, else:
Total count of bodies - "Scan complete. [count] bodies found."
High Value bodies (AW, ELW, WW, and terraformables) - " [count] notable body/bodies found. Suggest full spectrum scanning"
^ if possible, add a boolean toggle to only read out high value potential if current ship has a DSS fitted.
FSS:
On FSS scanning - I want a simple readout that just tells me what the type of body/transmission is, such as 'Icy Ringed planet found."
High Value body (AW, ELW, WW, and terraformables) - "This body may be suitable for further detailed surface scanning"
Ringed planets - "Planet rings may contain [material types]." (if thats possible, to identify mining hotspots or things like musgravite etc).
When all high value bodies scanned - "All high value bodies have been indexed". (only if there are remaining non high value bodies remaining)
When ALL bodies scanned - "All bodies in this system have been indexed".
DSS:
On Scan 100% - "Mapping Complete" Then use the default bodyreport script.
Notes: The default scripts have toggles for some things, like the bodyreport script lets you toggle off certain information, so I wouldnt mind having something similar for toggling which body types are included as "High value" (such as including gas giants or not). Alternatively, if I can set a value limit, as I noticed there's an estimatedvalue variable for bodies, so perhaps high value planets can just be set by an estimatedvalue threshold rather than by actual body type, or even have the option of using both (must be of a certain type, and also have an estimate value of above X).
That said, I am unsure how accurate the estimated value variable is or what criteria it uses (does it act off a full DSS mapping or just an FSS scan?)
So, my first question, is all of these things actually possible? if not, which bits aren't?
And secondly, I am trying to figure out what scripts would relate to each of these? I am unsure on which scripts are triggered for each scan type, like I can see there's a discovery scan script, and a body mapped script (which I believe is the DSS?), but I cant see one for the FSS.
Or, if anyone has something a bit similar already setup, then I'd love to pick through their scripts if thats at all possible.
I also won't say no if someone just wants to take up the challenge to do it all for me, but I'm not in any way expecting that.
I am trying to figure out how the various body scan scripts interact with each other so that I can figure out which ones need to be changed.
What I'd like:
Discovery scan:
if system already scanned then do nothing, else:
Total count of bodies - "Scan complete. [count] bodies found."
High Value bodies (AW, ELW, WW, and terraformables) - " [count] notable body/bodies found. Suggest full spectrum scanning"
^ if possible, add a boolean toggle to only read out high value potential if current ship has a DSS fitted.
FSS:
On FSS scanning - I want a simple readout that just tells me what the type of body/transmission is, such as 'Icy Ringed planet found."
High Value body (AW, ELW, WW, and terraformables) - "This body may be suitable for further detailed surface scanning"
Ringed planets - "Planet rings may contain [material types]." (if thats possible, to identify mining hotspots or things like musgravite etc).
When all high value bodies scanned - "All high value bodies have been indexed". (only if there are remaining non high value bodies remaining)
When ALL bodies scanned - "All bodies in this system have been indexed".
DSS:
On Scan 100% - "Mapping Complete" Then use the default bodyreport script.
Notes: The default scripts have toggles for some things, like the bodyreport script lets you toggle off certain information, so I wouldnt mind having something similar for toggling which body types are included as "High value" (such as including gas giants or not). Alternatively, if I can set a value limit, as I noticed there's an estimatedvalue variable for bodies, so perhaps high value planets can just be set by an estimatedvalue threshold rather than by actual body type, or even have the option of using both (must be of a certain type, and also have an estimate value of above X).
That said, I am unsure how accurate the estimated value variable is or what criteria it uses (does it act off a full DSS mapping or just an FSS scan?)
So, my first question, is all of these things actually possible? if not, which bits aren't?
And secondly, I am trying to figure out what scripts would relate to each of these? I am unsure on which scripts are triggered for each scan type, like I can see there's a discovery scan script, and a body mapped script (which I believe is the DSS?), but I cant see one for the FSS.
Or, if anyone has something a bit similar already setup, then I'd love to pick through their scripts if thats at all possible.
I also won't say no if someone just wants to take up the challenge to do it all for me, but I'm not in any way expecting that.
This is a bit of a mash up of multiple default scripts as I am still learning (I don't even yet know what code language this is using, I am using python syntax highlighting in notepad++ but not sure exactly).
But here is my discovery scanner script so far:
The "Bodies notable" is a seperate script that contains all the coinfigurable options for what should be considered "notable", it include planet type, estimated value, or terraformable. It was taken from the default bodies to map script, and now I can call the same options in multiple scripts while having different readouts.
:::UPDATED 2:16 - 24/02/2021:::
I would like to add a toggle to ONLY read out notable bodies if a DSS is installed on the current ship or if it will read it anyway. But other than that it appears to be working so far.
If anyone can see any improvements or possible mistakes I may have made that feedback would be appreciated.
But here is my discovery scanner script so far:
The "Bodies notable" is a seperate script that contains all the coinfigurable options for what should be considered "notable", it include planet type, estimated value, or terraformable. It was taken from the default bodies to map script, and now I can call the same options in multiple scripts while having different readouts.
:::UPDATED 2:16 - 24/02/2021:::
Code:
{_ Fetch from Context, if a context is set _}
{if state.eddi_context_system_name:
{set reportSystem to SystemDetails(state.eddi_context_system_name)}
|else:
{set reportSystem to SystemDetails(system.systemname)}
}
{set unreportedHighValue to true} {_ Reports a list of notable planets that have been scanned but not mapped _}
{set reportUndiscovered to true} {_ Reports any potential first discovery bodies _}
{F("Bodies notable")} {_ Fetches options stored in Bodies notable script to determine good candidates _}
{if !reportSystem.name || reportSystem.name = "":
I'm not sure which system you are asking about.
|else:
{pause(1000)}
{set totalBodies to 0}
{set mappedBodies to 0}
{set notableBodies to 0}
{set undiscoveredBodies to 0}
{set toMapList to []}
{set scannedNotableBodies to 0}
{set mappedNotableBodies to 0}
{for body in reportSystem.bodies:
{set totalBodies to totalBodies + 1}
{if body.mapped:
{set mappedBodies to mappedBodies +1}
}
{if body.bodyType.invariantName != "Star":
{if reportPlanetTypes[body.planetClass.invariantName]:
{if !body.alreadydiscovered:
{set undiscoveredBodies to undiscoveredBodies +1}
}
{if !toMapList[body.shortname]:
{set toMapList to cat(toMapList, [body.shortname])}
}
{if body.scanned:
{set scannedNotableBodies to scannedNotableBodies +1}
}
{if body.mapped:
{set mappedNotableBodies to mappedNotableBodies +1}
}
|elif body.estimatedvalue > highValueThreshold:
{if !body.alreadydiscovered:
{set undiscoveredBodies to undiscoveredBodies +1}
}
{if !toMapList[body.shortname]:
{set toMapList to cat(toMapList, [body.shortname])}
}
{if body.scanned:
{set scannedNotableBodies to scannedNotableBodies +1}
}
{if body.mapped:
{set mappedNotableBodies to mappedNotableBodies +1}
}
|elif body.terraformState.invariantName = "Candidate for terraforming" || body.terraformState.invariantName = "Terraformed":
{if reportTerraformables:
{if !body.alreadydiscovered:
{set undiscoveredBodies to undiscoveredBodies +1}
}
{if !toMapList[body.shortname]:
{set toMapList to cat(toMapList, [body.shortname])}
}
{if body.scanned:
{set scannedNotableBodies to scannedNotableBodies +1}
}
{if body.mapped:
{set mappedNotableBodies to mappedNotableBodies +1}
}
}
}
}
}
}
{set notableBodies to len(toMapList)}
{_ Begin talking _}
Scan Complete:
{if notableBodies != scannedNotableBodies || notableBodies = 0:
{totalBodies} bodies {Occasionally(2, "have been")} {OneOf("detected", "identified", "scanned", "indexed")},
{if scannedNotableBodies < 1:
{if notableBodies = 1:
One of which is potentially {OneOf("notable", "of interest", "interesting", "of high value")}.
|elif notableBodies > 1:
{notableBodies} of {OneOf("which are", "which may be", "these are")} {OneOf("potentially notable bodies", "potentially interesting bodies", "potentially high value", "of potential interest")}.
}
|elif notableBodies > 0:
There
{if (notableBodies - scannedNotableBodies) = 1:
is
|else:
are
}
still {notableBodies - scannedNotableBodies} potentially {OneOf("notable", "interesting", "high value")} bodies to be {OneOf("scanned", "identified", "indexed")}.
}
|elif mappedNotableBodies != notableBodies:
{if notableBodies = 1: Body |else: Bodies}
{set cur to 0}
{while cur < notableBodies:
{P(toMapList[cur], "body")}
{set cur to cur + 1}
{if cur = notableBodies - 1: and
|elif cur < notableBodies - 1:,
}
}
{if notableBodies = 1: has
|else: have
}
not yet been detail surface scanned.
|else:
{OneOf("You have mapped all {if mappedBodies < totalBodies: {OneOf(\"notable\", \"interesting\", \"high value\", \"worthwhile\")}} bodies.",
"All {OneOf(\"notable\", \"interesting\", \"high value\", \"worthwhile\")} bodies {OneOf(\"have been mapped\", \"are now mapped\")}")}
}
{if reportUndiscovered && undiscoveredBodies > 0:
There are {undiscoveredBodies} undiscovered bodies in this system.
}I would like to add a toggle to ONLY read out notable bodies if a DSS is installed on the current ship or if it will read it anyway. But other than that it appears to be working so far.
If anyone can see any improvements or possible mistakes I may have made that feedback would be appreciated.
Last edited:
Mining hotspots aren't revealed until you actually send a probe into the ring. Hotspot data is also not available from the EDSM server.
If we haven't scanned a body then we won't have information to judge whether that body is high value or not unless the body was previously scanned and we were able to retrieve that prior scan data from EDSM.
Estimated value is present from the FSS scan, but you should note that the estimated value will increase if you also perform a DSS scan.
The FSS scan triggers the
Body scanned script. Depending on your selections, that script would then invoke either the Body report script or the Body report summary script (the latter being the default). I would suggest that you scoop out the Body report summary script, copy in the Body report script, and then trim the contents down to suit your wishes and make comparisons against your Bodies notable criteria. The script already includes a section that describes rings.As you surmised, the DSS scan triggers the
Body mapped script ("Mapping complete"), which then invokes the Body report script to provide a detailed description of the mapped body. The default behavior here sounds similar to what you are trying to accomplish so you likely won't need to modify either script very much.