kOS Scriptable Autopilot System 0.9

[Dappa]

Things I'd like to have in kOS. (not in a specific order)

• Exponential falling efficiency of new antennas.
  Meaning: With 5 antennas you will not have the range of 5 times one antenna but e.g. 3.05 times (factor 0.75). And while 11 Antennas give you the range of 3.83 times of one. It is impossible to reach 4. (Well with 27 you reach 3.9983 which is fairly close. And 40 brings you to 3.9999597737).
  A 0.9 or a 0.99 factor might also be possible (0.99 means each new antenna is 0.1 less efficient than the one before).
• Com range of the base module should be the diameter of KSC.
• Vessel to Vessel communication. Send them Values. Let them run programs. Shortly lets remote use them. Even a relay network might be possible.
  So you want your data from Jool? Get some relay satellites!

I think having all those comm options would stray too far from the purpose of kOS. Such advanced communication capability would be better served by integrating kOS and RemoteTech. In fact, while the current communication system of kOS already is very simple, I think it should be simplified or omitted.

[FellipeC]

I think having all those comm options would stray too far from the purpose of kOS. Such advanced communication capability would be better served by integrating kOS and RemoteTech. In fact, while the current communication system of kOS already is very simple, I think it should be simplified or omitted.

Both mods would benefit of such integration. RemoteTech could ditch the autopilot part in favor of kOS.

[SolarLiner]

Anyway real missions use a mix of land stations, satellites and in past even ships and airplanes.

To take the Voyager example, the only thing working for them is the Voyager comm dish and the Deep Space Network, which is a series of ground stations scattered around the world. Apollo mission never used a single relay satellite. Because it is cheaper and quicker to repair.

I like the idea of, for example, if you send a probe orbiting Mun, you can only give commands if it is flying on near side of Mun and also KSC is in line of sight, unless you have more communications satellites to be a relay.

Basically, coupling kOS with RemoteTech.

[Bizz Keryear]

is it possible, with the current release, to have say a 'bootstrap' program running almost like in the background, that at certain points in time, or when very specific criteria are matched or specific conditions arise that it can spawn of a stored program and when that one is complete, re-enter the base / bootstrap program???

In background isn't possible (yet). But the craft keeps being controllable as long as you don't lock steering and thrust. And if you run a program in a endless loop, you can use if or when

The need for relay satellites isn't distance. Is line of sight

Also true, but KSP don't simulates blackouts due blocking from celestial bodies.

Sounds like you're looking for Telemachus or Persistent Trails.

I didn't know trails yet(so I can't say something about that), but the other loggers where too slow (slowed down the game unreasonable... like Telemachus) , I had to deal with manual export, or in Telemachus from time to time I lost connection and all the data I collected so far. And I have tried quite a lot.

And I had a typo. I meant statistic not static .

Languages have had functions a LOT longer than the 80's. To give a single reference point for example, the "C" language was invented in 1970.

Funny in the 80's I was on my C64/C16 with Basic... Never got assembler, though.

It's *already* pretty unrealistic how many antennae are needed. Why make it even worse?

Number of relay satellites NASA needs to communicate between Earth and the Voyager probe: zero.

The way real space programs deal with the long distances of communication to very weak probes operating on very small amounts of power is simply to build higher-powered stations on the Earth end of things to compensate. Sending a relay probe halfway between Earth and the target probe in order to allow you to get away with lower transmission power on your Earth station actually makes things more expensive overall, because a kilogram of payload can buy you a heck of a lot lot of kilowatt-hours on Earth.

Time needed to communicate within the Kerbaluniverse: also zero.

Realism isn't everything. A game has its limits. Not only technical limits. E.g. you can't do a realistic time delay or it would be boring and frustrating. If Voyager I would be still had any reason to be controlled ... I mean there is nothing out there and the probe is currently blind (cameras are turned off) .. but if they were on and we would wan't to react to an event we have to do it 17 hours and 22 minutes before will be happened, and if the computer on the probe would be in need to request data from earth it would be at least take 34 hours and 44 before it would have those infos.

Imagine a game like that. People would be bored to hell. Especially those who complain (on steam) that the loading time is too long (I think he talked about two minutes or so)...

On the other hand... Lets wait and see what brings 0.22 into play.

I think having all those comm options would stray too far from the purpose of kOS. Such advanced communication capability would be better served by integrating kOS and RemoteTech. In fact, while the current communication system of kOS already is very simple, I think it should be simplified or omitted.

I don't like the RT Idea of delay. Edited September 25, 2013 by Bizz Keryear

[Dunbaratu]

Funny in the 80's I was on my C64/C16 with Basic... Never got assembler, though.

Same here. But as I grew up and learned more about programming I also realized that this toy I grew up with didn't represent how language worked out in the real world. The idea that you'd want to forgo function calls to simulate being in the 1980s makes no sense when function calls existed a lot longer than that. Besides, even if you were doing raw assembler in the 1980s you still had access to a lot more of what the hardware had to offer so you could at least manipulate a stack manually and therefore implement function calls with return parameters and everything. KOS is a strange combination of not being able to do it the low-level way and ALSO not being able to do it the high-level way either.

Realism isn't everything. A game has its limits. Not only technical limits. E.g. you can't do a realistic time delay or it would be boring and frustrating. If Voyager I would be still had any reason to be controlled ... I mean there is nothing out there and the probe is currently blind (cameras are turned off) .. but if they were on and we would wan't to react to an event we have to do it 17 hours and 22 minutes before will be happened, and if the computer on the probe would be in need to request data from earth it would be at least take 34 hours and 44 before it would have those infos.

Imagine a game like that. People would be bored to hell. Especially those who complain (on steam) that the loading time is too long (I think he talked about two minutes or so)...

This argument would make perfect sense if you had been suggesting something that would make the game more fun. You weren't. Diminishing returns on antennae would reduce fun.

[SiliconPyro]

Before the comms of kOS get changed any, perhaps it should be considered that 0.22 is going to introduce vanilla comms with its own limitations and parameters. If kOS could somehow use that methodology to transmit programs like scientific data, then more attention could be focused on the language itself than comms.

[pizzaoverhead]

Apollo mission never used a single relay satellite.

It should also be noted that the Apollo Lunar Module used the Command/Service Module as a relay.

Also true, but KSP don't simulates blackouts due blocking from celestial bodies.

KSP doesn't, but mods like RT can and do.

[Dunbaratu]

It should also be noted that the Apollo Lunar Module used the Command/Service Module as a relay.

Which isn't related to Bizz's suggestions which were all about antenna range from earth to probe and had nothing to do with line of sight. The Command module wasn't being used to shorten the distance to home. The distance savings between earth and command module versus the distance between earth and lunar lander is negligible.

If anything if you want to simulate problems of long distance signals then POWER consumption would affect range more so than number of antennae. The tradeoff should be on how much power the probe can muster. Requiring that you festoon the probe with many dishes all over it (such that small probes become physically impossible because you need more space just to get the antennae to fit) is not the way to go.

[Payload]

Well, I have a chicken and egg question. How the heck are we supposed to know the height of our ship? Don't tell me check before lift off. That is easy enough and it doesn't work if your launch clamps are tall or if your ship is taller at lift off than landing like almost all of them are. It also doesn't work if you are landing a ship form orbit.

You can get your height over terrain if your steering is locked to up and you subtract radar alt from altitude. That only fixes the landing over water problem. It still doesn't tell you how tall your ship is. It tells you how far your kOS unit is from the ground.

I have tried to check against status, but it doesn't seem to work either. Maybe I am doing it wrong? Not really any working examples of that anywhere.

O.K. I got if status = "LANDED" to work. That must have been fixed since I last tried. That also opens up the door for a whole lot nice things.

Edited September 25, 2013 by Payload

[drtedastro]

how many kerbals is it from one end to the other?

[Gaius]

Languages have had functions a LOT longer than the 80's. To give a single reference point for example, the "C" language was invented in 1970.

...and was strongly influenced by ALGOL, initially created in the 50's. As Tony Hoare once quipped, ALGOL-60 was a vast improvement on most of its successors.

Although if we wanna go back to the 50's for computer languages, I prefer LISP...

Edited September 25, 2013 by Gaius

[Bizz Keryear]

Which isn't related to Bizz's suggestions which were all about antenna range from earth to probe and had nothing to do with line of sight. The Command module wasn't being used to shorten the distance to home. The distance savings between earth and command module versus the distance between earth and lunar lander is negligible.

If anything if you want to simulate problems of long distance signals then POWER consumption would affect range more so than number of antennae. The tradeoff should be on how much power the probe can muster. Requiring that you festoon the probe with many dishes all over it (such that small probes become physically impossible because you need more space just to get the antennae to fit) is not the way to go.

I think we should drop that discussion to after 0.22 anyway. But that was my personal wishlist. No one (else) has to like it. I thought it as fun to have limitations, to raise the difficulty a bit.

I personally don't think you need the ability to access the archive drive anytime. And if the 10kB isn't enough you can always add another interface. By the way it would be logic to use the module manager mod to add it to all pods/probe cores/etc. And while it is cool to have sites like Space Computer [...], you can definitely learn a lot of stuff from other peoples programs. It also takes the fun from it. If I really wanted to have a ready to use solution I would use mechjeb. No trouble with limited memory, its all full auto, it even has a scripting interface.

So why choose kOS over mechjeb? Because of the limitations! But they are rendered useless if you have too much access to the archive drive.

And if you program it yourself, you have to ask you do you really need that fancy menu? Maybe you will use that program (in that form) only once, so you can edit it the values and drop the menu.

The launch program from Space Computer needs 7k but you can bring a vessel into a good orbit with much less lines. geeez : I did it again... I didn't wanted to discuss it and yet I done it.

And one more word ... kOS always have given me the feeling of a flying home computer. ...

Point added to my personal wishlist: Ability to change the style of the Interface to light blue font on dark blue background (C64 style rulez!)

P.S.: Who else thinks that 0.22 comes in one month or less?

[Bizz Keryear]

Well, I have a chicken and egg question. How the heck are we supposed to know the height of our ship? Don't tell me check before lift off. That is easy enough and it doesn't work if your launch clamps are tall or if your ship is taller at lift off than landing like almost all of them are. It also doesn't work if you are landing a ship form orbit.

You can get your height over terrain if your steering is locked to up and you subtract radar alt from altitude. That only fixes the landing over water problem. It still doesn't tell you how tall your ship is. It tells you how far your kOS unit is from the ground.

I have tried to check against status, but it doesn't seem to work either. Maybe I am doing it wrong? Not really any working examples of that anywhere.

O.K. I got if status = "LANDED" to work. That must have been fixed since I last tried. That also opens up the door for a whole lot nice things.

Anyway how the heck does mechjeb get the right numbers?

An Idea: Just approach the ground slowly (2-9m/s) from a certain height ... e.g. 50m (should be enough for any ship) and when the vertical speed becomes 0 it means you have touched the ground. Also in a landing script you might want to reduce the thrust if you decent speed is too low. So if your thrust is 0 and your vertical speed is 0 it means you have successfully landed... without really knowing the true height of your ship.

Well status landed is another way I guess.

how many kerbals is it from one end to the other?

counter question, how many kerbals is it high when in orbit... (imagining a kerbal ladder up to geosync orbit...)

[Dunbaratu]

The launch program from Space Computer needs 7k

No it doesn't. It's identical to a program with the comments and whitespace stripped which is far smaller. Most of that 7k is legibility not algorithm (and some of it is just the fact that it was written before KOS had some of the features it has now. Like the extra PRINT lines to redraw the menu all over the place is because PRINT AT didn't exist yet when it was first started.

Anyway, to allow good editing practices of proper indenting and proper commenting without it costing overhead space in KOS, just make a "compiler" program outside of KSP that takes well documented properly indented code as input and spits out compacted uglified code for KOS to see as output. Since the terminal editor doesn't really work as an editor anyway (wide content is utterly invisible, not wrapping the text old-school style nor letting you see it by side-scrolling new-school style. It is in fact even worse than editing an actual C64 basic program was) anything serious is going to use an external editor anyway. As long as you use an external editor you may as well go that extra step and also edit your code in your own directory somewhere and "publish" it over to your KOS archive through a filter. Then you don't have to write deliberately uglified code that isn't indented and isn't commented.

I'd show my little program that does this but I doubt most people have a Perl interpreter installed so I don't think it would be that useful.

(I primarily program in UNIX but I use Windows for KSP because the ports aren't that well implemented, but I've got my Windows installation stuffed full of UNIX-like tools like Perl and Bash and Vim.)

Point added to my personal wishlist: Ability to change the style of the Interface to light blue font on dark blue background (C64 style rulez!)

I'm editing in an external gvim window. I've already got this feeling by setting the colors the way I want and downloading a C64 font to use in the editor.

[Dunbaratu]

O.K. I got if status = "LANDED" to work. That must have been fixed since I last tried. That also opens up the door for a whole lot nice things.

Status LANDED works but it effectively means the script is "blind" and has to feel the ground to find its height. If what you want to do, for example, is skycrane-drop your payload when it's about 1 meter above the ground - you can't tell what that actually is without knowing how high the SCS part is above the payload's bottom. This is why my skycrane script currently has to actually land on the ground first and then detach the skycrane, which doesn't look quite as cool.

And as a bit of advice, any script that checks using status = "LANDED" should probably also add: OR STATUS = "SPLASHED" to the check. Otherwise it will fail when coming down over water.

I almost wish that status was a bitwise flag set to handle the fact that more than one thing can be true at a time about a craft. A craft on the water should be considered BOTH splashed AND landed. But without bitwise manipulations it's a pipe dream anyway.

Edited September 25, 2013 by Steven Mading

[Sma]

Just downloaded and I am going to love using it but there is one thing I didn't see in the documentation. Is there a way to prompt the user for a value and assign that value to a variable?

not yet exactly, a few of us have been talking about that incase you missed it.

What you can do is declare a parameter(s)

declare parameter aspCount.
declare parameter orbitAltitude.

Then you would run your program like: run orbit2-9(3,100000). or, something like that i forget if there was a space after the file or not. This option just came out in the last release.

[Payload]

I did add OR if splashed. I was also having trouble with my suicide timer being off because of drag. I added the drag calcs and now that is perfect. I've got it where it will land any rocket with a TWR of greater than 1.5 from an altitude of 500m or greater on Kerbin.

I haven't tried bodies with out an atmosphere, as my current program assumes a lot of things. I am tracking radar alt by setting a terrain height. So one problem right off the bat will be landing angle. I think I might setup a low pass and then increase my pitch to keep my vertical speed at zero until my horizontal speed is 0. I also have a lot of constants to replace with variables so they can be set by a script that is run at the beginning of the program. I also haven't tried running my scripts from the menu yet in .65. It still didn't work in .61 though.

I know it sounds like a silly request, but can we get a group setting to either de-focus the kOS window or can we get kOS fixed to not default to physical warp when the window is focused?

[Dunbaratu]

I mentioned it a few times so I thought I'd post it.

This is the Perl script I use when I want to edit my code and then publish it over to the KOS archive. It allows me to be as verbose as I like in comments and indent as much as I like in comments without those good programming practices costing me anything on the actual part in the game because the code the KOS mod sees has had indents and comments stripped out. I don't see this as cheating because as far as the game is concerned it's identical to what the code would have looked like had I not bothered to make it legible. I just completely reject the idea that removing legibility from the code to make it fit is a valid or interesting challenge. Removing algorithmic complexity to make it fit IS a valid challenge, but removing purely cosmetic legibility features like indentation and comments to make it fit is not.

There is one small cost a block comment does still cost with this script but it's small. A line consisting only of comments is not entirely deleted. A blank zero-length line is left behind in its place so that the line number counts are still accurate in those few places where the KOS interpreter actually tells you a line number in an error message.

Oh, and yes i know this could have been done with a few regular expression search/replace functions instead. The reason I didn't do it that way is that I'm still entertaining the idea of making the filter do more by having it mangle variable names into shorter forms and maintain a mapping for them. If I decide to do that then I will need to analyze the text with something better than a regular expression search/replace.

To Use it:

1 - You need Perl installed. If you're on Windows its not there by default but is downloadable with a google search for "Perl on Windows".

2 - Make a directory on your hard drive somewhere that you want to make your editing of your KOS source code happen. Copy out all the .txt files from your KOS archive directory to this new location, and rename them all to have .ksc extensions instead. I use "KSC" to mean "KOS Source Code".

3 - Edit the program to change the two lines at the top that say:

$inDir="C:\\Users\\Dunbaratu\\KOS code";
$outDir="C:\\Program Files (x86)\\Steam\\steamapps\\common\\Kerbal Space Program\\Plugins\\PluginData\\Archive";

To make them point at your own places instead. inDir is the directory where you want to edit your source code (the one you set up in step 2 above) and and outDir is the directory where the KOS archive is stored (If you installed the game via Steam with its default folder locations you can probably use the same outDir setting I have there, otherwise you will need to change it.)

4 - Run the perl script after you make edits to publish the edits to your KOS archive.

5 - BE AWARE that if you adopt this system the Perl script does overwrite .txt files in your KOS archive with the stuff you have in your KSC files, so if you use "EDIT PROGNAME." inside the KOS terminal you'll be editing the temporary version that can get overwritten next time. Other than occasionally trying something quick and dirty to test how a KOS feature works, I do all my editing in my own KSC files now and just double-click the "export.pl" program after I've made edits to get them to appear in the archive of the game.

File: "export.pl" :

#!C:\MinGW\perl

$inDir="C:\\Users\\Dunbaratu\\KOS code";
$outDir="C:\\Program Files (x86)\\Steam\\steamapps\\common\\Kerbal Space Program\\Plugins\\PluginData\\Archive";
opendir(my $dHandle, $inDir ) || die "Can't open $dir as directory to read: $!";
while( $fName = readdir($dHandle) ) {
  if( $fName =~ /\.ksc$/i ) {
    $fNewName = $fName;
    $fNewName =~ s/ksc$/txt/ig;
    open( KSC, "<$inDir/$fName" ) || die "Can't open $inDir/$fName for input: $!";
    open( TXT, ">$outDir/$fNewName" ) || die "Can't open $outDir/$fNewName for output: $!";
    print "$fName --> $fNewName: ";
    $cCount = 0;
    while( $srcLine = <KSC> ) {

      $qCount = 0; # number of quotes so far on the line.
                   # Used so that a comment start inside a
		   # quote string gets left alone, as in:
		   # PRINT "THIS STRING // IS NOT A COMMENT".
		   # Since KOSscript only allows one-line
		   # strings there is no need to remember
		   # quotes opened on previous lines.

      $commPos = -1; # Position of start of the comment on the line.
                     # Remains -1 if there isn't a comment.

      $len = length($srcLine);

      $firstNonSpacePos = -1; # For trimming all indentation on the line,
                              # Find the first non-whitespace char and
			      # cut off everything that came before it.

      for( $i = 0; $i < $len ; ++$i ) {
        $ch=substr($srcLine, $i, 1 );
        $chNext=( ($i < $len-1) ? substr($srcLine, $i+1, 1 ) : "\0" );
	if( $firstNonSpacePos < 0 and
	       $ch ne " " and
	       $ch ne "\t" and
	       $ch ne "\n" and
	       $ch ne "\r" ) {
	  $firstNonSpacePos = $i;
	}
	if( $ch eq "\"" ) {
	  ++$qCount;
	}
	# 0.6 style comments:
	if( $ch eq "/" and $chNext eq "/" and ($qCount%2 == 0) ) {
	  $commPos = $i;
	  break;
	}
        # My own older comment style I was using before
	# KOSscript had its own comments :
	#
	# if( $ch eq "#" and ($qCount%2 == 0)  ) {
	#   $commPos = $i;
	#   break;
	# }
      }	
      if( $commPos >= 0 ) {
	for( $cutPos = $commPos-1 ;
	     $cutPos >=0 and ( ( substr( $srcLine,$cutPos,1) eq " " ) or
	                       ( substr( $srcLine,$cutPos,1) eq "\t" ) ) ;
	     --$cutPos ) {
        }
	# "\x0d\x0a" is for the CR/LF text terminators Windows uses.
	# Change that part if you run this on a UNIX (including Mac).
	# Perl is *supposed* to translate "\n" into a CRLF on Windows
	# but it doesn't seem to always work right so I hard coded
	# the characters.
	$srcLine = substr($srcLine, 0, $cutPos+1) . "\x0d\x0a";
	++ $cCount;
      }
      if( $firstNonSpacePos >= 0 ) {
        $srcLine = substr($srcLine, $firstNonSpacePos ) ;
      }
      print TXT $srcLine;
    }
    close( KSC );
    close( TXT );
    if( $cCount == 0 ) {
      print "no comments found.\n";
    } else {
      print "$cCount comments stripped.\n";
    }
  }
}
closedir $dHandle;
print "press enter to finish.\n";
$line = <STDIN>

[galarsson]

You can also insert comments, that doesn't have to be stripped, in the code like this.

{"My comment."}.

The string within the parenthesis will not be executed because of the way the interpreter works, but the parsing will still cost an execution cycle.

[inferno4200]

not yet exactly, a few of us have been talking about that incase you missed it.

What you can do is declare a parameter(s)

declare parameter aspCount.
declare parameter orbitAltitude.

Then you would run your program like: run orbit2-9(3,100000). or, something like that i forget if there was a space after the file or not. This option just came out in the last release.

Thanks for the reply. Darn shame that it isn't supported yet. I'm working on a fully scripted autopilot for my SSTO and I wanted to combine both ascent and landing into the same script with a prompt for the user to select which section to execute. Hopefully soon!

[Dunbaratu]

You can also insert comments, that doesn't have to be stripped, in the code like this.

{"My comment."}.

The string within the parenthesis will not be executed because of the way the interpreter works, but the parsing will still cost an execution cycle.

I don't think you understand the reason I'm stripping them. It's not because the syntax doesn't support them. It's because they cost space.

[Sma]

Thanks for the reply. Darn shame that it isn't supported yet. I'm working on a fully scripted autopilot for my SSTO and I wanted to combine both ascent and landing into the same script with a prompt for the user to select which section to execute. Hopefully soon!

For now you could use the parameter option.

declare parameter sstoMode.
if sstoMode = asc { // ascent mode code here }.
if sstoMode = lan { // landing mode code here }.

Then when you run the program:

run ssto(asc).

or

run ssto(lan).

Another way people have used to get input into the program is using action groups to trigger different segments of code, although I don't like that method as it limits you to action groups you can use for different parts of your ship.

[seanth]

I'm really interested in applying this to circumnavigations to Kerbin with boats. I completed one circumnavigation as a way of testing boat designs and automation using Mechjeb, but was not really satisfied with its ability to hold a course using the space plane guidance panel (http://forum.kerbalspaceprogram.com/threads/25016-In-search-of-Ferdinand-Magellan?p=657141&viewfull=1#post657141).

The rover controls look like exactly what I want as far as targeting a lat/long and updating course direction during the flight to stay pointed at a target vs just holding a heading. I haven't done anything in k-OS yet, but I'm slightly concerned that the rover steering won't work with rudder steering structures.

If rudders work with rover steering through k-OS, then it'd be fairly easy to control jet engine throttle based on distance to target.

[inferno4200]

For now you could use the parameter option.

declare parameter sstoMode.
if sstoMode = asc { // ascent mode code here }.
if sstoMode = lan { // landing mode code here }.

Then when you run the program:

run ssto(asc).

or

run ssto(lan).

Another way people have used to get input into the program is using action groups to trigger different segments of code, although I don't like that method as it limits you to action groups you can use for different parts of your ship.

Ah that could work! Thank you! The parameter method definitely works better. Not always enough action groups as is!

[UnpossibleRockets]

I cant seem to get my terminal window focused. So while I'm scripting, the hotkeys will set everything off. like T or S or spacebar. Most of the other mods I use just autofocus. help?