So all those variables are voice attack variables? Like the INT:EDDI docking granted landingpad ? I had assumed those were EDDI internal variables. If they are Voice Attack variables, that changes everything.
Yes, it does.
To clarify, when EDDI parses a Journal event, it executes (simultaneously but asynchronously) both the Speech responder script and the VoiceAttack command associated with that Journal event. EDDI makes available to VoiceAttack any pertinent data that was included in the Journal event. As Commander Tkael stated, https://github.com/cmdrmcdonald/EliteDangerousDataProvider/blob/master/VoiceAttack.md is your friend when it comes to leveraging VoiceAttack with EDDI.
Another very important resource is the Journal Manual from FDev, which details all Journal events and the data available for each specific event, http://hosting.zaonce.net/community/journal/v8/Journal_Manual.doc. This is the bible... read it, learn it, live it. This will tell you exactly what EDDI is (and is not) capable of doing.
Lastly, be mindful of EDDI and VoiceAttack's particular strengths and weaknesses. EDDI is excellent at parsing large amounts of data and 'saying things', but is incapable of 'doing things' and passing data between EDDI & VA is doable but very limited. VoiceAttack is horrible at parsing data, okay at 'saying things', and is all about 'doing things'. Use each to it's strength and avoid, if you can, its weakness.
For example, my current project is utilizing the 'Traveling Salesman Problem' to take all your current missions, devise a 'shortest distance traveled' route (returning you back to your starting point), and automatically plot the next system as you complete missions.
The algorithm for TSP requires the use of a matrix of distances between each mission location. If I could build matrices within an EDDI speech responder script, the problem would be trivial because nested looping is sublime within Cottle, plus all the mission location distances are easily attainable (via SystemDetails())... Disclaimer: not sure if Cottle can 'do' matrices, which would put the kibosh on solving entirely within a speech responder script.
But, as I said, passing data from VA to EDDI is very limited. As a result, I pass the 'To' and 'From' systems names to a speech responder script which returns the distance and I build a pseudo-matrix within VoiceAttack using the 'dynamic variables' trick (VA on hard-mode and worthy of it's own post). Doing this within VA is very painful (because this IS NOT playing to VA's strength) but the results (I think) will greatly improve the QoL for Mission Stackers.
Building, maintaining, and pruning a 'mission list' from ((Mission accepted)), ((Mission completed)) and ((Mission abandoned)) events is pretty much working. I hope to have it fully working and share it with you all in the near future... current sticking point is finding a non-brute-force algorithim (shortcut to running all (n-1)! permutations) that is within VA's limited capability. The ultimate answer may be turning it into a VA plugin, but given I'm not a skilled C# programmer, there's a bit of a learning curve to overcome.
EDIT: multiple edits to improve readability
Last edited: