[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Pondafarr]

Ok, so I ensured I have the latest release off Curse, and reloaded. Removed the bit of code seen above, replaced it with

LOCK STEERING to HEADING(90, 10)

Now, I get the "Syntax error" for line 41....

WAIT 1.

Would someone please review this script and tell me why I would get a syntax error for a -WAIT- command?

// Orginal KoS SSTO Script by bsalis
// for KPrize posted 13 Nov 2013
// Modified by Pondafarr

CLEARSCREEN.

SET KerbinRad to 600000.
SET RunwayAlt to 70.
SET KscLat to -0.0486073307693005.
SET KscLng to -74.7238159179688.
SET LandingTarget to LATLNG(KscLat, KscLng).
SET LandingLng to LATLNG(0, KscLng).
SET GlideOffset to 80.
SET GlideYawMag to 100.
SET turn1 to 100.
SET turn2 to 4999.
SET turn3 to 9999.
SET turn4 to 19999.
SET turn5 to 75000.
SET Pi TO 180.
SET PitchF TO 70.
SET PitchAoI TO 12.
SET StartAlt TO 12000.
SET EndAlt TO 24000.


// Take-off Check list
PRINT " INITIATING TAKEOFF SEQUENCE".
WAIT 1.0.
LIGHTS ON.
WAIT 1.0.
PRINT " Brakes Off".
WAIT 1.0.
BRAKES OFF.
WAIT 1.0.
PRINT " Flight Computer On".
WAIT 1.0.
SAS ON.
WAIT 1
// PRINT " Gimme a Vector Victor".
// LOCK STEERING to HEADING(90, 10).
// PRINT " Copy, heading is: 90, pitch 10deg".
WAIT 1.0.
PRINT " Roll on 2!".
AG2 on.
WAIT 1.0.
LOCK THROTTLE to SHIP:maxAccel * SHIP:mass/SHIP:maxthrust.
until altitude > 150 {
if verticalspeed < targetVert {SET targetPitch to targetPitch + 0.5.}.
if verticalspeed > targetVert {SET targetPitch to targetPitch - 0.5.}.
if targetPitch < -85 {SET targetPitch to -85.}.
if targetPitch > -40 {SET targetPitch to -40.}.
lock steering to up + R(0,targetPitch,-90).
}.
when altitude > turn1 then PRINT "Raise Gear".
GEAR OFF.
WAIT 2.
PRINT " Gear Up".

// Initial Climb
PRINT "BEGINNING INITIAL CLIMB".
when altitude > turn1 then lock steering to heading(90, 45).
WAIT 1.0.
WAIT until altitude > 10000.
print " opening all air intakes".
AG3 on.


// Dynamic Pitching
WAIT until altitude > StartAlt.
print " Dynamic pitching engaged".
SET Counter to 0.
until SHIP:INTAKEAIR < .26 {
SET ScaledAlt TO ALTITUDE - (EndAlt - StartAlt).
SET ScaledPi TO ScaledAlt * ((Pi / 2) / (EndAlt - StartAlt)).
SET Sined TO SIN(ScaledPi).
SET RawPitch TO (PitchF - PitchF * Sined) + PitchAoI.
SET FinalPitch TO 0 - (90 - (RawPitch)).
lock steering to up + R(0,FinalPitch,-90).
SET Counter to Counter + 1.
if Counter > 30 {
print " pitch " + ROUND(90 + FinalPitch, 3) + " degrees".
SET Counter to 0.
}.
WAIT 1.0.
}.

print "Switching to rocket ascent".
lock steering to up + R(0,-45,-90).
AG1 on.
AG2 off.
AG3 off.
WAIT 2.
print " pitch 45 degrees".
WAIT until ALTITUDE < 40000.
print " pitch 35 degrees".
lock steering to up + R(0,-55,-90).
WAIT until ALTITUDE < 50000.
print " pitch 10 degrees".
lock steering to up + R(0,-80,-90).
// WAIT 5.
// toggle ag4.
WAIT until APOAPSIS > 100200.
print " target Ap reached".
lock throttle to 0.
lock steering to PROGRADE.
WAIT 1.0.
print " Coasting to Ap".

WAIT until ETA:APOAPSIS < 11.
print " Circularising".
lock steering to up + R(0,-90,-90).
WAIT 1.0.
lock throttle to 1.
WAIT until PERIAPSIS > 99900.
lock throttle to 0.
WAIT 1.0.

unlock steering.
print " Now in orbit".

WAIT 10.
WAIT until LandingTarget:DISTANCE > 900000.
print " Tracking distance to KSC".
print " do not warp past 900000, burn is at 830000".
until LandingTarget:DISTANCE < 900000 {
print " distance from KSC " + ROUND(LandingTarget:DISTANCE).
WAIT 1.0.
}.

clearscreen.
print " Initiating re-entry".
lock steering to RETROGRADE.
WAIT until LandingTarget:DISTANCE < 830000.
print " re-entry burn".
lock throttle to 1.
WAIT until PERIAPSIS < -89500.
lock throttle to 0.
WAIT 2.
// toggle ag5.
print " setting re-entry pitch".
WAIT 1.0.
lock steering to UP + R(0,-95,-90).

WAIT until ALTITUDE < 20000.
print " preparing for glide".
ag2 on.
lock steering to UP + R(0,-100,-90).

WAIT until ALTITUDE < 18000.
SET CurrentAltitude to ALTITUDE.
SET TargetLevelDist to LandingLng:DISTANCE.
SET TrgAta to ARCCOS((TargetLevelDist / 2) / (KerbinRad + CurrentAltitude)).
SET TrgCba to TargetLevelDist * SIN(TrgAta).
SET TrgBrz to TargetLevelDist * COS(TrgAta).
SET TrgCrz to CurrentAltitude - TrgBrz.
SET GlideAngle to ARCTAN(TrgCba / TrgCrz).
print "Glide descent has started with slope of " + ROUND(GlideAngle, 3).
WAIT 1.0.

SET Counter to 0.
until ALTITUDE < (300 + RunwayAlt) {
SET CurrentAltitude to ALTITUDE.
SET TargetLevelDist to LandingLng:DISTANCE.
SET TrgAta to ARCCOS((TargetLevelDist / 2) / (KerbinRad + CurrentAltitude)).
SET TrgCba to TargetLevelDist * SIN(TrgAta).
SET TrgBrz to TargetLevelDist * COS(TrgAta).
SET TrgCrz to CurrentAltitude - TrgBrz.
SET TrgDrz to TrgCba / TAN(GlideAngle).
SET RawGlideDeviation to TrgDrz - TrgCrz.
SET GlideDeviation to GlideOffset + RawGlideDeviation.

SET GlideAoa to 0.
if GlideDeviation < 0 {
SET GlideAoa to GlideAngle - 180.
}.
if GlideDeviation > 600 {
SET GlideAoa to -90.
}.
if GlideAoa = 0 {
SET GlideAoa to (GlideDeviation / 20) + GlideAngle - 180.
}.

SET GlideYaw to (LATITUDE - KscLat) * GlideYawMag.
if GlideYaw > 0 {
if GlideYaw > 10 {
SET GlideYaw to 10.
}.
if GlideYaw < 0.1 {
SET GlideYaw to 0.1.
}.
}.
if GlideYaw < 0 {
if GlideYaw < -10 {
SET GlideYaw to -10.
}.
if GlideYaw > -0.1 {
SET GlideYaw to -0.1.
}.
}.

SET Counter to Counter + 1.
if Counter > 30 {
print " d " + ROUND(RawGlideDeviation) + " p " + ROUND(GlideAoa, 3) + " y " + ROUND(GlideYaw, 3).
SET Counter to 0.
}.

lock steering to UP + R(GlideYaw,GlideAoa,-90).
WAIT 1.0.
}.

print " Landing".
lock steering to UP + R(0,GlideAoa,-90).
gear on.

WAIT until ALTITUDE < (100 + RunwayAlt).
print " begining flare".
lock steering to UP + R(0,-90,-90).

SET FlareStart to 20.
SET FlareEnd to 3.5.
SET MaxPitch to 8.
WAIT until ALT:RADAR < FlareStart.
print " dynamic flare".
SET FlarePitch to MaxPitch - 90.
lock steering to UP + R(0,FlarePitch,-90).
WAIT 1.0.
until ALT:RADAR < FlareEnd {
SET DropDist to 0 - (ALT:RADAR - FlareStart).
SET FlarePitch to DropDist * (MaxPitch / (FlareStart - FlareEnd)) - 90.
lock steering to UP + R(0,FlarePitch,-90).
WAIT 1.0.
}.

print " touchdown".
unlock steering.
WAIT 2.
brakes on.
WAIT 1.0.
print " braking".
WAIT 10.

Edited July 7, 2014 by Pondafarr

[Laie]

90% of the time, "syntax error" means that you forgot the period at the end of the previous line.

SAS ON.
WAIT 1                                                         <- here's the syntax error
// PRINT " Gimme a Vector Victor".
// LOCK STEERING to HEADING(90, 10).
// PRINT " Copy, heading is: 90, pitch 10deg".
WAIT 1.0.                                                     <- here kOS notices that something is wrong.

If it's not a missing period, it's usually a mismatched bracket {} -- these can be a pita to track down. As said above: kOS doesn't report where the error is, but where it becomes aware of it. In case of a missing }, it reports the error to be at the very end of the file, because it has no idea which bracket you didn't close -- all it knows is that at the end of the file, there's at least one bracket still open.

Edited July 7, 2014 by Laie
extended

[Dunbaratu]

Do I really want to know? Seriously: do I need to understand this before I can even try to make any use of directions? Or can I just assume that pitch is yaw and yaw is pitch and not worry about what's really going on behind the scenes?

Sadly, that's not going to work because they aren't off by exactly 90 degrees like that so you can just swap pitch for yaw. It might be that the x axis is, say, 20 degrees left of , and 30 degrees up from, your facing axis, depending. When your ship rotates, the xyz axes don't. When you move to a new position in orbit so that "east" isn't the same direction as it was before, the xyz axes don't rotate to match. (Sadly, they *do* sometimes rotate based on the completely hidden criterion of whether or not you're close enough to the surface to make the game want to render the individual terrain polygons or not, which is confusing as all get-out. When your altitude is low, it rotates the universe and freezes the planet's terrain polygons so it doesn't have to bog down animation rate by constantly recalculating their coordinates, but when you're high enough up that it replaces the terrain polygons with just a flat low-res image map, then it starts rotating the planet and freezing the universe. This makes it impossible to tell you which way the x and z axes are really pointing at any time because it depends on where you lifted off and where you came back down, at what times. A least if they were fixed it would be easier to explain.)

I desperately want to add some features to help with this so that people don't need to use the native messy frame of reference if they don't want to, but we're on a feature freeze because of the upcoming KSP 0.24. This constantly recurring question by users about how on earth to use the native xyz system makes me see it as a big problem in need of fixing, and I have an idea how.

SHIP:CONTROL is relative to your ship. THERE, the terms pitch, yaw, and roll do actually mean what they say.

In the meantime, if you need to see a vector relative to your ship's facing you can do it with vector math and dot products. Get basis vectors of the frame of reference you want (forward, topward, starboardward) in the native XYZ terms, then dot-product them times any XYZ vector to get the terms in your own reference frame.

Like so:

// WARNING: This pair of statements will become one step after the next update and need to be
// changed.  This is because the next update contains a new fix that when you rotate a vector
// by a direction you get a vector out (right now you get a rotation back which is silly).
// This means that each pair of setting dir then setting Unit will need to be combined into just setting
// unit directly after that fix goes through.
//
LOCK foreDir to SHIP:FACING * V(0,0,1).  // The Z axis, after rotating to facing, becomes forward.
LOCK foreUnit to foreDir:VECTOR. // *(see comment not above!  IMPORTANT!)

LOCK topDIr to SHIP:FACING * V(0,1,0).  // The Y axis, after rotating to facing, becomes topward.
LOCK topUnit to topDir:VECTOR.  // *(see comment not above!  IMPORTANT!)

LOCK starboardDir to SHIP:FACING * V(1,0,0).  // The X axis, after rotating to facing, becomes starboard.
LOCK starboardUnit to starboardDir:VECTOR.  // *(see comment not above!  IMPORTANT!)

// Now the 3 unit vectors can be used as basis vectors for you to play with, and with
// dot products you can get those 3 components of any native-xyz vector:

SET foreComponent to someVector * foreUnit.
SET topComponent to someVector * topUnit.
SET starboardComponent to someVector * starboardUnit.

(Disclaimer - I didn't try running any of that example yet - I may have left/right swapped on the starboard one. the left-handedness of the coord system always trips me up.)

Edited July 7, 2014 by Steven Mading
cut-n-paste error in the code example - I had "topDir" for both topUnit and StarboardUnit

[Dunbaratu]

So, I'm trying to setup an initial SSTO takeoff profile, and I can't get this code to work:

set ship_relative_dir to R(0,0,0).
set ship_relative_dir:pitch to 5.
declare wantdir.
set wantdir to ship:facing + ship_relative_dir.

LOCK STEERING to wantdir.

I keep getting the dreaded "Object not set" error at wantdir.

WTF am I doing wrong?

I apologise, my suggestion was misleading, as it seems. You can't set the PITCH of a direction after it's made. Directions are immutable and their components can only be GETted, not SET, and directions can only be changed by making a new one.

So change this:

set ship_relative_dir to R(0,0,0).
set ship_relative_dir:pitch to 5.

To just one line like this:

set ship_relative_dir to R(5,0,0).

Ironically, the reason I didn't say it like that the first time was that I was trying to avoid an error. I didn't want to make the error of getting the wrong part of the tuple for pitch. But I forgot you can't SET the pitch, so by trying to avoid giving bad advice… I gave bad advice.

[Dunbaratu]

Ok, so I ensured I have the latest release off Curse, and reloaded. Removed the bit of code seen above, replaced it with

LOCK STEERING to HEADING(90, 10)

Now, I get the "Syntax error" for line 41....

WAIT 1.

Line 41 doesn't look *exactly* like that in the body of the code you posted. It looks like this:

WAIT 1

(Lacking the period (.) in the actual program.)

[Dr_Goddard]

I believe I have identified a small bug.

I love the autorun feature in the latest pre-release, but if I configure k-OS to open into volume "0" using CONFIG:ARCH, it doesn't work.

[Pondafarr]

Steven Mading, Laie, thank you VERY much for helping to find that missing period. I had no idea that it was THAT line, since KoS told me the problem was somewhere else.

Now to review one more time...

And Steven, thanks for trying to give good advice for the ship heading issue, I want to end up with a flexible program I could use with all my SSTO's, and having smart code will go a long way...

[Camacha]

Steven Mading, Laie, thank you VERY much for helping to find that missing period. I had no idea that it was THAT line, since KoS told me the problem was somewhere else.

As far as kOS is concerned, it is on another line, as you did not bother to end your previous line correctly

[Dunbaratu]

The reason it doesn't mention it on the previous line is that kerboscript, like most programming languages, does not constrain you to have to put an entire statement on the same line.

Just because it failed to find a period at the end of a line doesn't mean its an error yet. It's not known to be an error because maybe the next line has the period on it, or maybe the expression wasn't over and it continues like so:

WAIT 1
+ y*3.

Only once it gets to the first thing that isn't a valid continuation of the math expression can it be certain the period wasn't going to be coming.

[Laie]

First off, many many thanks for taking the time and answering these questions. But no good deed shall go unpunished... I'm going to pester you until either I can make use of directions or you're no longer willing to waste your time on me.

LOCK foreDir to SHIP:FACING * V(0,0,1).  // The Z axis, after rotating to facing, becomes forward.
LOCK foreUnit to foreDir:VECTOR. // *(see comment not above!  IMPORTANT!)

forUnit seems to be zero no matter what. Of course, both are locked, so my they give my the deviation from facing, right? Wrong. I tried SETting foreDir rather than LOCKing it, so I would get the deviation from whatever it was when I SET it, but no such luck.

print forUnit.
V(0,0,0)

You see, I've got a rover. kOS gave me the ability to keep the speed at a steady 8m/s; now I can drive it at 4x physicswarp, up- and downhill, over bumps and though pits, without fear of tipping over. That alone is priceless. But you know how it is, I can't leave good enough alone. Now I also want it to keep it's direction despite all those bumps throwing me off the track.

I won't even try LOCK STEERING TO HEADING; on a rover, that can go nowhere but belly-up. What I want to do is a) pick up my direction when the script starts, detect any deviations from that direction, c) apply wheelsteer as necessary.

I tried PRINT NORTH - FACING while going in circles on the runway and it doesn't really make sense.

(no code, just for indentation)
compass direction --  output of PRINT NORTH - FACING
 90 -90
135 -45
180   0
225 -45
270 -90
315 225
  0 180
 45 225

Now that I see it as a table I have to admit that it does make sense, in a way. Most of the time it would even be usable for my purpose, but I'm afraid of the occasions when it wouldn't.

[Dunbaratu]

forUnit seems to be zero no matter what.

The things I've been saying only apply to the pre-release not the normal release. If you are using the normal release you'll get the V(0,0,0) problem. It's been such a long time since a full release that a lot of important features are missing from it.

[noah123103]

Okay so i have this script here and was trying to test this mod out for the first time and ran into some issues because this script was made on a early version and i cant find the version for download anywhere so i cant downgrade! this is the script: http://pastebin.com/zZwek06Z, im getting an error with the liquidfuel variable, at line 111 and 173 it says the "< >" are not valid, so i take those out and it runs...but when it counts down it says "tried to push infinity in to the stack" then continues to countdown and then launch. When it launches i get another line that catches my eye "variable liquid fuel is not defined". I know its not defined and i have been looking at this code for a while and this is day 1 of me using this mod and im confused out of my mind, i don't know how to define it and i could really use some help. Thanks guys.

Pictures to show what i mean:

http://imgur.com/lcHrTHg,kVUat70#0

http://imgur.com/lcHrTHg,kVUat70#1

[Dr_Goddard]

I'd like to see a small addition to k-OS. It would be nice to have the ability to play sounds. Maybe just a beep? It would help in adjusting timing and debugging, and could be an audible cue when passing through the 100K mark or other situations where what is happening is not readily visible.

Besides... it would be neat. You could make radio reports to base...audible countdown...screams of terror...

[Dr_Goddard]

[

I tried PRINT NORTH - FACING while going in circles on the runway and it doesn't really make sense.

(no code, just for indentation)
compass direction --  output of PRINT NORTH - FACING
 90 -90
135 -45
180   0
225 -45
270 -90
315 225
  0 180
 45 225

Now that I see it as a table I have to admit that it does make sense, in a way. Most of the time it would even be usable for my purpose, but I'm afraid of the occasions when it wouldn't.

Edited July 8, 2014 by Dr_Goddard

[Pondafarr]

I'm getting a recurring Out of Sync error, which cuts my throttle and breaks the script.

Situation:

SSTO launch profile (code below)

this occurs at 2.1 km from KSC.

i understand that the Out of Sync error may be related to a "race condition", but I have removed all complicated bits from my code and the problem persists.

Is my using of two "wait until altitude > 4000" commands possibly the cause?

What log file should I submit for analysis?

On looking up race condition, it may be my crude timing attempts.

/// Basic SSTO Launch Script by Pondafarr
// Contributing code snippets: Bsalis, Steven Mading, et.al.

CLEARSCREEN.

// Take-off Check list
PRINT " INITIATING TAKEOFF SEQUENCE".
WAIT 1.0.
LIGHTS ON.
WAIT 1.0.
PRINT " Brakes Off".
WAIT 1.0.
BRAKES OFF.
WAIT 1.0.
PRINT " Flight Computer Enabled".
WAIT 1.0.
SAS OFF.
WAIT 1.0.
PRINT " Gimme a Vector Victor".
LOCK steering to up + R(0,-45,-90).
PRINT " Copy, heading is: 90, pitch 45deg".
WAIT 1.0.
PRINT " Roll on 2!".
AG2 on. //Basic jets
WAIT 1.0.
LOCK THROTTLE to 1.
PRINT " The captain has illuminated the no-puking sign".
wait until altitude > 4000.
AG3 on. //Turbo Jets
when altitude > 4000 then PRINT "   Engaging Turbos".

// MidFlight
wait until altitude > 12000.
LOCK STEERING TO HEADING(90,50).
wait until altitude > 14000.
LOCK STEERING TO HEADING(90,45).
wait until altitude > 16000.
LOCK STEERING TO HEADING(90,35).
wait until altitude > 18000.
LOCK STEERING TO HEADING(90,30).
wait until altitude > 20000.
LOCK STEERING TO HEADING(90,15).

// FINAL ASCENT
PRINT "Switching to rocket ascent".
wait until altitude > 24000.
LOCK steering to up + R(0,-45,-90).
AG2 off. //Basic Jets
AG3 off. //Turbo jets
AG1 on. //Rapier engine
WAIT 2.
PRINT "   pitch 45 degrees".
WAIT until ALTITUDE < 40000.
PRINT "   pitch 35 degrees".
LOCK steering to up + R(0,-55,-90).
WAIT until ALTITUDE < 50000.
PRINT "   pitch 10 degrees".
LOCK steering to up + R(0,-80,-90).
WAIT until APOAPSIS > 100200.
PRINT "   target Ap reached".
LOCK throttle to 0.
LOCK steering to PROGRADE.
WAIT 1.0.
PRINT " Coasting to Ap".

// CIRCULARIZING
WAIT until ETA:APOAPSIS < 11.
PRINT " Circularising".
LOCK steering to up + R(0,-90,-90).
WAIT 1.0.
LOCK throttle to 1.
WAIT until PERIAPSIS > 99900.
LOCK throttle to 0.
WAIT 1.0.
unlock steering.
PRINT " Now in orbit".
AG8 on. //Extend Solar Panels and Antenna.

PRINT "Welcome to spaAAAAAAAAAAAAAAAAAAce!".

Edited July 8, 2014 by Pondafarr

[jwwolff]

when altitude > 4000 then PRINT " Engaging Turbos".

when you use a when... then statement you need to have curly brackets {}. example: when altitude > 4000 then{print "Engaging Turbos.}.

[jwwolff]

Change <liquidfuel> to SHIP:LIQUIDFUEL or STAGE:LIQUIDFUEL. the former will get the entire ships liquid fuel the latter will get the liquid fuel in the tanks kip assigns to that stage. Based on my quick glance I would suggest going with the former.

[Pondafarr]

thanks, that will help clarify my code.

when you use a when... then statement you need to have curly brackets {}. example: when altitude > 4000 then{print "Engaging Turbos.}.

[Dunbaratu]

Okay so i have this script here and was trying to test this mod out for the first time and ran into some issues because this script was made on a early version and i cant find the version for download anywhere so i cant downgrade! this is the script: http://pastebin.com/zZwek06Z,

That pastebin is showing what the code looks like WITH the "<" and ">" marks, not what you did to try to remove them. You say you removed them and then got the error, but you didn't show what it looked like after the removal. Did you literally JUST delete the '<' and '>' and therefore I should assume that the code you ran with is what I see with those singleton characters removed? If so, then that's the problem. "<liquidfuel>" needs to be replaced with "ship:liquidfuel", not just merely "liqudfuel".

If that's not the problem then you'll have to show what you did to remove the "<" and ">" marks and give a pastebin of THAT.

[Dunbaratu]

when you use a when... then statement you need to have curly brackets {}. example: when altitude > 4000 then{print "Engaging Turbos.}.

That is not true.

WHEN/THEN allows the body to be either a singleton statement or a block of code with squiggly braces. Much like "C" and "Java", the squiggly braces are optional when the body only contains one statement.

If what you're saying was the problem, the error would have been a syntax error rather than a runtime error.

Granted, it's often good programming practice to use the squiggly braces anyway even where not needed, but that's another issue.

One thing I see as a deficiency in the language is how the rules about requiring squiggle braces are not consistent between the different places they could be used. SOME places allow them to be optional when only one statement is in the body. Other places require them unconditionally.

Optional: WHEN/THEN, ON.

Required: IF, UNTIL.

The old-time C programmer in me wants to see them optional all the time, but that would probably require adding the required parentheses around the condition in the if/until cases that C has, which it has specifically because it needs some way to mark where the conditional expression ends and the body begins when there's no squiggly braces.

Basically, fixing the inconsistency would break some backward compatibility no matter which way around it's fixed. Making the braces required everywhere would break old WHEN/THEN's and making them optional everywhere would necessitate adding required parentheses to the Ifs and UNTILs.

[Dunbaratu]

I'm getting a recurring Out of Sync error, which cuts my throttle and breaks the script.

What you're seeing is an underlying C Sharp error bubbling up to be exposed to you. In C Sharp, "Out of Sync", despite the name, has nothing to do with timing or threading at all. It means that while using one of the built-in collection looping operators, the collection itself was changed, which C Sharp's iterators are too simple to understand how to handle, so it throws up its hands and spews this error whenever it happens.

The kOS equivalent would be trying to make a FOR loop over a LIST, and deleting items of the LIST inside the FOR loop.

Since your code doesn't appear to do any looping of its own the problem must be happening in kOS's own Csharp code. Can you say what the version of kOS is? This problem used to happen a lot and it was fixed, but it's been so long since a real release that this fix might not be on the public curse release.

[Pondafarr]

I am using the latest release version, 0.12.1, downloaded yesterday.

workaround was to reboot, and load my next flight phase program.

To trouble shoot my code, I separated every distinct phase into individual programs, then bug fixed until each section worked properly(ish). The section in question should be a simple "climb until altitude is 1000", but it breaks at about 2.1 km from KSC every time I've run it.

 
// Take-off Check list
PRINT " INITIATING TAKEOFF SEQUENCE".
WAIT 1.
LIGHTS ON.
WAIT 1.
PRINT " Brakes On".
WAIT 1.
BRAKES On.
WAIT 1.
PRINT " Flight Computer Enabled".
WAIT 1.
SAS OFF.
WAIT 1.
PRINT " Gimme a Vector Victor".
LOCK STEERING TO HEADING(90,25).
Wait 1.
PRINT " Copy, heading is forward and up ".
WAIT 1.
PRINT " Roll on 2!".
// Basic jets
AG2 on.
WAIT 2.
LOCK THROTTLE to 1.
Wait 2.
Print "Release Brakes".
Brakes off.
PRINT " The captain has illuminated the no-puking sign".
wait until ALTITUDE > 150.
GEAR OFF.
WAIT 2.
WHEN ALTITUDE > 1000 THEN RUN SSTOMF.  //STOMF is the midflight climb

I'm going to try a supersimple version next, and see if its related to a ship unload condition (there was a ship sitting on the vertical launch platform, perhaps its unload caused the problem, the render distance should have been right about that distance)

Edited July 9, 2014 by Pondafarr

[Pondafarr]

After some preliminary testing, it does seem that removing the rocket from the vertical launch pad had removed the error from my SSTO launch. The unload of the rocket effected my SSTO program with the Out of Sync error. (note, the other rocket did NOT have a KOS computer, so I believe it was a simple craft unloading issue)

Further investigations are warranted of course.

[Pondafarr]

Hokay. I got my initial climb code sorted out, but now I'm having problems with flameout detection.

Would you please look at this and tell me if I'm missing something?

if ALTITUDE > 20000 {
  // Check for flameout of any of the existing engines:
  set stg_numF to 0.
  list engines in stg_eList.
  for stg_eng in stg_eList { 
    if stg_eng:flameout {
      set stg_numF to stg_numF + 1.
    }.
  }.
  if stg_numF > 0 {
    PRINT " engine(s) flamed out".
	PRINT "DROPPING BASIC JETS".
	LOCK THROTTLE to 0.
	AG2 off. //basic jets
	AG3 on. //turbojets
	WAIT 2.
	LOCK THROTTLE TO 1.
  }.
}.

if ALTITUDE > 25000 {
  // Check for flameout of any of the existing engines:
  set stg_numF2 to 0.
  list engines in stg_eList.
  for stg_eng in stg_eList { 
    if stg_eng:flameout {
      set stg_numF2 to stg_numF2 + 1.
    }.
  }.
  if stg_numF2 > 0 {
    PRINT " engine(s) flamed out".
	PRINT "SWITCHING TO RAPIER ENGINES".
	LOCK THROTTLE to 0.
	AG2 off. //basic jets
	AG3 OFF. //turbo jets
	ag1 ON. //RAPIER engine
	WAIT 2.
	LOCK THROTTLE TO 1.
  }.
}.

[Laie]

Hokay. I got my initial climb code sorted out, but now I'm having problems with flameout detection.

Would you please look at this and tell me if I'm missing something?[...]

Looks good at first sight. I didn't count the brackets and periods, though. The one problem I do see is that you're checking for flameout exactly once, at a set altitude -- but that's a conceptual thing, not a syntax error. IMO, the check should be part of the main loop and run in short intervals; you want to catch a flameout quickly.

If you want to quickly test your code, build a contraption with one intake and a dozen engines; this should provide you with flameouts without even taking off.

Edited July 11, 2014 by Laie
+ testbed