[1.3] kOS Scriptable Autopilot System v1.1.3.0

[falken]

Thanks! Seems so simple now.

[Kemp_J]

I'm not sure if you're ok with videos being posted here, so if it's a problem then let me know and I'll delete this post. I've made the first video in a series I've started that looks at kOS and I'd love any feedback or suggestions you have. This video mainly discusses scripts and where they're stored. It's pretty basic and just sets the viewer up for the rest of the series. (Also, it would be good to know one way or the other whether videos are acceptable here or if there is a better place to post them.)

https://youtu.be/cLaK-VNv_v4

[LN400]

I need some help with this piece. It is a WIP for an automated launch->orbit insertion.

The problem:

I have 1 when/then trigger and while other commands in that trigger seem to work fine (I tested several), the unlock steering does not work so right now I initiate the g-turn but the steering remains locked which is not really any good. Any insight as to why this particular command fails to execute?

declare global lean to 0. //for measuring the angle between nose and srfprograde, need global for a when trigger.


//P1 Liftoff
declare pitchover to r(0,0,0).
//Sets steering to vertical climb
lock steering to up + r(0,0,180) + pitchover.


//prepares auto throttle from liftoff until g-turn.
list engines in eng.
lock eng_thrust to eng[0]:thrust.
lock ship_weight to ship:mass*9.81.
lock twr to eng_thrust/ship_weight.


set throt to 1.
lock throttle to throt.
wait 2.


//tracks prograde marker for gravity turn
lock traject_angle to up:yaw - ship:prograde:yaw.


stage.


//waits for the prograde marker to hit 40 degrees above the horizon where 90* is on the horizon.
until traject_angle < 50
{
    if twr > 1.45
    {
        set throt to throt-0.001.
    }
    if twr < 1.45
    {
        set throt to throt+0.001.
    }
}


//P2 G-turn
//Initiating
set pitchover to r(0,-5,0).
lock lean to abs(facing:yaw - srfprograde:yaw).
when lean < 0.5 then
{
    unlock steering.
    unlock lean.
}


//Performing G-turn phase 1 for a 51 seconds lead to apoapsis.
until eta:apoapsis > 51
{
    if traject_angle > 45.5
    {
        set throt to throt+0.001.
    }
    if traject_angle < 44.5
    {
        set throt to throt - 0.001.
    }
}
unlock traject_angle.


print "done".

EDIT: I did some further testing on unlock and the same happened with throttle. It was stuck after the trigger activated. Is this a known issue?

EDIT 2: Found the issue tracker and apparently there is a known issue with when and unlock but it appeared they solved it and one more thing: They said it was related to unlock being inside brackets but the latest test i had it with no brackets, just one line with unlock steering. Same problem so it's not the brackets it seems.

EDIT 3. For the records: I use KOS 0.17.3.

Edited August 14, 2015 by LN400
Adding latest

[Dunbaratu]

EDIT 2: Found the issue tracker and apparently there is a known issue with when and unlock but it appeared they solved it and one more thing: They said it was related to unlock being inside brackets but the latest test i had it with no brackets, just one line with unlock steering. Same problem so it's not the brackets it seems.

It's only solved in the development version, not in the released version. The tracker you were looking at is used to decide what work the developers need to do still. Being unsolved there means not only being wrong in the release but also being wrong in the current development version.

[chapstickelk]

Maybe someone can point out what i am missing..

I have a function to return a list of arguments to create a node to match inclination with a target:

function inc_match{
  DECLARE parameter tg.


  local myNorm to vcrs(ship:up:vector,ship:velocity:orbit).
  local tgNorm to vcrs(tg:up:vector,tg:velocity:orbit).
  local point to vcrs(myNorm,tgNorm).
  local pos0 is vang(ship:up:vector,point).




  local oldAngle to vang(ship:up:vector,point).


  wait 1.
  if oldAngle < vang(ship:up:vector,point)
  {
    local pos0 to 360 - vang(ship:up:vector,point).
  }
  else
  {
    local pos0 to vang(ship:up:vector,point).
  }
  local burnETA to (ship:obt:period/360) * pos0.
  local v to velocityat(ship,time:seconds+burnETA):orbit:mag.


  local dv to 2*v*SIN(vang(myNorm,tgNorm)/2).


  local n to list(time:seconds+burnETA,0,-dv,0).
  unlock angleToAN.
  return n.
}

if i cut and paste the contents of that function block of code into its own script, it works well.. i get very erratic results when it's used as a function like:

set foo to inc_match(target).
exec_node(foo).

exec_node is a function that creates and executes a maneuver node according to the arguments in the list.

[Dunbaratu]

i get very erratic results when it's used as a function like:

Can you define "very erratic results" a bit more specifically?

[chapstickelk]

Can you define "very erratic results" a bit more specifically?

Looks like I just needed a break. Looking at it today the answer became obvious to me. When i changed it into a function i did a find/replace on all SET to LOCAL... the pos0 variable inside the if/else statements was getting set local to that scope, separate from the pos0 variable which was local to the main scope of the function.

I guess when i was testing it I didnt notice that it was always messing up when moving away from the ascending node.

[ColKlonk]

Just playing around a bit.. but having a problem after the first stage event.

Transfer proggy to rocket (Unit 1.) run it... Everything works perfectly until it stages.. then control is lost ??

I've tried various methods of the same idea.. but the first stage event bombs..

With RSS+Real Fuels I had to add a pre-ignition sequence to the stage events to get the engine to start.

In either case control is lost after 'staging'.

//**************************************************************

//

//**************************************************************

FUNCTION LAUNCH_Title

{

CLEARSCREEN.

PRINT "SHIP PARAMETERS AND ORBIT INFO." AT (0,0).

PRINT "===============================" AT (0,1).

PRINT "Planet Name : " + SHIP:BODY:ATM:BODY AT (0,3).

PRINT "Planet Atmosphere : " + h_Atm AT (0,5).

PRINT "Rocket Excess Height : " + h_Dum AT (0,7).

PRINT "Rocket Launch Height : " + h_Lau AT (0,9).

PRINT "Rocket Orbit Height : " + h_Orb AT (0,11).

}

//**************************************************************

//

//**************************************************************

FUNCTION STATUS_Title

{

PRINT "CURRENT VEHICLE STATUS" AT (0,13).

PRINT "======================" AT (0,15).

}

//**************************************************************

//

//**************************************************************

FUNCTION BLANK_Line

{

PARAMETER X.

PARAMETER Y.

PRINT " " AT (X,Y).

}

//**************************************************************

//

//**************************************************************

FUNCTION STATUS_Info

{

PRINT "Calculated Pitch :: " AT (0,17).

PRINT "SHIP Pitch :: " AT (0,19).

PRINT "Throttle Setting :: " AT (0,21).

}

//**************************************************************

// Gimbal Setting

//**************************************************************

//FUNCTION Set_Gimbal

//{

// SET CalcPitch TO 90 * ((h_Lau - SHIP:ALTITUDE)/h_Lau).

// IF CalcPitch < 0 { SET CalcPitch TO 0.}

// SET ThisPitch TO 90 - vang(ship:up:vector, ship:facing:forevector).

// SET m_Tmp TO CalcPitch - ThisPitch.

// IF m_Tmp > 1 {SET m_Tmp TO 1.}

// IF m_Tmp < -1 {SET m_Tmp TO -1.}

// SET m_Tmp TO m_Tmp/40.

// SET SHIP:CONTROL:PITCH TO m_Tmp.

// PRINT CalcPitch AT (22,17).

// PRINT ThisPitch AT (22,19).

//}

//

////**************************************************************

//// Throttle Setting

////**************************************************************

//FUNCTION Set_Throttle

//{

// SET m_Tmp TO 90 - vang(ship:up:vector, ship:srfprograde:forevector).

// SET m_Tmp TO (CalcPitch - m_Tmp) / 5.

// IF m_Tmp < -1 {SET m_Tmp TO -1.}

// IF m_Tmp > 1 {SET m_Tmp TO 1.}

// SET m_Tmp TO (m_Tmp/1000) + m_Thrott.

// IF m_Tmp > 1 {SET m_Tmp TO 1.}

// IF m_Tmp < 0.1 {SET m_Tmp TO 0.1.}

// SET m_Thrott TO m_Tmp.

// PRINT m_Thrott AT (22,21).

//}

//**************************************************************

// DUMPING HEIGHTS: AG3=> EGG SHAPED FAIRING AT THE POINTY END

// AG4=> LIGHTS AERIALS..ETC

// AG5=> SOLAR PANELS

//**************************************************************

FUNCTION DoTheDumps

{

WHEN SHIP:ALTITUDE > h_Dum THEN {TOGGLE AG3.}

WHEN SHIP:ALTITUDE > h_Dum1 THEN {

TOGGLE AG4.

TOGGLE AG5.

}

}

//**************************************************************

// LOCK CONTROLS, SET DIRECTIONS, LAUNCH AND WAIT FOR ROLL.

//**************************************************************

//FUNCTION LaunchTo2000m

//{

// LOCK STEERING TO HEADING(ThisHead , CalcPitch).

// LOCK THROTTLE TO m_Thrott.

// STAGE.

// WAIT UNTIL SHIP:ALTITUDE > 2000.

//}

//**************************************************************

// LAUNCH PROGRAM START

//**************************************************************

SET h_Atm TO 25000.

SET b_Atm TO SHIP:BODY:ATM:EXISTS.

IF b_Atm = TRUE {SET h_Atm TO SHIP:BODY:ATM:HEIGHT.}

SET h_Dum TO h_Atm * 0.9.

SET h_Dum1 TO h_Atm * 1.

SET h_Dum2 TO h_Atm * 1.1.

SET h_Lau TO h_Atm * 1.2.

SET h_Orb TO h_Atm * 1.6.

SET Min_Throttle to 0.1.

SET Max_Throttle to 1.

SET m_Thrott to 1.

SET CalcPitch TO 90.

SET ThisHead TO 90.

SET ThisPitch to 0.

SET m_Tmp to 0.

SET m_Tmp2 to 0.

DoTheDumps().

LAUNCH_Title().

STATUS_Title().

STATUS_Info().

LOCK STEERING TO HEADING(ThisHead , CalcPitch).

LOCK THROTTLE TO m_Thrott.

STAGE.

WAIT UNTIL SHIP:ALTITUDE > 2000.

SAS ON.

SET SASMODE TO "PROGRADE".

UNTIL SHIP:ALTITUDE > 500000 // USUALLY SET THIS TO h_Lau -> Just outside the atmosphere.

{

//******************************************************

// Staging / LOST CONTROL PROBLEM HERE

//

//Note:- that the 'STAGE' command has the same result,in

// that there is no control after 1st staging.

//******************************************************

IF STAGE:LQDHYDROGEN < 300

{

SET m_Thrott TO 1.

TOGGLE AG2. //Start next stage engine

WAIT 0.1. //

TOGGLE AG1. //Dump the empty stage.

}

SET CalcPitch TO 90 * ((h_Lau - SHIP:ALTITUDE)/h_Lau).

IF CalcPitch < 0 { SET CalcPitch TO 0.}

SET ThisPitch TO 90 - vang(ship:up:vector, ship:facing:forevector).

SET m_Tmp TO CalcPitch - ThisPitch.

IF m_Tmp > 1 {SET m_Tmp TO 1.}

IF m_Tmp < -1 {SET m_Tmp TO -1.}

IF m_Tmp < 0.4 {

SET m_Tmp TO 0.

}

ELSE {

SET m_Tmp TO m_Tmp/50.

}

SET SHIP:CONTROL:PITCH TO m_Tmp.

PRINT CalcPitch AT (22,17).

PRINT ThisPitch AT (22,19).

SET m_Tmp TO 90 - vang(ship:up:vector, ship:srfprograde:forevector).

SET m_Tmp TO (CalcPitch - m_Tmp) / 5.

IF m_Tmp < -1 {SET m_Tmp TO -1.}

IF m_Tmp > 1 {SET m_Tmp TO 1.}

SET m_Tmp TO (m_Tmp/1000) + m_Thrott.

IF m_Tmp > 1 {SET m_Tmp TO 1.}

IF m_Tmp < 0.1 {SET m_Tmp TO 0.1.}

SET m_Thrott TO m_Tmp.

PRINT m_Thrott AT (22,21).

}

SET SHIP:CONTROL:NEUTRALIZE to TRUE.

Edited August 17, 2015 by ColKlonk

[Kermit the Krog]

Thanks for the work on the mod - I continue to use it on virtually every mission

I skimmed the thread and checked the doc but couldn't find anything relating to this, so I have a question: Is there currently any way one can take screenshots via kOS? If not, are there plans to include this feature?

Explanation: In trying to simulate early remote sensing platforms (e.g. Corona and the early Landsats), I've rigged up a passable script to predict corner lat/lng points based on the lat/lng of the center of images taken with Automated Screenshots. Unfortunately, manually starting both at slightly different times introduces a certain degree of error. Furthermore, one can't have the interval between shots vary dynamically in AS (when orbital parameters change, for example) as one could with a simple script.

Edited August 17, 2015 by Kermit the Krog
Clarifying

[Dunbaratu]

Thanks for the work on the mod - I continue to use it on virtually every mission

I skimmed the thread and checked the doc but couldn't find anything relating to this, so I have a question: Is there currently any way one can take screenshots via kOS? If not, are there plans to include this feature?

Explanation: In trying to simulate early remote sensing platforms (e.g. Corona and the early Landsats), I've rigged up a passable script to predict corner lat/lng points based on the lat/lng of the center of images taken with Automated Screenshots. Unfortunately, manually starting both at slightly different times introduces a certain degree of error. Furthermore, one can't have the interval between shots vary dynamically in AS (when orbital parameters change, for example) as one could with a simple script.

Not at the moment, but it's an interesting idea. I'd normally not be in favor of adding too many more things to kOS that break the fourth wall (I'm not entirely happy with it controlling timewarp, which I still consider to be an issue of player boredom alleviation only, so it's something that "exists" only on the player's side of the fourth wall, and is not part of the gameworld). i.e. Jebadiah is blissfully unaware that the human being watching his space mission is watching it in compressed time - HE has to actually experience those many months of waiting, unlike the player.

But it could be argued that a screenshot is a bit different in that it's a thing a probe could actually do in the gameworld - it would actually take photos and beam them back home. Granted the camera angle is a bit "magic" in that the player camera is hanging off in midair where there's no physical camera, but it might be okay to just gloss over that detail. It would be really nifty to arrange some sort of special interface to the HullCameraVDS mod to actually take the photos from the vantage points of the actual cameras. But in the meantime, supporting screenshots may be a doable thing. But to be honest, it's not high on the priority list at the moment (a list that mostly exists in people's heads and isn't formalized at all).

[Kermit the Krog]

It would be rally nifty to arrange some sort of special interface to the HullCameraVDS mod to actually take the photos from the vantage points of the actual cameras.

That's exactly it - as soon as I saw some of the new filters in Hullcam, I got to work. Here's the preliminary result after a couple passes (not to hijack the thread, of course - in fact, it's a testament to how versatile kOS is):

In any case, I can definitely see your side of not putting it in - the interest is out there if you feel like throwing it in.

[Drew Kerman]

i.e. Jebadiah is blissfully unaware that the human being watching his space mission is watching it in compressed time - HE has to actually experience those many months of waiting, unlike the player.

Hah, that's how I feel it should be viewed it as well

It would be really nifty to arrange some sort of special interface to the HullCameraVDS mod to actually take the photos from the vantage points of the actual cameras

agreed

[Dunbaratu]

I missed doing my episode last week due to some illness and other stuff. But this week I'm back, and I'm going to try doing it a bit earlier to make it possible to at least see it late at night in Europe. It's not the best time but it's a compromise. Like most compromises it leaves everyone a little bit inconvenienced. It's a bit early for North and South America just getting back home from work, but a bit late for Europe saying up late. But it' the best I can pull off on a weeknight.

URL: http://www.twitch.tv/dunbaratu

Time: (UTC-5) 17:00, 2015-08-18, Tuesday.

Topic: Continuation of landing script for airplanes at the runway.

What was missed, unbroadcast: I did spend a small amount of time changing my script to use geoposition waypoints instead of raw XYZ waypoints, which helped a lot. I'll start by going over that. But I didn't do much more than just that since last time.

[Dunbaratu]

Stream was successful!

At the end of the 2.5 hour session, I had a working landing script that was used to land 2 different planes.

The channel archive is here (where you can see the archived episode from today):

http://www.twitch.tv/dunbaratu

The google drive folder containing the end result of the session (the script) is here:

https://drive.google.com/folderview?id=0Bxkeai7oN35ffl9kb2xGN2Q5cFI0TFg3RmVYYzg0aE9PNW1oUnRmNUwtVzA5VlllOU51eUE&usp=sharing

[magico13]

Quick question/feature request:

Can kOS make quicksaves?

I'm semi-planning to try an Elcano challenge (circumnavigation by rover) using kOS to drive the rover. I've got a script that works well enough, so that's not the question. As you may or may not know, you can't quicksave when going over terrain at any appreciable speed, so I'd like to set up "waypoints" that the rover will stop at so I can quicksave (losing several hours of driving would suck). I'd love if I could just have kOS handle driving to the waypoint, stopping, making a named quicksave, and then continuing on without me having to manually make a save and somehow tell the rover to continue on. Then I could leave it running when I'm away from the computer for a bit and it won't be wasting time parked and/or I won't lose hours of progress because my last quicksave was 100 km ago.

So, if kOS can't make quicksaves then consider this a feature request If it's totally impractical for some reason, then that's fine. It's not a big deal, mostly just a quality of life thing.

[Dunbaratu]

Short highlight from yesterday evening's live steam, showing just the best landing toward the end - 6 minutes in length.

[Dunbaratu]

Scripts used during the stream available here now:

https://drive.google.com/folderview?id=0Bxkeai7oN35ffmFzZzZXTXZXWG9kUm5ERjhjR1pLcTBCZVJDX0FtVGltT2QtaUF1TTJqQVk&usp=sharing

Give it a try with your own airplane designs. Let me know how it performs.

- - - Updated - - -

@magico13 - we've had people asking for quicksave/quickload before. Part of why we're nervous about it is that currently kOS doesn't properly restart the program where it left off when being reloaded from "on rails" or from a new game load. Instead you have to re-run your script from the beginning (which means to use save/load, you need to design a script such that it can pick up where it left off if it is quit and re-run from the top.)

But a quicksave-only... might be doable.

[magico13]

But a quicksave-only... might be doable.

That's all I'd need for what I'm planning. But it's not a big deal if you don't add it since I can just make the rover stop at each waypoint and I can tap F5. Or I might just write a plugin that makes a quicksave when the rover's surface speed drops to zero. If you do add the ability to make quicksaves, I'd suggest making it so you can name the quicksave from within the script.

Making saves is as easy as calling GamePersistence.SaveGame(), so we'd just need a way to get at that through kOS.

[Dunbaratu]

Let's kOS with a kOS dev - final version of landing script - short episode

I did a few fixes to the landing script and I'm going to consider it a done topic for now, preferring to move on to a new topic next time. But I want to wrap it up with a final episode showing the final changes I did, so they end up in the channel's broadcast history and not just on youtube alone.

So a short episode tonight - demoing the final version of the script (I hope):

UTC-5, 21:00 2015-08-20

www.twitch.tv/dunbaratu.

duration: somewhere between half an hour and one hour, I think.

[dolphen]

I don't know if this is the correct forum to ask for help, but tried at r/kos on reddit and they could not help, so I though I would try here. I have made a script that should take a satellite to orbit. I am using remoteTech and the problem is that my satellite becomes uncontrollable when I loose connection to kerbin. This should only happen if I try to control from kerbin, but this also happens when I copy a script to my satellite and run it. The whole idea behind using KOS (for me that is) is that I can have some predefined action that my satellite should take - and independently of its connection to kerbin - it should do it. A link to the complete file, as .txt, is here as readable through a browser: https://www.dropbox.com/s/2xqjow7habxidvi/A2.txt?dl=0 . Only the last part is interesting, as the initial part with ascend goes well i.e. it is circularizing the orbit that is problematic so I have just copied last last part of the code here:

WAIT UNTIL SHIP:ALTITUDE > ORBITHEIGHT. // pause here until ship is high up.

print "test 2".

wait 10.

SET WARP TO 0.

print "test 3".

wait 10.

LOCK STEERING TO HEADING(90,0).

print "test 4".

wait 10.

SET throttleValue to 1. // full throttle

print "test 5".

wait 10.

A video of the whole ascend and circularizing is at https://youtu.be/Kru6-9Z88H0?t=366 set at 6:15 for the problem.

I have activated RT in kos menu and I don't run the script from 0, but I copy it over to the satellite and run it from 1.

Can anybody tell me what I am doing wrong ? Thanks in advance for any help you can give.

[gleedadswell]

Just starting out trying kOS, which looks awesome.

In the editor popup window the "r", "e" and "s" keys (i.e. the ones corresponding to editor commands) are not functioning. So I can't even type

print "hello world".

in the editor since I get

pint "hllo wold".

I'm frankly not bothered because I intend to do any kOS programming in a text editor, outside of KSP. But I thought I'd bring it up.

[Dunbaratu]

Just starting out trying kOS, which looks awesome.

In the editor popup window the "r", "e" and "s" keys (i.e. the ones corresponding to editor commands) are not functioning. So I can't even type

Linux? I'm going to assume so because that's where this problem usually is found.

Unity 4 does some really silly things on its Linux port that really have nothing to do with any native problems in the OS itself and are just Unity *choosing* to introduce differences on Linux that it didn't need to.

Try this mod to fix it. Others have had success with it:

http://forum.kerbalspaceprogram.com/threads/108561-1-0-2-%28Apr27-15%29-Control-Lock-Input-text-into-text-fields-without-issuing-commands-to-your-vessel

- - - Updated - - -

I don't know if this is the correct forum to ask for help, but tried at r/kos on reddit and they could not help, so I though I would try here. I have made a script that should take a satellite to orbit. I am using remoteTech and the problem is that my satellite becomes uncontrollable when I loose connection to kerbin. This should only happen if I try to control from kerbin, but this also happens when I copy a script to my satellite and run it. The whole idea behind using KOS (for me that is) is that I can have some predefined action that my satellite should take - and independently of its connection to kerbin - it should do it. A link to the complete file, as .txt, is here as readable through a browser: https://www.dropbox.com/s/2xqjow7habxidvi/A2.txt?dl=0 . Only the last part is interesting, as the initial part with ascend goes well i.e. it is circularizing the orbit that is problematic so I have just copied last last part of the code here:

WAIT UNTIL SHIP:ALTITUDE > ORBITHEIGHT. // pause here until ship is high up.

print "test 2".

wait 10.

SET WARP TO 0.

print "test 3".

wait 10.

LOCK STEERING TO HEADING(90,0).

print "test 4".

wait 10.

SET throttleValue to 1. // full throttle

print "test 5".

wait 10.

A video of the whole ascend and circularizing is at https://youtu.be/Kru6-9Z88H0?t=366 set at 6:15 for the problem.

I have activated RT in kos menu and I don't run the script from 0, but I copy it over to the satellite and run it from 1.

Can anybody tell me what I am doing wrong ? Thanks in advance for any help you can give.

What happens if you explicitly set the throttle value to 0 at the bottom of the script?

When the script ends it should drop throttle to whatever setting it had before you ran - which because of the dumb decision by squad to default the throttle to 50%, is 50% rather than zero like it should be. But at any rate I don't see it dropping to 50% in the video so I assume it still has locked throttle when the script ends.

Also, prove the script ended by printing something at the bottom of it:

PRINT "SCRIPT END".

[dolphen]

Linux? I'm going to assume so because that's where this problem usually is found.

Unity 4 does some really silly things on its Linux port that really have nothing to do with any native problems in the OS itself and are just Unity *choosing* to introduce differences on Linux that it didn't need to.

Try this mod to fix it. Others have had success with it:

http://forum.kerbalspaceprogram.com/threads/108561-1-0-2-%28Apr27-15%29-Control-Lock-Input-text-into-text-fields-without-issuing-commands-to-your-vessel

- - - Updated - - -

What happens if you explicitly set the throttle value to 0 at the bottom of the script?

When the script ends it should drop throttle to whatever setting it had before you ran - which because of the dumb decision by squad to default the throttle to 50%, is 50% rather than zero like it should be. But at any rate I don't see it dropping to 50% in the video so I assume it still has locked throttle when the script ends.

Also, prove the script ended by printing something at the bottom of it:

PRINT "SCRIPT END".

The last lines of my script is:

print "test 2".

wait 10.

SET WARP TO 0.

print "test 3".

wait 10.

LOCK STEERING TO HEADING(90,0).

wait 10.

SET SASMODE TO "PROGRADE".

print "test 4".

wait 10.

SET throttleValue to 1.

print "test 5".

wait 10.

print "waiting for periapsis".

WAIT UNTIL SHIP : PERIAPSIS > ORBITHEIGHT.

print "periapsis is reached".

// WHEN THE PREIAPSIS IS AT ORBIT HEIGHT KILL THROTTLE

SET throttleValue to 0.

// STAGE.

PRINT "SCRIPT END".

WAIT UNTIL SHIP:ALTITUDE > 120000. // pause here until ship is high up.

It reaches "test 5" and "waiting for periapsis" but not "script end"- so the problem is not that the script stops. I really have no idea why it goes out of control...

[ColKlonk]

It reaches "test 5" and "waiting for periapsis" but not "script end"- so the problem is not that the script stops. I really have no idea why it goes out of control...

There's sumting not so right.. as I lose control at staging - tried various other methods but no solution yet..

http://forum.kerbalspaceprogram.com/threads/68089-1-0-4-kOS-Scriptable-Autopilot-System-v0-17-3-2015-6-27?p=2142922&viewfull=1#post2142922

[hvacengi]

I don't know if this is the correct forum to ask for help, but tried at r/kos on reddit and they could not help, so I though I would try here. I have made a script that should take a satellite to orbit. I am using remoteTech and the problem is that my satellite becomes uncontrollable when I loose connection to kerbin. This should only happen if I try to control from kerbin, but this also happens when I copy a script to my satellite and run it. The whole idea behind using KOS (for me that is) is that I can have some predefined action that my satellite should take - and independently of its connection to kerbin - it should do it. A link to the complete file, as .txt, is here as readable through a browser: https://www.dropbox.com/s/2xqjow7habxidvi/A2.txt?dl=0 . Only the last part is interesting, as the initial part with ascend goes well i.e. it is circularizing the orbit that is problematic so I have just copied last last part of the code here:

WAIT UNTIL SHIP:ALTITUDE > ORBITHEIGHT. // pause here until ship is high up.

print "test 2".

wait 10.

SET WARP TO 0.

print "test 3".

wait 10.

LOCK STEERING TO HEADING(90,0).

print "test 4".

wait 10.

SET throttleValue to 1. // full throttle

print "test 5".

wait 10.

A video of the whole ascend and circularizing is at https://youtu.be/Kru6-9Z88H0?t=366 set at 6:15 for the problem.

I have activated RT in kos menu and I don't run the script from 0, but I copy it over to the satellite and run it from 1.

Can anybody tell me what I am doing wrong ? Thanks in advance for any help you can give.

The issue is that you are steering with SAS turned on. Remote tech negates the stock SAS control, and so it fails to steer correctly. The documentation appears to only call this out for setting SASMODE (see here: http://ksp-kos.github.io/KOS_DOC/commands/flight/systems.html?highlight=sasmode#global:SAS) I will modify the documentation to identify that lock steering using SAS is also limited in remote tech. If you turn off SAS, it should start to work. If you vessel is unstable using the current kOS steering code, I'm working on pushing an update to that code as quickly as possible which is significantly more accurate.

Let me know how it goes with SAS turned off.