kOS Scriptable Autopilot System 0.9

[Dunbaratu]

I noticed that the aforementioned lag spikes happen pretty much every time when a script is repeatedly looping through an until loop. Every second or sometimes every two seconds, the game will freeze for a tenth of a second or so. The simulation does not seem affected, but when it gets intense it can be very annoying.

Like I said, I have a fairly meaty CPU, so I can not imagine that being the cause of the problem.

So I'm glad it's not just me. I get this too in an until loop. One symptom is that if the engines are thrusting you'll hear them go schhhhh...schhhhhh..schhhhh..schhhhh instead of just a steady ssssschhhhhhhhhhhhhhhhhhhhhhhhhh.

[Camacha]

So I'm glad it's not just me. I get this too in an until loop. One symptom is that if the engines are thrusting you'll hear them go schhhhh...schhhhhh..schhhhh..schhhhh instead of just a steady ssssschhhhhhhhhhhhhhhhhhhhhhhhhh.

Have you found any solutions? Like I said before, I find that adding a wait 0.05 or 0.1 to the loops alleviates the worst of it, but it still occurs and it slows the speed or resolution of the loop down. Sometimes that is fine, but at other times I really would like to have that calculative power.

I have a feeling that it sometimes gets progressively worse. Have you noticed this?

I have not noticed the sound yet, as I am currently playing on a system with no sound. That will change soon, but for now it is quiet at KSC.

Edited November 20, 2013 by Camacha

[Dunbaratu]

Have you found any solutions? Like I said before, I find that adding a wait 0.05 or 0.1 to the loops alleviates the worst of it, but it still occurs and it slows the speed or resolution of the loop down. Sometimes that is fine, but at other times I really would like to have that calculative power.

I have a feeling that it sometimes gets progressively worse. Have you noticed this?

Yes. But once I make the UNTIL loop "let go" the progression stops getting worse. I've tried doing all the work I can in lock expressions just so I can make the loops wait slowly without it hurting anything.

[Camacha]

Okay, this is weird. I have seen for a number of times now that two kOS units interact somehow.

- I have two seperate craft on the ground next to each other. I take off with one and leave it hovering via kOS dead steady at a certain height. I switch to the next craft, and a couple of times the second one with the same program would just start oscillating while a single craft never oscillates unprovoked. The first craft then joins in, spontaneously . The really weird thing is that when I switch back to the first craft, it is rock steady again, while the first one seems to oscillate more. Switching back and forth shows the same thing again and again.

- I do the same thing with hovering and switching. Now the first craft takes off at full speed as soon as I start the program of the second, heading off into the distance. Even is kOS would stop working, the throttle would be 0 instead of 1.

- My craft start crashing randomly right at the start. They did not do this before with the same script. Upon a menu exit and reload the problem is gone.

- One craft hovers, the other crashes, first craft crashes too.

The weird thing is that this does not happen consistently. I have hovered two craft together without a problem on multiple occasions. As long as you make sure not too stray to far from the other craft it should be fine. I have a feeling that variables or certain circumstances persist that should not - until a game restart or something similar. I have had incidents before where craft performance was inexplicitly down, which resolved itself magically later.

Yes. But once I make the UNTIL loop "let go" the progression stops getting worse. I've tried doing all the work I can in lock expressions just so I can make the loops wait slowly without it hurting anything.

Huh, funny. I was actually avoiding lock expressions as they run every cycle. Do you mean you use them to avoid the until loop, or so that you can use a cycle-slowing wait without too much damage? I guess either is a valid strategy, although I think the first one is a safer way to go as I am not sure whether wait eliminates the slowdown or simply extends the time before it becomes a problem.

Unfortunately breaking the loop is not enough on its own for me; not even reverting the flight or going back to the start menu means a clean slate. The problem seems less severe after a revert, but still persists.

Edit: or you could use wait until in combination with lock, but I am unsure whether that causes the same problems or not. Using seperate programs instead of until loops would also work, I guess.

Edited November 20, 2013 by Camacha

[Dunbaratu]

Huh, funny. I was actually avoiding lock expressions as they run every cycle.

They used to but they don't anymore. Now they're implemented much more efficiently. Now they run each time they're mentioned in an expression, but NOT run when they aren't mentioned. If you say "lock x to (big math expression here)." on line 1, and then only use 'x' in an expression in two places - on line 10 and on line 20, then the "big math expression here" is only executing at line 10 and line 20. (not at line 2,3,4,5,6,7,8,9,11,12,13,14,15,16,17,18, or 19).

[adammada]

They used to but they don't anymore. Now they're implemented much more efficiently. Now they run each time they're mentioned in an expression, but NOT run when they aren't mentioned.

AHA so its a feature, not a bug.

I wanted do do something like that (basically Interrupt ReQuest):

SET doautostage TO false.

LOCK doautostage TO stage:liquidfuel < 0.1.

ON doautostage RUN autostage.

and noticed that it don't work, unless i keep using doautostage like PRINT doautostage. Which denied whole concept, because if i need to use it everywhere i can just run program which will check it by IF, not LOCK.

Edited November 20, 2013 by adammada

[aNewHope]

I have a question:

Is there any easy way of locking a vector to your up-direction? maybe the unit vector or your vertical speed as vector.

This would solve a lot of problems right now, as it would bring an easy way of getting your 6 orbital directions with it.

Crossproduct of up and prograde --> normal vector.

Crossproduct of normal vector and retrograde --> radial out.

Edited November 20, 2013 by aNewHope

[wingnut]

I've uploaded the maneuvering scripts to the kOS wiki. Features:

1. add maneuver node at periapsis for changing apopsis altitude (more fuel efficient)

run per1(mun:altitude). 

Baloan, which formula did you use to calculate the deltav for the periapsis node to raise apoapsis?

I'm trying to create a node at periapsis with the Hohmann transfer orbit formula but the projected apoapsis always turns out to be higher than specified in the parameter, this is my script launched from a low Kerbin orbit with an eccentricity of roughly 0.03:

DECLARE PARAMETER x.
SET r TO 600000.
SET sma TO (APOAPSIS+2*r+PERIAPSIS)/2.
SET gm TO 3531600000000.
SET dv1 TO SQRT(gm/sma)*(SQRT(2*(x+r)/(sma+x+r))-1).
ADD NODE(TIME:SECONDS + ETA:PERIAPSIS,0,0,dv1).

[Dunbaratu]

I have a question:

Is there any easy way of locking a vector to your up-direction? maybe the unit vector or your vertical speed as vector.

This would solve a lot of problems right now, as it would bring an easy way of getting your 6 orbital directions with it.

Crossproduct of up and prograde --> normal vector.

Crossproduct of normal vector and retrograde --> radial out.

I've needed this in my scripts too. So when I worked out a way I wrote it down here:

http://kos.wikia.com/wiki/Tutorial_with_example_-_Conversion_from_Directions_to_XYZs

http://kos.wikia.com/wiki/Tutorial_-_getting_normal_vector

[CrAzY GeNiUs]

Need help ! ! !

set p to 0.

print p.

0

if altitude > 1000 {set p to 1.}. // I'm on ALTITUDE 1358 m.

print p.

1

if altitude < 1000 {set p to 2.}. // I'm on ALTITUDE 589 m.

print p.

1

WTF ! ! ! ! ! ! ! ! ! ! ! !

HELP

Edited November 21, 2013 by CrAzY GeNiUs

[Dunbaratu]

Need help ! ! !

?

Need help with.... what?

(help with how to post a screenshot?)

[baloan]

Baloan, which formula did you use to calculate the deltav for the periapsis node to raise apoapsis?

Hi wingnut, I ran your script on one of my ships in an almost circular orbit.

The difference in apoapsis is visible. The Hohmann transfer orbit formula having apoapsis at 600198km while my script has apoapsis at 599998km.

The difference in the scripts is that perinode.txt (or the deprecated per1.txt) works with elliptical orbits to start with. In a first step

set vom to velocity:orbit:mag.  // actual velocity
set r to rb + altitude.         // actual distance to body
set ra to rb + periapsis.        // radius in periapsis
set va to sqrt( vom^2 + 2*mu*(1/ra - 1/r) ). // velocity in periapsis
set a to (periapsis + 2*rb + apoapsis)/2. // semi major axis present orbit

I calculate the ship's velocity va in periapsis from the current velocity vom and the distance r. In a second step the periapsis velocity is used for calculating burn deltav. For easier debugging I calculate after-burn periapsis velocity v2.

// future orbit properties
set r2 to rb + periapsis.    // distance after burn at periapsis
set a2 to (apoapsis2 + 2*rb + periapsis)/2. // semi major axis target orbit
set v2 to sqrt( vom^2 + (mu * (2/r2 - 2/r + 1/a - 1/a2 ) ) ).

This first step, correcting for the slight eccentricity, makes the difference. I derived the solutions from the energy formula here.

Edited November 20, 2013 by baloan

[Dunbaratu]

If you get the common ship-comes-off-rails-and-half-of-it-is-gone bug and want to rescue your save file and still be able to use the broken vessel, there is a workaround you can do that will ressurrect it and bring it back alive fully formed without having to revert to an earlier save to do it.

FIRST: If you get the bug and see the ship half missing, do NOT ALLOW KSP to write to the persistence file. It will write out its broken idea of what's in the vessel and then it's stuck that way. Instead force KSP to quit without saving to the persistence file You do this by NOT using the menus to exit. Don't quit nicely or it might save as you back out to the space center and then to the main menu. Instead do a forced hard quit externally (i.e. using the Task Manager in Windows or a "kill -9" in Linux or Mac.)

SECOND: Just get rid of the entire memory context of the vessel in the save file.\

This will have the effect of making the vessel "forget" all its variables, although it will still have all the files on its hard drive. But in so doing it will also avoid the bug that's been preventing the ship from loading properly.

Here's how: In your persistence save file there is a section for the vessel that has the KOS part on it. It will look like this:

				MODULE
				{
					name = kOSProcessor

You will have one of these for each KOS SCS part in your universe.

In that section, if you scroll down a ways you'll see a section looking something like this:

					context
					{
						variables
						{
							variable1 = value1
							variable2 = value2
							variable3 = value3
							variable4 = value4
							variable5 = value5
						}
						context
						{
							context-type = kOS.ImmediateMode
						}
					}

All the variables you ever set on that KOS computer will be there in that variable section. The bug happens when trying to re-load those variables into the module, some of them it doesn't understand how to parse back in correctly. To make it re-loadable, just get rid of the variable context entirely (presumably you don't need it to remember the old values), by removing all the variable = value lines leaving just empty braces behind like so:

					context
					{
						variables
						{
						}
						context
						{
							context-type = kOS.ImmediateMode
						}
					}

This means that SCS part will have forgotten all its variables in memory, but will now load properly.

Obviously, don't edit the persistence file while the game is running a campaign. Make sure you've gotten out of KSP first, as explained above.

Edited November 21, 2013 by Steven Mading

[wingnut]

The difference in the scripts is that perinode.txt (or the deprecated per1.txt) works with elliptical orbits to start with. In a first step

set vom to velocity:orbit:mag.  // actual velocity
set r to rb + altitude.         // actual distance to body
set ra to rb + periapsis.        // radius in periapsis
set va to sqrt( vom^2 + 2*mu*(1/ra - 1/r) ). // velocity in periapsis
set a to (periapsis + 2*rb + apoapsis)/2. // semi major axis present orbit

I calculate the ship's velocity va in periapsis from the current velocity vom and the distance r. In a second step the periapsis velocity is used for calculating burn deltav. For easier debugging I calculate after-burn periapsis velocity v2.

// future orbit properties
set r2 to rb + periapsis.    // distance after burn at periapsis
set a2 to (apoapsis2 + 2*rb + periapsis)/2. // semi major axis target orbit
set v2 to sqrt( vom^2 + (mu * (2/r2 - 2/r + 1/a - 1/a2 ) ) ).

Thank you baloan for your explanation. I have follow-up questions please as I am still not able to identify which formula on the Elliptic orbit page you used as basis for your velocity calculations, namely those two lines:

set va to sqrt( vom^2 + 2*mu*(1/ra - 1/r) ).

set v2 to sqrt( vom^2 + (mu * (2/r2 - 2/r + 1/a - 1/a2 ) ) ).

Did you use thie velocity or the energy formula as basis and what did you change to get the tow equations from above?

[Garek]

Does kerboscript have functions, i.e.

begin surface_retro().
set result to velocity:surface + R(180,0,0).
return result.
end.
//...
set x to surface_retro().

Is there something like that, or is it at least planned?

(didn't read all the thread, sorry, it's too long)

[Camacha]

Does kerboscript have functions, i.e.

begin surface_retro().
set result to velocity:surface + R(180,0,0).
return result.
end.
//...
set x to surface_retro().

Is there something like that, or is it at least planned?

(didn't read all the thread, sorry, it's too long)

I am not sure what you mean, but you can do math with vectors and stuff like that. Just read the Github manual for more details.

[Garek]

I read the github manual, I think I understood how to do math in kOS. What I want to know is if I can define my own functions for (possibly complicated) stuff I use on multiple places in the same script. The Code above was just the first simple example of such a user-defined function I cound think of. It's something you're used to if you ever coded using a professional programming language. It's pretty much required for complex programs to not become a horrible mess and helps with the size limit.

[Camacha]

I read the github manual, I think I understood how to do math in kOS. What I want to know is if I can define my own functions for (possibly complicated) stuff I use on multiple places in the same script. The Code above was just the first simple example of such a user-defined function I cound think of. It's something you're used to if you ever coded using a professional programming language. It's pretty much required for complex programs to not become a horrible mess and helps with the size limit.

I do not think kOS features them officially, but there are things that can be used in a similar way. You can put stuff into lock to commands, which only get executed when a variable in them is changed/used (see Steven's story in one of the previous pages). You could also use run in combination with a seperate script that represents your function. When could also be exploited, depending on the situation.

There are few commands in kOS, but with some creativity they are pretty versatile. If you are used to full scale fully featured languages kOS is pretty sparse

[Garek]

You could also use run in combination with a seperate script that represents your function.

So I found this. Am I right to assume that all scripts executed without restarting kOS share the same set of (user-defined!) variables? This would mean that one could use files pretty much like functions with all variables being "global".

Also, lock will be useful for shortcut stuff like surface_retrograde, thank you.

[Camacha]

So I found this. Am I right to assume that all scripts executed without restarting kOS share the same set of (user-defined!) variables? This would mean that one could use files pretty much like functions with all variables being "global".

Yes, all variables persist between scripts on the same kOS unit. Be careful with variable names, but it can be quite useful. Splitting up your program in different scripts also helps keeping things organised, making it easier to update/upgrade a script or function without affecting the rest of the program.

Be careful with locking the program in until[i/] loops, they can cause KSP to lag.

[a1270]

Yes, all user-defined variables are global unless declared with DECLARE. Rebooting a kOS module does not clear locks or global variables.

[Sma]

So I found this. Am I right to assume that all scripts executed without restarting kOS share the same set of (user-defined!) variables? This would mean that one could use files pretty much like functions with all variables being "global".

Also, lock will be useful for shortcut stuff like surface_retrograde, thank you.

I didn't check the link you found but no, KSP does not currently have functions, but you can run seperate programs and treat them as functions as all the variables are global. A simple example (I might have left something out as it's just off the top of my head but the basic idea for faux functions is there):

//launch program
print "3". wait 1.
lock steering to heading 90 by 90.
print "2". wait 1.
lock throttle to 0.2. stage.
print "1". wait 1.
print "0 - Allonz-y! ".
lock throttle to 1. stage.

run ascend(100000, 80000, 10000). //Being as that variables are global they could be declared as parameters at the top and then wouldn't need to be input as a parameter here but I did this just as an example.

run circ.

//In orbit now, deploy solar panels and turn on sas

panels on.
sas on.

//ascend
declare parameter ap. //Apoapsis
declare parameter pe. //Periapsis
declare parameter gravtAlt. // Gravity turn Altitude

until apoapsis > ap {

   if altitude > gravtAlt { lock steering to  heading 90 by 45. }
   if stage:liquidfuel < 1 { stage. }
   if eta:apoapsis < 45 { lock steering to prograde. lock throttle to 0.4. }

}

lock throttle to 0.

//circ
wait until eta:apoapsis < 20.
lock throttle to 1.
wait until periapsis <  (pe - 10000).
lock throttle to 0.5.
wait until periapsis < (pe - 2000).
lock throttle to 0.2.
wait until periapsis < (pe - 10).
lock throttle to 0.

[Garek]

This is nice. I already have some ideas floating around for a land-at-target program, which will work really well with such faux-functions. Sadly, I don't have any time to play until at least next thursday, and even then it will take some time to set stuff up.

[Camacha]

This is nice. I already have some ideas floating around for a land-at-target program, which will work really well with such faux-functions. Sadly, I don't have any time to play until at least next thursday, and even then it will take some time to set stuff up.

I am working on the same thing

[Camacha]

Yes, all user-defined variables are global unless declared with DECLARE.

Are you sure? I just did a little test and it seems that declared variables are also shared globally. I do not think kOS is capable of confining variables to a single script.

Note that global means the local system/single kOS unit. Other kOS units will not recognize declared variables, even though they sometimes interact in weird ways (see my earlier post).

Rebooting a kOS module does not clear locks or global variables.

It depends. Lock steering dus unlock, variables and other locks do not seem to be reset.