Release EDDI 3.3 - Bring your cockpit to life

I have the same issue. EDDI always report I have on jump remaining when arriving at destination system.
Is there a wrong "," in the script line 32 and or line 34
Hmm, no, that section of code only reacts to jump_count being greater than 0, which is set on line 14 from an existing state variable. That state variable seems to only be set in the 'Next jump' event script, which is triggered when a system is selected to jump to, and should be set to zero when your FSD kicks in (the FSD engaged event). I'm guessing 'Next jump' is triggered somewhere between 'FSD engaged' (where the state variable is set to zero), and the 'Jumped' event (which is reporting the one more jump).

Maybe @T'kael or @VerticalBlank can provide more insight into this. In the mean time, I'll see if I can reproduce it myself.
 
Hmm, no, that section of code only reacts to jump_count being greater than 0, which is set on line 14 from an existing state variable. That state variable seems to only be set in the 'Next jump' event script, which is triggered when a system is selected to jump to, and should be set to zero when your FSD kicks in (the FSD engaged event). I'm guessing 'Next jump' is triggered somewhere between 'FSD engaged' (where the state variable is set to zero), and the 'Jumped' event (which is reporting the one more jump).

Maybe @T'kael or @VerticalBlank can provide more insight into this. In the mean time, I'll see if I can reproduce it myself.
You are right, my FSD Engaded script was disabled. It works now. But I dont think it is reporting "arrived at destination"
 
You are right, my FSD Engaded script was disabled. It works now. But I dont think it is reporting "arrived at destination"
Ahhh, ok, that explains that part then.

Hmm, the Jumped script should say you have arrived when destinationdistance is zero. I'll test that and see what I come up with.
 
OK, so I've tried this out now. I will admit, I'm not 100% sure I'm doing this right, but this is what I've done:

I've taken a few quick delivery missions to nearby systems, and then run RouteDetails("route"), with this output:
"Missions route calculated for 3 systems. Total route distance is 48.0 lightyears. First mission destination is C D-51 1 4 4 7, 15.6 lightyears away."

I've then selected the system in the galaxy map (and set a route to it), and tested the variables destinationsystem.name & destinationdistance. destinationsystem.name is blank (and destinationsystem is 'void'), and destinationdistance is zero.

I then went and completed the first delivery mission, and got this:
"Next mission destination is Esubilanque, 12.9 lightyears away."

Now I get destinationsystem.name and destinationdistance filled with the correct information, as per the output above. Jumping to Esubilanque, I now get it telling me I have arrived: "... Silcarius has arrived at the Esubilanque system.... "

So, as long as I'm doing this right, it looks like these variables are only being populated when a RouteDetails("update") is performed (and successfully completed), but not when a RouteDetails("route") is done to begin with. This means that if you only have one mission, it will never tell you that you have arrived at your mission destination. If you have 2 or more, then it will tell you for the second one and each after that.
 
Last edited:
OK, so I've tried this out now. I will admit, I'm not 100% sure I'm doing this right, but this is what I've done:

I've taken a few quick delivery missions to nearby systems, and then run RouteDetails("route"), with this output:
"Missions route calculated for 3 systems. Total route distance is 48.0 lightyears. First mission destination is C D-51 1 4 4 7, 15.6 lightyears away."

I've then selected the system in the galaxy map (and set a route to it), and tested the variables destinationsystem.name & destinationdistance. destinationsystem.name is blank (and destinationsystem is 'void'), and destinationdistance is zero.

I then went and completed the first delivery mission, and got this:
"Next mission destination is Esubilanque, 12.9 lightyears away."

Now I get destinationsystem.name and destinationdistance filled with the correct information, as per the output above. Jumping to Esubilanque, I now get it telling me I have arrived: "... Silcarius has arrived at the Esubilanque system.... "

So, as long as I'm doing this right, it looks like these variables are only being populated when a RouteDetails("update") is performed (and successfully completed), but not when a RouteDetails("route") is done to begin with. This means that if you only have one mission, it will never tell you that you have arrived at your mission destination. If you have 2 or more, then it will tell you for the second one and each after that.
thank you for taking the time to test, but this is beyond my comprehension. I guess it does not work quite as it should.
 
OK, so I've tried this out now. I will admit, I'm not 100% sure I'm doing this right, but this is what I've done:

I've taken a few quick delivery missions to nearby systems, and then run RouteDetails("route"), with this output:
"Missions route calculated for 3 systems. Total route distance is 48.0 lightyears. First mission destination is C D-51 1 4 4 7, 15.6 lightyears away."

I've then selected the system in the galaxy map (and set a route to it), and tested the variables destinationsystem.name & destinationdistance. destinationsystem.name is blank (and destinationsystem is 'void'), and destinationdistance is zero.

I then went and completed the first delivery mission, and got this:
"Next mission destination is Esubilanque, 12.9 lightyears away."

Now I get destinationsystem.name and destinationdistance filled with the correct information, as per the output above. Jumping to Esubilanque, I now get it telling me I have arrived: "... Silcarius has arrived at the Esubilanque system.... "

So, as long as I'm doing this right, it looks like these variables are only being populated when a RouteDetails("update") is performed (and successfully completed), but not when a RouteDetails("route") is done to begin with. This means that if you only have one mission, it will never tell you that you have arrived at your mission destination. If you have 2 or more, then it will tell you for the second one and each after that.
@T'kael and @VerticalBlank, is this the expected behaviour, or should I raise an issue on GitHub?
 
thank you for taking the time to test, but this is beyond my comprehension. I guess it does not work quite as it should.
All done. Number #2232
Thanks. Here's my initial evaluation:

The proper flow, as currently programmed, appears to be:
1. {RouteDetails("route")} 'Traveling Salesman' (RNNA) route for all active missions. Takes a system name as an optional secondary argument. If set, the resulting route shall be plotted relative to the specified star system rather than relative to the current star system. This proposes a route but does not set it (see step 2).
2. {RouteDetails("set")} Set destination route to a single system. Sets the route destination to the last star system name returned from a Route details event. An optional second argument sets the route destination to the star system name specified instead. An optional third argument sets the destination station. This sets the actual destination.
3. (Do mission stuff)
4. {RouteDetails("update")} Update to the next mission route destination, once all missions in current system are completed. Takes a system name as an optional secondary argument. If set, the resulting route shall be plotted relative to the specified star system rather than relative to the current star system. This updates the mission destination.
 
Thanks. Here's my initial evaluation:

The proper flow, as currently programmed, appears to be:
1. {RouteDetails("route")} 'Traveling Salesman' (RNNA) route for all active missions. Takes a system name as an optional secondary argument. If set, the resulting route shall be plotted relative to the specified star system rather than relative to the current star system. This proposes a route but does not set it (see step 2).
2. {RouteDetails("set")} Set destination route to a single system. Sets the route destination to the last star system name returned from a Route details event. An optional second argument sets the route destination to the star system name specified instead. An optional third argument sets the destination station. This sets the actual destination.
3. (Do mission stuff)
4. {RouteDetails("update")} Update to the next mission route destination, once all missions in current system are completed. Takes a system name as an optional secondary argument. If set, the resulting route shall be plotted relative to the specified star system rather than relative to the current star system. This updates the mission destination.
Ahh, ok, I see. I, and I guess others, had assumed that requesting a 'route' would also set the 'destinationsystem' (and related variables). Would it be possible then, to amend the help page entry for RouteDetails() to clarify that a destination is not set, and that a 'set' is still required for this?

I was just thinking about it, and I can see why this has been done this way, but wouldn't it be better to automatically set the 'destinationsystem' (et al) when a route of any kind is requested? Requesting a route and then a 'set', repeats the destination speech, which is redundant (and kind of annoying too). Also, most of the time when a route is requested, people will want the destination set anyway.

Hmm, I've just tried the above for the nearest human broker:
Code:
{set route to RouteDetails("human")}
{set route to RouteDetails("set")}
{destinationsystem}.
I get this output:
The nearest human technology broker is at Broderick Dock, in the Timos system, 36.9 lightyears away. Clipboard set to destination system.
.
Destination set to the Timos system, 36.9 lightyears away.
What am I doing wrong that makes 'destinationsystem' not be populated? I can understand that it may not be populated in this output because it seems to be coming before the 'set', but even after running this script and trying 'destinationsystem' by itself, it's still not set (even if I run each line of code individually). Or doesn't "set" work for "human", is it only for "route"? 🤔
 
Hi Darkcyde,
I'm sure you're more versed in Cottle programming, but I took a look at github anyway. One thing caught my eye.
You write here "destinationsystem" but I think only "destination" has to go in here. Please have another look yourself.


1628191504428.png
 
Hi Darkcyde,
I'm sure you're more versed in Cottle programming, but I took a look at github anyway. One thing caught my eye.
You write here "destinationsystem" but I think only "destination" has to go in here. Please have another look yourself.


View attachment 255022
Hi nepomuk,

Well, I may be above average with Cottle programming, but I still have trouble sometimes with fully understanding the functions and variables that EDDI uses. You are absolutely right to ask those kind of questions, because I could easily be wrong with something I've said. I learn just as much from other people asking questions, as I do trying things by myself. So keep asking! ☺️

In this case though, while I understand what you are saying, I believe those variables are only available in the 'Route details' event (and any script that uses RouteDetails() ). As far as I can see, they are not global variables (like a State variable is). To use them, they are event variables, so event.routetype for example. To use them in other scripts later, you would need to set State variables to them. I have a block of State variables at the end of the 'Route details' script that does this for me:
Code:
{SetState('routedetails_routetype', event.routetype)}
{SetState('routedetails_destination', event.system)}
{SetState('routedetails_station', event.station)}
{SetState('routedetails_route', event.route)}
{SetState('routedetails_distance', event.distance)}
{SetState('routedetails_routedistance', event.routedistance)}
{SetState('routedetails_count', event.count)}
{SetState('routedetails_missionids', event.missionids)}
Hmm, looking at this now, I see there is no 'destination' variable for that event. It seems to be called 'system' instead. Looks like the help section could be wrong. This is copied from the 'variables' page for the 'Route details' event:
Information about this event is available under the event object. Note that these variables are only valid for this particular script; other scripts triggered by different events will have different variables available to them.
  • count - Count of missions, systems, or expiry seconds, depending on route type
  • distance - The distance to the destination system
  • missionids - The mission ID(s) associated with the destination system, if applicable
  • route - Delimited systems list, if applicable
  • routedistance - The remaining distance of the missions route, if applicable
  • routetype - Type of route query
  • station - The destination station, if applicable
  • system - The destination system

The two variables I was referring to above (destinationsystem.name and destinationdistance) are global variables set when a RouteDetails("set") is done (or an "update"). These should be set and available to all scripts, just like a State variable is. They are used in the 'Jumped' event on lines 23 & 24:
Code:
{if destinationsystem && destinationsystem.name != "":
    {if destinationdistance = 0:

These should be set by a RouteDetails("set") after a route has been created, but as in my previous post, they don't appear to be set if the route was a RouteDetails("human") one.

DC
 
Hi nepomuk,

Well, I may be above average with Cottle programming, but I still have trouble sometimes with fully understanding the functions and variables that EDDI uses. You are absolutely right to ask those kind of questions, because I could easily be wrong with something I've said. I learn just as much from other people asking questions, as I do trying things by myself. So keep asking! ☺️

In this case though, while I understand what you are saying, I believe those variables are only available in the 'Route details' event (and any script that uses RouteDetails() ). As far as I can see, they are not global variables (like a State variable is). To use them, they are event variables, so event.routetype for example. To use them in other scripts later, you would need to set State variables to them. I have a block of State variables at the end of the 'Route details' script that does this for me:
Code:
{SetState('routedetails_routetype', event.routetype)}
{SetState('routedetails_destination', event.system)}
{SetState('routedetails_station', event.station)}
{SetState('routedetails_route', event.route)}
{SetState('routedetails_distance', event.distance)}
{SetState('routedetails_routedistance', event.routedistance)}
{SetState('routedetails_count', event.count)}
{SetState('routedetails_missionids', event.missionids)}
Hmm, looking at this now, I see there is no 'destination' variable for that event. It seems to be called 'system' instead. Looks like the help section could be wrong. This is copied from the 'variables' page for the 'Route details' event:


The two variables I was referring to above (destinationsystem.name and destinationdistance) are global variables set when a RouteDetails("set") is done (or an "update"). These should be set and available to all scripts, just like a State variable is. They are used in the 'Jumped' event on lines 23 & 24:
Code:
{if destinationsystem && destinationsystem.name != "":
    {if destinationdistance = 0:

These should be set by a RouteDetails("set") after a route has been created, but as in my previous post, they don't appear to be set if the route was a RouteDetails("human") one.

DC
Noted, help documentation for Route details will receive a bit of polish.

With respect to your test, I think you're mostly doing it right.
destinationsystem should be a star system object but you're code above seems to be expecting a string.

I'm triggering an exception when I put these together in the same script.
Code:
{set route to RouteDetails("human")}
{set route to RouteDetails("set")}

If I break it up into two scripts then it works.
Code:
{set route to RouteDetails("human")}
Code:
{set route to RouteDetails("set")}
{destinationsystem.systemname} confirmed.
 
Last edited:
Noted, help documentation for Route details will receive a bit of polish.

With respect to your test, I think you're mostly doing it right.
destinationsystem should be a star system object but you're code above seems to be expecting a string.

I'm triggering an exception when I put these together in the same script.
Code:
{set route to RouteDetails("human")}
{set route to RouteDetails("set")}

If I break it up into two scripts then it works.
Code:
{set route to RouteDetails("human")}
Code:
{set route to RouteDetails("set")}
{destinationsystem.systemname} confirmed.
Ah yes, you're right about the {destinationsystem} being wrong in my test. Must have been a typo while I was trying things. 🙁

Your suggestion of {destinationsystem.systemname} isn't what is used in the Jumped event though. It's {destinationsystem.name} in there, but I guess it seems that either will work just as well. :)

I've tried my test again (using the right variable this time), and I'm not getting any problems, other than the {destinationsystem.name} being spoken between the two RouteDetails() lines (and not being populated until after the "set" has been performed). There are no errors in the log either. Any ideas why the RouteDetaisl() is behaving like this? Shouldn't they execute in linear order, one after the other, and then the {destinationsystem.name}?

I've also tried a second script where I cancel the route, then have the variable spoken. This runs in reverse order, first speaking the variable, and then cancelling the route. I tried your example too, one script to get a route, and the second to set it and speak the variable. The second script also went in reverse order, saying nothing for the variable, and then speaking the "set" message. From this, it seems that RouteDetails() is best run by itself in a separate script, before you need to use it's output, otherwise you get very weird results where variables are populated when you don't expect them to be, or not populated when you would expect that they are. 🤷‍♂️

Or is my PC just running things in a very weird way? 🤔
 
Ah yes, you're right about the {destinationsystem} being wrong in my test. Must have been a typo while I was trying things. 🙁

Your suggestion of {destinationsystem.systemname} isn't what is used in the Jumped event though. It's {destinationsystem.name} in there, but I guess it seems that either will work just as well. :)

I've tried my test again (using the right variable this time), and I'm not getting any problems, other than the {destinationsystem.name} being spoken between the two RouteDetails() lines (and not being populated until after the "set" has been performed). There are no errors in the log either. Any ideas why the RouteDetaisl() is behaving like this? Shouldn't they execute in linear order, one after the other, and then the {destinationsystem.name}?

I've also tried a second script where I cancel the route, then have the variable spoken. This runs in reverse order, first speaking the variable, and then cancelling the route. I tried your example too, one script to get a route, and the second to set it and speak the variable. The second script also went in reverse order, saying nothing for the variable, and then speaking the "set" message. From this, it seems that RouteDetails() is best run by itself in a separate script, before you need to use it's output, otherwise you get very weird results where variables are populated when you don't expect them to be, or not populated when you would expect that they are. 🤷‍♂️

Or is my PC just running things in a very weird way? 🤔
It's not just you, I was seeing the same. A single thread is resolving the script. It resolves the functions first (in whatever order the Cottle parser chooses) then the script as a whole.

I could potentially add some additional threading to push the spawned Route details events after the triggering script, but even if I do then I'd still not be able to guarantee that the resulting Route details events would be output in script order.

Ultimately, this was designed as a call and response system and separating the calls (either with separate scripts or more likely separate VA commands) will result in the best experience.

Eliminating "set" could help with this (so that two calls to RouteDetails() in the same script are much less likely), but that could also significantly change the experience for users using the current setup, particularly in VA. Additional community feedback on this point would be most welcome.
 
Last edited:
...

Eliminating "set" could help with this (so that two calls to RouteDetails() in the same script are much less likely), but that could also significantly change the experience for users using the current setup, particularly in VA. Additional community feedback on this point would be most welcome.
Hmm, would it be possible to add an optional second parameter to auto-run a "set" at the same time? That way, peoples existing EDDI and VA won't need to be changed, and would still work as normal (with no second parameter). It would give people an additional choice to tailor their scripts and commands to how they prefer, either automatically, or two separate commands.

Something like: {set route to RouteDetails("route", "set")}. I'm guessing it wouldn't be too much trouble to add some additional code to the end of the function that says 'if 2nd parameter is "set" then set the destination', or (more probably) where the function checks for the first parameter, it can do something like 'if 1st parameter or 2nd parameter is "set" then set the destination', although that would probably need additional checks to make sure the first parameter was one that creates a route (so not "cancel" for example). This is going to look like crap, but this is my line of thinking at the moment:
Code:
{if 1st parameter = "route":
     do route stuff
|elif 1st paramter = "human":
    get nearest human broker
|elif ....
}

{if 1st parameter is "set" || (a destination system is set above from the 1st parameter && 2nd parameter is "set"):
   set the destinationsystem object
}

Please excuse my crude Cottle sudo-code analogy. ☺️
 
Hmm, would it be possible to add an optional second parameter to auto-run a "set" at the same time? That way, peoples existing EDDI and VA won't need to be changed, and would still work as normal (with no second parameter). It would give people an additional choice to tailor their scripts and commands to how they prefer, either automatically, or two separate commands.

Something like: {set route to RouteDetails("route", "set")}. I'm guessing it wouldn't be too much trouble to add some additional code to the end of the function that says 'if 2nd parameter is "set" then set the destination', or (more probably) where the function checks for the first parameter, it can do something like 'if 1st parameter or 2nd parameter is "set" then set the destination', although that would probably need additional checks to make sure the first parameter was one that creates a route (so not "cancel" for example). This is going to look like crap, but this is my line of thinking at the moment:
Code:
{if 1st parameter = "route":
     do route stuff
|elif 1st paramter = "human":
    get nearest human broker
|elif ....
}

{if 1st parameter is "set" || (a destination system is set above from the 1st parameter && 2nd parameter is "set"):
   set the destinationsystem object
}

Please excuse my crude Cottle sudo-code analogy. ☺️
Both route and set already have optional secondary arguments.

What you suggest is possible, but it would increase the complexity of an already-complex function. It might also interfere with any users trying to use route's normal secondary argument and a destination of the Set star system. :unsure:
 
Last edited:
Top Bottom