kOS Scriptable Autopilot System 0.9

[Dunbaratu]

Im assuming this doesnt do orbit calculations automatically? Like, i cant say "transit duna" and it works that out? I assume ive got to do my own math and work out my own thrust points?

Correct. That's why I like the idea of this over using mechjeb. Mechjeb is somebody ELSE's autopilot that just works out of the box. With this I make my own autopilot, and my own mistakes.

But that being said, it's still got a ways to go before it's really practical to be able to do that stuff yet. Not quite enough information is exposed to the player writing a KOS script to be able to do all those math operations. But it looks like it's getting there, and it's gotten popular enough that there's now more than just one person helping edit the code for it on the GitHub archive.

To give an example of how there's not quite enough information yet: you can't query to find the position of the planets. So there's not any way to calculate when to make your burn if you want to, for example, go to Duna.

[check]

Has anyone been able to get the facing command to work properly? Because I can't find a way to pull my attitude. The numbers in 'facing' don't make sense.

up:pitch, up:roll, up:yaw does not make sense...

At least not for aircraft.

[Dunbaratu]

The only problem is that you have to delete the file for each edit and you cant read the file either.

No, you don't *have* to delete the file after each edit. You *may* delete the file if it's your intent to start over. But that might not be your intent. So I prefer it how it works now. If you WANT to do just one statement each time by deleting the file each time you can do that. But otherwise you can build a larger program to run by appending many lines to the same file.

On the subject of the self-modifying code use of the logger:

I can think of two practical uses for this. It's not just a silly toy example for the heck of it:

Useful Thing 1: Running a variable program name: The self-modifying code gives you the ability to make a hardcoded part of the syntax that wasn't designed to use a variable capable of doing so anyway. For example, normally you can't run a program whose name is stored in a variable. But with self-modifying code you could.

// This section of code simulates contacting home base and asking them to transmit the stats about the body I'm orbiting:
// OLD WAY YOU HAD TO DO IT:
if body = "Kerbin" {
  copy KerbinStats from archive.
  run KerbinStats.
}.
if body = "Mun" {
  copy MunStats from archive.
  run MunnStats.
}.
if body = "Minmus" {
  copy MinmusStats from archive.
  run MinmusStats. 
}.
if body = "Duna" {
  copy DunaStats from archive.
  run DunaStats. 
}.
// ... etc ... with an entry for all the bodies in the game.

// The NEW way with self-modifying code:
delete getStats.
set cmd to "copy " + body + "Stats from archive.".
log cmd to getStats.
set cmd to "run " + body + "Stats.".
log cmd to getStats.
run getStats.

Useful thing 2: Giving data or setting communication signal flags for another SCS module on another craft to see:

Imagine that two craft are working together to do a thing (docking?), and craft 1 needs to tell craft 2 when it's ready for craft2 to start running its code.

Since SCS modules can't talk to each other directly unless they're on the same ship and can see each others hard drives, we use the archive as a stand-in for the idea of radio communication between the two craft. (craft 1 signals the archive, and craft 2 queries the archive. Imagine that this is like them talking to each other directly.)

So imagine a signal flag called comFlag with these 3 values:

0 = wait for it....

1 = Please do your thing.

2 = I acknowledge that I got your signal.

There is a file on the archive called "signal" that just has this one line:

set comFlag to 0.

.

The code for craft 1 does this:

// At the point this code is ready to tell craft 2 that it's done, it runs this:
switch to archive.
log "set comFlag to 1." to signal.
switch to 1.

The code for craft 2 has this polling loop in it:

switch to archive.
set comFlag to -999.
while comFlag < 1 {
  run signal.
}.
log "set comFlag to 2." to signal.
switch to 1.
// Do its thing.

Now of course the file never got deleted, just appended to, so it actually looks like this now:

set comFlag to 0.
set comFlag to 1.
set comFlag to 2.

But only the result of the lastmost line will "stick", overwriting the earlier ones.

At some point when the two programs agree that they're done using the flag file they'll have to delete it so it doesn't keep growing. You might be wondering why I didn't just delete it each time so it only ever has 1 line in it. This is because doing that would only be safe if the two statements "delete singal." and "log ... to signal." could be made into a single atomic operation that can't be interrupted. As long as there is the chance that craft 2 might try to "rum comFlag" just at the very moment that craft1 has just deleted it but hasn't executed the next line to re-write it yet, there's a danger of craft 2's code crashing on the file not found error. Since marking a section for atomic execution is a fairly in-depth programming feature that just doesn't exist in KOSscript and I don't expect it to, I ensure this problem doesn't happen by just making sure I only edit the signal file with one simple statement, which looking at the KOS code I know at least THAT much would be atomic (unlike in a real compiled language where you couldn't even assume a single line of code is atomic, in KOS you can).

Edited September 28, 2013 by Steven Mading

[Dunbaratu]

Has anyone been able to get the facing command to work properly? Because I can't find a way to pull my attitude. The numbers in 'facing' don't make sense.

up:pitch, up:roll, up:yaw does not make sense...

At least not for aircraft.

They don't make sense because they're mis-labeled. They're CALLED yaw pitch and roll which makes you think they'd be related to the aircraft's view of the horizon, but they're not. They're relative to the native XYZ coordinate system of KSP. For example, what's called "yaw" is actually more like longitude (but not zeroed at the same point so it will always be an offset of longitude). A yaw of zero means "I'd be pointing at the center of the sky straight up if I was at the exact spot on my planet that the X axis comes out of the surface." A yaw of 90 means "This is the direction that would be pointed straight up if I was at the spot on the planet where the Z axis comes out of the surface. If that's not where I'm located then that's not true, for example if I'm actually at the spot the X axis comes out, then a yaw of 90 means I'm pointed due east at the horizon".

I spent quite a while working it out by trial and error since KOS hides the real XYZ coordinates it was hard to figure out what the actual coordinate system even is. I put a long winded thing about it on the community wiki.

[Dunbaratu]

It's a pain, but:

In the modifying program:

log "print h + e + l + l + o." to modified.

In the modified program:

set h to "h".

set e to "e".

set l to "l".

set o to "o".

I thought of that. It doesn't work because it merely moves the problem to a new spot. Now instead of the modifying program being unable to print the quotes to build the statement print "hello"., it is now unable to print the quotes to build the statement set h to "h". and set o to "o" and so on.

Besides, if that worked you'd just make one variable to store the dquote instead of a variable for each letter:

set cmd to "print " + dquote + "hello" + dquote + "." .

log cmd to prog.

The real problem is there is NO way to store a quote in a variable in the first place.

Edited September 28, 2013 by Steven Mading

[razark]

I thought of that. It doesn't work because it merely moves the problem to a new spot.

...

The real problem is there is NO way to store a quote in a variable in the first place.

Nope. Look again. The set.. to commands are in the log file you are modifying, so you are never trying to print a quote, you simply append a command that tells it to print a concatenated group of variables. The variables just happen to each contain a string of length 1, so you are building your string without ever using a quote.

Yeah, just tested it.

testmod.txt contains:

log "print h + e + l + l + o." to log.

log.txt contains:

set h to "h".
set e to "e".
set l to "l".
set o to "o".

>run testmod.

<Program ended.

log.txt contains:

set h to "h".
set e to "e".
set l to "l".
set o to "o".

print h + e + l + l + o.

>run log.

<hello

<Program ended.

As I said, it's a pain, but it is doable.

[Dunbaratu]

Nope. Look again. The set.. to commands are in the log file you are modifying, so you are never trying to print a quote, you simply append a command that tells it...

Your second post describes writing the first half of the program statically ahead of time and only writing the latter half of it dynamically. Your first post didn't explicitly mention that this is what you had in mind. Your idea works but only if the dynamic program is going to be run just once and then never again. It doesn't work if you want to write the dynamic code in a loop where it changes each time. To do that you can't just keep appending code. You have to delete and re-create the program from the start, and that means writing half the file ahead of time statically and then writing the other half later dynamically isn't a solution.

Edited September 28, 2013 by Steven Mading

[drtedastro]

@Steven Mading.

Have you uploaded your KoS file for the sky-crane landing from earlier post. I would like to start from back to front as you have. I now have a good rover / crane combo that i want to build on and it will be where code start. I liked your methods used for the landing.. I have several other 'options' that i am interested in trying for the MaxSlope issue prior to touch down. Again, great job.

[Dunbaratu]

@Steven Mading.

Have you uploaded your KoS file for the sky-crane landing from earlier post. I would like to start from back to front as you have. I now have a good rover / crane combo that i want to build on and it will be where code start. I liked your methods used for the landing.. I have several other 'options' that i am interested in trying for the MaxSlope issue prior to touch down. Again, great job.

If you click on the embedded video and go to the Youtube site, the description had the link to it. But here it is again:

http://kos.wikia.com/wiki/Example_-_Descend_Lander/Skycrane

I've read through it again and realized there's some code in there I can delete. It sets a few variables up front that are no longer actually used anymore. They're a holdover from previous versions before KOS supported passing parameters to programs.

[drtedastro]

Thanks, sorry i missed the link. If you have time and want to critique, take a look at

The video sucks, but it was my first. the rover in the vid, compacted, is 5.61 tons and works good. I have the sky-crane for atmospheric and non-atmospheric working just fine... Time for the code...

agian, thanks.

[BGog42]

Another trick you can do with the new logfile feature is to use it to write self-modifying code - because the KOS mod does not differentiate between log files and program scripts. They're all ".txt" files behind the scenes.

HA! I wrote the new log feature. I can't believe I didn't think of this myself. Clearly the next thing I should do is take care of that pesky problem with the quotes.

[Dunbaratu]

Thanks, sorry i missed the link. If you have time and want to critique, take a look at

The video sucks, but it was my first. the rover in the vid, compacted, is 5.61 tons and works good. I have the sky-crane for atmospheric and non-atmospheric working just fine... Time for the code...

agian, thanks.

That looks great. It's a bit annoying that hinged connectors are on the "do not suggest" list because they are so clearly needed to do missions the way real space programs do them. I like this mod. But ... what's the connection to KOS?

[Camacha]

Is it my or are the problems caused by kOS not having a proper parser steadily increasing? I understand that changing this is a pain, but I can not help but feel it is getting in the way of crating the accessible language kOS was supposed to be.

[drtedastro]

That looks great. It's a bit annoying that hinged connectors are on the "do not suggest" list because they are so clearly needed to do missions the way real space programs do them. I like this mod. But ... what's the connection to KOS?

I am working on making some completely autonomous probes / rovers / missions, and only using the 'controls is in Houston' approach. I really like what you have been doing with KoS, as it fits into what i am 'trying' to do. I have been looking forward to a mod such as this since i started KSP, and you have proven that it has the whereforall to do what is needed. Thanks.

[Camacha]

I just realised that kOS combined with controlling Infernal Robotics might do wonders for easily controlled (jet-)VTOL's. Being able to adjust the position of engine pods might overcome the problems with throttle delay typically associated with these types of craft.

I always had a hard time neatly manually controlling any type of rocket or jet powered vertical descent, kOS makes life easier by eliminating pilot error.

[Dunbaratu]

I just realised that kOS combined with controlling Infernal Robotics might do wonders for easily controlled (jet-)VTOL's. Being able to adjust the position of engine pods might overcome the problems with throttle delay typically associated with these types of craft.

I always had a hard time neatly manually controlling any type of rocket or jet powered vertical descent, kOS makes life easier by eliminating pilot error.

But it introduces programmer error instead. Which is basically just pilot error that happened ahead of time. Autopilots are better at having fast reaction times, which gives the quick instant corrections needed for hovering, but its not because of pilot error that autopilots do the job better. It's because the meaty CPU in the pilot's skull has a very slow clock speed and more importantly has a very slow I/O system to receive the data about the state of the craft at any given instant and send commands back to respond to that state. The software running on that slow meaty CPU might be just fine with no errors in it and it still won't be able to do the job very well.

[Dunbaratu]

Is it my or are the problems caused by kOS not having a proper parser steadily increasing? I understand that changing this is a pain, but I can not help but feel it is getting in the way of crating the accessible language kOS was supposed to be.

It's sort of inevitable that they will increase over time. As the language gets more things added to it, the parser complexity grows, to the point where it starts to become harder and harder to maintain a monolithic top-down parser like this. You find that making one change requires making it in 20 different places in order to make the language consistent about the change. Thankfully, from the issues raised on GitHub, I get the impression that the mod author is very aware of this but just doesn't have experience with parser generators and is still feeling the way through the idea. It can be a daunting subject the very first time you write using one, so I don't want to push too hard about making the change. I understand it might take a while for a person doing it for the first time. It's NOT a simple subject and most colleges dedicate an entire semester course to it when they teach it.

Also, I can't complain too loudly about it when I'm not taking the time to teach myself Csharp and .NET to do it myself. I can't really fault someone else for not having time to learn a new tool from scratch when I'm not volunteering to do a similar thing from my end either.

[deadshot462]

I installed 0.65 but can't get it to work.

Is it supposed to go in the "GameData" folder or merged to main folders?

Where do I save the "Archive" folder and the text files?

[yum]

@deadshot462

"\Kerbal Space Program\GameData\kOS"

"\Kerbal Space Program\Plugins\PluginData\Archive"

[KevinLaity]

@deadshot462

"\Kerbal Space Program\GameData\kOS"

"\Kerbal Space Program\Plugins\PluginData\Archive"

Someday I'll get around to putting the archive folder into the new structure

[KevinLaity]

It's sort of inevitable that they will increase over time. As the language gets more things added to it, the parser complexity grows, to the point where it starts to become harder and harder to maintain a monolithic top-down parser like this. You find that making one change requires making it in 20 different places in order to make the language consistent about the change. Thankfully, from the issues raised on GitHub, I get the impression that the mod author is very aware of this but just doesn't have experience with parser generators and is still feeling the way through the idea. It can be a daunting subject the very first time you write using one, so I don't want to push too hard about making the change. I understand it might take a while for a person doing it for the first time. It's NOT a simple subject and most colleges dedicate an entire semester course to it when they teach it.

Also, I can't complain too loudly about it when I'm not taking the time to teach myself Csharp and .NET to do it myself. I can't really fault someone else for not having time to learn a new tool from scratch when I'm not volunteering to do a similar thing from my end either.

I'm taking the first step now toward better parsing by having a special regex builder.

This allows me to take complicated regexes like these

^SOMETHING\(([ :@A-Za-z0-9\.\-\+\*/\"]+),([ :@A-Za-z0-9\.\-\+\*/\"]+),([ :@A-Za-z0-9\.\-\+\*/\"]+)\)$
^PRINT (.+)$
^LOG (.+?) TO (.+?)$

And boil them down to these

SOMETHING_(3)
PRINT *
LOG * TO %

This is not the end of the story, but this will help ensure things like that whitespace is always handled the same way, variables names are always processed using the same rules, etc.

[Dunbaratu]

I'm taking the first step now toward better parsing by having a special regex builder.

This allows me to take complicated regexes like these

^SOMETHING\(([ :@A-Za-z0-9\.\-\+\*/\"]+),([ :@A-Za-z0-9\.\-\+\*/\"]+),([ :@A-Za-z0-9\.\-\+\*/\"]+)\)$
^PRINT (.+)$
^LOG (.+?) TO (.+?)$

And boil them down to these

SOMETHING_(3)
PRINT *
LOG * TO %

This is not the end of the story, but this will help ensure things like that whitespace is always handled the same way, variables names are always processed using the same rules, etc.

That's an excellent approach. It can get a bit confusing at times why expressions that work in one context don't work in another.

[MP X10L]

Ok, after some days of playing around, here are some things I would really love to see:

Logarithm function as well as e-function.

Readout of atmospheric density.

Also I have some trouble when doing calculations with angles.

eg.: arcsin(0.3) + 1

is not possible. Seems that arcsin returns to many digits.

Same for arccos and arctan. They all return 4 digits more.

Sin, cos and tan work.

[Camacha]

But it introduces programmer error instead. Which is basically just pilot error that happened ahead of time.

A program can be perfected to be reliable, whereas even a well trained pilot always leaves room for mistakes

Autopilots are better at having fast reaction times, which gives the quick instant corrections needed for hovering, but its not because of pilot error that autopilots do the job better. It's because the meaty CPU in the pilot's skull has a very slow clock speed and more importantly has a very slow I/O system to receive the data about the state of the craft at any given instant and send commands back to respond to that state. The software running on that slow meaty CPU might be just fine with no errors in it and it still won't be able to do the job very well.

You would be amazed how many complex calculations those 'slow' meaty processors can do. They are incredibly useful when trying to find out how you should perform a certain manoeuvre, as they can not only react quickly to ever changing situations, the brain is also capable of complex problem solving and improvisations. When you know how to do something, however, this complexity sometimes works against you. The same input does not always yield the same result due to a large number of things being estimated and interpreted. A scripted computer does things a lot more linear, which is as much an advantage as a disadvantage, but comes in handy when doing things where the parameters are known.

[Camacha]

I'm taking the first step now toward better parsing by having a special regex builder.

Very nice, I did not expect something like this so soon!

Also, I can't complain too loudly about it when I'm not taking the time to teach myself Csharp and .NET to do it myself. I can't really fault someone else for not having time to learn a new tool from scratch when I'm not volunteering to do a similar thing from my end either.

I never intended to fault anyone (and I think I did not). I just noted a problem, which I feel is part of a constructive environment - even when I am not actively working to fix the problem myself I love the project so far and I think that it can be even more awesome when people keep contributing their input, views and opinons. Kevin has been amazing - looking at what people need and use in their project and implementing it in kOS.

If I only were to talk about problems that I can and will fix myself the world would become a small place - and I guess there would not be much point in talking about it if you are going to fix the thing yourself anyway.