[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Drew Kerman]

hello there, i am trying to make a "surface info" screen for my ascent little prog, the issue i get is that the number just keep flickering...

First, don't blank the whole screen. Print the static bits of the interface once at load, then just use PRINT AT to update the parts that are changing. Second, use several WAIT 0.001 statements to force the program to jump to the next tick before blanking out a line you need to refresh. I explain it more in this post I made earlier. I never got a better idea from the devs so this is what I do and it works, with the slightest of slowdown in refresh times of course.

[Drew Kerman]

I'm still wondering how to set WARP to PHYSICS mode. I tried banging a few commands into the console and spent a few minutes looking through the source. No idea.

[Panichio]

I just spent too long reading through the kOS github page and can't see anyway to find, when my maneuver node gets me into say Mun's SOI, the periapsis of that fly-by. It would be incredibly useful to be able to have a loop add a small number to node:prograde until that periapsis meets a certain criteria like less than or equal to. Is there any other way to find that periapsis for kOS to use as a variable?

[Dunbaratu]

I just spent too long reading through the kOS github page and can't see anyway to find, when my maneuver node gets me into say Mun's SOI, the periapsis of that fly-by. It would be incredibly useful to be able to have a loop add a small number to node:prograde until that periapsis meets a certain criteria like less than or equal to. Is there any other way to find that periapsis for kOS to use as a variable?

If you are NOT going to execute any manuever nodes and are already on a path drifting toward an encounter, it works like so:

Each Orbit has a suffix called PATCHES which is a LIST of all the follow-on ORBITs that represent the next patches of orbit after the current one. For example, if you are currently in an orbit of Kerbin, which will pass through Mun'a SOI on a gravity slingshot, back into Kerbin's SOI, and then escape Kerbin's SOI into the Sun's SOI, then you'd have a data structure like this:

SHIP:Orbit describes your current orbit patch in Kerbin.

SET futurePatches to SHIP:Orbit:Patches makes a LIST of the orbits you'll transition into later, in which:

futurePatches[0] describes the Mun orbit patch of your flyby gravity slingshot (and therefore its :PERIAPSIS will be the closest approach to the Mun)

futurePatches[1] describes the Kerbin orbit patch after the flyby of the mun, in which you are on an escape trajectory out of Kerbin's SOI.

futurePatches[2] describes the Sun orbit after you leave Kerbin's SOI.

Now, what about when you have a manuever node?

When you have a maneuver node, it will have a suffix called :ORBIT, which is the predicted orbit patch that begins just after the maneuver node burn will have occured, assuming you somehow managed to execute the maneuver node as predicted with perfect precision.

This Manuever node's :ORBIT is just like any other Orbit, in that it too will have a :PATCHES suffix that you can use to see its future transitions.

[Panichio]

If you are NOT going to execute any manuever nodes and are already on a path drifting toward an encounter, it works like so:

Each Orbit has a suffix called PATCHES which is a LIST of all the follow-on ORBITs that represent the next patches of orbit after the current one. For example, if you are currently in an orbit of Kerbin, which will pass through Mun'a SOI on a gravity slingshot, back into Kerbin's SOI, and then escape Kerbin's SOI into the Sun's SOI, then you'd have a data structure like this:

SHIP:Orbit describes your current orbit patch in Kerbin.

SET futurePatches to SHIP:Orbit:Patches makes a LIST of the orbits you'll transition into later, in which:

futurePatches[0] describes the Mun orbit patch of your flyby gravity slingshot (and therefore its :PERIAPSIS will be the closest approach to the Mun)

futurePatches[1] describes the Kerbin orbit patch after the flyby of the mun, in which you are on an escape trajectory out of Kerbin's SOI.

futurePatches[2] describes the Sun orbit after you leave Kerbin's SOI.

Now, what about when you have a manuever node?

When you have a maneuver node, it will have a suffix called :ORBIT, which is the predicted orbit patch that begins just after the maneuver node burn will have occured, assuming you somehow managed to execute the maneuver node as predicted with perfect precision.

This Manuever node's :ORBIT is just like any other Orbit, in that it too will have a :PATCHES suffix that you can use to see its future transitions.

Ah, thank you! I forgot how to access lists. Stupid me. I only have one problem now, though. I can get futurePatches[1]:periapsis just fine and it returns the correct number for both current orbit and orbit after a maneuver but when I print futurePatches[1] kOS returns "ORBIT of <unnamed>". Why does it do that?

[Dunbaratu]

Ah, thank you! I forgot how to access lists. Stupid me. I only have one problem now, though. I can get futurePatches[1]:periapsis just fine and it returns the correct number for both current orbit and orbit after a maneuver but when I print futurePatches[1] kOS returns "ORBIT of <unnamed>". Why does it do that?

It's trying to say "this is an orbit of ...." where the "...." turns out to be the maneuver node rather than the vessel. And maneuver nodes don't have names so it doesn't have anything to print there.

[soulsource]

Sorry if these questions have been answered before, but I didn't find answers for them by searching the forum or in the kOS docs.

• What is the current state of Remote Tech 2 integration? Is kOS in any way affected by signal delay? If no, is there some way to emulate it, for instance by waiting for an action group to be used, an event that might be delayed by RT2?
  
• If I have a program running in kOS and switch to another vessel outside the current physics range, and then back again, will the program still be running or do I need to restart it? What if I exit KSP?
  

Thanks in advance!

[Dunbaratu]

Sorry if these questions have been answered before, but I didn't find answers for them by searching the forum or in the kOS docs.

• What is the current state of Remote Tech 2 integration? Is kOS in any way affected by signal delay? If no, is there some way to emulate it, for instance by waiting for an action group to be used, an event that might be delayed by RT2?
  

It's still not there by default but it is easy to simulate the delay - just google the speed of light in meters per second, and multiply it by Kerbin:Distance to get the number of seconds a signal should take to make a one-way trip between home and the craft. If you want to simulate that you need a two-way communication, then wait twice as long as that.

• If I have a program running in kOS and switch to another vessel outside the current physics range, and then back again, will the program still be running or do I need to restart it? What if I exit KSP?
  

This is *supposed* to be supported, but I'm not sure it's really working well. The entire load/save system needs looking at at some point.

[soulsource]

Thanks for the answer! Regarding the delay, I've figured that I can just make kOS wait for an action group to change and then press the corresponding key. The action group will get the proper delay from Remote Tech. This is especially useful when running multiple commands in rapid succession.

I stumbled across another issue with kOS on Linux (or more precisely: with Unity on Linux...). While the new kOS.dll file works fine for RETURN, canceling a running program does not seem to work. CTRL+c does nothing, at least for me.

[mecki]

Is it possible to fly a proper gravity turn with Real Solar System and FAR with this?

[Ralathon]

Is it possible to fly a proper gravity turn with Real Solar System and FAR with this?

Yes, but calculating a proper gravity turn is a very difficult affair. The equations cant be solved analytically, so you have to run simulations until you find one that works.

Most people approximate a gravity turn with something like a sqrt curve which gives reasonable results.

[Drew Kerman]

...and then press the corresponding key.

Wait kOS can send keystrokes to the game?

[soulsource]

Sorry for not expressing this more clearly. kOS can be set to either do something ON an action group state change, or can be set to WAIT for an action group. Remote Tech on the other hand delays action group commands by the signal delay. With "corresponding key" I meant the keyboard keys 1 to 0, which activate the action groups.

So, while the craft would react immediately to commands typed into the kOS console, by letting kOS first WAIT for an action group, the further execution of the kOS script can be delayed by exactly the same signal delay (taking into account the full signal path, counting the distance between the relays) as other commands. Of course this is just for roleplaying purposes ;-)

[madlemur]

Yes, but calculating a proper gravity turn is a very difficult affair. The equations cant be solved analytically, so you have to run simulations until you find one that works.

Most people approximate a gravity turn with something like a sqrt curve which gives reasonable results.

FWIW, I'm going to be working on integrating FAR with kOS, so that maybe we can get some aero-data that's useful. That may mean exposing more aero-data in general (useful bits like Q, AoA, etc., etc.) if they are not already exposed, and if they are readily accessible or reasonably calculated from the KSP API. Then you could program something in to make your throttle and pitch adjustments with bounds at certain values of Q and/or AoA. erendrake said he spoke with ferram, and trying to reach terminal velocity in FAR would be counter-productive to maintaining even short-term vessel coherence, although I would certainly expose FAR's terminal velocity values. I'm still digging through both the kOS code and the FARAPI code to see what will need to be done. Not to mention trying to learn about aerodynamics, orbital mechanics, and C#...

[Dunbaratu]

@madlemur, can you tell us what the acronyms "Q" and "AoA" are? I'm guessing AoA might be Angle of Attack? In which case, you can already get the SHIP:VELOCITY:SURFACE which is the way you're going, and you can get vectors pointing in the ship-relative axes with (SHIP:FACING*V(1,0,0)), (SHIP:FACING*V(0,1,0), and (SHIP:FACING*V(0,0,1)). Putting all that together with some dot product math it should be possible to obtain your angle of attack, even in kerboscript today. (Basically, take the component of the velocity that is in your ship's "top" facing direction, by dot-producting with one of those 3 axis vectors (I forgot which one is "top" in the SPH-built ships). It will tell you how much your velocity is going upward or downward relative to your facing. Then to transform that into an angle, get the arcsin() of the triangle in which the vertical leg is the vertical velocity component you created, and the hypotenuse is the length of SHIP:VELOCITY:SURFACE.) This is all doable today in a single expression in kOS without any changes behind the scenes.

For example, it might look something like this:

LOCK AoA TO arcsin( VDOT(SHIP:FACING*V(0,1,0),SHIP:VELOCITY:SURFACE) / SHIP:VELOCITY:SURFACE:MAG ).

(Although I may have the V(0,1,0) wrong and it's actually V(1,0,0) or V(0,0,1) depending on which way the axes go for spaceplane hangar ships.)

Edited August 8, 2014 by Steven Mading

[madlemur]

It appears my reply may have been eaten... Q is the pressure on the hull. It is based on the air density and surface velocity. If you watch the FAR GUI, it triggers the "High Dyn Pressure" warning when q > 40000. If I can find or compute some of the other data points in Stock, I'll also surface the various coefficients that FAR provides. I don't want to limit any data to only FAR users.

[LessrOf2Weevils]

in v0.11 We will have the following values in ORBIT

APOAPSIS - Altitude

PERIAPSIS - Altitude

BODY - Reference Body, has a bunch of its own data.

PERIOD - in seconds

INCLINATION

ECCENTRICITY

SEMIMAJORAXIS

SEMIMINORAXIS

TRANSITION - How the current orbit patch will end

INITIAL,

FINAL,

ENCOUNTER,

ESCAPE,

MANEUVER,

PATCHES - all of the proceeding orbit patches. which have all of these same values.

we have an open issue for adding more to orbit. feel free to add your thoughts

https://github.com/erendrake/KOS/issues/18

I feel like a complete noob asking this, but how do you access these values. I've tried and number of different prefix combinations, but none seem to work.

Thanks

[Dunbaratu]

I feel like a complete noob asking this, but how do you access these values. I've tried and number of different prefix combinations, but none seem to work.

Thanks

For current orbit your ship is drifting on: SHIP:ORBIT (i.e. SHIP:ORBIT:PERIOD).

For the orbit that will start after a manuever node is executed, assuming it gets executed exactly as planned:

SET mynode to NODE( time:seconds + 120, 0, 0, 100 ).

ADD mynode.

print "After upcoming burn, period will be " + mynode:ORBIT:PERIOD.

[amiavamp]

I've been playing KSP for a while now, and I decided to try out kOS after attempting to land a probe on Ike with RemoteTech's signal delay. (I did manage to touch down minus an engine after some F5/F9 spam, but that's beside the point.) I've spent the past few days constructing and tweaking some (extremely novice) scripts to carry a probe from takeoff, to orbit, to reentry, and to landing on Kerbin. I was bustling with questions when I started with kOS, but I decided to try to find answers to all of them on my own instead of pestering the forum. However, I've unfortunately run into a few dead ends that are stymieing my progress toward creating a full catalog of autopilots. Hopefully this post isn't too much of a wall of text.

1. What is the simplest way for a landing script to detect whether the surface beneath is land or water? I've noticed that both Kerbal Engineer and the IVA instruments report the radar altitude as being below sea level if water is beneath the craft. This is an example of how I've been doing it so far:

IF ALTITUDE > ALT:RADAR {
    SET altFlag TO 1.
    WAIT UNTIL ALTITUDE < 400.
}
ELSE {
    SET altFlag TO 2.
    WAIT UNTIL ALT:RADAR < 400.
}.
UNTIL altFlag = 3 {
    IF altFlag = 1 AND ALTITUDE < 15 AND VERTICALSPEED > -1 AND VERTICALSPEED < 1 { SET altFlag TO 3. }.
    IF altFlag = 2 AND ALT:RADAR < 15 AND VERTICALSPEED > -1 AND VERTICALSPEED < 1 { SET altFlag TO 3. }.
    WAIT 0.001.
}.

However, I get the feeling that the usage of variables as arbitrary flags is not a best coding practice, and every character typed further strains storage space. Is there a more concise method to doing this landing procedure?

2. My scripts seem to have a real problem with throttle control. Unless I put "SET CONFIG:SAFE TO FALSE." somewhere in the script, I inevitably get an error message about a value being NaN. This is probably something that can be worked around with the correct logic, although I'm not sure how to set it up. This is one of the bits of code that is causing the error:

IF vesselAcceleration > 0 AND vesselAcceleration < 18 AND throttleValue < 1 {
        SET throttleValue TO throttleValue + 0.01.
    }.
    IF vesselAcceleration > 0 AND vesselAcceleration > 18 AND throttleValue > 0.01 {
        SET throttleValue TO throttleValue - 0.01.

I assume the issue is being caused by "throttleValue + 0.01" equaling a number greater than 1 at some points. Is there a way to avoid the issue without disabling CONFIG:SAFE or preventing the craft from using the entire range of throttle?

3. I have a script that is set up to detect the types of fuel that are present on a vessel for the purposes of staging when out of fuel. This is in an attempt to make a more general "takeoff and enter orbit" script instead of needing one that is specifically tailored for each vessel. However, the method I am using simply refuses to work. This is the relevant snippet of code:

SET fuelType TO 0. // 0 = none, 1 = solid, 2 = liquid, 3 = both
UNTIL APOAPSIS >= targetAltitude {
    IF STAGE:SOLIDFUEL < 0.02 AND (fuelType = 1 OR fuelType = 3){
        PRINT "No solid fuel. Attempting to stage.".
        STAGE.
    }.
    IF STAGE:LIQUIDFUEL < 0.02 AND (fuelType = 2 OR fuelType = 3){
        PRINT "No liquid fuel. Attempting to stage.".
        STAGE.
    }.
    IF STAGE:SOLIDFUEL > 0 AND STAGE:LIQUIDFUEL = 0 { SET fuelType TO 1. }.
    IF STAGE:SOLIDFUEL = 0 AND STAGE:LIQUIDFUEL > 0 { SET fuelType TO 2. }.
    IF STAGE:SOLIDFUEL > 0 AND STAGE:LIQUIDFUEL > 0 { SET fuelType TO 3. }.
    WAIT 0.001.
}.

The "fuelType" variable works as intended - it changes to the correct value when a type of fuel runs dry. However, the IF statements that contain the STAGE function never trigger. I've tried several variants of this, including using "NOT fuelType = 2" or "fuelType <> 2" for the solid fuel section. I've also tried moving the part that sets the value of "fuelType" to the top of the loop. Nothing seems to work. However, if I remove the "fuelType" requirements, the stages trigger, as do the print messages. Previously, I'd been using an arbitrary flag value to control when each type of fuel should have its quantity checked, but I would really like to have a script that requires less modification to transfer between vessels.

4. How do I prevent WHEN statements from interrupting other commands? When I discovered that WHEN statements stop and never resume UNTIL and WAIT UNTIL statements, I started to avoid using WHEN as much as possible. This leads to some repetitive code, which I would also like to avoid - sometimes, I need the same constant condition check for multiple UNTIL loops in a script, like being able to stage both during ascent and during orbital maneuvers. I understand that Kerboscript is not truly multithreaded and instead can only process one action at a time, but it seems odd how it breaks other loops entirely. For example, if I have "WAIT UNTIL maneuverNode:BURNVECTOR:MAG < 0.5." running to determine when to cut the throttle during a burn, and then a WHEN statement triggers before it's done, the program will just instantly end as soon as the WHEN loop is over.

I would greatly appreciate any help with these matters.

[Entropius]

Is it possible for a kOS script to suspend a Kerbal Alarm Clock event, like a reduction in warp?

Sometimes I execute a kOS script that I know has some built-in warp controls and won't overshoot the node, but KAC doesn't know that, so I have to let KAC halt the warp, then I manually resume warp. Is kOS integration with KAC possible?

[Drew Kerman]

Sometimes I execute a kOS script that I know has some built-in warp controls and won't overshoot the node, but KAC doesn't know that, so I have to let KAC halt the warp, then I manually resume warp. Is kOS integration with KAC possible?

Sounds like you're using KAC to automatically create an alarm for the maneuver node? If so, afterwards you can edit the alarm properties so that it only notifies you, not mess with the warp. Or you can set this when you create the maneuver node alarm if you do it manually

[Entropius]

Sounds like you're using KAC to automatically create an alarm for the maneuver node? If so, afterwards you can edit the alarm properties so that it only notifies you, not mess with the warp. Or you can set this when you create the maneuver node alarm if you do it manually

While I technically could do that, it's even more inconvenient than what I'm currently doing (letting KAC halt the warp, and manually resuming it till my kOS script halts it). I swap back and forth a bunch between manual control and my kOS auto-node script. I was a bit much to expect, but I thought it was worth asking anyway.

On an unrelated note, does anybody know the proper units for engine fuel flow? The documentation doesn't seem to know, and speculates it's liters/second, but I'm not sure that would be useful. But on the other hand if it were in mass/second (metric tons/sec?), you could actually use it in the Tsiolkovsky rocket equation.

[undercoveryankee]

On an unrelated note, does anybody know the proper units for engine fuel flow? The documentation doesn't seem to know, and speculates it's liters/second, but I'm not sure that would be useful. But on the other hand if it were in mass/second (metric tons/sec?), you could actually use it in the Tsiolkovsky rocket equation.

It's probably in in-game units of resource/second, where 1 unit of a resource represents whatever the resource author wants it to. E.g. 1 liter (a lot of mods), 24 kerbal-hours (TAC Life Support 0.8 and below) or who knows what else. The stock fuels correspond better with the displayed sizes of the tanks if each unit takes up a couple of liters, but I don't recall Squad ever quoting an official number. Multiply by the density of the resource to get tons/sec.

[Dunbaratu]

1. What is the simplest way for a landing script to detect whether the surface beneath is land or water?

Your technique is correct. If SHIP:ALTITUDE > ALT:RADAR, then you have ground terrain under you, else you are over water. To detect if you are landed, try using STATUS instead and check for if its value is either "LANDED" or "SPLASHED".

However, I get the feeling that the usage of variables as arbitrary flags is not a best coding practice, and every character typed further strains storage space. Is there a more concise method to doing this landing procedure?

What you're doing with the flags is fine. The error must come from somewhere else.

2. My scripts seem to have a real problem with throttle control. Unless I put "SET CONFIG:SAFE TO FALSE." somewhere in the script, I inevitably get an error message about a value being NaN. This is probably something that can be worked around with the correct logic, although I'm not sure how to set it up. This is one of the bits of code that is causing the error:

IF vesselAcceleration > 0 AND vesselAcceleration < 18 AND throttleValue < 1 {
        SET throttleValue TO throttleValue + 0.01.
    }.
    IF vesselAcceleration > 0 AND vesselAcceleration > 18 AND throttleValue > 0.01 {
        SET throttleValue TO throttleValue - 0.01.

That bit of code *cannot* be causing the error "Tried to push NaN into the stack". It might be *triggering* the error, but the error has to be caused by one of the places those variables (vesselAcceleration or throttleValue) is being set.

I assume the issue is being caused by "throttleValue + 0.01" equaling a number greater than 1 at some points.

No, that cannot be the cause of a NaN error. You don't get NaN for throttle values out of range. Instead for throttle values out of range, kOS just sets the real throttle to max or min. (if you say THROTTLE is 2, the actual throttle you'll get just caps out at 1 instead.)

NaN, meaning "Not a Number", is an acronym for how computers store the fact that a calculated value cannot be properly represented in real numbers. The floating point numbers kOS uses (and most computer programs use) are only capable of storing Real Numbers. If you try to calculate the square root of a negative number, for example, the computer can't store the result because the native number type doesn't do imaginary numbers. (There are more messy homebrewed number types that can do complex math, but the native low-level numbers computers use can't.)

Another place where you might get NaN is when using a math function call where you passed in an invalid input that's outside the range of values it can give an answer for. For example, there is no such thing as the arccos(1.001), because there's no angle at which the cosine of that angle is higher than 1. If you try to call arccos(1.001), you'll get a result of NaN.

Look elsewhere in your code for either taking roots of negative numbers, or using inverse trig passing in values outside the range [-1,1]. It's probably one of those two things.

Incedentally, this sort of problem ("where is this runtime error coming from?") should get easier in the future, I hope. I spent the last few days working on an update to kOS that will have it trace backward from the compiled code to the original script source code line from which runtime errors happened. If it's approved and works, it would let you see "oh, THAT's the math operation where it generated a NaN, right there, on line 15, column 24."

3. I have a script that is set up to detect the types of fuel that are present on a vessel for the purposes of staging when out of fuel. This is in an attempt to make a more general "takeoff and enter orbit" script instead of needing one that is specifically tailored for each vessel. However, the method I am using simply refuses to work. This is the relevant snippet of code:

SET fuelType TO 0. // 0 = none, 1 = solid, 2 = liquid, 3 = both
UNTIL APOAPSIS >= targetAltitude {
    IF STAGE:SOLIDFUEL < 0.02 AND (fuelType = 1 OR fuelType = 3){
        PRINT "No solid fuel. Attempting to stage.".
        STAGE.
    }.
    IF STAGE:LIQUIDFUEL < 0.02 AND (fuelType = 2 OR fuelType = 3){
        PRINT "No liquid fuel. Attempting to stage.".
        STAGE.
    }.
    IF STAGE:SOLIDFUEL > 0 AND STAGE:LIQUIDFUEL = 0 { SET fuelType TO 1. }.
    IF STAGE:SOLIDFUEL = 0 AND STAGE:LIQUIDFUEL > 0 { SET fuelType TO 2. }.
    IF STAGE:SOLIDFUEL > 0 AND STAGE:LIQUIDFUEL > 0 { SET fuelType TO 3. }.
    WAIT 0.001.
}.

At first glance this logic looks okay to me. Have you tried inserting print statements at the top of the loop to verify that all the relevant variable values are what you think they are? Usually if I have an if clause that should be triggering, but isn't, I diagnose it by inserting a print statement just before the if check that prints out the value of all the variables the conditional expression is using, so I can see if it's really using the values I think it is.

4. How do I prevent WHEN statements from interrupting other commands?

By not using WHEN statements? Asynchronous flow, where you are interrupting the normal program flow by inserting a diversion into the WHEN clause before continuing with the rest of the mainline code is the *sole purpose* of a WHEN statement.

When I discovered that WHEN statements stop and never resume UNTIL and WAIT UNTIL statements

That is simply not true. When the WHEN statement is finished, control should pick up where it left off in the main code, and that means continuing right where it left off in the middle of the UNTIL loop. It would only abort the loop if your WHEN block altered one of the variables that the UNTIL loop is using as its conditional check so the check's boolean value changes, but then that's correct behavior if it does that.

What you might be expriencing is that flow won't continue until the WHEN statement is finished. THAT is true, but it's not what you said. (You claimed it would never resume the original statement and that's false. It will - but only when the WHEN statement is finished. You shouldn't be putting loops that are meant to run in the background in a WHEN. WHEN clauses should be designed to flow through fast and finish to the bottom.)

This is especially true because WHEN doesn't just interrupt the flow of your program. It actually interrupts the flow of the entire KSP simulation itself. If you put an infinite loop in your WHEN clause, it won't just stop your program - it will freeze-frame all of KSP and require killing and restarting KSP.

(All mods are allowed to register an updater function that gets called once per animation frame by Unity. But the process of iterating over all the registered updater functions and calling all of them is single-threaded and therefore any misbehaving mod can freeze ALL the updates for the whole game if it never finishes its own update call.)

The WHEN clause allows users to write programs that can do this, because unlike with the rest of the program flow, WHEN is designed to run its flow all the way to the bottom before finishing the update (while the mainline code just runs 100 or so instructions and then waits for the next update to continue, the WHEN code runs all the way through to the bottom and is supposed to finish in a single animation update.)

One of the issues on the issues tracker is to make it explicitly notice when a WHEN clause is taking too long, and abort it with an error message telling the user what's going on and why and how they have to redesign their code.

(edit: If your program logic is one in which you'd LIKE to have a WHEN clause that behaves a bit like a background loop, I recommend looking into the PRESERVE keyword in the docs. It keeps the WHEN trigger around after it finishes, making it possible for it to get called again in the next update, and the next, and the next. This can make a sort of loop out of the WHEN clause, but its one that executes exactly one iteration per animation frame.)

Edited August 9, 2014 by Steven Mading

[WeirdCulture]

Hi Guys,

i have some "Issues",

1.) I use RT2. And it seems that the craft only execute maneuver when a connection is established? is that Worked as Designed, or do i make any errors? I hoped i can upload a Program as long I have connection and then the craft will execute maneuvers even a Connection is not established. It seemsit woked the opposite way. I can "upload" any program any time i want, but a connection is needed to executre maneuvers

2.) I downloaded the latest from curse, At start i got the wrong version printet on the screen Meh! Layer 8 Problem

3.) Awsome Mod!

Edited August 11, 2014 by WeirdCulture