[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Pondafarr]

I think I understand.

In theory, I was only concerned with checking under conditions a flameout might occur...above 20k for all engine, and above 25k for half engines.

How would I loop this correctly for my ascent phase?

[Laie]

I don't know the words to explain it properly (and suspect you don't know them either). But I can show you how I do it:

when flameout > 0 then {
  toggle agX //jets off
  toggle agY //rockets on
  set mode_trigger to 1.
}

until mode_trigger=1 {
 check conditions (climbrate, airspeed, what have you)
 adjust pitch
 adjust throttle
 check engines for flameouts
 wait 1.
}

This is not proper code, but should illustrate what I mean: every second, the conditions are checked and the flight parameters are adjusted. Looking after the engines is just one more condition to check. Once I have a flameout, this triggers the WHEN..THEN block, which in turn causes the loop to end.

If you have nothing else to do but wait for a flameout, you could also do it like this:

until flameout > 0 {
  for engines in enginelist {...
}}
toggle agX.

This would just check for flameouts, over and over again, until it eventually happens.

Edited July 11, 2014 by Laie

[Pondafarr]

Ahh, and a light bulb illuminates.

with this pseudo code, I have a better idea where I need to go, thanks!

[Pondafarr]

Ok, next silly question. Is it considered proper to have a single program or to cut it up into master/slave routines? Both seem to have pros and cons.

I have two options:

One mammoth program, currently ~325 lines. Pain to sift through to find the area I need to fix (and I have to fix ALOT usually lol)

Master file which calls subprograms. Easier to manage individual sections of code, but I'm not sure I can call out other programs from within a program and return to master upon completion?

Current plan:

BOOT (loads all checklists from archive, initiates Preflight Checklist

Preflight Checklist (Sets all variables, initiates takeoff, conditionally calls other programs)

Midflight Profile (2000 to 25000, most of the issues I've been fighting recently)

High Altitude (>25000)

Circularization

Landing at KSC from Orbit (currently untested)

[Dunbaratu]

Calling out to other programs works just fine. Variables are global so whatever the child program sets the parent program should see. There's a few things that don't cross the program boundary correctly - like triggers (you set up a WHEN/THEN trigger in a subprogram and it won't trigger in the parent program).

As far as performance goes, the very first time a program runs it will take a moment to compile the subprograms which takes a bit of time but from then on it never re-compiles it so it will be faster after that.

[Drew Kerman]

why is it than when I type in print "target is at " + abs(target:bearing). directly into the console it spits out target is at 0.247887546 yet when I type the exact same thing into a program file and run it, the console tells me values of type System.String cannot have a suffix

??

[Dunbaratu]

why is it than when I type in print "target is at " + abs(target:bearing). directly into the console it spits out target is at 0.247887546 yet when I type the exact same thing into a program file and run it, the console tells me values of type System.String cannot have a suffix

??

What happened is just that your target wasn't set when running the program, but it was set when running the interactive command.

Unfortunately one thing I really don't agree with about how TARGET works is that when you have no target set, the keyword returns an object of type STRING instead of one that is a vessel or body. When you have no target set, then TARGET is the string "NONE", so you get the problem that you can't get the :bearing of a string.

The reason I don't like this is that the kos script writer is helpless to protect the program against this problem given that there exists no tests for the type of an object. You can't say "if TARGET is a string do this, else do that". There's also no way to check if an object is NULL so you can't have TARGET return NULL when there's no target either.

[Drew Kerman]

What happened is just that your target wasn't set when running the program, but it was set when running the interactive command.

actually no, here's what's really happening. If I run this code

set target to "waypoint1".
print "<" + time:clock + "> target selected".

brakes off.
lock wheelsteering to target.
lock wheelthrottle to turnSpeed.
until abs(target:bearing) < 1 {
  clearscreen.
  print "target bearing: " + target:bearing.
}.

Then I get the error message. If I run this:

set target to "waypoint1".
print "<" + time:clock + "> target selected".

brakes off.
lock wheelsteering to target.
lock wheelthrottle to turnSpeed.
until abs(target:bearing) < 1 {
  clearscreen.
}.

I still get the error message. But if I run this

set target to "waypoint1".
print "<" + time:clock + "> target selected".

brakes off.
lock wheelsteering to target.
lock wheelthrottle to turnSpeed.
wait until abs(target:bearing) < 1.

Then the target is properly selected and the code executes... except for the fact that I never defined turnSpeed, and after the console informs me of that fact I can't see to get the cursor to appear in it anymore, I guess because the program is still running as the rover won't be moving to turn and satisfy the wait until command.

I'm using the latest pre-release

[Drew Kerman]

also, my brain is melting trying to get a proper pitch reading from my rover. I've seen it two ways so far. The first is to Control From Here via the rover body, which places my navball vector indicator straight up. Now, if I go down or up a slope facing north or south, I get no pitch change. If I go up or down a slope facing east or west, I get a pitch change but its the same value so I can't actually tell if I'm going up or down a slope. If I Control From Here with the Rover Brain from Rover Science then I get a nice horizontal-facing navball but then my roll is the value that tells me if I'm pitched up or down however when my heading is between 2 and 178 degrees when I'm level the roll value is 90. When my heading is 182 to 358 degrees, my roll value is 270 when I'm level. Anytime I'm facing nearly directly north or south my roll becomes 0 and my pitch becomes 90 or 270.

So the first method is just KSP being KSP and is meant for ships, not rovers. The second method is still me getting screwed by KSP being designed for ships but also I think in part due to improper orientation of the part model file.

So is there any way to tell whether my rover is going up or down a slope without having to do a crapload of calculations to derive it?

[Drew Kerman]

and one last problem that has me stumped going to bed. I begin my rover autopilot with a program that initializes a bunch of variables and starts the rover off towards its target. That then calls a program that watches over the rover as it drives with several when...then statements looking for problems. One of those problems is going too fast (accelerating down a slope) so some braking is needed. Since I can't put

brakes on.
wait 1.

inside of a trigger, I call another program to do that for me, which then calls back to the monitoring program. But then the monitoring program just ends. Here's the code:

BeginDrive

print "<" + time:calendar + ">".
log "<" + time:calendar + ">" to RoverLog.

// data regarding waypoints
set numWaypoints to 1. // must be at least 1
set currentWaypoint to 1. // can start at any number from 1 to numWaypoints
set waypointName to "waypoint". // whatever you have your waypoint vessels named

// environment variables
set yesterday to time:day. // today is yesterday... until tomorrow
set currentSlope to 0. // 0 = level, 1 = upslope, 2 = downslope
set absOn to false. // ABS activated or not
set lastABS to -1. // when to re-enable the ABS message, previous speed
set goingAround to false. // trying a new route
set oneWayTried to false. // have we tried going around one way already?
set haveArrived to false. // lets the drive monitoring program switch to the next waypoint
set doneBraking to false.

// variables to control the rover driving
set upSlopeAngle to 10. // an angle greater than or equal this will enable certain driving limits
set downSlopeAngle to -10. // an angle greater than or equal to this will enable certain driving limits
set cruiseSpeed to 0.75. // this is how fast the rover will travel when driving straight and level
set downSlopeSpeed to 0.5. // this is how fast the rover will travel when driving down a slope greater than downSlopeAngle
set upSlopeSpeed to 1. // this is how fast the rover will travel when driving up a slope greater than upSlopeAngle
set currentSpeed to cruiseSpeed. // for various drive functions, the speed used can be any of the ones defined above
set overSpeed to 10. // m/s of how fast not to go
set absUseCount to 0. // keeps us from stepping on the brakes forever
set goAroundMaxAttempts to 5. // how many times we should attempt to climb a hill before calling for help
set goAroundDistance to 500. // how many meters we should travel before attempting to drive to the waypoint again
set goArounds to 0. // variable that tracks the number of attempts
set goAroundSpeed to 2. // m/s that triggers the rover to stop trying to climb a slope
set lastGoAroundLocation to 0. // the last place we attempted a go-around
set firstGoAroundLocation to 0. // the place where we first attempted a go-around

print "<" + time:clock + "> program initialized".
log "<" + time:clock + "> program initialized" to RoverLog.

// time to head for the first waypoint!
set target to waypointName + currentWaypoint.
print "<" + time:clock + "> target selected".
log "<" + time:clock + "> target selected" to RoverLog.

print "<" + time:clock + "> driving to target".
log "<" + time:clock + "> driving to target" to RoverLog.
brakes off.
lock wheelsteering to target.
lock wheelthrottle to currentspeed.

run MonitorDrive.

clearscreen.

MonitorDrive

if doneBraking {
print "coming from ABS".
set doneBraking to false.
}.

// update the log if a new day passes
when yesterday < time:day then {
set yesterday to time:day.
print "<" + time:calendar + ">".
log "<" + time:calendar + ">" to RoverLog.
preserve.
}.

// make sure we never go too fast
when surfacespeed > overspeed then {
if absOn = false {
set absOn to true.
print "<" + time:clock + "> ABS activated".
log "<" + time:clock + "> ABS activated" to RoverLog.
}.
lock wheelthrottle to 0.
brakes on.
set absUseCount to absUseCount + 1.
set lastABS to time:seconds.

// if we're constantly tapping the brakes, let's try slowing down if we can
if absUseCount > 25 and ship:control:wheelthrottle > 0.1 {
print "<" + time:clock + "> slowing down to prevent overspeed".
log "<" + time:clock + "> slowing down to prevent overspeed" to RoverLog.
set absUseCount to 0.
lock wheelthrottle to ship:control:wheelthrottle - 0.1.
}.

run ABS.
}.

// reset the ABS message if 5 seconds have passed since the last use of ABS
// also resume previous speed
when absOn = true and time:seconds - lastABS > 5 then {
print "<" + time:clock + "> resuming normal speed".
log "<" + time:clock + "> resuming normal speed" to RoverLog.
set absOn to false.
lock wheelthrottle to currentSpeed.
set absUseCount to 0.
set lastABS to -1.
preserve.
}.

// start slowing down if we are close to our waypoint
when target:distance < 150 then {
print "<" + time:clock + "> Approaching waypoint" + currentWaypoint.
log "<" + time:clock + "> Approaching waypoint" + currentWaypoint to RoverLog.
lock wheelthrottle to -0.5.
}.

// come to a stop at our waypoint
when target:distance < 25 then {
print "<" + time:clock + "> Reached waypoint" + currentWaypoint.
log "<" + time:clock + "> Reached waypoint" + currentWaypoint to RoverLog.
lock wheelthrottle to 0.
brakes on.
set haveArrived to true.
}.

wait until haveArrived.

// test to ensure program ending *after* coming back from ABS

ABS

brakes off.
lock wheelthrottle to currentSpeed.
set doneBraking to true.
run MonitorDrive.

wait 1.

[Pondafarr]

perhaps the wait statement needs something to check?

try

wait until haveArrived = true.

or convert it to a

set haveArrived = 0.

// come to a stop at our waypoint

do stuff {

set haveArrived to haveArrived + 1.

}.

wait until haveArrived > 1.

[Dunbaratu]

Then the target is properly selected and the code executes... except for the fact that I never defined turnSpeed, and after the console informs me of that fact I can't see to get the cursor to appear in it anymore, I guess because the program is still running as the rover won't be moving to turn and satisfy the wait until command.

I'm using the latest pre-release

Wait, does the code execute or does the console inform you that you never defined turnSpeed? Those seem to be mutually exclusive descriptions of the situation, since seeing that message would mean the program dies there and never gets to the part where it even tries to execute abs(target:bearing).

[Dunbaratu]

and one last problem that has me stumped going to bed. I begin my rover autopilot with a program that initializes a bunch of variables and starts the rover off towards its target. That then calls a program that watches over the rover as it drives with several when...then statements looking for problems. One of those problems is going too fast (accelerating down a slope) so some braking is needed. Since I can't put

brakes on.
wait 1.

inside of a trigger, I call another program to do that for me

The fact that you can't do a 'wait' inside a THEN clause is still true regardless of whether it happens directly or via a call to a subprogram. The problem is that the WAIT statement waits until the next physics timeslice to perform the check, but the THEN clause all occurs within one physics timeslice.

[Dunbaratu]

So is there any way to tell whether my rover is going up or down a slope without having to do a crapload of calculations to derive it?

Since it's a matter of opinion how much calculation constitutes a"crapload", I can't answer that.

Your post contains no information about how you're trying to read the pitch, so it's not possible to answer it.

To find out if you're going up or down a slope, check if the upward facing vector is aimed closer to your velocity direction or more away from it. Do that with vector dot product.

// Put this somewhere inside your main loop:
    set upvec to up:vector.  // a unit vector pointing straight up.
    set velvec to ship:velocity:surface:normalized. // a unit vector pointing in your velocity direction.
    set dp to vdot(velvec,upvec).
    print "travel direction slope is " + ( 90 - arccos(dp) ) + " degrees".

If your velocity is exactly perpendicular to "up", the dot product is zero.

If the angle between velocity and up is less than 90, then dp is positive.

If the angle between velocity and up is more than 90 degrees, then dp is negative.

Since both upvec and velvet are unit vectors, the dot product between them is the cosine of the angle between them.

(EDIT: There's also a vector function VANG that gets angle between vectors directly, but I'm used to using dot product for it, and I strongly suspect that VANG is implemented with dot product under the hood anyway.)

[Laie]

If I go up or down a slope facing east or west, I get a pitch change but its the same value so I can't actually tell if I'm going up or down a slope. [...] when my heading is between 2 and 178 degrees when I'm level the roll value is 90. When my heading is 182 to 358 degrees, my roll value is 270 when I'm level.

Welcome to the club. If anyone knows a solution to this...? Please. Pretty please.

Regarding brakes, I don't let kOS to use them. Braking without flipping is an art... however, I had great success with setting a desired speed and controlling the throttle to stick to it.

lock v to round(ship:airspeed,3).
set tv to 16.   //target velocity

set t to 0.5.
lock wheelthrottle to t.

until 1 = 2 {
 if v < (tv*0.97) {set t to min(1,(t + 0.01)).}
 if v > (tv*1.03) {set t to max(-1,(t - 0.01)).}
 print v + " " + t.
 wait 0.2.
}.

This is merely the core function -- as written, this will over-and undershoot quite a bit and take a long time to settle down on the target speed. But I assure you that this approach works quite well. Rover maintains its speed going up-and downhill, adapting to whatever slope comes it's way.

[Drew Kerman]

perhaps the wait statement needs something to check?

No, the program runs fine at first it's only when it is run the second time from ABS that it just ends

Wait, does the code execute or does the console inform you that you never defined turnSpeed?

Clarification - in all previous attempts to run the code the target was never selected (I was watching it to turn green in the distance and it didn't). In the instance where I get the variable undefined error, the program successfully selects the target object (it turns green on screen). So that's what I meant by the code executing - the variable was never defined in the previous attempts either. I put the code up there so you or anyone could try to reproduce

The fact that you can't do a 'wait' inside a THEN clause is still true regardless of whether it happens directly or via a call to a subprogram. The problem is that the WAIT statement waits until the next physics timeslice to perform the check, but the THEN clause all occurs within one physics timeslice.

Awwww shucks I was afraid of that, but hoped calling a new program would be a fresh slate in regards to physics ticks. Oh well, there are other ways to do it.

Your post contains no information about how you're trying to read the pitch, so it's not possible to answer it.

Ah, yes I forgot that while editing the file in the game I somehow managed to overwrite the archived version and lost all the code I was using to detect slope in the MonitorDrive code that I pasted here. So my original target was using the ship:facing direction vector. My knowledge of maths is pretty awful despite being 32 Thanks for the velocity vector suggestion I will work to get that implemented.

Regarding brakes, I don't let kOS to use them. Braking without flipping is an art...

No, it's just all in the design. If you're flipping when braking you need to lower the rover's CoM. Place the wheels higher up on the body, for starters. I've sped my rover up to 9m/s on the runway, locked the brake on with the button on the altimeter and nosed down a tad on final stop but didn't flip (it used to be flip-happy tho). That is, unless my camera arm is up now it's mandated that the rover travel with the camera arm folded down

[mileshatem]

I must be missing something very simple, but I've been banging my head against this long enough that I'm hoping someone else point out the obvious.

I want to calculate the angle between my active ship's facing and a maneuver node. The problem is that node:burnvector returns vector format, and ship:facing returns direction format. And as far as I can tell, there's no alternative for nodes which will return a direction, or for ships which will return a vector. I'm hoping I don't have to manually convert from one to the other, but if I do is there a wiki page or something someone can link me to on how to do that? Thanks.

[Camacha]

Try ship:facing:vector

[mileshatem]

Try ship:facing:vector

That would be the very simple thing I was missing. Thank you!

[Drew Kerman]

awwwws yea. Thanks for the help guys! My rover autopilot software is shaping up nicely. It just drove off the runway and out to a waypoint flag 1.2km to the north

It will run at a set speed unless it detects it's going too fast, which is when it will tap the brakes to slow down. If that doesn't work after a while it will decrease speed. It can tell when it hits level ground again so it will resume cruise speed. If it detects a slope that's deemed to steep downwards it will also slow down. Finally it will gradually slow up and stop near the waypoint. This is all tweakable via variables to handle different rovers on different planets and such. My next addition will be speeding up when it climbs a slope and a go-around feature - if it starts crawling up a slope it will back down, trek laterally a set distance, and try again to move towards the waypoint. If it gets stuck again on a lateral traverse before traveling the set distance, it will try to traverse the opposite direction. If that also doesn't work or after a set number of tries to reach the waypoint fails it will stop and await further instructions. My next milestone is to make it out to the desert west of KSC - that's like 150km!

BeginDrive

// BeginDrive
// ----------
// sets some global variables needed by the various
// programs that will be called during the drive
/////////////////////////////////////////////////////

clearscreen.
print "<" + time:calendar + ">".
log "<" + time:calendar + ">" to RoverLog.

// data regarding waypoints
set numWaypoints to 1. // must be at least 1
set currentWaypoint to 1. // can start at any number from 1 to numWaypoints
set waypointName to "waypoint". // whatever you have your waypoint vessels named

// environment variables
set yesterday to time:day. // today is yesterday... until tomorrow
set currentSlopeType to 0. // 0 = level, 1 = upslope, 2 = downslope
set currentSlopeAngle to 0. // the degree of up/down pitch the rover is currently experiencing
set absOn to false. // ABS activated or not
set lastABS to -1. // when to re-enable the ABS message, previous speed
set goingAround to false. // trying a new route
set oneWayTried to false. // have we tried going around one way already?
set haveArrived to false. // lets the drive monitoring program switch to the next waypoint, or end
set onApproach to false. // are we almost there yet?

// variables to control the rover driving
set upSlopeAngle to 10. // an angle greater than or equal this will enable certain driving limits
set downSlopeAngle to 10. // an angle greater than or equal to this will enable certain driving limits
set cruiseSpeed to 0.75. // this is how fast the rover will travel when driving straight and level
set downSlopeSpeed to 0.5. // this is how fast the rover will travel when driving down a slope greater than downSlopeAngle
set upSlopeSpeed to 1. // this is how fast the rover will travel when driving up a slope greater than upSlopeAngle
set currentSpeed to cruiseSpeed. // for various drive functions, the speed used can be any of the ones defined above
set overSpeed to 10. // m/s of how fast not to go
set absUseCount to 0. // keeps us from stepping on the brakes forever
set goAroundMaxAttempts to 5. // how many times we should attempt to climb a hill before calling for help
set goAroundDistance to 500. // how many meters we should travel before attempting to drive to the waypoint again
set goArounds to 0. // variable that tracks the number of attempts
set goAroundSpeed to 2. // m/s that triggers the rover to stop trying to climb a slope
set lastGoAroundLocation to 0. // the last place we attempted a go-around
set firstGoAroundLocation to 0. // the place where we first attempted a go-around
set approachSpeed to 3. // m/s of the speed we should begin coasting to our waypoint at
set approachDistance to 150. // meters from the waypoint to begin slowing down
set approachSpeedReverse to -0.5. // how fast we should slow down once we pass approachDistance (should be a negative number!)
set stopDistance to 25. // meters from the waypoint we should put on the brakes to bring the rover to a stop

print "<" + time:clock + "> program initialized".
log "<" + time:clock + "> program initialized" to RoverLog.

// time to head for the first waypoint!
set target to waypointName + currentWaypoint.
print "<" + time:clock + "> target selected".
log "<" + time:clock + "> target selected" to RoverLog.

print "<" + time:clock + "> driving to target".
log "<" + time:clock + "> driving to target" to RoverLog.
brakes off.
lock wheelsteering to target.
lock wheelthrottle to currentspeed.

run MonitorDrive.

/////////////

MonitorDrive

// MonitorDrive
// ------------
// the "main loop" of the rover program that keeps tabs
// on how the rover is performing and makes corrections
// as needed to prevent accidents
///////////////////////////////////////////////////////

// update the log if a new day passes
when yesterday < time:day then {
set yesterday to time:day.
print "<" + time:calendar + ">".
log "<" + time:calendar + ">" to RoverLog.
preserve.
}.

// make sure we never go too fast
when surfacespeed > overspeed then {
if absOn = false {
set absOn to true.
print "<" + time:clock + "> ABS activated".
log "<" + time:clock + "> ABS activated" to RoverLog.
}.
lock wheelthrottle to 0.
brakes on.
set absUseCount to absUseCount + 1.
set lastABS to time:seconds.

// if we're constantly tapping the brakes, let's try slowing down if we can
if absUseCount > 25 and ship:control:wheelthrottle > 0.1 {
print "<" + time:clock + "> slowing down to prevent overspeed".
log "<" + time:clock + "> slowing down to prevent overspeed" to RoverLog.
set absUseCount to 0.
lock wheelthrottle to ship:control:wheelthrottle - 0.1.
}.
}.

// do we need to disable the brakes?
when absOn = true and time:seconds - lastABS >= 1 then {
brakes off.
lock wheelthrottle to currentSpeed.
}.

// reset the ABS message if 5 seconds have passed since the last use of ABS
// also resume previous speed
when absOn = true and time:seconds - lastABS > 5 then {
print "<" + time:clock + "> resuming normal speed".
log "<" + time:clock + "> resuming normal speed" to RoverLog.
set absOn to false.
lock wheelthrottle to currentSpeed.
set absUseCount to 0.
set lastABS to -1.
preserve.
}.

// start slowing down if we are close to our waypoint
when target:distance < approachDistance then {
set onApproach to true.
print "<" + time:clock + "> approaching waypoint" + currentWaypoint.
log "<" + time:clock + "> approaching waypoint" + currentWaypoint to RoverLog.
lock wheelthrottle to approachSpeedReverse.
}.

// make sure we don't completely stop before reaching our waypoint!
when onApproach = true then {
if surfacespeed < approachSpeed {
print "<" + time:clock + "> coasting to waypoint" + currentWaypoint.
log "<" + time:clock + "> coasting to waypoint" + currentWaypoint to RoverLog.
set onApproach to false.

// if we are moving up a slope we should give ourselves some gas
if currentSlopeAngle > 1 {
lock wheelthrottle to currentSlopeAngle * 0.05.
} else {
lock wheelthrottle to 0.
}.
}.
preserve.
}.

// if a change in pitch causes us to level out, we can return to cruising speed
when currentSlopeAngle > -1 and currentSlopeAngle < 1 then {
if currentSlopeType <> 0 {
set currentSlopeType to 0.
print "<" + time:clock + "> level terrain detected. Resuming cruise speed".
log "<" + time:clock + "> level terrain detected. Resuming cruise speed" to RoverLog.
set currentSpeed to cruiseSpeed.
lock wheelthrottle to currentSpeed.
}.
preserve.
}.

// if a change in pitch causes us to head down to a large degree, we should decrease speed
when currentSlopeAngle < -1 and abs(currentSlopeAngle) > downSlopeAngle then {
if currentSlopeType <> 2 {
set currentSlopeType to 2.
print "<" + time:clock + "> slope greater than " + downSlopeAngle + " degrees detected. Slowing down".
log "<" + time:clock + "> slope greater than " + downSlopeAngle + " degrees detected. Slowing down" to RoverLog.
set currentSpeed to downSlopeSpeed.
lock wheelthrottle to currentSpeed.
}.
preserve.
}.

// come to a stop at our waypoint
when target:distance < stopDistance then {
print "<" + time:clock + "> reached waypoint" + currentWaypoint.
log "<" + time:clock + "> reached waypoint" + currentWaypoint to RoverLog.
lock wheelthrottle to 0.
brakes on.
set haveArrived to true.
}.

until haveArrived = true or abort = true {
set upvec to up:vector. // a unit vector pointing straight up.
set velvec to ship:velocity:surface:normalized. // a unit vector pointing in your velocity direction.
set dp to vdot(velvec,upvec).
set currentSlopeAngle to 90 - arccos(dp).
}.

///////////////

[Drew Kerman]

What happened is just that your target wasn't set when running the program, but it was set when running the interactive command.

I figured this out. The target was selected but the game needed an extra tick to recognize this fact for me to use any properties of target.

In other words, this will return the string error:

set target to waypointName + currentWaypoint.
print "<" + time:clock + "> driving " + round(target:distance, 2) + "m".

and this is the proper way to do it:

set target to waypointName + currentWaypoint.
wait 0.001.
print "<" + time:clock + "> driving " + round(target:distance, 2) + "m".

[erendrake]

I figured this out. The target was selected but the game needed an extra tick to recognize this fact for me to use any properties of target.

In other words, this will return the string error:

set target to waypointName + currentWaypoint.
print "<" + time:clock + "> driving " + round(target:distance, 2) + "m".

and this is the proper way to do it:

set target to waypointName + currentWaypoint.
wait 0.001.
print "<" + time:clock + "> driving " + round(target:distance, 2) + "m".

I consider this a bug, if targeting takes a moment to settle we should not make you put a wait in your script. Would you mind writing this up on the github repo?

[Drew Kerman]

Sure. The interesting thing is that this script works fine:

set target to MyTarget.
lock wheelsteering to target.

Although I suppose that, since lock is something that is continually executed although the expression is evaluated the actual call to target doesn't occur until the next tick cycle and hence is a valid object by then.

[Joe32320]

The command velocity:surfaceheading no longer seems to be working in the current pre-release of kOS, is there any work around for this/is it possible for it to be a valid command again?

[Dunbaratu]

The command velocity:surfaceheading no longer seems to be working in the current pre-release of kOS, is there any work around for this/is it possible for it to be a valid command again?

When I redid vessel velocity, I dropped it because the code had this comment above that suffix:

//TODO: I created this one for debugging purposes only, at some point I'll make a function to transform vectors to headings in a more eloquent way

I don't know who the "I" was in that comment, but I assumed it was never officially documented or published as working so nobody was using it.

By the way that better way never seemed to get implemented. You can get a 3d direction from a vector but not a 2d compass heading without some vector math with a cross product with the north vector.