[1.3] kOS Scriptable Autopilot System v1.1.3.0

[damerell]

I believe he is referring to something similar to Console.ReadLine() in C#, or cin >> in C++,

You don't say.

which is a feature unfortunately lacking in kOS.

I feared so.

[Dunbaratu]

I believe he is referring to something similar to Console.ReadLine() in C#, or cin >> in C++, which is a feature unfortunately lacking in kOS.

It keeps getting put off because a prerequisite is to first provide users with proper string manipulations (length, substrings, check for isdigit(), etc) they can use in their scripts, and that kept getting pushed back. Without proper string manipulation, reading raw input is often useless (no way to go from the string "10000" to the number ten thousand that you can perform math operations on).

String operations are planned for kOS 0.18.0. Depending on how fast they are to implement, maybe user input too, but it's more likely that user input ends up coming out after that. Because once you open up user input, detecting bogus input and reacting to it is one of those things that explodes code size and turns simple things into a mess of exception cases, we'd like to give nice wrappers around all that to keep kOS having the sort of "newbie-friendly" feel it has now. We get lots of users saying they've never programmed before but they picked up kOS to give it a go. We want to keep it accessible for them. We've been throwing around the idea of having one single kOS command that can specify an input field and just tell kOS something like "this needs to be an integer between 1 and 100 please" and having kOS deal with the mess of enforcing that. This is all still pie-in-the-sky talk so don't take this as a promise.

Edited July 7, 2015 by Steven Mading

[Qigon]

We've been throwing around the idea of having one single kOS command that can specify an input field and just tell kOS something like "this needs to be an integer between 1 and 100 please" and having kOS deal with the mess of enforcing that. This is all still pie-in-the-sky talk so don't take this as a promise.

Sounds very useful and also very cool!

Can you add one more thing to the wish list? Some basic handle of units, like time and distance. So you'd say set t to 10000 and it'd print 5 days, or 10km, or 10.000 etc etc. And a very small number would print as 2.36/100.000 etc etc. Maybe it could be called pretty print.

[ABZB]

I would really like the ability to request user input via command line - for example, in my launch script, I would like to be able to set the acceleration that I want to maintain, or alter the steepness of the launch profile, without having to open the file and re-set the variables each time.

[VFB1210]

keep kOS having the sort of "newbie-friendly" feel it has now. We get lots of users saying they've never programmed before but they picked up kOS to give it a go. We want to keep it accessible for them.

And I have to say, as much as I appreciate this sentiment and commend you for the effort you've gone through to make everything accessible to people new to programming, sometimes I find myself wishing there were an alternative available that used somewhat higher-level syntax. (and I don't mean that in the computational sense, just something like more like "private foo = number;" instead of "LOCAL foo IS number.") Hell, if I were good enough at programming, I'd even start poking around under the hood and seeing what it might take to get a kOS-like mod that used straight C#. (Or, at the very least, something very close to it.) Unfortunately, I lack the knowledge and skills to even be able to determine whether or not that is actually feasible, much less execute it.

I would really like the ability to request user input via command line - for example, in my launch script, I would like to be able to set the acceleration that I want to maintain, or alter the steepness of the launch profile, without having to open the file and re-set the variables each time.

There are actually a couple of ways you could accomplish this. You could set all or some of those variables as parameters and then pass them as inputs to the program when it is run. For example:

//myLaunchProgram.ks

PARAMETER inclination
PARAMETER periapsis
PARAMETER apoapsis
...etc.

//programmy stuff

and then do:

RUN myLaunchProgram(45,100,250). //45 degree inclination, 100km periapsis, 250km apoapsis.

Or, if you have a second monitor like I do, you can keep the script open in a text editor on your second panel, (scripts stored in kOS's archive are in Kerbal Space Program/Ships/Script) run your program, watch your rocket explode, tweak some stuff in the text editor, CTRL+S, then reload your rocket and do

COPY myLaunchProgram.ks FROM ARCHIVE.
RUN myLaunchProgram.ks.

Edited July 8, 2015 by VFB1210

[Dunbaratu]

And I have to say, as much as I appreciate this sentiment and commend you for the effort you've gone through to make everything accessible to people new to programming, sometimes I find myself wishing there were an alternative available that used somewhat higher-level syntax. (and I don't mean that in the computational sense, just something like more like "private foo = number;" instead of "LOCAL foo IS number.") Hell, if I were good enough at programming, I'd even start poking around under the hood and seeing what it might take to get a kOS-like mod that used straight C#. (Or, at the very least, something very close to it.) Unfortunately, I lack the knowledge and skills to even be able to determine whether or not that is actually feasible, much less execute it.

There already exists a kOS-like system that lets you write an autopilot directly in C#.

It's called Stock KSP.

This is why it's unlikely that C# would ever be supported by kOS. It would be a sort of large effort to get you something a bit similar to what you already can do today by writing your own mod.

I really feel that this next point needs to be in a FAQ:

People often operate under the misconception that kerboscript is hindering kOS. It's exactly the other way around. kOS is hindering kerboscript. As the underlying VM becomes more capable, those capabilites get exposed by adding them to kerboscript. If the language is missing a feature, it's because the VM is missing it.

For example, right now the VM can't store the notion of a user-defined struct. That also limits user-defined OOP things like classes and methods. Again, the VM causes this, and kerboscript follows suit.

Kerboscript is not the cause of the limitations. It's the *effect* of them.

Edited July 8, 2015 by Steven Mading

[VFB1210]

People often operate under the misconception that kerboscript is hindering kOS. It's exactly the other way around. kOS is hindering kerboscript. As the underlying VM becomes more capable, those capabilites get exposed by adding them to kerboscript. If the language is missing a feature, it's because the VM is missing it.

For example, right now the VM can't store the notion of a user-defined struct. That also limits user-defined OOP things like classes and methods. Again, the VM causes this, and kerboscript follows suit.

Kerboscript is not the cause of the limitations. It's the *effect* of them.

Please don't get me wrong, I absolutely understand that, and I was in no way trying to say that kerboscript is holding the mod back. While I don't posses the programming skills to produce anything like kOS, I do know enough to know that is a massive undertaking, and that even though this mod has matured for a quite a long time already, it needs more time to become more well rounded and full-featured.

It's just that programming in kerboscript can sometimes feel...I'm not exactly sure how to describe it; maybe a little juvenile? That sort of gets the sentiment across but sounds much more derogatory than I actually feel about it. And I'd like to reiterate that I understand kerboscript's purpose and appreciate all of the work you've done to make it so accessible. Without that accessibility the mod may not have garnered much support, without much support it probably wouldn't have been picked up by two new authors who have improved the mod so much, and I would be without a mod that I very much enjoy.

It's just that part of me feels like something more C#/C++ like wouldn't have been too difficult for a complete noob to get used to. A good example to look at would be the Expression2 system from the Garry's Mod mod WireMod (say that 5 times fast!). Very similar premise to kOS, but is coded in a syntax very much like C++ (though it is distinctly its own--it isn't actually C++). Despite that, new users without programming experience had little or no trouble picking it up.

I'm not sure why I'm saying all this though, it's not like I'm entitled enough to think that such a large feature of the mod should be changed because I want it to scratch my "I feel smart." itch a little better. And to be perfectly honest, I would 100% rather keep kOS with all of its current features and kerboscript, rather than ditch kerboscript and lose features until they can be put back in with a new language.

[Dunbaratu]

I'm not sure why I'm saying all this though, it's not like I'm entitled enough to think that such a large feature of the mod should be changed because I want it to scratch my "I feel smart." itch a little better. And to be perfectly honest, I would 100% rather keep kOS with all of its current features and kerboscript, rather than ditch kerboscript and lose features until they can be put back in with a new language.

I'm not entirely happy with the syntax decisions made early in Kerboscript by others (the dot to end commands was not entirely constructed correctly in the BNF grammar, where it should have been defined as a separator between statements. Instead it was defined as a PART of each of the statements, making it necessary to include it even in the midst of other expressions such as the new FROM loop). But despite being a bit weird, I sort of dislike drastic alterations in a language more than I do the weirdness of Kerboscript. I don't want it to become like Perl, where it's nearly unreadable because there's 4 or 5 different valid syntax expressions that all mean the same thing. It makes it more likely that when reading someone else's code, you'll encounter a syntax construct they used that is totally baffling and alien to you despite having used the language a lot.

Basically, when the VM gets a new feature that allows a new expansion to kerboscript, I tend to prefer sticking to the look and feel of existing kerboscript as being more important than doing things the way I'm used to from other languages. Thus why you initialize new variables with a word ("is") rather than an equals sign.

Also, note that in the languages where you can use equals '=' for assignment, they almost always also demand that you use double-equals '==' for boolean checks. This isn't a coincidence. It's because these languages will sometimes allow assignment to also return a value (allowing you do do things like x = y = z = 1 to assign 3 variables at once) and therefore assignment statements are themselves also expressions. Since you can plug them both into the same place in the syntax, the compiler needs a way to differentiate which you meant. i.e. in C, "if( x = 1 )" always is true, because it only uses one equals sign, it's *assigning* x to 1, not comparing it to 1, and then returning from that the value assigned (the 1), which is always true. I'd rather keep kOS free of that sort of gotcha for the new programmers.

In order to continue to use the single-equals '=' for comparison, it makes sense to keep using words for assignment, for now, just to help the compiler easily differentiate them. And lets face it, using '=' for assignment isn't technically mathematically correct. It's just that we programmers have gotten used to the convention. (It's the reason older versions of BASIC used to require the word LET, as in LET X = 1, rather than just X = 1. It was to keep from rubbing the mathematicians the wrong way, back in the day when computer programming wasn't a separate profession unto itself, and most programmers were mathematicians first, and programmers second.)

[ABZB]

There are actually a couple of ways you could accomplish this. You could set all or some of those variables as parameters and then pass them as inputs to the program when it is run. For example:

//myLaunchProgram.ks

PARAMETER inclination
PARAMETER periapsis
PARAMETER apoapsis
...etc.

//programmy stuff

and then do:

RUN myLaunchProgram(45,100,250). //45 degree inclination, 100km periapsis, 250km apoapsis.

Or, if you have a second monitor like I do, you can keep the script open in a text editor on your second panel, (scripts stored in kOS's archive are in Kerbal Space Program/Ships/Script) run your program, watch your rocket explode, tweak some stuff in the text editor, CTRL+S, then reload your rocket and do

COPY myLaunchProgram.ks FROM ARCHIVE.
RUN myLaunchProgram.ks.

That's funny - I do the latter, myself (I prefer to have GoT or a nice game of Yugioh up in the other screen, though (Card games in SPACE)). I must have missed the PARAMETER thing - Thanks!

[VFB1210]

^I'm the same way, I usually have Netflix on while I'm messing around. Usually my setup is KSP on the main monitor in -popupwindow mode, Visual Studio on my portrait screen, and then my phone plugged into my line in with Futurama playing. Oversaturation of media? Pft.

Now in a vein actually related to kOS as it is, is it possible to pass variables around multiple scripts running on multiple processors? For instance, if I have a seperate processor that controls only the engine gimbal/throttle etc, could I pass things like throttle and steering information from a different kOS processing unit into that processor to keep guidance scripts clutter-free usable on different rockets, without LOCK STEERING shaking the rocket to pieces whenever SAS is not engaged.

[ABZB]

KOS:

We heard you like crashing, so we put a computer in your rocket, so you can crash while you crash

[damerell]

(It's the reason older versions of BASIC used to require the word LET, as in LET X = 1, rather than just X = 1. It was to keep from rubbing the mathematicians the wrong way, back in the day when computer programming wasn't a separate profession unto itself, and most programmers were mathematicians first, and programmers second.)

BBC BASIC did not, thankfully - but as someone who wrote BASIC in the 8-bit micro days, kerboscript is kind of comforting and familiar.

[Dunbaratu]

^I'm the same way, I usually have Netflix on while I'm messing around. Usually my setup is KSP on the main monitor in -popupwindow mode, Visual Studio on my portrait screen, and then my phone plugged into my line in with Futurama playing. Oversaturation of media? Pft.

Now in a vein actually related to kOS as it is, is it possible to pass variables around multiple scripts running on multiple processors? For instance, if I have a seperate processor that controls only the engine gimbal/throttle etc, could I pass things like throttle and steering information from a different kOS processing unit into that processor to keep guidance scripts clutter-free usable on different rockets, without LOCK STEERING shaking the rocket to pieces whenever SAS is not engaged.

I'd like there to exist some sort of API to let kOS cores talk to other kOS cores, with a simplified message queue (as in SET MSG TO GETMESSAGE(). PRINT MSG:TIMESTAMP + ", " + MSG:SOURCE + ", " + MSG:DATA. // prints something like 9132, VESSEL("ship A"), 3 to mean "ship A sent you a '3' at time 9132 seconds".)

But that sort of thing doesn't exist yet.

[VFB1210]

^That could be interesting, but I was more or less talking about a variable scope one step above global. Maybe SHARED or UNIVERSAL? I'd probably go with SHARED, and only allow processors to access shared variables when they are within a certain distance of the core they were declared on. Perhaps even allow antennas to increase this distance.

[baloan]

When I have a file foo.ks with

function aponode {
}.

function exenode {
}.

how do I access those functions from mission.ks?

aponode().
exenode().

[VFB1210]

Well, for one, those functions have nothing in them, and two, they need to be declared in every program you want to use them in. You call them just like you showed, using apnode() and exnode().

[Dunbaratu]

Well, for one, those functions have nothing in them, and two, they need to be declared in every program you want to use them in.

Correction: They need to be RUN in every program you want to use them in. Not declared. The system is designed to allow you to have KS files that are effectively just libraries used by other programs.

// This is the body of a file called mylib.ks:

function halfOf {
    declare parameter x.
    return (0.5)*x.
}.
function setmessage {
    declare parameter msg.
    print "                                               " at (0,5).
    print msg at (0,5).
}

// this is some other program, myprog.ks, that runs functions in mylib.ks

print "loading libraries".
run mylib.
print "library loaded".
setMessage( "half of 7 is " + halfOf(7) ). // example using the library.

The functions in mylib.ks don't need to be declared inside myprog.ks to be run from myprog.ks. myprog.ks just has to run mylib.ks first at the top, and from then on it has the functions of mylib.ks in its memory.

[damerell]

When I have a file foo.ks with

You "run foo.ks." in mission.ks before invoking those functions.

This is made clear by the kOS standard library. If you're anything like me, you are now saying "wait, there's a standard library??"

There is, it's at https://github.com/KSP-KOS/KSLib and jolly useful, it's also quite well hidden or perhaps I'm just oblivious.

[VFB1210]

Well I'll be damned. Awesome to know!

[Tafen]

I'm trying to make an automated rover, but i want to use biomes instead of cordinates. So heres my question: Is there a command that relates to which biome one's in? so that i can just write something like "if enters a new biome, then deploy/stop or something something" (not valid code speak back there, but you understand xD).

[MAV3RICK]

Is there some way of using the Kerbal Engineer redux values in kOS? I'm wondering if there's a way to limit throttle on launch so that atmospheric efficiency is no greater than 100%

[thegreatgonz]

Is there some way of using the Kerbal Engineer redux values in kOS? I'm wondering if there's a way to limit throttle on launch so that atmospheric efficiency is no greater than 100%

1. There's no way to access KER from kOS, as far as I know.

2. In older versions of kOS, you could compute atmospheric efficiency easily: there was a function to get terminal velocity, and atmospheric efficiency is just the ratio of your velocity to terminal velocity. That function has been removed from kOS, but that's because...

3. With the new aerodynamics model in KSP 1.0, terminal velocity is much harder to compute. I don't think KER is actually doing that; my hunch is it's just using the old model even though it no longer applies.

4. I've heard that 100% atmospheric efficiency is no longer a good rule of thumb for setting your launch velocity anyway.

[MAV3RICK]

Ah, ok. Thanks for the reply anyway.

[TDW]

Is there some way of using the Kerbal Engineer redux values in kOS? I'm wondering if there's a way to limit throttle on launch so that atmospheric efficiency is no greater than 100%

There is a way to get a combined value for drag and lift.

You use:

total force = mass * acceleration

total force = engine thrust + force due to gravity + lift&drag

this gives

lift&drag = mass * (acceleration - gravity) - thrust

It requires the use of an accelerometer for the acceleration as i don't think kOS will let you get the acceleration without one.

But it should work.

(am trying to put together a lib file for it now)

Edit: if drag is assumed to be along the retrograde vector then lift and drag can be split up as well with the lift component being at right angles to the direction of travel.

Edit2: it should be noted that this method can only be used on the fly and not for predictive calculations.

Edited July 12, 2015 by TDW

[Qigon]

There is a way to get a combined value for drag and lift.

You use:

total force = mass * acceleration

total force = engine thrust + force due to gravity + lift&drag

this gives

lift&drag = mass * (acceleration - gravity) - thrust

It requires the use of an accelerometer for the acceleration as i don't think kOS will let you get the acceleration without one.

But it should work.

(am trying to put together a lib file for it now)

Edit: if drag is assumed to be along the retrograde vector then lift and drag can be split up as well with the lift component being at right angles to the direction of travel.

Edit2: it should be noted that this method can only be used on the fly and not for predictive calculations.

Nice. I'd love to give that a try anytime. Anyway, a rough estimation will be more than enough for me.

BTW is thrust a vector?