kOS Scriptable Autopilot System 0.9

[Dunbaratu]

Also, I've noticed that a lot of the code that gets written into the code base by people other than Kevin never see the light of day during release. Someone wrote the original Sensor Reporter code into the code base a while back (it wasn't me, and no one asked me), but it hasn't appeared in any releases.

I fear that Kevin's absence may trigger people to sacrifice good design for practicality in the face of the current situation, and have them put more and more stuff into "side" mods for KSP that really belong in the main stock thing.

[woodywood245]

I fear that Kevin's absence may trigger people to sacrifice good design for practicality in the face of the current situation, and have them put more and more stuff into "side" mods for KSP that really belong in the main stock thing.

During the 0.8x debacle, I seriously considered writing a competitor to kOS that was compatible with the kOS language, but had features that kOS lacked, had a simpler architecture with well-documented code, and actually worked. I have some experience writing scripting engines, so I figured it probably wouldn't be too terribly difficult as long as I could learn enough of the KSP API. I had even begun working on it, and got a good way in before 0.9 was released. Since the 0.9 release, I stopped working on it, but I am always ready to pick it up again when the mood strikes me because I documented almost everything I did.

I love kOS, but there are times (especially when I'm looking at the source code), that the plugin makes me cringe. Examples: zero-based line numbers on error messages, lack of user-space exception handling, and the often-vague error messages that occur. And that's just a handful of things I would change.

I momentarily thought about trying to fix the problems in kOS during the 0.8x thing, but the architecture is so complicated and full of anti-patterns that I'm not sure it's worth the effort.

[Dunbaratu]

I love kOS, but there are times (especially when I'm looking at the source code), that the plugin makes me cringe. Examples: zero-based line numbers on error messages, lack of user-space exception handling, and the often-vague error messages that occur. And that's just a handful of things I would change.

I momentarily thought about trying to fix the problems in kOS during the 0.8x thing, but the architecture is so complicated and full of anti-patterns that I'm not sure it's worth the effort.

As a long-time programmer, zero-based anything doesn't bother me at all. It's less intuitive to the new programmer, but in the long run it's usually mathematically cleaner to count starting at zero, which is why languages tend to do it a lot. They're mimicking the language of mathematics when they do that.

That being said, the problem isn't that the line numbers start at zero. The problem is that even compensating for that they're still wrong most of the time. They're wrong for two reasons:

1 - They only report based on counting from the start of the current context (sub-body of code, like if conditions, loop bodies, etc).

2 - They CLAIM to be counting lines when they're actually counting statements. That's very different if you have more than one statement on the same line, or blank lines of padding, or comment lines.

3 - Whenever a C# exception is raised the flagrant error will never report where it happened - always saying zero.

Those are bigger problems. The fact that it starts at zero is rather minor in comparison to those problems. In fact starting at zero is only a problem due to a fact entirely external to kOS itself - that is the fact that text editors usually start at 1.

I'd much prefer it if kOS continued to *internally* count from zero but then just added 1 when reporting the error message.

I looked at the github code but was reluctant to jump in because C# is new to me and I don't actually like it much compared to other languages. I did just a little one tiny thing - making it so you don't have to manually say "switch to ..." when it first starts (you used to have to because the mod would start up with no selected volume yet and many file operations would error out as a result). Now I'm reluctant to jump in purely because of the current highly forked nature of the code. Without someone to make leadership decisions about what pull requests are in and which are out, it's becoming a forest of *different* mods rather than one mod. So it's not a good time for a newcomer to start getting involved in it until something is done that unifies it again.

One thing I would like to do is to implement a database of queryable body data. I assume the API knows things the Wiki doesn't - like the SOI radius of bodies.

Edited December 10, 2013 by Steven Mading

[woodywood245]

As a long-time programmer, zero-based anything doesn't bother me at all. It's less intuitive to the new programmer, but in the long run it's usually mathematically cleaner to count starting at zero, which is why languages tend to do it a lot. They're mimicking the language of mathematics when they do that.

That being said, the problem isn't that the line numbers start at zero. The problem is that even compensating for that they're still wrong most of the time. They're wrong for two reasons:

1 - They only report based on counting from the start of the current context (sub-body of code, like if conditions, loop bodies, etc).

2 - They CLAIM to be counting lines when they're actually counting statements. That's very different if you have more than one statement on the same line, or blank lines of padding, or comment lines.

3 - Whenever a C# exception is raised the flagrant error will never report where it happened - always saying zero.

Those are bigger problems. The fact that it starts at zero is rather minor in comparison to those problems. In fact starting at zero is only a problem due to a fact entirely external to kOS itself - that is the fact that text editors usually start at 1.

I'd much prefer it if kOS continued to *internally* count from zero but then just added 1 when reporting the error message.

I looked at the github code but was reluctant to jump in because C# is new to me and I don't actually like it much compared to other languages. I did just a little one tiny thing - making it so you don't have to manually say "switch to ..." when it first starts (you used to have to because the mod would start up with no selected volume yet and many file operations would error out as a result). Now I'm reluctant to jump in purely because of the current highly forked nature of the code. Without someone to make leadership decisions about what pull requests are in and which are out, it's becoming a forest of *different* mods rather than one mod. So it's not a good time for a newcomer to start getting involved in it until something is done that unifies it again.

One thing I would like to do is to implement a database of queryable body data. I assume the API knows things the Wiki doesn't - like the SOI radius of bodies.

I've noticed the same problems. The zero-based line numbers don't bother me so much as get on my nerves. I guess it's a pet peeve. "Array indices start at zero, line numbers start at 1," is how my brain thinks of it.

I've been using C# as my primary language for a few years now. I switched from VB after I had to use C/C++ and Java in my classes, and I got to the point where I was accidentally writing C-like code in my VB programs.

I'd like to communicate with Kevin before I introduce any code into his code base, because I consider him the lead developer. Until then, I'll just keep adding stuff to my little mod, and taking things out when they appear in kOS.

As far as the SOI of a body, the field sphereOfInfluence is in the CelestialBody class. To get the SOI of the body you're orbiting, you can look at vessel.mainBody.sphereOfInfluence.

[Dunbaratu]

I've noticed the same problems. The zero-based line numbers don't bother me so much as get on my nerves. I guess it's a pet peeve. "Array indices start at zero, line numbers start at 1," is how my brain thinks of it.

I've been using C# as my primary language for a few years now. I switched from VB after I had to use C/C++ and Java in my classes, and I got to the point where I was accidentally writing C-like code in my VB programs.

I'd like to communicate with Kevin before I introduce any code into his code base, because I consider him the lead developer. Until then, I'll just keep adding stuff to my little mod, and taking things out when they appear in kOS.

As far as the SOI of a body, the field sphereOfInfluence is in the CelestialBody class. To get the SOI of the body you're orbiting, you can look at vessel.mainBody.sphereOfInfluence.

For me it's more because I keep thinking in Java or C++ instead of in C#. I come from the world of UNIX programming, where C# isn't really used very much because of it being a Microsoft thing.

The other thing I'd like to do besides have a body database is look at all the "can't compare number to number" problems. People have been trying to fix it by making every single number in the mod into a Double, but that seems like its approaching the problem from the wrong end. If the code exists already that translates all numeric types into the word "Number" when reporting them, that seems to indicate the intention to actually support a mixture of numeric types, otherwise that wouldn't be needed. It seems the right response is to add the logic to do type promotion to the expression system.

[adammada]

During the 0.8x debacle, I seriously considered writing a competitor to kOS that was compatible with the kOS language, but had features that kOS lacked, had a simpler architecture with well-documented code, and actually worked. I have some experience writing scripting engines, so I figured it probably wouldn't be too terribly difficult as long as I could learn enough of the KSP API. I had even begun working on it, and got a good way in before 0.9 was released. Since the 0.9 release, I stopped working on it, but I am always ready to pick it up again when the mood strikes me because I documented almost everything I did.

Do it. Seriously. Publish on github, let others contribute. I was thinking about something like "get kOS terminal, and add LUA to it", but LUA is not that friendly, and i'm new to C#. So I just added pull requests to kOS, but Kevin is absent.

KSP API is not that hard, and kOS just uses MechJeb utility functions for few more complex things.

[sarkun]

Maybe Sensor Reporter could be of use

Oooh, that looks awesome! Will try when I get home.

[Radiokopf]

Hi,

i try to recreate the rover tutorial but when i try

abs(target:bearing)

it says "not a number".

target:bearing

works fine. So what am i doing wrong ? or did somethign change since the making of the ideo ?

print ABS(apoapsis).

works for me...

set x to target:bearing.

print abs(x).

works for now... maybe someone can tell my why

so...

set x to 1.

if x = 1 (print "true".).

does not work.. i dont get this..

Edited December 10, 2013 by Radiokopf

[John FX]

I have found that trying to use "revert flight" too many times with KOS enabled can do this (the black death effect). I've had success avoiding it by doing this:

Every time you're about to revert flight, FIRST go into the KOS terminal and give the command "SHUTDOWN.". THEN revert the flight.

There is something the KOS DLL is doing that leaves behind something still running when you revert flight. I'm not sure what it is, but a manual shutdown seems to avoid it.

I have found the cause of my issue. I have narrowed down the point that I lose control as the point when a program is running and I either dock with another craft or select `control from here` on a docking port.

I discovered this when I had a craft made from a command module and a lander that were docked and fully controllable and steering locked to prograde very well and as soon as I selected the docking port of the lander and clicked to `control from here` the craft went into a wild spin and could not be steered with `lock steering to`

Now I can simply not do that and all will be fine (fingers crossed)

[AbeS]

@Radiokopf, the last one should be:

set x to 1.
if x=1 {print "true".}.

{} instead of ()

[XanderTek]

I'm hoping I can get a little debugging help with my first attempt at a kOS script. I wanted to set up some sepratrons to fire just before landing to slow down a vehicle.

wait until verticalspeed<-1 AND ALT:RADAR<15.
stage.
print "Breaking!".
wait until verticalspeed>0.1.
stage.
print "Done!".

The craft contains:

stage 0: decouplers for the sepratrons

stage 1: sepratrons

stage 2: liquid fuel engine (just to get me off the launchpad for testing purposes)

The sepratrons fire when they're supposed to, but they never decouple and burn long enough that the craft starts ascending (positive vertical speed). The program prints "Done!" and finishes, but stage 0 remains untriggered. I can manually trigger stage 0, at which point they do decouple. Any idea why that second "stage" command wouldn't work?

Thanks!

[woodywood245]

The other thing I'd like to do besides have a body database is look at all the "can't compare number to number" problems. People have been trying to fix it by making every single number in the mod into a Double, but that seems like its approaching the problem from the wrong end. If the code exists already that translates all numeric types into the word "Number" when reporting them, that seems to indicate the intention to actually support a mixture of numeric types, otherwise that wouldn't be needed. It seems the right response is to add the logic to do type promotion to the expression system.

I can't be sure, but I think a lot of the comparison problems stem from the fact that the "var" type is used far too often. Ever since var was introduced in C#, people have been going crazy with it. C# is generally a strongly-typed language, which can do some limited implicit casting (about as much as C/C++ can). The var keyword breaks that, and when you use it for things it wasn't intended for (var was designed for implicit type assignment from LINQ statements, where you may not always know the output type), it can really mess things up.

[woodywood245]

I'm hoping I can get a little debugging help with my first attempt at a kOS script. I wanted to set up some sepratrons to fire just before landing to slow down a vehicle.

wait until verticalspeed<-1 AND ALT:RADAR<15.
stage.
print "Breaking!".
wait until verticalspeed>0.1.
stage.
print "Done!".

The craft contains:

stage 0: decouplers for the sepratrons

stage 1: sepratrons

stage 2: liquid fuel engine (just to get me off the launchpad for testing purposes)

The sepratrons fire when they're supposed to, but they never decouple and burn long enough that the craft starts ascending (positive vertical speed). The program prints "Done!" and finishes, but stage 0 remains untriggered. I can manually trigger stage 0, at which point they do decouple. Any idea why that second "stage" command wouldn't work?

Thanks!

I'm not sure what the cause of this is, but some operations won't finish before the program ends. The bandaid I use is to tack on a "wait 1." at the end of the program.

[Dunbaratu]

I'm hoping I can get a little debugging help with my first attempt at a kOS script. I wanted to set up some sepratrons to fire just before landing to slow down a vehicle.

wait until verticalspeed<-1 AND ALT:RADAR<15.
stage.
print "Breaking!".
wait until verticalspeed>0.1.
stage.
print "Done!".

The craft contains:

stage 0: decouplers for the sepratrons

stage 1: sepratrons

stage 2: liquid fuel engine (just to get me off the launchpad for testing purposes)

The sepratrons fire when they're supposed to, but they never decouple and burn long enough that the craft starts ascending (positive vertical speed). The program prints "Done!" and finishes, but stage 0 remains untriggered. I can manually trigger stage 0, at which point they do decouple. Any idea why that second "stage" command wouldn't work?

Thanks!

Can you hear a second "click" right after the first stage? If so then it did try to do it but KSP doesn't allow staging too quickly. I've had a hard time trying to hit "stage" successively less than a second apart sometimes. That's true both in kOS and just flying KSP manually too. If I hit spacebar two times quickly in succession sometimes the second one just goes "click" and doesn't do anything and I have to hit it again.

Here's the sort of logic I tend to use when I stage:

// Put this at the top of the code as a global config setting:
// assumeJustFuel:
//    A lower bound for the amount of mass you expect is a lot
//    smaller than the mass in any of your stages.  If the mass
//    changes by less than this much in the time it takes to run
//    a few statements it is probably just from burning fuel.
//    If it changes by more than this much it's
//    probably because you lost part of the vessel from staging.
set assumeJustFuel to 0.2.

// Then when staging do this:
set prevMass to mass.
until mass < (prevMass-assumeJustFuel) { stage. wait 0.25. }.

Essentially it just does what a human does when playing - hit the spacebar until it seems like a piece of the craft comes off. A human uses eyeballs to detect this, the script uses mass to detect it.

In your case it might be really fiddly to get theassumeJustFuel threshold just right since you're only expecting to lose the mass of sepratrons when you stage and that's a small enough amount that it might be mistaken for fuel loss.

[Dunbaratu]

does not work.. i dont get this..

Often "print" works in places where nothing else does, when it comes to "invalid" types. So you can print a number out just fine but then can't do any math with it or comparisons on it. This is because "print" is a lot more tolerant of any random hodgepodge of object types than the rest of kOS is. One of the ideas that C# copied directly from Java is the idea that any object in the system can implement a "toString" method that returns a string representation of itself and once it does that then it magically "just works" in any context where someone is trying to use it like a string (like when printing it).

[Dunbaratu]

I have found the cause of my issue. I have narrowed down the point that I lose control as the point when a program is running and I either dock with another craft or select `control from here` on a docking port.

I discovered this when I had a craft made from a command module and a lander that were docked and fully controllable and steering locked to prograde very well and as soon as I selected the docking port of the lander and clicked to `control from here` the craft went into a wild spin and could not be steered with `lock steering to`

Now I can simply not do that and all will be fine (fingers crossed)

Okay. I wasn't talking about the difficulties you had with steering when I talked about reverting flight with a kOS unit turned on, by the way - that I don't know what's going on with. I was talking about the black screen of death requiring you to kill KSP and re-run it from scratch. THAT is a thing I only got when reverting flight without shutdown more than a few times and it stopped happening after I got in the habit of always doing a shutdown before reverting.

[XanderTek]

Can you hear a second "click" right after the first stage? If so then it did try to do it but KSP doesn't allow staging too quickly. I've had a hard time trying to hit "stage" successively less than a second apart sometimes. That's true both in kOS and just flying KSP manually too. If I hit spacebar two times quickly in succession sometimes the second one just goes "click" and doesn't do anything and I have to hit it again.

Thanks, that seems to be it. I was hearing the click. Adding a small "wait" between the stages seems to do the trick so far. If the problem comes back, I'll try your approach of repeating stage until something changes.

[Daisai]

I get the error "expression error processing statement", even though when i simply use the exact same command without editing it it does not give this error.

For example when i try to launch a rocket i give the command "TOGGLE AG1"

I am wondering though if its possible to enable a script you made for a vehicle then change to something else and to see it run it anyway ?

Because if thats not possible i don't really see the point in spending to much time on this.

Even when trying the example from your video's it does not work.

Edited December 10, 2013 by Daisai

[Amazingteknique]

Just been getting interested in picking up kOS and checking it out, I have one question about how it plays with remote tech currently before I get too involved. Does the signal have any effect on this at the current moment or is it something you more or less have to pretend.

[woodywood245]

Just been getting interested in picking up kOS and checking it out, I have one question about how it plays with remote tech currently before I get too involved. Does the signal have any effect on this at the current moment or is it something you more or less have to pretend.

kOS is not compatible with RemoteTech at the moment, unfortunately.

[John FX]

Okay. I wasn't talking about the difficulties you had with steering when I talked about reverting flight with a kOS unit turned on, by the way - that I don't know what's going on with. I was talking about the black screen of death requiring you to kill KSP and re-run it from scratch. THAT is a thing I only got when reverting flight without shutdown more than a few times and it stopped happening after I got in the habit of always doing a shutdown before reverting.

You are completely right, I was suffering two different `features`. I have done some testing and locked it down as it seemed a bit random. KOS freaks out if you have a craft being controlled from (only tested this one pod) the three man pod and then you select a docking port and `control from here`. At this point KOS loses the ability to tell the facing of your craft permanently.

EDIT: Until you reselect the 3 man pod and `control from here` at which point the craft becomes completely controllable again!

OK, at least I know what to do about that happening and why it happens. Now I just need to figure out a way of landing my lander as that pretty much needs to be controlled from a docking port... (might put an octo core somewhere hidden...)

Edited December 11, 2013 by John FX

[Camacha]

There are a lot of things I've written that I'd love to see integrated directly into kOS (most of it being in the kOSExtensions portion of Sensor Reporter), and a few ideas I can't implement without changing the kOS source

I like what I am hearing.

Although I really like Kevin's approach and way of handling things, I am kind of relieved that someone might be interested in taking over when push comes to shove. Someone that seems capable to, that is

I love kOS, but there are times (especially when I'm looking at the source code), that the plugin makes me cringe. Examples: zero-based line numbers on error messages, lack of user-space exception handling, and the often-vague error messages that occur. And that's just a handful of things I would change.

Let us not forget that it is very much a work in progress Although I am in a different line of work, my early constructs are often horrible when looking at it from a finished product point of view. I mean, even a lot of KSP is or has been a placeholder for a long time.

And of course people have different styles and opinions on how things should be done and what is important. I think this is very true for programming.

One thing I would like to do is to implement a database of queryable body data. I assume the API knows things the Wiki doesn't - like the SOI radius of bodies.

I do not think this would be a good thing. In general, it seems fair to only include things that could be queried in real life. If you want to have the SOI radius, there is no way a program could know, other than humans telling it that information. That is perfectly feasible right now, as you can make data files to access when needed.

I also believe that is the direction Kevin is heading, as he has implemented quite some things that do not make life easy, but do make sense from a discrete computer in a world point of view.

Edited December 11, 2013 by Camacha

[adammada]

If you want to have the SOI radius, there is no way a program could know, other than humans telling it that information. That is perfectly feasible right now, as you can make data files to access when needed.

There is diffecence between making things too easy and making them just annoying. As you just laid out - player just needs to write script with values from KSP wiki.Its not an achievment to do such script. Its just plain annoying that it has to be done.

If we want realism there should not be "lock steering to..." function, because that makes everything too easy, and writing own good "autopilot" would be achievment.

[Camacha]

There is diffecence between making things too easy and making them just annoying. As you just laid out - player just needs to write script with values from KSP wiki.Its not an achievment to do such script. Its just plain annoying that it has to be done.

I think mods should mainly stick to their core values, which in this case means not providing any magic values. If someone wants to add them through a mod or by having a ready made community script, sure, why not? But other than that it really breaks the intention of the mod and the fourth wall of the game. I also would like to contend that implementing an efficient database is no challenge.

Part of the game (for me) is launching probes and sounding rockets to find these things out

If we want realism there should not be "lock steering to..." function, because that makes everything too easy, and writing own good "autopilot" would be achievment.

I do agree on this one. Using the lock command does feel like cheating at times, but in absence of direct input commands using it is inevitable in a lot of cases. Though I am certainly working on a more involved script that takes care of everything itself.

[adammada]

I think mods should mainly stick to their core values, which in this case means not providing any magic values. If someone wants to add them through a mod or by having a ready made community script, sure, why not? But other than that it really breaks the intention of the mod and the fourth wall of the game.

I don't understand why it "breaks the intention of the mod". This mod already has built-in body database. After typing ship:body you will probably get "Kerbin". You can get Kerbin mass. You can even get kerbin radious by doing some count (Kerbin:position:mag - altitude).

So its just being annoying that you have Kerbin:mass and don't have Kerbin:radious and few other body parameters.