kOS Scriptable Autopilot System 0.9

[Sma]

Did not need to do that indeed. Just build a rocket without the remote tech part and voilá, it works. I know you have nothing to do with RT, but can this be fixable in kOS so in future another plugin don't mess with this again?

Ah, that maybe, but thinking about it now, I was using RT2, and the remotech part was built in to all stock command pods in that version, so thats why I had to "remove it". Not being a mod developer myself I can't say for sure, but it's hard predict how certain mods will interact considering they are using the same resources. Like with RT2 it was having a problem with bouncing throttle because if you had mechjeb installed and on a rocket it would fight for control with RT2. Now kOS is working so that it can integrate with other mods, (by allowing calls back and forth I guess) but that's assuming the other mods opt to be compatible with kOS.

Another question. I heard in 0.65 video in youtube that you need to be in 100km range (i believe from KSP Base) to archieve volume works. More distance antennas are needed. How this works? Maybe with functionality of antennas and relays to be able to control my probes I can ditch remote tech and stay only with kOS, that is possible?

Currently I believe it just checks to see if you have an antenna, and if so how many, and then calculates how far away from KSC you can be based on the type and numbers, so currently it won't really be able to do relay or time delay like RT2 does. I imagine it'll be possible in the future, but that may very well be something stock before too long. We shall see.

[Camacha]

I really don't think the limit serves any purpose.

I agree. Maybe when it comes to beaming scripts across the solar system it could have some influence, but otherwise I feel this is a little bit too much a an restriction.

[FellipeC]

Ah, that maybe, but thinking about it now, I was using RT2, and the remotech part was built in to all stock command pods in that version, so thats why I had to "remove it". Not being a mod developer myself I can't say for sure, but it's hard predict how certain mods will interact considering they are using the same resources. Like with RT2 it was having a problem with bouncing throttle because if you had mechjeb installed and on a rocket it would fight for control with RT2. Now kOS is working so that it can integrate with other mods, (by allowing calls back and forth I guess) but that's assuming the other mods opt to be compatible with kOS.

Currently I believe it just checks to see if you have an antenna, and if so how many, and then calculates how far away from KSC you can be based on the type and numbers, so currently it won't really be able to do relay or time delay like RT2 does. I imagine it'll be possible in the future, but that may very well be something stock before too long. We shall see.

Indeed I know predicting how other mods will behave is complex. Maybe people from Squad can release some guidelines for mods developers to avoid such problems.

About remote techesque functionality, indeed I would like something like that in vanilla KSP. It already models the needs of fuel, air and energy very well, I think is a natural addition to model communications and even life support.

Also although I think kOS is something very hard to a newbie player to use, for the sake of unmanned probes it adds a lot of realism. Sum to the fact that indeed I don't care to hand fly any rocket (because I'm not good on this and in real life they almost never hand fly rockets anyway), so I expect kOS to keep up and growing with KSP!

[Dunbaratu]

Okay.. I tried to ask in pm, but apparently the forums dont want me to send one, so im forced to ask in here..

Kevin, I am a programmer myself, and have wanted to build an APS myself for some other games for a while. Im missing knowledge on how to properly implement parsers and lexers. Any recommendations? I would really like some input on this. I have basic knowledge, but not enough to actually get a functioning system with.

The basic advice about building a parser yourself is... don't. The algorithms for how to parse language text are so well known and well studied that there's a zillion libraries already out there to do all the work for you. Only make your own if you're trying to make parsers because you're trying to teach yourself that subject.

Here's an introductory list of known ones to start from: http://en.wikipedia.org/wiki/Comparison_of_parser_generators

KOS doesn't use anything like this which is part of the reason its syntax gets a bit wonky at times (expressions are defined at the top level instead of having a recursively nested list of building blocks, which is why expressions that *should* work don't a lot of the time).

[Dunbaratu]

The same antenna range that lets you perform "copy" operations from the archive also lets you perform "switch to archive"... making it sort of pointless to bother storing code on the probe and dealing with the 10k limit.

[razark]

The same antenna range that lets you perform "copy" operations from the archive also lets you perform "switch to archive"... making it sort of pointless to bother storing code on the probe and dealing with the 10k limit.

Unless you want to copy code over before sending your ship on a long voyage. For example: copy, modify and run the launch program, then delete it and load software for landing before heading to Duna.

[theSpeare]

How would one go about rounding a value to the closest whole?

[check]

How would one go about rounding a value to the closest whole?

Off the top of my head, you could try the following.

Assume x is the number you want to round, and z is your answer...

set y to x.
until y < 1 {
set y to y -1.
}.
if y >= 0.5 {set z to x-y+1.}.
if y < 0.5 {set z to x-y.}.

This could be slow if you have large values of x though.

[KevinLaity]

Okay.. I tried to ask in pm, but apparently the forums dont want me to send one, so im forced to ask in here..

Kevin, I am a programmer myself, and have wanted to build an APS myself for some other games for a while. Im missing knowledge on how to properly implement parsers and lexers. Any recommendations? I would really like some input on this. I have basic knowledge, but not enough to actually get a functioning system with.

Hey man, I got your pm and have now responded. Cheers

[KevinLaity]

KOS doesn't use anything like this which is part of the reason its syntax gets a bit wonky at times (expressions are defined at the top level instead of having a recursively nested list of building blocks, which is why expressions that *should* work don't a lot of the time).

This is correct, and I'm considering my options for what to do with kOS in this regard, but the options I've looked at seem like they'd take weeks or months to integrate into what I have.

Frankly I never thought the language would get as much use as it is!

[KevinLaity]

How would one go about rounding a value to the closest whole?

Sadly, there's no rounding function yet, and it may be part of a future expressions overhaul

[Dunbaratu]

This is correct, and I'm considering my options for what to do with kOS in this regard, but the options I've looked at seem like they'd take weeks or months to integrate into what I have.

Yeah the first step would probably have to be separating everything about parsing the text from everything about executing a statement once you understand what it is. That makes the parsing part more easily changed to a drop-in replacement. Right now it's all kind of mixed together which makes changing the parser kind of hard.

Frankly I never thought the language would get as much use as it is!

The curse of too much success can be a good problem to have.

[Bizz Keryear]

I'd say that might be possible but not sane.

I wasn't in a sane state. Lack of sleep makes me always do that. And the ironic character should be clear at the moment I called "Windows 7" a small program.

[...]you will quickly find that you wont be able to fit everything in to the 10k limit. Launch to orbit script from space computer is over 7k with comments.

I have to say it is working, but not a good code.

1. It lacks of a loop in the count down. I have written a code that allows a unlimited (well currently only up to 99 since the code has to be extended for each digit) countdown with the amount of lines.
   
2. The menu uses the same useless print all over instead of print ... at() which would use only one new line.
   
3. And above all that it uses useless whitespaces for formatting reasons.
   

And I don't like it for personal reasons. E.g.: My solarpannels are always on ag10 not ag1. My antennas are on ag9 (oneshot you see where this is going) my science is on ag8.

Used in the system: (lines: 71;length:1712)

//**UI Section.
print "Select your orbit altitude.".
print "--------------------------------".
print " ".
print "Use action group 9 to add 10Km to orbit alt.".
print " ".
print "Use action group 8 to remove 10Km from orbit alt.".
print " ".
print "Use action group 7 to confirm orbit alt.".

until selection = 1
 {
on ag9 set flagup to 1.
on ag8 set flagdown to 1.
on ag7 set confirm to 1.

 if flagup = 1
 {
 clearscreen.
 print "Select your orbit altitude.".
 print "--------------------------------".
 print " ".
 print "Default orbit alt is set to " + tOrbit + "m".
 print " ".
 print "Use action group 9 to add 10Km to orbit alt.".
 print " ".
 print "Use action group 8 to remove 10Km from orbit alt.".
 print " ".
 print "Use action group 7 to confirm orbit alt.".
 print " ".
 set tOrbit to tOrbit + 10000.
 print "You have selected " + tOrbit.
 toggle ag9.
 set flagup to 0.
 }.

 if flagdown = 1
 {
 clearscreen.
 print "Select your orbit altitude.".
 print "--------------------------------".
 print "".
 print "Default orbit alt is set to " + tOrbit + "m".
 print " ".
 print "Use action group 9 to add 10Km to orbit alt.".
 print " ".
 print "Use action group 8 to remove 10Km from orbit alt.".
 print " ".
 print "Use action group 7 to confirm orbit alt.".
 print " ".
 set tOrbit to tOrbit - 10000.
 if tOrbit < 80000 { set tOrbit to 80000. }.
 print "You have selected " + tOrbit + "m".
 toggle ag8.
 set flagdown to 0.
 }.

 if confirm = 1
 {
 clearscreen.
 print " ".
 print "You have confirmed " + tOrbit + "m".
 print " ".
 print "Lift Off in 5s.".
 toggle ag7.
 set confirm to 0.
 wait 2.
 set selection to 1.
 }.
 }.

quickly optimized by me: (lines: 44;length:971)

//**UI Section.
print "Select your orbit altitude.".
print "--------------------------------".
print " ".
print "Default orbit alt is set to " + tOrbit + "m".
print " ".
print "Use action group 9 to add 10Km to orbit alt.".
print " ".
print "Use action group 8 to remove 10Km from orbit alt.".
print " ".
print "Use action group 7 to confirm orbit alt.".
until selection = 1
 {
on ag9 set flagup to 1.
on ag8 set flagdown to 1.
on ag7 set confirm to 1.
 if flagup = 1
 {
 set tOrbit to tOrbit + 10000.
 toggle ag9.
 set flagup to 0.
 }.

 if flagdown = 1
 {
 set tOrbit to tOrbit - 10000.
 if tOrbit < 80000 { set tOrbit to 80000. }.
 toggle ag8.
 set flagdown to 0.
 }.
 print "You have selected " + tOrbit +"m      " at (0,10).
 if confirm = 1
 {
 clearscreen.
 print " ".
 print "You have confirmed " + tOrbit + "m".
 print " ".
 print "Lift Off in 5s.".
 toggle ag7.
 set confirm to 0.
 wait 2.
 set selection to 1.
 }.
 }.

43.28% Space saved.

As the proverb goes. "There is a lot of space in it" ....

[Dunbaratu]

Unless you want to copy code over before sending your ship on a long voyage. For example: copy, modify and run the launch program, then delete it and load software for landing before heading to Duna.

I always assume I will want enough antenna range to copy over replacement code. I may have found a bug or made a better version of the routine by the time the probe gets where its going.

The point is that if you have enough range to do a copy, you also have enough range to just run the version that's on the archive itself. About the only thing you can't do this way is have the same NAME for two versions of the same the program like you could if it was in two different places. As long as your two different versions have two different filenames, they can both live on the archive back home.

In order for the 10k limit to really have meaning, KOS would have to be changed to only allow software copying from a remote drive and stop allowing direct running of software that's on a remote drive.

I'm not sure I'd want to see this fixed though, because the way the limit is enforced I don't think is really fair. While it's true that you get penalized for writing sloppy code that's overly complex, you ALSO get penalized for the good practices of using lots of comments and for using longer variables names, and indenting correctly, none of which would cost a thing if your space was really this tight because if it was really this tight you wouldn't be sending source code you'd be sending compiled code.

Edited September 25, 2013 by Steven Mading

[Bizz Keryear]

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

• Less bugs
• Functions... maybe... they are not very 80's, though... how about a goto instead?
• File names also should eat up memory space.
• Limited transmission speed, depending on the max com range.
• 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!
• Very important: (Like in the editor) left and right arrow keys in the command line. I f* hate it to write a line complete anew if I realize that I have a typo at the beginning.
• Completion of (all) partly integrated function.
• A function, like the LOG one that someone had submitted but for some reasons isn't implemented yet, which allows you to write any data to disk. I am still looking for a good flight recorder (just for static (edit2: ups, typo meant instead: ) statistic reasons).
• For the reasons like above a possibility to read any value from any part.
• More key bindings. Not that KSP has us left with many choices, but the num keys instead. Like "on num6" for 6 on the num keypad which would you allow to have up to 15 keys which don't collide with anything in KSP and might even accessible within kOS (without irritating the user)
• firing / toggeling /turning on &// off any function of a part without having it in actiongroups. AGs are way to limited (symmetry: you cant fire one of a set you placed in symmetry. And there are only 10 of them. On complex mission designs they are colliding or exceeded way too fast)

Edit: A few things I came across: A print without at () removes the one that where printed with at().

E.g.:

clearscreen.
print "I am vastly in the middle at the screen" at (15,15).
wait 3.
print "I should appear under the last line but instead I".
print "clear the screen and write at the top of the screen.".
print "I however appear under them, but however" at (0,18).
print "unlike them I don't stay when the program ends" at (0,19).
wait 3.

Edit2: in this color

Edited September 25, 2013 by Bizz Keryear

[Dunbaratu]

Functions... maybe... they are not very 80's, though...

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.

[*]Limited transmission speed, depending on the max com range.

One good idea.

[*]Exponential falling efficiency of new antennas.

[ ... ]

[*]So you want your data from Jool? Get some relay satellites!

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.

[*]Very important: (Like in the editor) left and right arrow keys in the command line. I f* hate it to write a line complete anew if I realize that I have a typo at the beginning.

This would be good.

[*]Completion of (all) partly integrated function.[*]A function, like the LOG one that someone had submitted but for some reasons isn't implemented yet, which allows you to write any data to disk. I am still looking for a good flight recorder (just for static reasons)

I'd like it for debugging reasons. It's frustrating that when there's a crash into terrain the stats on the terminal screen are gone and you can't tell what it was printing out.

[*]More key bindings. Not that KSP has us left with many choices, but the num keys instead.

Before key bindings how about just a simple blocking IO 'read line" command for prompted input?

I'd like a better way to query what parts are installed on the craft. I.e. type the command: "LIST PARTS". See that? I'd like that available in a data structure the script can iterate over and read.

i.e. When writing a landing script it would be nice to check to see if any parachutes exist.

[pizzaoverhead]

A function, like the LOG one that someone had submitted but for some reasons isn't implemented yet, which allows you to write any data to disk. I am still looking for a good flight recorder (just for static reasons).

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

[drtedastro]

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???

[FellipeC]

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 need for relay satellites isn't distance. Is line of sight

[rkman]

[*]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).

Why restrict max range like that, even more harshly than in real life (inverse square)? 4 times the range should require 16 times the output power (and 16 times the power supply in the form of RTGs, solar panels, batteries), or a (dish) antenna with 16 times the surface area (or compromise between those two).

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

It's still cheaper to build multiple (3 or 4 should cover it) high power ground stations on Kerbin.

"Relays" come into play around distant destination bodies to enable comms with rovers/landers.

Edited September 25, 2013 by rkman

[inferno4200]

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?

[Sma]

Before key bindings how about just a simple blocking IO 'read line" command for prompted input?

Yes, exactly. I've said this a few times. While parameters works sort of, it would be nice to be able have prompted inputs to remind you what it is you're typing in. It would also be good for selecting targets once you get into orbit.

[FellipeC]

Why restrict max range like that, even more harshly than in real life (inverse square)? 4 times the range should require 16 times the output power (and 16 times the power supply in the form of RTGs, solar panels, batteries), or a (dish) antenna with 16 times the surface area (or compromise between those two).

This is very fair! Much better than multiple antennas approach.

It's still cheaper to build multiple (3 or 4 should cover it) high power ground stations on Kerbin.

"Relays" come into play around distant destination bodies to enable comms with rovers/landers.

Yep... But KSP is about launching things to space, so I think instead of 3 ground stations, why not 3 satellites? Anyway real missions use a mix of land stations, satellites and in past even ships and airplanes.

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.

Of course for a probe like Voyager the problem is more about power and antenna size, but as you said for rovers or satellites in another bodies the line of sight come into play.

[rhoark]

They just previewed 2 new antennae for .22, so I'd suggest this plan of action w.r.t comms:

Drop distance limits for now, focus development time on the language

Sometime after antenna selection expands, assign them a gradated series of ranges, with the best having full-system coverage.

Drop the unrealistic multiplication with multiple antennae

At some further point when the language is quite mature, take into account LOS and relays

[rkman]

This is very fair! Much better than multiple antennas approach.

Yep... But KSP is about launching things to space, so I think instead of 3 ground stations, why not 3 satellites?

Because it would be very time consuming and very expensive to put dishes with a diameter of dozens meters (gain factor about a million or so) and 100's of kW power requirement into orbit. Imagine putting the KSC tracking station into orbit. Whereas having that comms capacity on the ground is equally efficient (and a whole lot cheaper) as putting into LKO. http://deepspace.jpl.nasa.gov/dsn/educ/model.html

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

I never said that's not the case. What i am saying is that the bulk of comms capacity is on the ground 'at home', for very practical reasons.

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.

Of course for a probe like Voyager the problem is more about power and antenna size, but as you said for rovers or satellites in another bodies the line of sight come into play.

That does not require putting the equivalent of a ground station into orbit. Deep space comms is pretty involved already without that.

Edited September 25, 2013 by rkman