[1.3] kOS Scriptable Autopilot System v1.1.3.0

[marianoapp]

This happens because the script is compiled prior to be executed and "locks" are just a language construct that internally works pretty much like a function without parameters. So every time you use a locked variable in the script it gets replaced by a call to this function (all of this happens in the compilation stage).

And since you can lock the same variable to different expressions a function pointer is needed (the variable with the asterisk) that gets updated every time you lock/unlock that variable.

[Dunbaratu]

This happens because the script is compiled prior to be executed and "locks" are just a language construct that internally works pretty much like a function without parameters. So every time you use a locked variable in the script it gets replaced by a call to this function (all of this happens in the compilation stage).

And since you can lock the same variable to different expressions a function pointer is needed (the variable with the asterisk) that gets updated every time you lock/unlock that variable.

Then how about this simple solution to fix the problem:

Every time you see this in the script code:

set var to (expression).

and 'var' is defined as a lock function elsewhere rather than as a simple variable, then replace:

set var to (expression).

with the risc instructions that would do this instead:

Evaluate (expression) into a final value now. Create a function that will return that constant value. Use that function as the lock expression.

That way 'var' is still a function, still a lock. It's just now a lock who's expression just returns a constant - the value of which is the value of the expression as it was at the time the 'set' command was run.

So if it was this:

set x to 7.

set var to x + 5.

And var was a lock expression elsewhere, then executing the above lines of code would cause var to become a function that returns the constant 12 rather than a variable who's value is 12. As far as the script programmer cares the result would be the same either way.

(At this point the discussion probably belongs over in the development thread instead of this thread.)

I made a tracking issue for this: https://github.com/KSP-KOS/KOS/issues/13

Edited March 22, 2014 by Steven Mading

[Guest]

Hi there,

a few months ago I have written a kOS launching program. It worked very well, but then a new KSP version came out and I forgot about kOS and the program. Now that Erendrake is working on this new version of kOS (thank you very much, your work is awesome), I have used the last two weeks to update for the current version and make it usable with FAR (now it's almost only usable with FAR). It works almost perfect, uses a correct gravity turn trajectory (follows surface:prograde very closely) and utilizes maneuver nodes to complete its orbit.

So here it is, just for you:

staging only works with kOS 11.0 !

kOS programs

PS.: It works by using a lot of sub-programs. L1 is the master-program. Run it with the parameters

(your orbit altitude in m, launch inclination (0 = east; 90 = north; etc.), number of stages on your rocket).

Very nice program. Do you think you could make a few additions? Most rockets executed a "roll program" which rolled the vehicle after clearing the launch tower, so that they only have to steer with the pitch controls. The thing is, it needs to be done slowly. I'll look into writing it myself, but don't know if I manage that.

Another thing would be a more elaborate stager that would take into account Engine Ignitor mod (so that ullage motors can be properly utilized) and ability to somehow set staging conditions, so it's possible to hot-start a stage or separate boosters when they're still thrusting.

[Dunbaratu]

Now I went through and changed all my 'sets' that were triggering the variable-with-asterisk message into locks instead, to get the code to continue running, and now I have this new problem: Shortly after liftoff, within about a second or so, the KSP black screen of death triggers. (I'm sure people have seen it before - the 3-D view goes black, the altimiter starts showing all the same digit (i.e. 9999999 or 8888888 or 7777777 and so on, and execution seems to be continuing but very slowly, and you can't tell what's going on.)

This is a program that previously DID work on 0.9 that I've been trying to update to work in 0.11. I don't know what changed, but here's the KSP log of the point where the problem appears:

[LOG 11:46:50.285] activating stage 17 - current stage: 18
[LOG 11:46:50.286] [liquidEngine1-2]: Activated
[LOG 11:46:50.298] [launchClamp1]: Activated
[LOG 11:46:50.299] [liquidEngine1-2]: Activated
[LOG 11:46:50.308] [launchClamp1]: Activated
[LOG 11:46:50.309] [liquidEngine1-2]: Activated
[LOG 11:46:50.310] [liquidEngine1-2]: Activated
[LOG 11:46:50.319] [launchClamp1]: Activated
[LOG 11:46:50.320] [liquidEngine1-2]: Activated
[LOG 11:46:50.329] [launchClamp1]: Activated
[LOG 11:46:50.330] [liquidEngine1-2]: Activated
[LOG 11:46:50.338] [launchClamp1]: Activated
[LOG 11:46:50.340] [solidBooster]: Activated
[LOG 11:46:50.341] [liquidEngine1-2]: Activated
[LOG 11:46:50.349] [launchClamp1]: Activated
[LOG 11:46:50.351] [solidBooster]: Activated
[LOG 11:46:50.352] [00:00:00]: Liftoff!!
[ERR 11:46:50.357] Vessel Being Flagged Under Disabled Plugin
[LOG 11:46:52.045] Look rotation viewing vector is zero
[EXC 11:46:52.067] ArithmeticException: NAN
[LOG 11:46:52.101] recalculating orbit for mk1pod: Kerbin
rPos: [NaN, NaN, NaN]   rVel: [NaN, NaN, NaN] |NaN|
[LOG 11:46:52.106] recalculated orbit for mk1pod: the Sun
rPos: [NaN, NaN, NaN]   rVel: [NaN, NaN, NaN] |NaN|
[LOG 11:46:52.108] setting new dominant body: the Sun
FlightGlobals.mainBody: Kerbin
[LOG 11:46:52.109] Vessel mk1pod velocity resumed. Reference body: Sun vel: [NaN, NaN, NaN]
[LOG 11:46:52.109] Vessel launchClamp1 velocity resumed. Reference body: Kerbin vel: [1165.70850896705, 2.20600485801697, -9341.86065115751]
[LOG 11:46:52.110] Vessel launchClamp1 velocity resumed. Reference body: Kerbin vel: [1165.58655488284, -5.00523233413696, -9342.08744510042]
[LOG 11:46:52.111] Vessel launchClamp1 velocity resumed. Reference body: Kerbin vel: [1165.74433173733, 0.496987462043762, -9341.68154542168]
[LOG 11:46:52.112] Vessel launchClamp1 velocity resumed. Reference body: Kerbin vel: [1164.91580614203, -3.33820581436157, -9342.69322806142]
[LOG 11:46:52.112] Vessel launchClamp1 velocity resumed. Reference body: Kerbin vel: [1165.73379065088, -3.51643514633179, -9341.67233485518]
[LOG 11:46:52.113] Vessel launchClamp1 velocity resumed. Reference body: Kerbin vel: [1165.62684249123, 0.407076090574265, -9341.83273940671]
[LOG 11:46:52.155] Look rotation viewing vector is zero
[LOG 11:46:52.156] Look rotation viewing vector is zero
[LOG 11:46:52.157] Look rotation viewing vector is zero
[LOG 11:46:52.157] Look rotation viewing vector is zero
[LOG 11:46:52.157] Look rotation viewing vector is zero
[LOG 11:46:52.158] Look rotation viewing vector is zero
[ERR 11:46:52.222] Invalid parameter because it was infinity or nan.
[ERR 11:46:52.222] dest.radius>=0.0f
[ERR 11:46:52.223] Invalid parameter because it was infinity or nan.
[ERR 11:46:52.223] dest.radius>=0.0f
[ERR 11:46:52.223] dest.radius>=0.0f
[ERR 11:46:52.223] Invalid parameter because it was infinity or nan.
[ERR 11:46:52.224] dest.radius>=0.0f
[ERR 11:46:52.224] dest.radius>=0.0f
[ERR 11:46:52.224] dest.radius>=0.0f
[ERR 11:46:52.225] Invalid parameter because it was infinity or nan.
[ERR 11:46:52.225] dest.radius>=0.0f
[ERR 11:46:52.225] dest.radius>=0.0f
[ERR 11:46:52.225] dest.radius>=0.0f
[ERR 11:46:52.226] dest.radius>=0.0f
[ERR 11:46:52.226] Invalid parameter because it was infinity or nan.
[ERR 11:46:52.226] dest.radius>=0.0f
[ERR 11:46:52.226] dest.radius>=0.0f
[ERR 11:46:52.227] dest.radius>=0.0f

The log gets spammed with more of those 'dest.radius' messages from there on until I kill KSP.

[erendrake]

Do you have a block of code i can execute that triggers this? I have seen the same thing before in a stock save so i hope we can track this down and fix it. You might try looking at the map view, it might show something interesting

[aNewHope]

Very nice program. Do you think you could make a few additions? Most rockets executed a "roll program" which rolled the vehicle after clearing the launch tower, so that they only have to steer with the pitch controls. The thing is, it needs to be done slowly.

That should be quite easy to accomplish. I locked the roll of the rocket to 360 - Inc (your launching angle) so it would keep the roll it had in the beginning.

You could replace

set Inc to 90-Inc.
lock steering to heading(pitch,inc,360-inc).

with

set Inc to 90-Inc.
lock roll to Inc-(Inc*(missiontime/60)).
when missiontime > 60 then {unlock roll. set roll to 0.}.
lock steering to heading(pitch,inc,360-roll).

This way within the first minute since launch you will slowly turn in the right direction. Of course you could increase the time or make it depend on your Inc value.

... hmm I like the Idea, gonna implement it in my copy.

PS.: I don't really know the engine ignitor mod but from the first look at the forum page I'd suggest this:

You could try a shallower approach (set your psi0 value closer to 90°)

or you could lock your steering to the horizon when your Ap is high enough and don't shut of your engines (This way you'll mostly raise the Pe but the Ap just a little). I can't guarantee that any of my suggestions will work, but that's what came into my mind at first.

PPS.: To have special staging conditions you'll probably need to add some extra "WHEN ... THEN" conditions. Totally depends on what you want your rocket to do.

Edited March 22, 2014 by aNewHope

[Dunbaratu]

Do you have a block of code i can execute that triggers this? I have seen the same thing before in a stock save so i hope we can track this down and fix it. You might try looking at the map view, it might show something interesting

Okay, I narrowed down the conditions and verified it was not being caused by any other mods and it still happens when kOS is the only mod. I also used a far smaller simpler craft and verified that it happens with that craft.

I put the code on google drive so you can give it a try. It's here:

https://drive.google.com/#folders/0Bxkeai7oN35fTkJQUnJRLUN2QjA

Along with the craft file of the test vessel, and a README showing the commands to run to kick it off.

I've tried this a number of times and verified that it reliably causes the problem every time.

Here's some screenshots of the steps leading up to the problem: The problem always happens at about T+2 seconds - just a moment after liftoff.

Edited March 22, 2014 by Steven Mading

[Hans Dorn]

I ran into a similar problem when playing around with gravity turns. I'ts late into the launch, after a couple minutes in my case...

Cheers

Hans

[Hans Dorn]

There's something weird with the "lock" command btw, seems like unlocking doesn't work properly.

The following sequence breaks the terminal window:

set a to 0.
set b to 1.
lock throttle to a.
unlock throttle.
lock throttle to b.

-> From here on nearly all input in the terminal results in "The given key was not present in the dictionary."

Toggling power on the CX-4181 fixes the terminal.

Cheers

Edited March 23, 2014 by Hans Dorn

[bartomanboy]

Is it me or is there no exponential function defined yet? (e^x)

I tried to calculate burn times for a certain deltav using a formula that needs this.

Also, I'm having some problems using the term "semimajoraxis" in my scripts. The documentation states that it's a part of the orbit structure, but I haven't found a way yet to acces it.

It gives this error: Unrecognized term 'SEMIMAJORAXIS', Type:FINAL

Any help would be greatly appreciated.

[Dunbaratu]

Is it me or is there no exponential function defined yet? (e^x)

I tried to calculate burn times for a certain deltav using a formula that needs this. http://www.braeunig.us/space/pics/eq1-21.gif

There's no need for an exponential function because there already exists the caret for "to the power of". What you need to perform e^x is not a function but rather a constant - you need the constant "e".

Like this:

set e to 2.718281828.

set y to e^x.

There exists a constant 'e' in the system already, but the syntax for accessing it is weird. You have to say:

consts():e.

The place where you *do* need support from the system giving you a function is when going the other way around, and getting the natural log. Doing that on your own is a mess because you'd have to calculate it from a series sum and that's too slow in kosscript.

For that you have ln():

set y to ln(x).

Also, I'm having some problems using the term "semimajoraxis" in my scripts. The documentation states that it's a part of the orbit structure, but I haven't found a way yet to acces it.

It gives this error: Unrecognized term 'SEMIMAJORAXIS', Type:FINAL

Try ORBIT:SEMIMAJORAXIS.

Or for getting it about a different ship than yourself, try:

TARGET:ORBIT:SEMIMAJORAXIS.

[bartomanboy]

There's no need for an exponential function because there already exists the caret for "to the power of"...

Thanks for your reply! A bit dumb of me not to see that.

I tried your approach for the semimajoraxis, but it didn't work, sadly enough. It keeps throwing errors. ( I use the Kerbal Space Port version 0.11.something )

If anyone knows a workaround for this, please let me know, or soon I'll have to calculate it manually.

[kaesekuchen]

I believe it's ship:obt:semimajoraxis , if i recall it correctly

[Dunbaratu]

I believe it's ship:obt:semimajoraxis , if i recall it correctly

Ah yes you're right. I forgot that ORBIT is abbreviated OBT.

[bartomanboy]

Thanks guys, you're great! This really needs to be added to the documentation though.

You can check here that this abbreviation is shown nowhere: http://ksp-kos.github.io/KOS_DOC/structure/orbit/

Unless I'm missing some website with key information.

[Kethevin]

Could someone give me an example of how you perform a targeted landing with K-OS? I am still having difficulty figuring out how to set up a deorbital maneuver node that will get my probe where I want on touchdown.

[Dunbaratu]

Could someone give me an example of how you perform a targeted landing with K-OS? I am still having difficulty figuring out how to set up a deorbital maneuver node that will get my probe where I want on touchdown.

That's actually one of the hardest tasks, if you have atmosphere. Without atmosphere it's a bit easier to calculate. But you're dealing essentially with one of those cases where the math stops being pretty and starts to become a case of using a numerical method iteratively to calculate an answer. I had originally planned on having that be my next goal to tackle back when Kevin Laity went AWOL and I stopped using kOS for a while. When kOS got resurrected, I've been trying to modify the stuff I already have to work with the new ever-changing system and that still isn't done yet so I haven't gone back to it.

[Dunbaratu]

Is it possible to provide a way for a kosscript writer to output a message to the KSP.log file?

The reason I ask is that this latest black screen of death problem is extremely difficult to narrow down where the problem first happens in my code. The reason I can't narrow down the line where it happens is that the program continues executing after the black screen, and therefore if I sprinkle print or log statements throughout the script, they will happily keep on printing long after the problem has hit - making it hard to tell where it actually occurred. On the other hand if I could dump those messages into KSP.log instead, then I could correlate where the messages are telling me I am within my script with where KSP.log starts spewing the other errors that correspond to the black screen of death. If I had that I could narrow down the offending code to at least which line of the script it is.

[kaesekuchen]

I'm probably just pointing something out that already occured to you, but in the longer run you probably save time and effort if you take the time to setup a dev environment.

Hunting said errors you are already knee deep in that terrain.

With a properly set-up IDE and debug version of KSP you can utilize "autoload" to reduce loadtimes/overhead between iterations and you can use the KSP.IO functionality to create tailor-made debug messages.

If for any reason whatsoever it's not an option for you to install a visual studio express or similar, just disregard this post.

[erendrake]

Thanks guys, you're great! This really needs to be added to the documentation though.

You can check here that this abbreviation is shown nowhere: http://ksp-kos.github.io/KOS_DOC/structure/orbit/

Unless I'm missing some website with key information.

Its a bit of an oversight, The Body and Vessel structures mention how to get their orbits but Orbit doesn't reciprocate Documenting this project is harder than others methinks

[Dunbaratu]

I'm probably just pointing something out that already occured to you, but in the longer run you probably save time and effort if you take the time to setup a dev environment.

Hunting said errors you are already knee deep in that terrain.

Sort of, and sort of not.

I know that every time I write some C code, that the compiler turns that into machine language and runs it that way. But I can debug the C code without having to dig too deeply into the actual low level machine language. There's enough that can be done at the higher level without resorting to that.

I'm not yet convinced that this is really a bug in kOS. It could be a bug in my own script.

Similarly, debugging kosscript shouldn't have to require diving down into the C# code underneath it, especially if one of the goals of kOS is to make it accessible.

Does anyone have good instructions for setting up a mod environment that *isn't* Visual Studio or Visual Studio express?

[CaptainKipard]

... numerical method iteratively...

What does that mean? Not the individual words mind you.

[marianoapp]

I'm not yet convinced that this is really a bug in kOS. It could be a bug in my own script.

You're right, it's a bug in your script

I found that you are calculating the terminal velocity using the ship's pressure sensor, but you don't have any sensor. So the density ends up as zero, the terminal velocity as Infinity and when you pass that to KSP everything crash. Changing the line "lock dense to ship:sensors:pres * atmToDens." to "set dense to 1." everything works, well, until some bug in the staging code make the rocket fail in a spectacular way

We'll have to add some code to sanitize what kOS sends to KSP to avoid this kind of problems in the future.

[Dunbaratu]

What does that mean? Not the individual words mind you.

Have you had calculus? If so there's a really good example of this sort of thing I can use. Imagine that you're trying to graph the derivative of a function. The definition of a derivative is a graph of the rate of change (slope) at each individual point along the original parent function. Now, a lot of the early coursework in a calculus class involves starting from the approximation of the slope, (y2-y1) / (x2-x1), for points 1 and 2 that are very close together, and then working out what the limit of that approximation becomes as the interval gap gets closer and closer to zero. You work out how this functions for basic polynomials, giving the nice rule that for a term Nx^m, the derivative becomes (N*M)x^(m-1). Then you work out how this limit gives an answer for other things, exponential functions, trig functions, and so on.

So after a while you've built a nice toolbox for "how do I avoid having to do the ugly limit math each time by instead using one of the previously solved cookie-cutter formulas in my derivative-making toolbox".

Then you do the same thing in the opposite direction and build a similar toolbox of integral-making tools using previously solved stock integral formulas.

But regardless of the usefulness of those tools, you still have the original definition to fall back on if faced with an ugly function that you don't have the tools for. If you come across something you haven't solved before you can still resort to taking the limit of the change as the delta-X approaches zero for derivatives, or the limit of the sum of the area under the curve by rectangular slices when trying to solve an integral.

It's resorting to those types of ugly methods that the phrase "numerical method iteratively" meant. It's a term for what to do when you don't have a nice clean mathematical function for an answer, and instead you have to cut something into finite chunks and sum the finite chunks, for some small enough finite sized chunks that give you a precision you consider acceptable.

Another example of the same sort of thing is when you don't know the *exact* function but can approximate it by executing a series for a lot of iterations, like finding the value of pi that way, or calculating the natural log of something that way.

A lot of the math of spaceflight ends up being that sort of messy thing, which is why the advent of computers was so important to spaceflight. A computer that can execute iterations quickly can make a numerical method solution into something almost as good as having the actual precise analytical answer.

[Dunbaratu]

You're right, it's a bug in your script

I found that you are calculating the terminal velocity using the ship's pressure sensor, but you don't have any sensor. So the density ends up as zero, the terminal velocity as Infinity and when you pass that to KSP everything crash. Changing the line "lock dense to ship:sensors:pres * atmToDens." to "set dense to 1." everything works, well, until some bug in the staging code make the rocket fail in a spectacular way

We'll have to add some code to sanitize what kOS sends to KSP to avoid this kind of problems in the future.

Ah thank you. That explains it.

However, I *swear* I remember seeing this script give a terminal velocity of Infinity before, for exactly the reason you cite of there not being a barometer, or because I used it on The Mun where the density is supposed to be zero, and having it display the string "Infinity" for the terminal velocity right there in the little display box my script uses, and that this did not break KSP before in the past.

I need to see what exactly it's "passing" to KSP in this case. Having an air density of zero and a terminal velocity of infinity used to be just fine in the script. It just uses these numbers to decide where to set the throttle so as not to exceed terminal velocity, and it uses them to decide how high to start the gravity turn. In the case where it thought the density was zero and the terminal velocity was infinity, that would just mean it would start the gravity turn immediately instead of going straight up for a while, and it would never throttle back to less than 100%. Neither of those two effects used to cause KSP to go black-screen like that. They *did* cause bad piloting when trying to liftoff from Kerbin, but not bugs that broke KSP. (And it was normal and correct behavior when lifting off from a body with no atmosphere, so I repeatedly flew with infinity term vel and zero density and it was fine because this script also took off from places like the Mun.).

I'll have to examine exactly what is breaking and see if I can narrow it down. It's got to have something to do with one of those numbers getting passed to KSP in a way that the older versions of kOS didn't. But thank you for taking the time to look at it. Now I can take over the debugging from there.