kOS Scriptable Autopilot System 0.9

[rhoark]

And last but not least the feature to read out the thrust currently put out by your rocket, would solve almost all problems with asparagus staging.

(When an outer stage burns out, you thrust suddenly decreases --> your program stages).

I do this with my launch script, watching for a sudden change in acceleration.

[withinboredom]

First post! Been lurking for awhile

I just wanted to let everyone know I've been working on a site for us to post and share our scripts on. kosstore dot com. Working with solarliner to get IDE integration and syntax highlighting on the site as well.

[SolarLiner]

I think you should make your own thread for the website and its updates, to keep this one "clear"

[Dunbaratu]

Maybe you could exclude comments from the program size calculations.

Agreed. While it's true that the real space race in the 60's used computers with very tiny capacity it's also true that they weren't sending ascii source code with the craft. They were sending machine code only. Comments cost nothing.

Unfortunately I already suggested that on the Github and the suggestion was already rejected.

[Dunbaratu]

Eeeerr, can't he use a round that is build in the C he uses? I mean most languages have that build in. I am sure Python has.

Yeah but if there's a chance there's no time to do all of it, I'd rather see TRUNC being the one that's done for the reasons stated. Obviously if both exist in KOS it becomes a moot point.

Isn't that the drag thing that are stored in the parts?

Yeah but KOS currently has no way to do something like this: "give me a list of the parts on the vessel. Okay now I'm going to iterate over that list and ask for each part's drag.".

If he had felt a gentle push to do it because I can't... (But the comment wasn't totally serious anyway)

Now I have done it anyway...

The reason I was confused is because nothing I suggested mentioned WHO to do it, only WHERE to do it.

[Dunbaratu]

First post! Been lurking for awhile

I just wanted to let everyone know I've been working on a site for us to post and share our scripts on. kosstore dot com. Working with solarliner to get IDE integration and syntax highlighting on the site as well.

This is good as long as the IDE integration doesn't become a necessary thing to use the site (not everyone plays KSP on Windows and that IDE is Windows-only.). And I end up not using it because I want to do my editing outside of the archive directory and run my code through my comment and indent stripper first. (And because I know vi, which makes modern editors feel a bit stifling and clunky to work with by comparison. But I know that's a rather rare opinion and not as important as the other reasons.)

But anyway, the comment stripper is important because instructive shared code of the sort you're talking about should be well documented and legible, but legibility runs afoul of the 10k limit.

There's a community wiki here: http://kos.wikia.com/wiki/KOS_Wiki on which I've been adding some example code of my own. It's probably a good idea not to duplicate this type of thing so if your place works well I might remove the example code from there and put it on yours instead.

[Sma]

And last but not least the feature to read out the thrust currently put out by your rocket, would solve almost all problems with asparagus staging.

(When an outer stage burns out, you thrust suddenly decreases --> your program stages).

This would indeed be nice. By now, you can implement staging for such rockets by coding the 'empty levels' of the stages into your program. Look up the fuel capacity of your rocket, then have a look at the capacity of the boosters in each stage and subtract it from the capacity of the whole rocket. The result is the amount of fuel your rocket will still have when the booster stage is spent. You can then trigger the staging command when the fuel of the current stage becomes lower than the 'empty level' of that stage. For the Kerbal-X stock rocket, the code looks like this:

set stage1_empty to 6480.
set stage2_empty to 5400.
set stage3_empty to 4320.

when stage:liquidfuel < stage1_empty then stage.
when stage:liquidfuel < stage2_empty then stage.
when stage:liquidfuel < stage3_empty then stage.

You don't actually need to know how much fuel you have, or check for sudden deceleration (could happen if something breaks, but doesn't destroy the rocket). What I do is set it up so my main stage, and asparagus stages are separate in the staging. In the program, you have it stage to activate the boosters, then you poll how much fuel you have in the stage, then stage again and poll that. You also need a variable that holds how many pair of asparagus stages you have, and how many stages have been dropped.

When parameters came out I changed it to work with that so I can tell the code how many asparagus stages the rocket has. Code I use is below (some of which I got from someone else...the formula i think..., but modified), with non relevant code stripped:

Update: Just found out this only works with rockets/boosters that feed into the center stage. If using a rocket with boosters and no fuel lines to the center stage and aspCount is set to 1 it'll stage the boosters before they're completely empty.

declare parameter aspCount. // Number of asparagus boosters (Paired...6 boosters would be 3)

set spentstages to 0. // Used for determining how many booster stages have been dropped.

stage. wait 1.
set aspFuel to stage:liquidfuel. // Total fuel in booster stages.
stage. wait 1.
set lowerStageFuel to stage:liquidfuel. // Total fuel in boosters and main stage.
set eachStageFuel to aspFuel / aspCount. // Amount of fuel for each pair of boosters in asparagus staging.
lock throttle to 1. wait 1.

stage. // Launch

until altitude > 25000 {
  // Check for low fuel and stage.
  set currenttotal to <liquidfuel>.
  if currenttotal < (totalfuel - (eachstagefuel * (spentstages + 1))) and spentstages < aspCount {set spentstages to spentstages + 1. stage.}. //if asparagus booster stage empty, stage.
}.

Edited October 5, 2013 by Sma

[KvickFlygarn87]

Yay, 0.7! When will it be able to access RCS for docking?

[JewelShisen]

LOVE that radar altitude now will not return -1 over water or at super high altitudes! Will make cruise missiles SO much easier to fly!

[Dunbaratu]

The radar altitude change will save several lines of code in what I wrote.

Also, I'm glad the inverse trig fixes are in. I needed those.

[Bizz Keryear]

That's the route I'm currently taking too. On a long run however, I think there should be something built right into the Pluging itself. An unexperienced user may not be willing to use additional external tools just to get some common example code to work.

There are two reasons why in game is not a good idea.

1. The loading times, it takes too long to just just test/compile a script. What is within a python program done in a few fractions of a seconds, takes in game half a minute or more. (just to get to the right screen.
   
2. Game time. The time in the game continues while you sort bugs out. Well that might be ok, when you only want to archive orbit, but a pain in the ass, when you miss your transfer to ... e.g. Jool. Please note that Squad always has stated that the Solarsystem will become bigger. More Gasgiants and their moons, Asteriods and such IMHO the only place they can be placed is behind the borders of the current system.
   

This would definitely be the more consequent solution. Then the existing part could also be removed.

Removing parts is certainly not a good Idea. Old vessels are broken then. In space and as craft files.

Anyway I have added it to the Installation and Usage in the K-OS Wiki All links are there (to the Module Manager thread as well as the download link and the needed .cfg file is also there.)

I am currently suffer of brain farts. So I dunno if its understandable.

Will there be a feature to create lists, where values can be accessed using variables? I picture it like this.

 l2(x) -> list two; line x

This is basically what I meant with 'arrays'. To have the ability to store multiple sets of data in a single variable and to look up a specific data set by an index. If this index could itself be read from a variable, one could (besides many other cool things) iterate over all data sets in a loop. E.g.

Do not wonder: Python programmer!

This was one of the first features I was missing in my very first program. It would indeed be useful.

This would indeed be nice. By now, you can implement staging for such rockets by coding the 'empty levels' of the stages into your program. Look up the fuel capacity of your rocket, then have a look at the capacity of the boosters in each stage and subtract it from the capacity of the whole rocket. The result is the amount of fuel your rocket will still have when the booster stage is spent. You can then trigger the staging command when the fuel of the current stage becomes lower than the 'empty level' of that stage. For the Kerbal-X stock rocket, the code looks like this:

set stage1_empty to 6480.
set stage2_empty to 5400.
set stage3_empty to 4320.

when stage:liquidfuel < stage1_empty then stage.
when stage:liquidfuel < stage2_empty then stage.
when stage:liquidfuel < stage3_empty then stage.

I was about to write that solution that the Space Computer had. But someone did it before me.

I may note that it only works if the Asparagus have the same size, in one of my Rockets I used a slightly bigger 1st Asparagus stage. I am currently overhauling it cause some solutions I used are now outdated (in the meaning that I used exploits in mods [fairings & collision] which nor no longer needed because now I can use Procedural Fairings).OhIhavegonesoofftopicnow. Anyway that Rocket gets a multi function satellite (originally equipped with ISA, but ISA is so dead right now and stuck in a horrible version ArrghIhatemybrainfarts) to anywhere in the Kerbal system.

I better come back I know what I wanted to say....

[SolarLiner]

Of course the IDE will not be needed to upload to the site! It is just an idea that I shared with him to make things a bit more "direct", like an overly simplified version control system where you code and push to the server.

Comment stripper is implemented for the 0.35 version of the IDE. It does it automatically if your code passes the 10k limit, however you will still able to "export" with the comments to a file.

[Dunbaratu]

There are two reasons why in game is not a good idea.

1. The loading times, it takes too long to just just test/compile a script. What is within a python program done in a few fractions of a seconds, takes in game half a minute or more. (just to get to the right screen.
   
2. Game time. The time in the game continues while you sort bugs out. Well that might be ok, when you only want to archive orbit, but a pain in the ass, when you miss your transfer to ... e.g. Jool. Please note that Squad always has stated that the Solarsystem will become bigger. More Gasgiants and their moons, Asteriods and such IMHO the only place they can be placed is behind the borders of the current system.
   

I see no connection whatsoever between what was suggested and your response to it. How on earth would having precheck for syntax errors, and choosing not to count comments against space limits do any of that?

[Dunbaratu]

Comment stripper is implemented for the 0.35 version of the IDE. It does it automatically if your code passes the 10k limit, however you will still able to "export" with the comments to a file.

Ah sorry I hadn't kept up with the changes. When I first suggested it in the IDE thread you said you weren't going to do it.

[withinboredom]

This is good as long as the IDE integration doesn't become a necessary thing to use the site (not everyone plays KSP on Windows and that IDE is Windows-only.). And I end up not using it because I want to do my editing outside of the archive directory and run my code through my comment and indent stripper first. (And because I know vi, which makes modern editors feel a bit stifling and clunky to work with by comparison. But I know that's a rather rare opinion and not as important as the other reasons.)

But anyway, the comment stripper is important because instructive shared code of the sort you're talking about should be well documented and legible, but legibility runs afoul of the 10k limit.

There's a community wiki here: http://kos.wikia.com/wiki/KOS_Wiki on which I've been adding some example code of my own. It's probably a good idea not to duplicate this type of thing so if your place works well I might remove the example code from there and put it on yours instead.

It's probably a good idea to leave example code on the wiki, I designed kosstore more for full featured scripts that can be reused.

I started a thread for the site, just waiting for a moderator to approve it so we don't pollute this thread.

[Bizz Keryear]

I see no connection whatsoever between what was suggested and your response to it. How on earth would having precheck for syntax errors, and choosing not to count comments against space limits do any of that?

He said that the comment stripping and validation checks should be done in game. While better error codes would be good, a check outside would be better and faster. your game would not be running away while fixing typos. Serious editing is often done outside already, why not check and compile it there, too. Instead of waiting the long loading times of ksp. Remember your Rocket might have a horrible accident if your program fails. Which would cause another loading screen.

[drtedastro]

The Changelog in the Wiki shows "You can now get the distance to an arbitrary latlng with :distance"

How is this distance being computed? Is it hardwired to current body? what about elev?

just checking before i crash another vessel...

[Dunbaratu]

He said that the comment stripping and validation checks should be done in game.

Yes, I saw that. Which is why I can't figure out what that has to do with what you said about performance, since none of that is computationally expensive.

While better error codes would be good, a check outside would be better and faster. your game would not be running away while fixing typos. Serious editing is often done outside already, why not check and compile it there, too.

Ah. You're comparing the suggestion that had been stated to a different suggestion that existed in your head but hadn't been stated up to that point so we had no way of seeing that that's what you meant. That makes more sense. I thought you were saying the suggestion was worse than what exists NOW, which is no checking ahead of time either in game or out of game. And THAT is not true. Pre-checking syntax does not take longer - it merely shifts the time burden earlier. If it takes time T to parse a typical line of code, and you have 10 lines in a program, pre-parsing just means that all of that wait time of 10*T happens before line 1 executes, compared to doing parsing like it is now where it happens on the fly, where each statement takes time T per line, for a total that still adds up to 10*T by the end of the program.

Now, if you talk about statements in a loop, then not only is pre-parsing not slower, but it is in fact actually FASTER. An on-the-fly parser interprets the syntax of a loop's body each time the loop executes. An up-front parser does the parsing work on the loop body just once no matter how many times the loop executes.

Your claim that editing on the launchpad is not practical I agree with. But it has no place in a discussion about whether or not the comments should be counted toward program size, or a discussion about whether the Mod performing pre-parsing would affect performance. And those two things were what the suggestion was about.

The advantage to pre-parsing the code is that it finds syntax errors in code whether it gets executed or not, rather than waiting until it is executed to find the errors. When there's if-conditions that trigger only some of the time, that matters. You can write code to respond to an exception case and never realize it has a syntax error until the exception case happens and the on-the-fly parser finally gets around to trying to read it.

I suspect that if it ever does switch to using a parser generator tool, it will end up having pre-parsing anyway, as that's how most of them work. They build a grammar tree and then you iterate through the grammar tree executing things as you visit the nodes.

Edited September 29, 2013 by Steven Mading

[KevinLaity]

The Changelog in the Wiki shows "You can now get the distance to an arbitrary latlng with :distance"

How is this distance being computed? Is it hardwired to current body? what about elev?

just checking before i crash another vessel...

It's based on a straight line between you and a position that's calculated from the latlng you gave it, and assumes that the target altitude is the same as your altitude.

So for now, it gets less accurate with distant targets, since the intent is to give you the surface distance you'll have to travel to reach that target. (Not the distance you'd have to tunnel through kerbin to go directly to that point). But for close targets it's a good enough approximation for now until I fix it.

[drtedastro]

excellent, thanks.

[Dunbaratu]

If you find a need to get a more accurate distance measure that does take into account the curvature of the body instead of the distance of tunneling through it, there's some helpful information here: http://www.movable-type.co.uk/scripts/latlong.html

[drtedastro]

thanks...again..

[yum]

With the new update, you can no longer have single unmatched brackets in a print statement. Heh took me a little bit to figure out what was wrong, while deleting the periods from my curly brackets. It throws the bracket matching error.

To recreate the bug, simply

print "(".

However, print "( )". works just fine.

As an aside, I watched the update video, and I haven't yet tested this myself, but if I am understanding this right, alt:radar will return the same value as altitude now, instead of -1. Does it work to a higher altitude than it did before? More importantly, alt:radar will return sea level when over water now. I understand that this type of simplification will be beneficial to some users (they don't have to handle errors), but I'd just like to mention that it does limit what we are capable of doing - personally I'd rather have more raw data available and have to account for errors. In any case, I'm loving kOS, thanks for all the hard work.

[JewelShisen]

With the new update, you can no longer have single unmatched brackets in a print statement. Heh took me a little bit to figure out what was wrong, while deleting the periods from my curly brackets. It throws the bracket matching error.

To recreate the bug, simply

print "(".

However, print "( )". works just fine.

As an aside, I watched the update video, and I haven't yet tested this myself, but if I am understanding this right, alt:radar will return the same value as altitude now, instead of -1. Does it work to a higher altitude than it did before? More importantly, alt:radar will return sea level when over water now. I understand that this type of simplification will be beneficial to some users (they don't have to handle errors), but I'd just like to mention that it does limit what we are capable of doing - personally I'd rather have more raw data available and have to account for errors. In any case, I'm loving kOS, thanks for all the hard work.

If I understand it right, alt:radar will return the altitude of the ship. So it should give you that number even when you are in space. I know I would like to get a reading for depth BELOW sea level for use with Hooligan Labs Submarine Mod.

[SolarLiner]

Ah sorry I hadn't kept up with the changes. When I first suggested it in the IDE thread you said you weren't going to do it.

I wasn't aware of the 10k limit by that time, and when comments got implemented, that sounded like a must-have feature for long scripts.