nope
Next jump is enabled
Release EDDI 3.3 - Bring your cockpit to life
- Thread starter VerticalBlank
- Start date
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
"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
I then went and completed the first delivery mission, and got this:
"Next mission destination is Esubilanque, 12.9 lightyears away."
Now I get
So, as long as I'm doing this right, it looks like these variables are only being populated when a
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:
thank you for taking the time to test, but this is beyond my comprehension. I guess it does not work quite as it should.
I have to confess that I'm a little less familiar with this area of the code. Go ahead and open a ticket, I'll investigate.
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... that was also the case with my problem. Although I find the FSD Engaged Script SO annoying. I'll just change it then.
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}.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.
github.com
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.
Help
Companion application for Elite Dangerous. Contribute to EDCD/EDDI development by creating an account on GitHub.
github.com
Hi nepomuk,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.
Help
Companion application for Elite Dangerous. Contribute to EDCD/EDDI development by creating an account on GitHub.
View attachment 255022
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)}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 forHi 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 areeventvariables, soevent.routetypefor 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:
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: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)}
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
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:
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.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?
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:
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.
BothHmm, 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.
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.
Last edited:
We're pleased to announce that EDDI version 4.0.1-b2 is now available for all users, either from the in-app upgrade or from here The full change log is available here. 
This update unlocks most previously unavailable Windows voices, adds support for custom user phonetic lexicons, improves tracking in the Crime Monitor (noting that combat bonds are still reported to the journal at pre-December 2020 buff levels), revises the Mission Monitor to provide greater detail about active missions, improves phonetic pronunciations for star systems and bodies with the P() function, adds several new events, and revises a number of other existing scripts.
