In-Development Prototype planetary landing assistance using VoiceAttack inline function

Only the saving to the EDDI thing. The first bit is going to be very useful, just speaking in the lat and long, and I've already started work on it. I'll test it out and let you know how it goes.
It's encouraging that you're engaged and enthusiastic about this project; thanks for your input (and you too, Hoodathunk). I have just started a github repository for this work - and I know as much about github as I do about EDDI. Perhaps you would like to contribute?
 
Only the saving to the EDDI thing. The first bit is going to be very useful, just speaking in the lat and long, and I've already started work on it. I'll test it out and let you know how it goes.
Well, that wasn't too difficult. I can enter lat and long via spoken commands although you do have to pause between each part to prevent VA from joining all the parts together. Still, it is a start at least.

Pause between each part. So Latutuide...1...4...2...point...7...4....2...1...longitude...minus...2...7...point...1...1...7....8

To confirm the coordinates say 'confirm coordinates'.

The VA variables CoordLatitude and CoordLongitude contain the lat & long as text.

VA-Lat-Long.png

VA-Numbers.png

VA-Confirm.png
 
Last edited:
It's encouraging that you're engaged and enthusiastic about this project; thanks for your input (and you too, Hoodathunk). I have just started a github repository for this work - and I know as much about github as I do about EDDI. Perhaps you would like to contribute?
I'm just packing to go away until Tuesday so I'll do something about it when I get back. For now, enjoy the new speech entered coordinate system :)
 
I wonder if there is a way to force the delay in EDDI for testing purposes. It would make sense to test for the radius not being set until after the event just to see what happens in the VA script but you'd need a way to do this reliably. Might be worth asking in the EDDI thread.

Personally, I'd put in a message to say that the radius was being determined if it came back as zero the first time and then a warning message after the timeout period (your 5 times loop), saying that since the radius could not be found the directions to the target could not be determined and the entire loop abandoned. Something along the Iines of:

"Waiting for planetary radius to be determined" and "Unable to determine planetary radius, direction to target cannot be given."

But that's just me.

By the way, I'd make the loop counter a variable that can be set in the VA script somewhere so that it can easily be tweaked by the commander to cope with slower computers.
I've implemented this suggestion with an initial loop count of 3. The spoken messages, with 'wait until complete' checked, provide the necessary delay between attempts.
 
Well, that wasn't too difficult. I can enter lat and long via spoken commands although you do have to pause between each part to prevent VA from joining all the parts together. Still, it is a start at least.

Pause between each part. So Latutuide...1...4...2...point...7...4....2...1...longitude...minus...2...7...point...1...1...7....8

To confirm the coordinates say 'confirm coordinates'.

The VA variables CoordLatitude and CoordLongitude contain the lat & long as text.
I amended your Confirm Location command to do some validation on the input:

Code:
Set Boolean [validLocation] to True
Set decimal [testLatitude] value to the converted value of {TXT:CoordLatitude}
Set decimal [testLongitude] value to the converted value of {TXT:CoordLongitude}
Begin Condition : [testLatitude] Is Less Than -90 OR [testLatitude] Is Greater Than 90
    Set Boolean [validLocation] to False
    Write [Red] 'The latitude is invalid: {DEC:testLatitude}' to log
    Say, 'The latitude is invalid. It should be in the range minus ninety to plus ninety. Please try again'  (and wait until it completes)
End Condition
Begin Condition : [testLongitude] Is Less Than -180.00000 OR [testLongitude] Is Greater Than 180.00000
    Set Boolean [validLocation] to False
    Write [Red] 'The target longitude is invalid: {DEC:targetLongitude}' to log
    Say, 'The target longitude is invalid. It should be in the range minus 180, to plus 180.'  (and wait until it completes)
End Condition
Begin Boolean Compare : [validLocation] Equals True
    Write [Blue] 'Latitude {TXT:CoordLatitude}, Longitude {TXT:CoordLongitude}' to log
End Condition
And to help with the timing of the spoken numbers, I've written to the log the current value of latitude and longitude as each digit is appended; this indicates when VA is ready for the next number:

Code:
Begin Text Compare : [CoordVariable] Equals 'LAT'
    Set Text [CoordLatitude] to [CoordNumber]
    Write [Green] 'Latitude: {TXT:CoordLatitude}' to log
Else If Text Compare : [CoordVariable] Equals 'LONG'
    Set Text [CoordLongitude] to [CoordNumber]
    Write [Green] 'Longitude: {TXT:CoordLongitude}' to log
End Condition
The next step is to decide what to do with the numbers! This is a different scenario from the one I've developed so far where waypoints are known in advance and stored in commands. If an ad hoc location can be captured, I need to think about where that fits in the sequence of approaching the target body, retrieving its radius, etc.
 
I amended your Confirm Location command to do some validation on the input:

Code:
Set Boolean [validLocation] to True
Set decimal [testLatitude] value to the converted value of {TXT:CoordLatitude}
Set decimal [testLongitude] value to the converted value of {TXT:CoordLongitude}
Begin Condition : [testLatitude] Is Less Than -90 OR [testLatitude] Is Greater Than 90
    Set Boolean [validLocation] to False
    Write [Red] 'The latitude is invalid: {DEC:testLatitude}' to log
    Say, 'The latitude is invalid. It should be in the range minus ninety to plus ninety. Please try again'  (and wait until it completes)
End Condition
Begin Condition : [testLongitude] Is Less Than -180.00000 OR [testLongitude] Is Greater Than 180.00000
    Set Boolean [validLocation] to False
    Write [Red] 'The target longitude is invalid: {DEC:targetLongitude}' to log
    Say, 'The target longitude is invalid. It should be in the range minus 180, to plus 180.'  (and wait until it completes)
End Condition
Begin Boolean Compare : [validLocation] Equals True
    Write [Blue] 'Latitude {TXT:CoordLatitude}, Longitude {TXT:CoordLongitude}' to log
End Condition
And to help with the timing of the spoken numbers, I've written to the log the current value of latitude and longitude as each digit is appended; this indicates when VA is ready for the next number:

Code:
Begin Text Compare : [CoordVariable] Equals 'LAT'
    Set Text [CoordLatitude] to [CoordNumber]
    Write [Green] 'Latitude: {TXT:CoordLatitude}' to log
Else If Text Compare : [CoordVariable] Equals 'LONG'
    Set Text [CoordLongitude] to [CoordNumber]
    Write [Green] 'Longitude: {TXT:CoordLongitude}' to log
End Condition
The next step is to decide what to do with the numbers! This is a different scenario from the one I've developed so far where waypoints are known in advance and stored in commands. If an ad hoc location can be captured, I need to think about where that fits in the sequence of approaching the target body, retrieving its radius, etc.
That seems to be reasonable. My code was a proof of concept so I left validation out. I've also tried to make the code general since there may be other VA commands that can use a spoken numeric input. I can't think of any off hand, but that doesn't mean that there are none, just that I can't think of any. Extending the first two commands would achieve this as required.

As for where it fits, well, I'd say that this is just another way to enter a single waypoint except that it is for the current body rather than one of a set of waypoints. But that's just off the top of my head and, since I've not put a great deal of thought into it, I'm probably spouting rubbish!

:)
 
I have just had a look at the wiki on GitHub and found a small error. On the How To page, item 5 where the script is entered into EDDI, the line:
Code:
{if event.approaching_surface:}
Has a trailing '}' and should not have one. The script will not work if you do not remove it.
 
I have just had a look at the wiki on GitHub and found a small error. On the How To page, item 5 where the script is entered into EDDI, the line:
Code:
{if event.approaching_surface:}
Has a trailing '}' and should not have one. The script will not work if you do not remove it.
Well spotted! I've updated the wiki appropriately. Thanks.
 
Just re-reading your Concepts page in the Wiki and noticed a slight misleading paragraph. The Near Surface Event in EDDI occurs whenever the ship crosses the Orbital Cruise boundary of a planet. That is either descending to the surface or ascending from the surface. In the first case the approaching_surface variable is true and in the second case the approaching_surface variable is false. Only when approaching_surface is true are the systemname & bodyname variables available.

What you have written is only half the story.
 
Thanks for that observation; I'll take a look. I will also point out that the bodyRadius variable becomes Not Set when passing through that boundary on the way up.
 
Just tried out the Landing Assistance scripts and I\m pleased to say that it all seems to work well except that I find the frequency of the range and bearing reports to be too high. I'd prefer this to be one every 10 seconds or so. Enhancement request. Please allow the commander to set the reporting frequency in seconds via a VA variable so that we can tailor it to our own preference.

Thanks.
 
Just tried out the Landing Assistance scripts and I\m pleased to say that it all seems to work well except that I find the frequency of the range and bearing reports to be too high. I'd prefer this to be one every 10 seconds or so. Enhancement request. Please allow the commander to set the reporting frequency in seconds via a VA variable so that we can tailor it to our own preference.

Thanks.
I'm glad it worked for you and I have at least one user. You make a valid point and I will implement it. For myself, I would set the interval to zero seconds because the slope and range can change rapidly on the final approach and you need to judge when to drop into the glide. Perhaps it would be possible to make the interval variable and calculated based on the angular distance to the destination. I need to experiment with this on a range of bodies with different radius and gravity. Once again, thanks for your interest and suggestions.
 
I'm not sure that such a feature is really required since this is a guide rather than strict instructions. Still, if you implemented it as an option, that would be good. Then I can have my fixed interval and others can have the variable one.

What would also be of use is a message indicating that the destination is now behind the ship.
 
I have a version of Landing Guidance in test which has the following enhancements:
  • The ability to enter numbers by speaking them. In this release, number capture is used, as described below, to set values for latitude, longitude, and reporting interval.
  • The new 'Set Landing Guidance Interval' command gives the ability to set the interval between reports of heading, slope, and range. The loop that repeatedly calculates these values now includes a pause which is set to the user's preference (defaulting to 1 second). The spoken interval can be a value in the range [1..9]. Once captured, the value is stored in the profile for subsequent use.
  • The 'latitude' and 'longitude' commands capture respectively the latitude and longitude where you want to land on a planet or moon. You use voice input to specify these values, providing an alternative to the existing use of waypoint commands. This means that you can be guided to a location on any body without having to create a waypoint for it. In this scenario no validation of the body name is performed when you enter orbital cruise.
The two styles of landing guidance - ad-hoc and using waypoints - offer a wider range of possibilities. The waypoint approach is useful in pre-planned scenarios like expeditions and where it's worthwhile to store the locations of well known, frequently visited POIs (e.g. you could create and share a command like: 'Set Dav's Hope Waypoint' so people who hadn't visited it could easily make their way there).
 
What would also be of use is a message indicating that the destination is now behind the ship.
I think that a sudden change of 'heading to target' by 180 degrees is sufficient indication that you've flown past the destination. It's a skill that develops with time to enter the glide phase at the right moment - not so soon that you fall short of the destination, and not so late that you overshoot. I'm still gaining that skill - it's that 10,000 hours of practice thing.
 
I think that a sudden change of 'heading to target' by 180 degrees is sufficient indication that you've flown past the destination. It's a skill that develops with time to enter the glide phase at the right moment - not so soon that you fall short of the destination, and not so late that you overshoot. I'm still gaining that skill - it's that 10,000 hours of practice thing.
I rather like the idea of having the AI say one of:

Fool, you've missed it.
Going right round the planet again?
Whee, roller coaster!
Who's driving this thing anyway?
Damn, human drivers!
Commander, you do know the target is now behind you.
I dunno, give the humans a hand and they still mess it up.

and many more if you over fly the target.
 
I rather like the idea of having the AI say one of:

Fool, you've missed it.
Going right round the planet again?
Whee, roller coaster!
Who's driving this thing anyway?
Damn, human drivers!
Commander, you do know the target is now behind you.
I dunno, give the humans a hand and they still mess it up.

and many more if you over fly the target.

😂 I was already liking this add-on as I was reading through the thread, and planning to download it when I get home, but add this in and you've definitely got a winner
 
Top Bottom