kOS Scriptable Autopilot System 0.9

[Dunbaratu]

I do have to say that there is an important information loss problem I'm getting with the new altimeter. I liked the idea at first until I tried using it.

I used to be able to detect the following conditions separately:

1 - I am over water. I know this because alt:radar: is bigger than altitude.

2 - I am over water. I know this because alt:radar is equal to altitude.

3 - alt:radar is unreliable right now and I can't use it because I'm too high. I know this because it's -1.

The reason the new inability to tell the difference between "I'm over water" and "I'm too high" is important is that I had a bit of my lander code that guessed at average ground height if it knew the radar was too high to work. If it didn't know the ground height, it would look up the body stats for the planet to obtain its terrain peak height, and take a guess that the ground height might be about half that. It wasn't perfect but it gave better approximations to use than what's there now (and once it got lower it stopped having to approximate and it could use the real data for the final landing). But I need to remove that now because I don't want false positives when it's over the water.

[Dunbaratu]

Pretty sure I got the formula for that from someone else, possibly Steve, don't remember now, but adapted it for my "understanding" lol.

It's possible. I did use that in my code.

But I don't exactly know why getting the speed in 2-D way by using the Pythagorean formula on surfacespeed and verticalspeed gives a different answer from getting it the 3-D way by using the Pythagorean formula on the XYZ parts of the velocity:surface vector. In principle they should return the same number. Is something off in how they're calculated by KOS, I wonder.

[Dunbaratu]

for anyone that cares.. I have written out a simple c function that will determine the result of a modulo operation on a value. might not be the most efficient, but hey, it works without error. Feel free to use it in whatever mods anyone might need it in. I dont know c# or i would have written it as that.

I don't think the reason these operators are missing is because the underlying C# code is hard. That's the easy part. I think they're missing because each one requires setting up the parsing of a new keyword in KOS code first. What you do in C# once you've parsed the KOS code is the easy part. If you look at the GitHub code, when a new function is added to KOSscript it's about a 8:1 ratio between "how many lines are about parsing the KOSscript" and "how many lines are about executing it in C# after it's parsed."

[Dunbaratu]

I would also like to propose that the default extension for kOS, be .kos. This would make things easier as I would like to be able to associate my kOS files to my editor but apart from standard text files.

But if this is done please don't break the self-modifying code trick I discovered by making LOG files and program files have different extensions. The self-modifying code trick si entirely dependent on the fact that the LOG command uses filenames with the same extension as the program code files.

[cfds]

I just use the "keep speed around 200m/s" mentality. Maybe not as accurate or efficient as what you're trying to do but it works for me and isn't "too complicated".

As long better is possible, good is not good enough.

Besides, the main problem is that LOCK TO does not work reliable with loops or wait statements, and that should be fixed.

[Dunbaratu]

(Sorry for the empty quote I used it only to link the conversation ...)

NO what I really meant, if you doing it inside of the game, you depend on the game that mean all those long loading times, also if you test run your script it will affect the vessel attached to it, which usually end in lots of explosions if the script fails caused by typos. I mean the real test if the ship behaves like you thought it will is another story, but if the script just simply stops cause you have forget a dot, a bracket or a quote-mark ... unneeded loading times I am not a ten finger writer and not typing blind, but I use both hands and not searching keys. Sometimes ... well its a not so rare case.... one finger is too fast and I end up with owrds (e.g.). Having those and the previous mentioned ones is really a pain in the (lower) south end if you facing north.

You still don't get what I said. The current situation is that the problem is solved neither IN *NOR* OUT of the game. I agree with a portion of (but not all of) those reasons for why solving it Out can be better than In. But since NEITHER solution exists, it's not a good reason to claim that solving it inside the game is a bad idea. To make that claim you have to compare to what exists NOW. Comparing a proposed solution for a real existing problem it to an imaginary solution that doesn't exist and is far less likely to be implemented isn't fair. It's the perfect being the enemy of the good.

However, that being said (that either solution, the In or Out solution is better than the one we have now which is NO solution), if you are going to enter the red herring side topic of which of the two proposed ideas is better, there is one VERY good thing to put in the PRO column for the in-game solution - it would use the same code, bugs and everything, as will be used when really executing the program, rather than code someone else wrote outside the game. This makes it more accurate for the question "will my script run". We've seen lots of cases were we have to change the KOSscript program because despite the program syntax being correct, the game engine has bugs in how it interprets it and it doesn't understand it. For a pre-syntax check to be practical, not only does it have to succeed at parsing where the real game succeeds at parsing, but it also has to fail at parsing exactly where the real game fails at parsing.

Edited September 30, 2013 by Steven Mading

[Camacha]

But if this is done please don't break the self-modifying code trick I discovered by making LOG files and program files have different extensions. The self-modifying code trick si entirely dependent on the fact that the LOG command uses filenames with the same extension as the program code files.

This, as it is a very nice feature with a lot of potential.

[Dunbaratu]

A far bigger problem on the parsing front, is how bugs in KOS can cause the entirety of KSP to freeze up and require an external task manager kill to get unstuck (and often require that you save-scummed before you started testing your KOS script because not only will the bugs freeze KSP but they will also corrupt your vessel in the persistence file). THAT is a bigger hindrance than anything else. It means that you have to re-launch KSP and try another thing, watch it hang again, kill it, relaunch it, try another thing, kill it, etc until you trace down where the bug is.

If KOS didn't cause KSP to freeze, then you don't have to bother with all that loading time because you just ALT-TAB between your text editor and KSP each time you want to try a different thing.

THAT makes it very time consuming to find bugs in KOSscript code (or bugs in the KOS mod itself). Right now I'm trying to figure out why I get KSP hangs when using the LOG command on renamed Volumes, but I'm trying to winnow it down to the exact minimal set of conditions that cause it so I can submit a bug report, and this process is very time consuming because I have to wait 5 minutes between attempts as I have to re-run KSP each time I change one tiny thing trying to search for the exact cause.

Finding out why KOSscript errors make KSP hang and getting that to stop would be very beneficial.

Edited September 30, 2013 by Steven Mading

[drtedastro]

My preference, should it matter, would be to leave the altimeter data the way it was. Direct reading from instruments should not be altered by the reporting or 'computing' method. When the instrument (from KSP) is giving a -1, it should stay that way. Now, if the system wants to make an additional output, say "messed with altitude", to make things easier for some, that's fine.. But please do not change / alter / fudge and or mess with 'raw' data...

Too each, their own, i suppose...

[Sma]

It's possible. I did use that in my code.

But I don't exactly know why getting the speed in 2-D way by using the Pythagorean formula on surfacespeed and verticalspeed gives a different answer from getting it the 3-D way by using the Pythagorean formula on the XYZ parts of the velocity:surface vector. In principle they should return the same number. Is something off in how they're calculated by KOS, I wonder.

Sorry, Steven, not Steve.

Anyway, it's altogether possible that when I tested it out originally something else was messed up in my code and both ways do work relatively the same. I'll try it out later tonight if I have time and see how it goes, though there could be something off in how they're calculated I guess.

My preference, should it matter, would be to leave the altimeter data the way it was. Direct reading from instruments should not be altered by the reporting or 'computing' method. When the instrument (from KSP) is giving a -1, it should stay that way. Now, if the system wants to make an additional output, say "messed with altitude", to make things easier for some, that's fine.. But please do not change / alter / fudge and or mess with 'raw' data...

Too each, their own, i suppose...

Perhaps a way around this would be for Kevin to include a 2nd alt... maybe alt2:radar for the new way of doing it, and alt:radar for the old way. Then you can decided how you want it done, as having kOS modify alt:radar for you does save a few lines of code and there for some programming space.

On a different note, it'll be interesting/fun once Kevin gets to the point of including different kOS units with different speeds/memory capacity/power needs in the future. Not an important feature, and maybe one that's not even possible, but it would be cool if we could generate sounds/tones like in old fashion c64/basic programming. Then we could create our own custom alert/warning sounds. Unfortunately though I don't think it can be done, likely due to a KSP limit not so much kOS.

Edited September 30, 2013 by Sma

[aNewHope]

Since a few days I'm working on an optimal launching script, that suits any rocket. And finally here it is (almost) !

You simply type in 5 parameters (Orbit height, Turn start, Inclination, Nr. of stages, Fuel crossfeed (y/n))

and there you go! This program is better at orbiting than me or MechJeb (I'm not the challenge, but MJ is not bad at efficient orbiting).

Javascript is disabled. View full album

//rocket launch system

declare parameter Ap.	// Orbit height [km]
declare parameter Ts.	// Turn start   [km]
declare parameter An.	// Launch angle [°]
declare parameter St.	// Stages
declare parameter As.	// Asparagus?   [1=yes,0=no]

set ro to 10. // allowed SMA - Error 
set rc to 1.  // allowed Eccentricy - Error


clearscreen.

// set gs to 175.
// set os to 2280.
// set La to 90-arctan(os/gs).
// set La to An+La*sin(An).

print "Target Orbit:  " + Ap + " km" at (24,0).
print "Turn Start:    " + Ts + " km" at (24,2).
print "Orbit angle:   " + An + " deg" at (24,4).
// print "Launch angle:  " + La at (24,6).
// print " deg    " at (44,6).
print "Current Stage: " + St at (24,8).
print "Flight State:  " at (24,10).  
print "Countdown" at (24,11).
Print "Flight log:" at (0,0).

set x to 3.
until x = 0 {
  print x at (0,2). set x to x - 1. wait 1.
}

If As > 0 {print "Fuel crossfeed detected!" at (24,15).
	print "Please stage manually" at (24,16).}

lock acc to maxthrust/mass.
set An to 90 - An.
set Ap to Ap * 1000.
set Ts to Ts * 1000.
set y to 90.

// lock steering to heading La by y.
lock steering to heading An by y.

lock throttle to 1.
stage. 
set t to maxthrust.

print "Liftoff !" at (0,2). 

print "Vertical climb" at (24,11).

Until Altitude > Ts{
    if As = 0 {
        if stage:liquidfuel = 0 {
          if <LiquidFuel> > 0 {
            stage.
            print missiontime  at (0,3).
            print " stage " + St + " detached" at (5,3).
            set St to St - 1.
            print St at (39,8).
          }
        }
    }
    if As > 0 {
        if maxthrust > t or maxthrust < t{
          print missiontime at (0,3).
          print " stage " + St + " detached" at (5,3).
          set St to St - 1.
          set t to maxthrust.
          print St at (39,8).
        }
    }
}

print missiontime at (0,4).
print " turn start" at (5,4).
print "Gravity Turn  " at (24,11).

Until Apoapsis > Ap{
    if As = 0 {
        if stage:liquidfuel = 0 {
          if <LiquidFuel> > 0 {
            stage.
            print missiontime  at (0,5).
            print " stage " + St + " detached" at (5,5).
            set St to St - 1.
            print St at (39,8).
          }
        }
    }
    if As > 0 {
        if maxthrust > t or maxthrust < t{
          print missiontime  at (0,5).
          print " stage " + St + " detached" at (5,5).
          set St to St - 1.
          set t to maxthrust.
          print St at (39,8).
        }
    }
set y to (1-(Altitude/Ap))*75.
lock throttle to (0.1+(Ap - apoapsis)/2000).
}

print "Coasting to Apoapsis" at (24,11).
set warp to 1.
print " s "  at (10,7).

when eta:apoapsis < (1000/acc) then {
set warp to 0.}

until eta:apoapsis < 800/acc{
if apoapsis > Ap {lock throttle to 0.}.
if apoapsis < Ap {lock throttle to 0.05.}.
print "ETA circularisation:" at (0,6).
print (eta:apoapsis - 800/acc) at (2,7).
set y to (1-(Altitude/Ap))*75.
}

print "Circularisation burn" at (24,11).
print missiontime at (0,6).
print " circularization" at (5,6).

// lock steering to heading An by y.
lock throttle to 1.
lock dif to ((apoapsis+periapsis)/2)-Ap.
until abs(dif) < ro{
    if As = 0 {
        if stage:liquidfuel = 0 {
          if <LiquidFuel> > 0 {
            stage.
            print missiontime  at (0,7).
            print " stage " + St + " detached" at (5,7).
            set St to St - 1.
            print St at (39,8).
          }
        }
    }
    if As > 0 {
        if maxthrust > t or maxthrust < t{
          print missiontime  at (0,7).
          print " stage " + St + " detached" at (5,7).
          set St to St - 1.
          set t to maxthrust.
          print St at (39,8).
        }
    }
    if eta:apoapsis < eta:periapsis {
    set y to (Ap-apoapsis)/20.}
    if eta:apoapsis > eta:periapsis {
    set y to (apoapsis-Ap)/20.}
    lock throttle to abs(dif)/10000.
}
lock throttle to 0.

print missiontime at (0,8).
print " Optimisation" at (5,8).
print "Optimisation        " at (24,11).
set y to 90. if verticalspeed > 0 {
set y to -90.}
wait 4.

until abs(verticalspeed) < rc{
lock throttle to abs(verticalspeed)/(2*acc).}

print missiontime at (0,9).
print " completion" at (5,9).
lock throttle to 0.
Print "Orbit complete" at (24,11).

print "Use AG 1 to end program" at (0,12).
on ag1 {set x to 1.}
wait until x = 1.

I hope you like my program and hopefully somebody can help me with some asparagus code.

[Bizz Keryear]

You still don't get what I said. The current situation is that the problem is solved neither IN *NOR* OUT of the game. I agree with a portion of (but not all of) those reasons for why solving it Out can be better than In. But since NEITHER solution exists, it's not a good reason to claim that solving it inside the game is a bad idea. To make that claim you have to compare to what exists NOW. Comparing a proposed solution for a real existing problem it to an imaginary solution that doesn't exist and is far less likely to be implemented isn't fair. It's the perfect being the enemy of the good.

However, that being said (that either solution, the In or Out solution is better than the one we have now which is NO solution), if you are going to enter the red herring side topic of which of the two proposed ideas is better, there is one VERY good thing to put in the PRO column for the in-game solution - it would use the same code, bugs and everything, as will be used when really executing the program, rather than code someone else wrote outside the game. This makes it more accurate for the question "will my script run". We've seen lots of cases were we have to change the KOSscript program because despite the program syntax being correct, the game engine has bugs in how it interprets it and it doesn't understand it. For a pre-syntax check to be practical, not only does it have to succeed at parsing where the real game succeeds at parsing, but it also has to fail at parsing exactly where the real game fails at parsing.

OK, now I get it, but wont you agree that other things are more important right now? Maybe it should be in for version 1.0 or so.

[Sma]

Since a few days I'm working on an optimal launching script, that suits any rocket. And finally here it is (almost) !

You simply type in 5 parameters (Orbit height, Turn start, Inclination, Nr. of stages, Fuel crossfeed (y/n))

and there you go! This program is better at orbiting than me or MechJeb (I'm not the challenge, but MJ is not bad at efficient orbiting).

Javascript is disabled. View full album

...

I hope you like my program and hopefully somebody can help me with some asparagus code.

Congrats on your launch code. Just wondering, how close does it get if you put in say, 100,000m for your orbit? Thats what I usually feed mine, sometimes itll be 100,000x136,000 (+/- 1000 or so). Ever since the update that increased the speed of kOS, I haven't taken much time to go through and work on my code. I had a loop until altitude was >25000 and then the next loop basically did almost nothing other than read out info. At one time it did do something though, just cant remember what. Because of that I started to condense/optimize it a little last night but started falling asleep during testing. I had a few times where I'd nod off for a minute, wake up and my AP was > 300,000 and climbing and I'm like "uhhhh what?". Coding late at night with out caffeine...yeh doesn't work so well, though in some causes I guess the reverse could be true too.

Also, I've posted what I use for my asparagus code somewhere before, ...maybe this link will work http://forum.kerbalspaceprogram.com/threads/47399-kOS-Scriptable-Autopilot-System-0-7?p=666643#post666643

See if that helps you at all.

[Bizz Keryear]

[...]

I'd like you to to put that on the wiki.

Space Computer has a (imho) good asparagus solution

[check]

That counter is delightfully useless yet awesome. But just one thing: would you leave some awesome stuff for the others to build?

LoL. The idea for these just popped into my head last night. I even considered making a 10x10 light grid and looping a 10-15 frame animation... but the lights don't blink fast enough.

[drtedastro]

Sorry, Steven, not Steve.

Anyway, it's altogether possible that when I tested it out originally something else was messed up in my code and both ways do work relatively the same. I'll try it out later tonight if I have time and see how it goes, though there could be something off in how they're calculated I guess.

Perhaps a way around this would be for Kevin to include a 2nd alt... maybe alt2:radar for the new way of doing it, and alt:radar for the old way. Then you can decided how you want it done, as having kOS modify alt:radar for you does save a few lines of code and there for some programming space.

On a different note, it'll be interesting/fun once Kevin gets to the point of including different kOS units with different speeds/memory capacity/power needs in the future. Not an important feature, and maybe one that's not even possible, but it would be cool if we could generate sounds/tones like in old fashion c64/basic programming. Then we could create our own custom alert/warning sounds. Unfortunately though I don't think it can be done, likely due to a KSP limit not so much kOS.

Adding or including a 2nd alt, etc. as you said, would be the perfect way. Like I tried to convey, I have nothing against 'extra' options, directives or such, just the convolution of existing, raw (as it comes from the ship, unit, whatever) data.

This would be a perfect place for a function(s), that contain 'whatever' and is called 'something'....

thanks.

[Dunbaratu]

OK, now I get it, but wont you agree that other things are more important right now? Maybe it should be in for version 1.0 or so.

I'm not so sure it is a good idea to wait because this change is large enough that it may become too big of a chore if the codebase is too large by the time it gets addressed. This is because it's not the sort of thing that can be addressed by merely adding more code to what's already there. It has to be addressed by going through and altering a lot of the code that's already there. The more code that's there, the more unappealing the project becomes and the more likely someone is to look at it and say "nope, too much work".

Edited September 30, 2013 by Steven Mading

[Dunbaratu]

I'm having a heck of a time trying to trace a bug in one of my scripts where I have a single craft with more than one Volume on it and I'm trying to have multiple SCS units read the same volume. To do that correctly you must give the volume a name. The number is not sufficient because different SCS units number the volumes differently (One cpu might call a volume "2" while another calls it volume "1"). So the volumes NEED to be named.

And that's where the problem is.

First, on the master CPU that controls the craft, I RENAME VOLUME 1 to MasterDisk.

Then I want the master CPU to copy some program files off to the child CPUs on the attached other parts.

I do this by trying to use LOG and self-modifying code to write out these commands:

COPY missile to 2.

COPY missile to 3.

COPY missile to 4.

etc. in a loop going from 2 to 11.

Each time I run the LOG'ed code, delete it, and recreate it to get the different statements. (You might ask why I don't just write all the statements and run them once - it's because if some of the missiles have been fired already by a previous use, then not all the volumes are still there and I don't want the error to stop the program from getting to the other ones.)

The problem is, it always crashes and hangs KOS. But NOT always at the same point. Sometimes it gets a bit farther. I'm trying to trace down the exact circumstances but when I do it starts working correctly when I strip it down to the simplest test example.

As near as I can tell it seems that once I rename "volume 1" to "MasterDrive" and then "switch to MasterDrive", that from then on it's a crapshoot whether or not file operations work. Sometimes it crashes on "delete", sometimes it crashes on "log". It is frustratingly inconsistent.

When I make a tiny example on the launchpad, the tiny example works.

Has anyone else had problems trying to get volume renaming to work for them?

I'm beginning to wonder if there's a timing issue with all these file operations. Like it works when the CPU is fast and not when it's slow.

I'm trying to test different cases to get it narrowed down but it's a tediously slow process when each test causes KSP to hang and need a task-manager kill and relaunch and reload.

Edited October 1, 2013 by Steven Mading

[Motokid600]

Loops with only a WAIT statement are ignored by KOS. Perhaps something like

until 0 {

wait 1.

set ix to 0.

}.

will work better.

The wait command doesn't seem to be the problem. That works, but.. can kOS even perform a lock steering to target?

clearscreen.

print "Locking to Target.".

LOCK STEERING TO TARGET.

until 0 {
 wait 1.
 set ix to 0.
 }.

This doesn't work. It locks the steering, but not to my target. Any ideas?

.. And what does "Out of range mean?" My keys stop functioning in the kOS window so I reboot the computer. Now when I try to switch to archive. It says out of range.

Edited October 1, 2013 by Motokid600

[Dunbaratu]

The wait command doesn't seem to be the problem. That works, but.. can kOS even perform a lock steering to target?

clearscreen.

print "Locking to Target.".

LOCK STEERING TO TARGET.

until 0 {
 wait 1.
 set ix to 0.
 }.

This doesn't work. It locks the steering, but not to my target. Any ideas?

.. And what does "Out of range mean?" My keys stop functioning in the kOS window so I reboot the computer. Now when I try to switch to archive. It says out of range.

So many things to mention:

1 - LOCK STEERING TO TARGET should instead be LOCK STEERING TO TARGET:DIRECTION.

("TARGET" is a string - the name of the vessel being targeted.)

(edit: okay stupid bbcode, look, not everyone who types a punctuation mark meant it to be a stupid smiliey!!! STOP DOING THAT! The smiley you see above is a colon followed by a letter "D".)

2 - "Out of Range" means you are trying to manipulate files on the archive drive but the archive drive is too far from the craft and you don't have antennae to reach it. More info here: http://kos.wikia.com/wiki/Remote_Updates

3 - I have seen KOS bug out in such a away that you can still type but you can't SEE that you're typing until you hit ENTER. Then you finally see your text appear, but it never gets executed or does anything. I have no clue what causes this but sometimes rightclicking the SCS on the ship and selecting "toggle power" off and on again will unstick it. It's definitely a bug though. Because the bug sometimes gets triggered by manipulating the volumes and switching volumes that might be what you encountered. When the bug gets really bad, it can hang all of KSP and require you to CTRL-ALT-DEL and kill ksp.exe. But I've never seen it get so bad you have to actually reboot the computer.

[TMS]

Learn the ways of the noparse.

[noparse]TARGET:DIRECTION[/noparse]

(I agree BTW)

[MP X10L]

Hi, is there a way to readout the current pitch on the navball? I tried to figure out how exactly facing works and then calculating my pitch, but I have serious problems with that. ^^

print heading.

returns yaw at the navball ... before I try this the whole day I wanted to know whether there is a easy way to access pitch.

I need it to calculate my current thrust independent from maxthrust, which allows for asparagus staging .... at least I hope. ^^

This is what I wanted to use to teach me how this stuff works, but I realized it would take .... some time. ^^ It works for some regions on the navball. Those regions move or disappear when moving over Kerbin .... so yeah.

until 0 {
print ((facing:pitch + latitude)^2 + (facing:yaw + longitude)^2)^(0.5) at(0,30).
print "facing: " + facing at(0,31).
print "heading: " + heading at(0,32).
}.

Could someone help me? ^^ The staging is one of the last parts of my launchscript which already propels me into an desired orbit with an accuracy of 500m with only one burn.

[UbioZur]

1 - LOCK STEERING TO TARGET should instead be LOCK STEERING TO TARGET:DIRECTION.

("TARGET" is a string - the name of the vessel being targeted.)

(edit: okay stupid bbcode, look, not everyone who types a punctuation mark meant it to be a stupid smiliey!!! STOP DOING THAT! The smiley you see above is a colon followed by a letter "D".)

If you go to advance edit, you have the option to disable smiley text.

[Dunbaratu]

If you go to advance edit, you have the option to disable smiley text.

Well that's backward. You have to do to "Advanced" to get it to do LESS. Erm Okay. Well anyway thanks for the heads up.

[Wingy]

Hi gang. I'm new to all of this, even forums, but howdy just the same. k-OS rocks, KL! Like everyone else, I have ideas for its future. Would it be possible to play sound files with it, someday, w/chatterer or not? How about a voice synthesizer with lots of parameters so we could make scripted chatter? Ok, a sound-file player would be fine, too. These launch scripts are event sequencers in a way, and instead of boring PRINT statements, the realism would REALLY be sweet if they were 'PLAY [some chatter]' instead. This would also allow video-of-the-launch narration to be done much easier and automated, too, one would think. Maybe another nice feature would be an automatic SWITCH TO 0. option at k-OS window-opening.

Has anyone else had problems with: set tVal to tVal - (or +) 0.02? I did. I instead used: set tVal to tVal + downbump (or upbump). I declared downbump and upbump at the top... as -0.02 and 0.02 respectively, and it all started working. Don't ask ME why it acted that way.

But all in all,(or half'n'half) k-OS is just plain TOO MUCH FUN! Keep up the excellent work, KL and everyone else.