kOS Scriptable Autopilot System 0.9

[CrAzY GeNiUs]

lock throttle to 1.
lock steering to heading h1 by p1.
print "THROTTLE 1".
wait 1.

set h1 to 90.
set p1 to 35.
set target to "target1".
set td to target:distance.

brakes off.
stage.
print "BRAKSE OFF".
print "ENGINE ON".

wait 30.
gear off.
print "GEAR UP".
set h1 to target:heading.

print "TARGET DISTANCE:" at (0,4).

print "PITCH:" at (0,5).

wait until altitude > 9250.
set p1 to 0.

until 0 {
     if altitude > 10000 {set p1 to -1.}.
     if altitude < 10000 {set p1 to 8.}.
     print p1 at (8,5).
     print target:distance at (21,4).
}.

next "LANDING SISTEM"

NEED HELP for LANDING SISTEM

Edited December 4, 2013 by CrAzY GeNiUs

[goldenpeach]

Three engines would be enough; just look at tricopters, they work on the same principle. Any higher number of engines would also work.

Yes, we are coding for fun, so you might as well code this too

Just tough of a problem with my "more rocket" solution: those rocket will have to hover around the grasshopper and I don't know how to do that.

PS: using another set of rockets to control those rocket is not a viable solution.

[rottielover]

Hello, At one point in time there was talk about setting up a repository of code for the users to view / share / learn from. Was that done?

Thanks for any info / help. Looks like I am finally going to have time to properly play / test this mod.

Again, thanks.

I too am looking for the same thing. I grabbed three sample text files from the wiki, but only one of them worked for my sample test rocket (examples were the basic auto launch, looped launch, and complex launch).

I was able to play with entering commands directly, but the R(x,x,x) confused me as setting 90,90,90 pointed me at what I thought was 0,180,0

I'll be perfectly honest, I resisted this mod for so long because I thought it felt like "work", but I've relented.

To be honest it reminds me a little of bat scripting (iknow right).

Well back to the wiki I guess.

[AeroEngy]

I am trying to write some code that waits for my alignment with a maneuver node before proceeding. I found the following code on the wiki which looks like it would do exactly what I want. However, I get an error saying "pitch object not found" ... or something along those lines. I figured out that this was because instead of locking steering to a direction like "retrograde" in the wiki example I lock to a "node" so it has different properties.

Is there any easy way to get the pitch/yaw properties from a node? If not I guess I would have to somehow figure out the direction vector of the node and the direction vector of the ship ... is there an easy way to get those? Before I over complicate things again I wanted to check to make sure I am note missing some node or ship property that I am unaware of like Ship:SuperUsefulAndEasyDeltaAlignmentValue ...

set mySteer to retrograde.  // I use a node here instead of retrograde
lock steering to mySteer.

lock align to abs( cos(facing:pitch) - cos(mySteer:pitch) )
              + abs( sin(facing:pitch) - sin(mySteer:pitch) )
              + abs( cos(facing:yaw) - cos(mySteer:yaw) )
	      + abs( sin(facing:yaw) - sin(mySteer:yaw) ) .
wait until align < 0.2.

EDIT: I figured out how to get the node's direction from another example. Here is the updated code in case anyone else needs something similiar.

[B]set nodedir to R(0,0,0) * mynode:deltav.[/B]
lock steering to mynode.
// Use this to figure out when steering is complete.
lock align to abs( cos(facing:pitch) - cos(nodedir:pitch) ) 
		+ abs( sin(facing:pitch) - sin(nodedir:pitch) )	
		+ abs( cos(facing:yaw) - cos(nodedir:yaw) ) 
		+ abs( sin(facing:yaw) - sin(nodedir:yaw) ) .
wait until align < 0.1.

Edited December 4, 2013 by AeroEngy

[check]

Anyone having issues when running KOS for an extended period of time? I've got a shortish program (1.7k) and after about 15 minutes of continuous running, KSP get's REALLY laggy. As soon as I stop my KOS program, everything runs smooth. The program isn't logging anything, just directing a rover... V 0.9.2

[Kass]

I too am looking for the same thing. I grabbed three sample text files from the wiki, but only one of them worked for my sample test rocket (examples were the basic auto launch, looped launch, and complex launch).

I was able to play with entering commands directly, but the R(x,x,x) confused me as setting 90,90,90 pointed me at what I thought was 0,180,0

I'll be perfectly honest, I resisted this mod for so long because I thought it felt like "work", but I've relented.

To be honest it reminds me a little of bat scripting (iknow right).

Well back to the wiki I guess.

The up + R system makes sense when you understand how it's working. Basically the centre point of the navball, ie. when the craft is pointing straight up is 0 (zero). The trick is to know that even though that's your centrepoint, mathematically using this you need to work from 90 which at first seems very counter-intuitive. So if you were to input a command that tells kOs to go 90 degrees from straight up, the result is to go along the horizon, along the heading you've set, the opposite from how it works in a plane which obviously sets the horizon as zero and everything else is plus or minus that horizon zero point.

So the first number up + R(this one, 0, 0). controls the pitch along the line on the navball that reads 0-180. The second number up + R (0,this one,0) controls the heading along the line that runs 90-270 and finally the third number up + R (0,0,this one) controls the rotation of the craft. They work independently so changing the roll using the third number does not change the way the craft pitches using the other 2 numbers.

Angel desired is A. Centre point is 90.

So 90-A* either 1 or -1 to make it positive or negative is the number you input.

(0,30,180) East at 60 degrees inclination.

(-30,0,180) North at 60 degrees inclination.

(-30,0,0) Also North at 60 degrees but craft rotated 180 degrees about it's axis.

Dunno if that makes any sense.

[John FX]

Hello, I have decided to bite the bullet and make a KOS script. I am having trouble getting my craft to face a particular direction, or look like it is turning at all.

I am using

lock steering to heading 90 by 55.

Which AFAIK should face me at at a 55 degree pitch and a normal launch direction (east)

Am I missing something? My craft wiggles the fins and gimbals for a while then does nothing. My craft needs to turn using the gimbal and fins, torque is not an option.

The up + R system makes sense when you understand how it's working. Basically the centre point of the navball, ie. when the craft is pointing straight up is 0 (zero). The trick is to know that even though that's your centrepoint, mathematically using this you need to work from 90 which at first seems very counter-intuitive. So if you were to input a command that tells kOs to go 90 degrees from straight up, the result is to go along the horizon, along the heading you've set, the opposite from how it works in a plane which obviously sets the horizon as zero and everything else is plus or minus that horizon zero point.

So the first number up + R(this one, 0, 0). controls the pitch along the line on the navball that reads 0-180. The second number up + R (0,this one,0) controls the heading along the line that runs 90-270 and finally the third number up + R (0,0,this one) controls the rotation of the craft. They work independently so changing the roll using the third number does not change the way the craft pitches using the other 2 numbers.

Angle desired is A. Centre point is 90.

So 90-A* either 1 or -1 to make it positive or negative is the number you input.

(0,30,180) East at 60 degrees inclination.

(-30,0,180) North at 60 degrees inclination.

(-30,0,0) Also North at 60 degrees but craft rotated 180 degrees about it's axis.

Dunno if that makes any sense.

Myself I just need some more examples or to know the answers to a couple of questions.

I assume the axis for the final number is the `rotate on the direction of travel` number?

What would east at 55 degrees be is it, +r(0,35,180)? and would south at 10 degrees be +r(80,0,180)?

So would that mean straight up is +r (0,0,180)?

If that is all ok (thinking as I type) then would a standard launch and gravity turn start at (0,0,180) and smoothly go to (0,90,180)?

EDIT : after looking at the WIKI again I am still unsure whether to use `set direction to up+r(0,10,180).` or `set steering to up+r(0,10,180).` to make my craft point 10 degrees east from vertical. It really is not explicitly clear on that point.

or `set direction to up+r(0,10,180). set steering to direction.` (which seems redundant)

EDIT2 : Ok so it seems my craft is trying to stay vertical, as in it is moving the fins and gimbal, but it is not actually doing anything to control the direction it flies.

Here is the code I am using.

lock throttle to 1.
lock steering to up.
stage.
print "launch".
until 0 {
wait 1.
if altitude>7999 {break.}.
}.
print 8000.

Can anyone tell me why `lock steering to up.` does not keep my craft pointed straight up?

EDIT 3 : lock steering to up+r(0,0,0). does not change my attitude or anything else.

EDIT 4: As there have been no replies I`m going to put KOS on a fresh install with no mods and see if that works. AFAIK I am doing it right but it is not working.

Edited December 4, 2013 by John FX

[Bizz Keryear]

OK. I contacted Kevin on Twitter, Facebook and G+. No reply so far... to be fair I just twittered him, so there can't be an answer yet.

Anyway I restrained myself to contact him LinkendIn, phone (which would be relative expensive from here [foreign calls are not within my flatrate]), Stack Exchange, his car tuning forum, a diablo forum (don't think he is still active there anyway), his dating site ... because of obvious reasons ... and several other sites he created a log in ... which is the point where even I stopped looking...

(basically at the Day I searched I was looking for a very fresh sign of life...I don't remember which site it exactly was, but a post/log in on same day was good enough.)

So the Good news are... It seems he is still breathing. (e.g. Twitter on dec the 2nd)

Bad news are ... it seems he doesn't want to speak to/with us.

[Dunbaratu]

Anyone having issues when running KOS for an extended period of time? I've got a shortish program (1.7k) and after about 15 minutes of continuous running, KSP get's REALLY laggy. As soon as I stop my KOS program, everything runs smooth. The program isn't logging anything, just directing a rover... V 0.9.2

Yes. I think it's something about the UNTIL loops that does it because I can get the lag to stop without killing the program entirely if I just quit one UNTIL loop and start the next one. For example, this program does literally nothing other than spin in a loop until 15 minutes have passed:

set initTime to time:seconds.
set done to 0.
until done {
  if time:seconds > initTime + 9000 { set done to 1. }.
}.

And this program does the same thing, except it does it in 5 seperate copy-pasted chunks of 3 minutes each rather than as one loop of 15 minutes:

set initTime to time:seconds.
set done to 0.
until done {
  if time:seconds > initTime + 1800 { set done to 1. }.
}.
set initTime to time:seconds.
set done to 0.
until done {
  if time:seconds > initTime + 1800 { set done to 1. }.
}.
set initTime to time:seconds.
set done to 0.
until done {
  if time:seconds > initTime + 1800 { set done to 1. }.
}.
set initTime to time:seconds.
set done to 0.
until done {
  if time:seconds > initTime + 1800 { set done to 1. }.
}.
set initTime to time:seconds.
set done to 0.
until done {
  if time:seconds > initTime + 1800 { set done to 1. }.
}.

The first one seems to generate more laggy pauses in animation than the second one does. It seems to be something that's accumulating the longer a loop has been running, that then is getting cleared out when the loop ends.

[Dunbaratu]

OK. I contacted Kevin on Twitter, Facebook and G+. No reply so far... to be fair I just twittered him, so there can't be an answer yet.

Bad news are ... it seems he doesn't want to speak to/with us.

That seems like a bit of a premature conclusion if you've only just now sent the message. It's early morning hours in the US right now. (I shouldn't be writing this. I need to go to bed.)

[Bizz Keryear]

That seems like a bit of a premature conclusion if you've only just now sent the message. It's early morning hours in the US right now. (I shouldn't be writing this. I need to go to bed.)

Well... twitter today is my last hope. G+ and FB where some days ago.

[rottielover]

The up + R system makes sense when you understand how it's working. Basically the centre point of the navball, ie. when the craft is pointing straight up is 0 (zero). The trick is to know that even though that's your centrepoint, mathematically using this you need to work from 90 which at first seems very counter-intuitive. So if you were to input a command that tells kOs to go 90 degrees from straight up, the result is to go along the horizon, along the heading you've set, the opposite from how it works in a plane which obviously sets the horizon as zero and everything else is plus or minus that horizon zero point.

So the first number up + R(this one, 0, 0). controls the pitch along the line on the navball that reads 0-180. The second number up + R (0,this one,0) controls the heading along the line that runs 90-270 and finally the third number up + R (0,0,this one) controls the rotation of the craft. They work independently so changing the roll using the third number does not change the way the craft pitches using the other 2 numbers.

Angel desired is A. Centre point is 90.

So 90-A* either 1 or -1 to make it positive or negative is the number you input.

(0,30,180) East at 60 degrees inclination.

(-30,0,180) North at 60 degrees inclination.

(-30,0,0) Also North at 60 degrees but craft rotated 180 degrees about it's axis.

Dunno if that makes any sense.

Making sense - Yes

Am I truly understanding - nope.

I'm still trying to wrap my head around it. I'm another coming from using MechJeb's SmartASS surface controls. so I'm used to seeing 90,90,0 meaning pointing straight up (90 deg heading, 90 deg from horizon, and 0 roll angle). So if I wanted to point straight East with a roll I would go 90 , 0 , 90 and my craft would roll and point straight east at the horizon on the nav ball.

Suggestion / Enhancement request? - Would it be possible to implement a "N(x,x,x)" system to force steering to point to a position on the Nav Ball? (N for NavBall) . In otherwords if I want to steer West, with a 45 degree angle up and roll over on my back I could state: "lock steering to N(270,45,180). "

Anyway it's just a thought. In the meantime I'll continue trying to wrap my head around the R system.

I've grabbed many examples from the Wiki, but I'm finding that there are a lot of them written in such a way that your craft needs to be build and staged in a certain way. There doesn't seem to be very many scripts written in such a way as they "detect" number of stages and act accordingly. Maybe I'm just not sure how to do that?

Basically I would like to be able to write a standard launch script without re-writing the script for each craft.

[AeroEngy]

Making sense - Yes

Am I truly understanding - nope.

I'm still trying to wrap my head around it. I'm another coming from using MechJeb's SmartASS surface controls. so I'm used to seeing 90,90,0 meaning pointing straight up (90 deg heading, 90 deg from horizon, and 0 roll angle). So if I wanted to point straight East with a roll I would go 90 , 0 , 90 and my craft would roll and point straight east at the horizon on the nav ball.

Suggestion / Enhancement request? - Would it be possible to implement a "N(x,x,x)" system to force steering to point to a position on the Nav Ball? (N for NavBall) . In otherwords if I want to steer West, with a 45 degree angle up and roll over on my back I could state: "lock steering to N(270,45,180). "

Anyway it's just a thought. In the meantime I'll continue trying to wrap my head around the R system.

I've grabbed many examples from the Wiki, but I'm finding that there are a lot of them written in such a way that your craft needs to be build and staged in a certain way. There doesn't seem to be very many scripts written in such a way as they "detect" number of stages and act accordingly. Maybe I'm just not sure how to do that?

Basically I would like to be able to write a standard launch script without re-writing the script for each craft.

The R(#,#,#) system is an Euler rotation which is hard to wrap your head around. Read this from the wiki. If you pass it multiple angles at once there is a good chance you will not be pointing in the direction you actually wanted (see second paragraph under "Long Version"..

To be more specific I think (don't hold me to this) it is actually an extrinsic Tait-Bryan rotation following a zxy sequence. ... although I still get confused when rotating UP which way xyz are pointed ...

What you describe as your Navball steering system can aleardy be accomplished with the HEADING command. Example LOCK STEERING TO HEADING(45, 90) will set you at a compass/navball setting of EAST (90) pointing 45 degrees above the horizon. The only thing that heading doesn't set is roll.

[John FX]

What you describe as your Navball steering system can aleardy be accomplished with the HEADING command. Example LOCK STEERING TO HEADING(45, 90) will set you at a compass/navball setting of EAST (90) pointing 45 degrees above the horizon. The only thing that heading doesn't set is roll.

So why does this not work when the line is cut and pasted from your example?

lock throttle to 1.
print STAGE:LIQUIDFUEL.
LOCK STEERING TO HEADING(45, 90).
stage.
print "launch".
print STAGE:LIQUIDFUEL.
until 0 {
print STAGE:LIQUIDFUEL.
wait 1.
if altitude>7999 {break.}.
}.
print STAGE:LIQUIDFUEL.
print "start gravity turn".

This what the code shown does.

I must be doing something wrong, could someone who knows please let me know what it is?

I`m trying to launch east at 45 degrees but I head south instead.

Edited December 4, 2013 by John FX

[AeroEngy]

So why does this not work when the line is cut and pasted from your example?

lock throttle to 1.
print STAGE:LIQUIDFUEL.
LOCK STEERING TO HEADING(45, 90).
stage.
print "launch".
print STAGE:LIQUIDFUEL.
until 0 {
print STAGE:LIQUIDFUEL.
wait 1.
if altitude>7999 {break.}.
}.
print STAGE:LIQUIDFUEL.
print "start gravity turn".

This what the code shown does.

I must be doing something wrong, could someone who knows please let me know what it is?

I`m trying to launch east at 45 degrees but I head south instead.

Interesting. I am not 100% sure why it would do that. However, I had something similiar happen to me before. I fixed it by changing my roll orientation before setting the pitch angle via heading. Mine would eventually steer to the correct heading but it did it in an arc across the compass instead of just by directly pitching over. I guess it might be how kOS steers and which direction it seeks to first or since you are pointing straight up it might get confused sort of like a gimbal lock ... but I don't really know. Anyway if I changed my roll first it would fix it.

Here is a section of my launch code that handles attitude control which works pretty good. I took some intersting bits like the turn profile from some code I found on the forums.

PRINT "Setting Attitude Profile". 
SET tgtorbvel to sqrt(gConst*bodyMass / (bodyRadius+tgtApo)). 
LOCK STEERING TO UP+R(0,0,180).                              //set to straight up as positioned on the pad i.e pointing toward VAB.
WHEN alt:radar > 500 THEN LOCK STEERING TO HEADING(90, 90).  // this is also straight but changes roll .. same as UP+R(0,0,0) ... I think
LOCK turnProfile to 90 - sqrt(vel:mag/tgtorbvel)*90.         // calculates a parabolic turn (90 to 0) based the ratio of current velocity to orbVel 
WHEN turnProfile < 1 THEN LOCK turnProfile to 1.             // Velocity can exceed ending orb velocity on ascent and return negative pitch ... switch to turn based on total energy.
WHEN currpress < 0.25 THEN LOCK STEERING TO HEADING(turnProfile, 90).  // start turn at pressure of 0.25 about 8k on kerbin

Note: vel is locked to either velocity:orbit or velocity:surface depeding on altitude.

currpress is locked to the equation for atmospheric pressure.

body parameters like radius, mass, and grav constants are loaded based on what body you are on.

Edited December 4, 2013 by AeroEngy

[Dunbaratu]

I must be doing something wrong, could someone who knows please let me know what it is?

I`m trying to launch east at 45 degrees but I head south instead.

Is your KOS SCS module installed straight up? did you rotate it when attaching it to the craft?

[John FX]

Interesting. I am not 100% sure why it would do that. However, I had something similiar happen to me before. I fixed it by changing my roll orientation before setting the pitch angle via heading. Mine would eventually steer to the correct heading but it did it in an arc across the compass instead of just by directly pitching over. I guess it might be how kOS steers and which direction it seeks to first or since you are pointing straight up it might get confused sort of like a gimbal lock ... but I don't really know. Anyway if I changed my roll first it would fix it.

Here is a section of my launch code that handles attitude control which works pretty good. I took some intersting bits like the turn profile from some code I found on the forums.

PRINT "Setting Attitude Profile". 
SET tgtorbvel to sqrt(gConst*bodyMass / (bodyRadius+tgtApo)). 
LOCK STEERING TO UP+R(0,0,180).                              //set to straight up as positioned on the pad i.e pointing toward VAB.
WHEN alt:radar > 500 THEN LOCK STEERING TO HEADING(90, 90).  // this is also straight but changes roll .. same as UP+R(0,0,0) ... I think
LOCK turnProfile to 90 - sqrt(vel:mag/tgtorbvel)*90.         // calculates a parabolic turn (90 to 0) based the ratio of current velocity to orbVel ... I am going to change this to be based on energy instead.
WHEN turnProfile < 1 THEN LOCK turnProfile to 1.             // This why I am changing to energy instead of velocity ... velocity can exceed ending orb velocity on ascent and return negative pitch.
WHEN currpress < 0.25 THEN LOCK STEERING TO HEADING(turnProfile, 90).  // start turn at pressure of 0.25 about 8k on kerbin

I have just done a few test launches and I can confirm you are right. I locked steering to up before launch (to fix a roll attribute) and it did do a sort of `shuttle roll` just after launch and then turned in the expected way.

Now I just have to figure out why shutting down just one engine means KOS thinks the stage has no fuel...

[John FX]

Is your KOS SCS module installed straight up? did you rotate it when attaching it to the craft?

The KOS module is for sure but the rest of the craft including root pod? not so sure.

I have found a workaround by setting a roll attribute and waiting for the craft to settle down (conveniently the roll at the start does give it a little more stability)

I`ll build with that in mind in the future.

[Sacred Aardvark]

Interesting. I am not 100% sure why it would do that. However, I had something similiar happen to me before. I fixed it by changing my roll orientation before setting the pitch angle via heading. Mine would eventually steer to the correct heading but it did it in an arc across the compass instead of just by directly pitching over. I guess it might be how kOS steers and which direction it seeks to first or since you are pointing straight up it might get confused sort of like a gimbal lock ... but I don't really know. Anyway if I changed my roll first it would fix it.

Disclaimer: The following is accurate to the best of my knowledge, but is based mostly on conjecture and what I remember reading, along with some empirical evidence backing it up. It however it could well be incorrect or come to the right results for the wrong reasons, I haven't checked the kOS source to see what it's actually doing under the hood.

I'm under the impression that KSP internally uses euler angles and kOS (and some other mods) are just handling the math of converting the user friendly input of heading by pitch on the navball into an appropriate euler rotation.

If you're at level flight and rolled 90 degrees, your pitch controls will affect heading in relation to the ground, despite still controlling pitch in relation to the craft. You'll need at that point craft-yaw to alter ground-pitch. kOS tries to sort this out for you, but isn't perfect in it's execution.

When launching from the pad, changing to 45 degrees pitch with heading 90 and roll 0, requires rolling 90 degrees and pitching down. A human operator can see that this can be easily achieved by yawing to 45 degrees and then rolling, or rolling and then pitching down, etc. What kOS is doing is trying to satisfy both at the same time, pitching down to 45 while rolling 90 degrees, which results in the heading going towards south by southwest, because from the pad the pitch vector is north-south and the craft is rolling to make the pitch vector west-east, so kOS corrects by adding yaw towards the correct heading and since it's still doing the roll and pitch it can take a while sorting itself out towards the right heading and pitch.

Like you've noticed, setting the values separately and letting it sort out the roll before pitching down should work, since it has a clear thing to do. Engineering your craft to have superb roll control and sluggish pitch and yaw can also serve as a workaround, since it'll manage to roll the craft to near the correct orientation before managing to alter the pitch too badly in the wrong direction, but it's hardly reliable.

TL;DR: Pitching while rolling causes yaw in addition to pitch, and yawing while rolling causes pitch in addition to yaw, which can cause issues for kOS finding the correct heading, so don't do it. (or expect the potential issues if you do)

[Captain_Party]

Anyone have a script for RSS?

[check]

Yes. I think it's something about the UNTIL loops that does it because I can get the lag to stop without killing the program entirely if I just quit one UNTIL loop and start the next one. For example, this program does literally nothing other than spin in a loop until 15 minutes have passed:

set initTime to time:seconds.
set done to 0.
until done {
  if time:seconds > initTime + 9000 { set done to 1. }.
}.

And this program does the same thing, except it does it in 5 seperate copy-pasted chunks of 3 minutes each rather than as one loop of 15 minutes:

set initTime to time:seconds.
set done to 0.
until done {
  if time:seconds > initTime + 1800 { set done to 1. }.
}.
set initTime to time:seconds.
set done to 0.
until done {
  if time:seconds > initTime + 1800 { set done to 1. }.
}.
set initTime to time:seconds.
set done to 0.
until done {
  if time:seconds > initTime + 1800 { set done to 1. }.
}.
set initTime to time:seconds.
set done to 0.
until done {
  if time:seconds > initTime + 1800 { set done to 1. }.
}.
set initTime to time:seconds.
set done to 0.
until done {
  if time:seconds > initTime + 1800 { set done to 1. }.
}.

The first one seems to generate more laggy pauses in animation than the second one does. It seems to be something that's accumulating the longer a loop has been running, that then is getting cleared out when the loop ends.

Thanks for that. Hopefully this is something that'll get fixed.

[Camacha]

OK. I contacted Kevin on Twitter, Facebook and G+. No reply so far... to be fair I just twittered him, so there can't be an answer yet.

I am not too sure of Kevin's reasons for not being around here anymore, but I am quite sure that trying to contact someone over a couple of seperate channels at the same time might appear a little... pushy. I can imagine he needed a break and opening an all-out offensive for contact might not help.

The first one seems to generate more laggy pauses in animation than the second one does. It seems to be something that's accumulating the longer a loop has been running, that then is getting cleared out when the loop ends.

Unfortunately breaking the loop is not the silver bullet. I have found that KSP stays laggy sometimes, requiring an actual restart to behave again. I feel this predominantly happens after running a long loop that causes unplayable amounts of lag.

[AbeS]

Anyone have a script for RSS?

I had one, but it stopped working in the atmo after updating some mods (not sure of which)

[TheCanadianVendingMachine]

with the code

print "Skycrane systems Activated. Waiting until 2000 meters for engine start.".
wait until alt:radar = 2000.
lock retrograde.
stage.
print "Retroburn.".
lock throttle 1.
wait until surfacespeed = 3.
lock throttle 0.
print "Retroburn over.".
wait until alt:radar = 200.
lock throttle 1.
print "Hovermode on standby.".
wait until verticalspeed = 20.
print "Hover mode start.".
lock throttle 0.1.
wait until verticalspeed = 5.
print "Waiting until altitude is two meters above surface.".
wait until alt:radar = 10.
print "Ten meters".
wait until alt:radar = 2.
stage.
lock throttle 1.

It comes out with "Error Syntax line 0"

Edit. This is with all long scripts. I have tried with another I just made

Edit 2. I am stupid, I was writing lock throttle 1, instead of lock throttle to 1.

Edited December 5, 2013 by TheCanadianVendingMachine

[Dunbaratu]

I am not too sure of Kevin's reasons for not being around here anymore, but I am quite sure that trying to contact someone over a couple of seperate channels at the same time might appear a little... pushy. I can imagine he needed a break and opening an all-out offensive for contact might not help.

Well the thing is the Mod code is open sourced, so it's perfectly legal to fork it and make a new project for it. It's just a bit rude to do that if the creator was planning to return to it later. All we really need to know is "are you abandoning it or just taking a short break?" It's a relevant difference.

Unfortunately breaking the loop is not the silver bullet. I have found that KSP stays laggy sometimes, requiring an actual restart to behave again. I feel this predominantly happens after running a long loop that causes unplayable amounts of lag.

I think once it's been going long enough it's started causing problems with the rest of the KSP code it might break things.. If it's leaking memory in some way than other parts of KSP would start to break when the 32-bit memory limit is hit.