[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Cairan]

That makes kOS scripts who's purpose is to keep a ship on a particular orientation "at all times" even when not in view sort of impossible.

It's unfortunate because I think it would make perfect sense to use kOS for a "station-keeping" script like this, but sadly doing so would require more than just a mere mod. It would require changing how squad's own code works.

That's one of the major differences between Orbiter and KSP, on Orbiter you can have DLLs run continuously, the physics engine runs all the time, there is no "rails" to speak of (which is both a blessing and a curse...) That was one of the most important feature of KSP that I had to adapt to, as you must consider the "sphere of physics" around the active vessel.

[GabeTeuton]

I did a hard test for this program I came up with... got a new designed airplane, set 5 waypoints to different flyby places asked to be flown by by a fine prints contract... took off... got at around 17k above sea level started the script after some tweaking thanks to the sfs file and the stock trim for guidance... and made it back... AWESOME FLIGHT... I was going to post the statics (Flight Results) but as i quicksaved and had to quickload as i screwed up the landing the first time (hahaha) the statics were reset...

The script behaved perfectly, i'm really happy with this result... the airplane needed a little bit more pitch authority as i was around the 0.9 (+/- 0.05) pitch range for U and D, but still it was amazing... I'm really happy and grateful for the support the people here gave me!

Thanks!

PS: I recorded 2 minutes of the flight, when I was returning from the last checkpoint, but I can't upload it as of now, maybe later or tomorrow! And I'll link it here if anyone is interested in watching it in action!!!!!! Once again THANK YOU!

Edited October 30, 2014 by GabeTeuton

[Cairan]

I did a hard test for this program I came up with... got a new designed airplane, set 5 waypoints to different flyby places asked to be flown by by a fine prints contract... took off... got at around 17k above sea level started the script after some tweaking thanks to the sfs file and the stock trim for guidance... and made it back... AWESOME FLIGHT... I was going to post the statics (Flight Results) but as i quicksaved and had to quickload as i screwed up the landing the first time (hahaha) the statics were reset...

The script behaved perfectly, i'm really happy with this result... the airplane needed a little bit more pitch authority as i was around the 0.9 (+/- 0.05) pitch range for U and D, but still it was amazing... I'm really happy and grateful for the support the people here gave me!

Cool! Good to hear your script worked so well!

On another subject, while 0.15 is under dev, I have another question...

Am I right in understanding that with 0.15, it will now be possible to store binaries instead of interpreted scripts in the kOS CPUs with a COMPILE instruction? That will solve the "comments take up valuable space" issue I've been having with my code so far! It was a pain to maintain commented and non-commented versions... Good work if that's the case!

And is anyone working currently on RasterProp integration of the terminal window? It seems to me that this could be hacked in a read-only manner with snapshots of the terminal in a first step... The holy grail of RPM integration would be DSKY-like with the RPM's displays arrow keys but that would require supporing triggers along the lines of ON RPMUP, ON RPMDN, ON RPMLT, ON RPMRT, ON RPMOK, ON RPMNO, etc.

[Dunbaratu]

Am I right in understanding that with 0.15, it will now be possible to store binaries instead of interpreted scripts in the kOS CPUs with a COMPILE instruction? That will solve the "comments take up valuable space" issue I've been having with my code so far! It was a pain to maintain commented and non-commented versions... Good work if that's the case!

That is the goal. I had a working system in place before we started adding the new method suffix system for 0.15. I'll need to go back and re-test it to make sure it still works after all the changes. It does make the program the same size regardless of whitespace and comments, but it still does take up more space with long variable names than short ones because the actual "machine language" used under the hood is a sort of object-aware computer that knows the names of variables and looks them up by name (so the variable name does have to be stored in the machine language). I managed to reduce the expense of it a bit by only storing the long variable name once in a packed argument section, and then referring to it by numerical index into the section after that. (So the difference in storage space between saying MyLongVariableName versus saying mLVN only exists the first time it's used. After that all subsequent uses take up the same space in the ML file.)

And is anyone working currently on RasterProp integration of the terminal window? It seems to me that this could be hacked in a read-only manner with snapshots of the terminal in a first step... The holy grail of RPM integration would be DSKY-like with the RPM's displays arrow keys but that would require supporing triggers along the lines of ON RPMUP, ON RPMDN, ON RPMLT, ON RPMRT, ON RPMOK, ON RPMNO, etc.

Madlemur was taking this task on. But it's going to take time because madlemur is new to kOS and has to get a grasp of the existing terminal code first.

[Cairan]

Good to hear about the variable-object index scheme... You know, I'm teaching my 4 year old a lot of stuff using "the space critters" as we call the Kerbals between us, and I was looking for a way to justify teaching my son how to program like I did at his age on my VIC-20... then along came kOS and I'm using it to teach him about coding, thinking in a procedural flow, writing commands, etc...

Thanks a lot for everyone's work so far!

[FreeThinker]

EDIT: by prograde towards the sun, you mean kerbin's prograde in relation to it's orbit around the sun? does the sun have a prograde by itself?

By prograde to the sun I simply ment point the the ship heading directly towards the sun at all time. Nothing more, nothing less. I had hoped there would be a basic basic script available in the community to keep keep a basic satalite without automatic solar panels headed towards the sun. I can't be the only one that want something simple like this, can I?

[Cairan]

By prograde to the sun I simply ment point the the ship heading directly towards the sun at all time. Nothing more, nothing less. I had hoped there would be a basic basic script available in the community to keep keep a basic satalite without automatic solar panels headed towards the sun. I can't be the only one that want something simple like this, can I?

Since the physics don't get updated while a ship is on rails, if your satellite has flat solar panels, and your batteries are topped off except when in shadows, no power should be consumed while not in focus. Just do a loop that checks if your satellite is pointed toward the sun (that would be called "pointing nadir" to the sun, by the way), so when you switch back to it, if it is not, reset the orientation toward the sun.

Personally, I always put 3 flat panels on any designs I make which do not include an RTG, even on Interstellar reactor-powered crafts just in case, spread 120° from each other, that way I don't have to worry about loosing power, and control, if my panel is not pointed toward the sun.

[FreeThinker]

Since the physics don't get updated while a ship is on rails, if your satellite has flat solar panels, and your batteries are topped off except when in shadows, no power should be consumed while not in focus. Just do a loop that checks if your satellite is pointed toward the sun (that would be called "pointing nadir" to the sun, by the way), so when you switch back to it, if it is not, reset the orientation toward the sun.

Yes, I know that a satelite on rails, doesn't generate or require power, but I think that's cheating! Right now I use mech Jeb to point my satelite in the direction of the Sun by Targeting Moho (I can't seem to be able to target Kerbol) and set Smart SAS to head prograte to the target. As a result it point at least somewhere in the direction of the sun but it's not accurate enough. One alternative idea it to put a satelite in low orbit around the Sun but it requires so much Delta V that I either need Ion engines or some solar sail to achieve it. Since automated Solar sails seemt to know exactly where the sun it, why wouldn't I be able to use some script to do the same?

Edited October 31, 2014 by FreeThinker

[Trewor007]

Does anybody know if the next KOS update will have, a SET method for the :STAGE prefix on some parts?

[Cairan]

Madlemur was taking this task on. But it's going to take time because madlemur is new to kOS and has to get a grasp of the existing terminal code first.

Thinking back on this issue, and reading a few pages back of the thread, I'd look into how TeleMachus worls, maybe even write up a kOS interface for it, as a very first step... Then kOS could emulate the TeleMachus approach and have it's own server listening for connections...

Now that would be extremely expandable if kOS listened to a port. Say I have a DSKY-like hardware control display running on a Rasberry PI, then it could send keystrings / triggers to another computer running KSP along kOS and receive values for the LED displays from it...

[madlemur]

Well guys, after several hours of not doing the laundry I managed to get a primitive Altitude Holder to work as desired... it can be further tweaked but it will need nearly constant tweak as ship Level Flight AoA will change as CoM changes due to fuel consumption, and if the vehicle is perfectly balanced to have the dCoM at the same point than the CoM it will still need tweaking as speed will change due to mass decreasing with fuel consumption...

HOWEVER, it does its job onces the basic tweak is set... By basic tweak I mean that the needed U and D variables are set to a specif point according to plane, I have no idea if it's possible to calculate those based on plane specs...

EDIT= in order to get an estimate of U and D, you need to flight to your desire height and at the desired speed (or throttle), then manually trim the airplane with the stock system, until you are more or less satisfied, let's say when VS is more or less 5 m/s (positive value), then quicksave... pause the game, go to the quicksave, search "trimpitch" (the one for your vessel) and there you have a rough estimate of the values of U and D, if the trim gets you 5 m/s VS, then your U is around that pitch... you'll probably want less than that... but not much!

I proudly present=

LOCK VS to verticalspeed.
LOCK THROTTLE TO 0.66. // Throttle also affects U and D,
// 0.66 was selected randomnly...
SET U TO 0.16.         // The pitch up value.
SET D TO -0.075.       // The pitch down value.

clearscreen.

UNTIL ALT:RADAR < 0 {

if VS < 0.1 {

UNTIL VS > 0 SET SHIP:CONTROL:PITCH TO U.
}

ELSE {

UNTIL VS < 0 SET SHIP:CONTROL:PITCH TO D.
}.

PRINT "<Altitude Holder v0.1>" AT (13,0).
PRINT "Radar Altitude= " + ALT:RADAR AT (0,3).
PRINT "Current Pitch= " + SHIP:CONTROL:PITCH AT (0,5).
PRINT "Vertical Speed= " + VS AT (0,7).
PRINT "Pitch Up Setting= " + U + "  Pitch Down Setting= " + D AT (0,9).
PRINT "Program made by GabeTeuton" AT (20,30).
}.

I thought I had posted this, but it must have gotten eaten...

Not sure if this will work better for you, but the nested UNTIL loops concerned me.

LOCK VS to verticalspeed.
SET THT TO 0.66.
SET U TO 0.16.         // The pitch up value.
SET D TO -0.075.       // The pitch down value.

clearscreen.

// Trim up when losing altitude
WHEN VS < 0 {
  SET SHIP:CONTROL:PITCH TO U.
  PRESERVE.
}.

// Trim down when gaining altitude
WHEN VS > 0 {
  SET SHIP:CONTROL:PITCH TO D.
  PRESERVE.
}.

// Action group 5: reduce effect of up trim
ON AG5 {
  SET U TO U - 0.02.
  IF U < 0 THEN SET U TO 0.
  PRESERVE.
}.

// Action group 6: increase the effect of up trim
ON AG6 {
  SET U TO U + 0.02.
  IF U > 1 THEN SET U TO 1.
  PRESERVE.
}.

// Action group 7: increase the effect of down trim
ON AG7 {
  SET D TO D - 0.02.
  IF D < -1 THEN SET D = -1.
  PRESERVE.
}.

// Action group 8: reduce the effect of down trim
ON AG8 {
  SET D TO D + 0.02.
  IF D > 0 THEN SET D = 0.
  PRESERVE.
}.

// Action group 9: reduce throttle
ON AG9 {
  SET THT TO THT - 0.02.
  IF THT  > 0 THEN SET THT = 0.
  PRESERVE.
}.

// Action group 10: increase throttle
ON AG0 {
  SET THT TO THT + 0.02.
  IF THT > 1 THEN SET THT = 1.
  PRESERVE.
}.

UNTIL ALT:RADAR < 0 {
  SET SHIP:CONTROL:MAINTHROTTLE TO THT.
  PRINT "<Altitude Holder v0.1a>" AT (15,0).
  PRINT "Radar Altitude= " + ALT:RADAR AT (0,3).
  PRINT "Current Pitch= " + SHIP:CONTROL:PITCH AT (0,5).
  PRINT "Vertical Speed= " + VS AT (0,7).
  PRINT "Pitch Up Setting= " + U + "  Pitch Down Setting= " + D AT (0,9).
  PRINT "Current Throttle= " + THT AT (0,11).
  PRINT "Program made by GabeTeuton with tweaks by madlemur" AT (20,30).
  WAIT 0.001.
}.

Changelog:

Got rid of nested UNTIL loops.

Added ability to fine tune U and D using action groups 5-8.

Added ability to fine tune throttle using action groups 9 and 10.

Added WAIT statement to UNTIL loop so that information is only updated once per update.

Notes:

There is no check for VS == 0, since it's unlikely that will ever be the case. The system will always be fluctuating. The best that could be done is to reduce the magnitudes of U and D until the fluctuations are minuscule.

[madlemur]

Thinking back on this issue, and reading a few pages back of the thread, I'd look into how TeleMachus worls, maybe even write up a kOS interface for it, as a very first step... Then kOS could emulate the TeleMachus approach and have it's own server listening for connections...

Now that would be extremely expandable if kOS listened to a port. Say I have a DSKY-like hardware control display running on a Rasberry PI, then it could send keystrings / triggers to another computer running KSP along kOS and receive values for the LED displays from it...

What I'm working on right now is a VT100/VT220-ish virtual terminal emulator that can be used in a GUI window (like the current console), an RPM prop (specifically an MFD page), or really anything. It's slow going at the moment, as I'm learning C#, Unity, and VT100/VT220... Oh, and most of my coding time is stolen cycles at work.

Bonus features: ANSI art and "native" support for eventual ssh/telnet-ish connections.

[GabeTeuton]

Good to hear about the variable-object index scheme... You know, I'm teaching my 4 year old a lot of stuff using "the space critters" as we call the Kerbals between us, and I was looking for a way to justify teaching my son how to program like I did at his age on my VIC-20... then along came kOS and I'm using it to teach him about coding, thinking in a procedural flow, writing commands, etc...

Thanks a lot for everyone's work so far!

Awesome to hear your kid is interested and it's great you are teaching him all those things haha, (i say those things cause i don't know for instance what procedural flow is).

I thought I had posted this, but it must have gotten eaten...

Not sure if this will work better for you, but the nested UNTIL loops concerned me.

LOCK VS to verticalspeed.
SET THT TO 0.66.
SET U TO 0.16. // The pitch up value.
SET D TO -0.075. // The pitch down value.

clearscreen.

// Trim up when losing altitude
WHEN VS < 0 {
SET SHIP:CONTROL:PITCH TO U.
PRESERVE.
}.

// Trim down when gaining altitude
WHEN VS > 0 {
SET SHIP:CONTROL:PITCH TO D.
PRESERVE.
}.

// Action group 5: reduce effect of up trim
ON AG5 {
SET U TO U - 0.02.
IF U < 0 THEN SET U TO 0.
PRESERVE.
}.

// Action group 6: increase the effect of up trim
ON AG6 {
SET U TO U + 0.02.
IF U > 1 THEN SET U TO 1.
PRESERVE.
}.

// Action group 7: increase the effect of down trim
ON AG7 {
SET D TO D - 0.02.
IF D < -1 THEN SET D = -1.
PRESERVE.
}.

// Action group 8: reduce the effect of down trim
ON AG8 {
SET D TO D + 0.02.
IF D > 0 THEN SET D = 0.
PRESERVE.
}.

// Action group 9: reduce throttle
ON AG9 {
SET THT TO THT - 0.02.
IF THT > 0 THEN SET THT = 0.
PRESERVE.
}.

// Action group 10: increase throttle
ON AG0 {
SET THT TO THT + 0.02.
IF THT > 1 THEN SET THT = 1.
PRESERVE.
}.

UNTIL ALT:RADAR < 0 {
SET SHIP:CONTROL:MAINTHROTTLE TO THT.
PRINT "<Altitude Holder v0.1a>" AT (15,0).
PRINT "Radar Altitude= " + ALT:RADAR AT (0,3).
PRINT "Current Pitch= " + SHIP:CONTROL:PITCH AT (0,5).
PRINT "Vertical Speed= " + VS AT (0,7).
PRINT "Pitch Up Setting= " + U + " Pitch Down Setting= " + D AT (0,9).
PRINT "Current Throttle= " + THT AT (0,11).
PRINT "Program made by GabeTeuton with tweaks by madlemur" AT (20,30).
WAIT 0.001.
}.

Changelog:

Got rid of nested UNTIL loops.

Added ability to fine tune U and D using action groups 5-8.

Added ability to fine tune throttle using action groups 9 and 10.

Added WAIT statement to UNTIL loop so that information is only updated once per update.

Notes:

There is no check for VS == 0, since it's unlikely that will ever be the case. The system will always be fluctuating. The best that could be done is to reduce the magnitudes of U and D until the fluctuations are minuscule.

I believe that under decrease throttle you meant "IF THT < 0 THEN SET THT = 0" right? 'cause if it's more than 0 you don't want it to be set to 0 just by pressing once! Also nice way to use IF, quite interesting, never thought about that.-

As you said accurately i doubt VS will ever be 0 until the trim feature is added at least, so the "0.02" step should work, i will definately give this a try... though I was asking if there was a way to while executing the program still be able to write commands, like for instance "SET U TO "arbitrary number".

Thanks for the suggestion!

(btw i'm uploading the video, as soon as it's finished i'll post it here)

Edit: OMG I spelled write, like RIGHT! HAHA

Edited October 31, 2014 by GabeTeuton
SPELL CHECK HAHA

[madlemur]

I believe that under decrease throttle you meant "IF THT < 0 THEN SET THT = 0" right? 'cause if it's more than 0 you don't want it to be set to 0 just by pressing once! Also nice way to use IF, quite interesting, never thought about that.-

As you said accurately i doubt VS will ever be 0 until the trim feature is added at least, so the "0.02" step should work, i will definately give this a try... though I was asking if there was a way to while executing the program still be able to right commands, like for instance "SET U TO "arbitrary number".

Thanks for the suggestion!

(btw i'm uploading the video, as soon as it's finished i'll post it here)

Quite right. I did a quick copy and paste to add throttle control via action groups, and I must have scanned over that too quickly.

Sadly, there's no good way to set an arbitrary value, yet. Who knows what black magic Steven Mading and erendrake are brewing up...

[GabeTeuton]

I made some tweaking as i was trying to use it and some syntax errors showed up... the "when" doesn't go with {}, it needs "THEN" after the condition... IF on the other hands, does need {} instead of THEN... and the {} for when, in order for it to include the preserve goes after the THEN... some variables on the action group part where "set d = 0", i replaced the "=" with TO hehe, and action group 0 is actually action group 10... and then it works!!!!! Now i'll test it!

(btw also moved the "by" me and you clause because as it's longer now it wouldn't fit the screen!)

SET THT TO 0.66.
SET U TO 0.16. // The pitch up value.
SET D TO -0.075. // The pitch down value.

clearscreen.

// Trim up when losing altitude
WHEN VS < 0 THEN {
SET SHIP:CONTROL:PITCH TO U.
PRESERVE.
}.

// Trim down when gaining altitude
WHEN VS > 0 THEN {
SET SHIP:CONTROL:PITCH TO D.
PRESERVE.
}.

// Action group 5: reduce effect of up trim
ON AG5 {
SET U TO U - 0.02.
IF U < 0 { SET U TO 0.}.
PRESERVE.
}.

// Action group 6: increase the effect of up trim
ON AG6 {
SET U TO U + 0.02.
IF U > 1 { SET U TO 1.}.
PRESERVE.
}.

// Action group 7: increase the effect of down trim
ON AG7 {
SET D TO D - 0.02.
IF D < -1 { SET D TO -1.}.
PRESERVE.
}.

// Action group 8: reduce the effect of down trim
ON AG8 {
SET D TO D + 0.02.
IF D > 0 { SET D TO 0.}.
PRESERVE.
}.

// Action group 9: reduce throttle
ON AG9 {
SET THT TO THT - 0.02.
IF THT < 0 { SET THT TO 0.}.
PRESERVE.
}.

// Action group 10: increase throttle
ON AG10 {
SET THT TO THT + 0.02.
IF THT > 1 { SET THT TO 1.}.
PRESERVE.
}.

UNTIL ALT:RADAR < 0 {
SET SHIP:CONTROL:MAINTHROTTLE TO THT.
PRINT "<Altitude Holder v0.1a>" AT (15,0).
PRINT "Radar Altitude= " + ALT:RADAR AT (0,3).
PRINT "Current Pitch= " + SHIP:CONTROL:PITCH AT (0,5).
PRINT "Vertical Speed= " + VS AT (0,7).
PRINT "Pitch Up Setting= " + U + " Pitch Down Setting= " + D AT (0,9).
PRINT "Current Throttle= " + THT AT (0,11).
PRINT "Program made by GabeTeuton with tweaks by madlemur" AT (0,30).
WAIT 0.001.
}.

LOCK VS to verticalspeed.

[madlemur]

I made some tweaking as i was trying to use it and some syntax errors showed up... the "when" doesn't go with {}, it needs "THEN" after the condition... IF on the other hands, does need {} instead of THEN... and the {} for when, in order for it to include the preserve goes after the THEN... some variables on the action group part where "set d = 0", i replaced the "=" with TO hehe, and action group 0 is actually action group 10... and then it works!!!!! Now i'll test it!

(btw also moved the "by" me and you clause because as it's longer now it wouldn't fit the screen!)

SET THT TO 0.66.
SET U TO 0.16. // The pitch up value.
SET D TO -0.075. // The pitch down value.

clearscreen.

// Trim up when losing altitude
WHEN VS < 0 THEN {
SET SHIP:CONTROL:PITCH TO U.
PRESERVE.
}.

// Trim down when gaining altitude
WHEN VS > 0 THEN {
SET SHIP:CONTROL:PITCH TO D.
PRESERVE.
}.

// Action group 5: reduce effect of up trim
ON AG5 {
SET U TO U - 0.02.
IF U < 0 { SET U TO 0.}.
PRESERVE.
}.

// Action group 6: increase the effect of up trim
ON AG6 {
SET U TO U + 0.02.
IF U > 1 { SET U TO 1.}.
PRESERVE.
}.

// Action group 7: increase the effect of down trim
ON AG7 {
SET D TO D - 0.02.
IF D < -1 { SET D TO -1.}.
PRESERVE.
}.

// Action group 8: reduce the effect of down trim
ON AG8 {
SET D TO D + 0.02.
IF D > 0 { SET D TO 0.}.
PRESERVE.
}.

// Action group 9: reduce throttle
ON AG9 {
SET THT TO THT - 0.02.
IF THT < 0 { SET THT TO 0.}.
PRESERVE.
}.

// Action group 10: increase throttle
ON AG10 {
SET THT TO THT + 0.02.
IF THT > 1 { SET THT TO 1.}.
PRESERVE.
}.

UNTIL ALT:RADAR < 0 {
SET SHIP:CONTROL:MAINTHROTTLE TO THT.
PRINT "<Altitude Holder v0.1a>" AT (15,0).
PRINT "Radar Altitude= " + ALT:RADAR AT (0,3).
PRINT "Current Pitch= " + SHIP:CONTROL:PITCH AT (0,5).
PRINT "Vertical Speed= " + VS AT (0,7).
PRINT "Pitch Up Setting= " + U + " Pitch Down Setting= " + D AT (0,9).
PRINT "Current Throttle= " + THT AT (0,11).
PRINT "Program made by GabeTeuton with tweaks by madlemur" AT (0,30).
WAIT 0.001.
}.

LOCK VS to verticalspeed.

Heh... That's what I get for writing code off the cuff when I'm otherwise hip deep in syntactically different code (C# and PHP)... Good catches, and good fixes. Let me know how it works!

[GabeTeuton]

Heh... That's what I get for writing code off the cuff when I'm otherwise hip deep in syntactically different code (C# and PHP)... Good catches, and good fixes. Let me know how it works!

Another tweak... pitch down just means the amount that the pitch will go down, but specially at high altitudes and speeds it's rare that you will need to pitch actually in a negative angle, unless the airplane AOA for level flight is near 0 at those altitude and speed... so i change the min rule for the pitch down setting to if it's > 1 then reset it to 0, 'cause in my new plane the pitch down is 0.23 and the pitch up is 0.25 (at around 20,3k), (which is really small, so it wobbles a tiny bit only...)! i would say this is the final version 'cause it's really working, MAYBE if AGX is implemented i can add more ag to tweak U and D by 0.001 and keep the 0.02, to make it wobble even less, or nothing !

LOCK VS to verticalspeed.
SET THT TO 1.
SET U TO 0.23. // The pitch up value.
SET D TO 0.23. // The pitch down value.

clearscreen.

// Trim up when losing altitude
WHEN VS < 0 THEN {
SET SHIP:CONTROL:PITCH TO U.
PRESERVE.
}.

// Trim down when gaining altitude
WHEN VS > 0 THEN {
SET SHIP:CONTROL:PITCH TO D.
PRESERVE.
}.

// Action group 5: reduce effect of up trim
ON AG5 {
SET U TO U - 0.02.
IF U < 0 { SET U TO 0.}.
PRESERVE.
}.

// Action group 6: increase the effect of up trim
ON AG6 {
SET U TO U + 0.02.
IF U > 1 { SET U TO 1.}.
PRESERVE.
}.

// Action group 7: increase the effect of down trim
ON AG7 {
SET D TO D - 0.02.
IF D < -1 { SET D TO -1.}.
PRESERVE.
}.

// Action group 8: reduce the effect of down trim
ON AG8 {
SET D TO D + 0.02.
IF D > 1 { SET D TO 0.}.
PRESERVE.
}.

// Action group 9: reduce throttle
ON AG9 {
SET THT TO THT - 0.02.
IF THT < 0 { SET THT TO 0.}.
PRESERVE.
}.

// Action group 10: increase throttle
ON AG10 {
SET THT TO THT + 0.02.
IF THT > 1 { SET THT TO 1.}.
PRESERVE.
}.

UNTIL ALT:RADAR < 0 {
SET SHIP:CONTROL:MAINTHROTTLE TO THT.
PRINT "<Altitude Holder v0.1a>" AT (15,0).
PRINT "Radar Altitude= " + ALT:RADAR AT (0,3).
PRINT "Current Pitch= " + SHIP:CONTROL:PITCH AT (0,5).
PRINT "Vertical Speed= " + VS AT (0,7).
PRINT "Pitch Up Setting= " + U + " Pitch Down Setting= " + D AT (0,9).
PRINT "Current Throttle= " + THT AT (0,11).
PRINT "Program made by GabeTeuton with tweaks by madlemur" AT (0,30).
WAIT 0.001.
}.

Here's the video from the first version, the one with the "until" loops...

I'm already thinking in a way to make it perfect... i mean it shouldn't be that hard right? I just need to make some variables that the pilot (user) can input according to the flight plan they want and with a little bit of help from ferram (to do the math) i should be able to make the program calculate the AoA for the desired conditions set by the player, and if this plugin can read data from FAR, that's it, it's just a matter for the player to input the altitude and speed desired, and then the program should calculate the AoA, for those values + the values it needs from far, and set the pitch to the correct AoA for those values... the software will take care of the throttle to maintain the desired speed all the way and that's all it needs...!!! omg... this is turning into an ambicious project that may end up being awesome!!!!

So let's start by asking the relevant questions... can kOS read all the values from FAR?

Edited October 31, 2014 by GabeTeuton
adding last bit (nice idea)

[Kertherina]

Use similar logics and vector maths to compare and compute the "up" vector of your vessel and the "up" vector of the body your vessel is orbiting.

Thank you for that hint, sadly i'm still stuck. I feel like i am overlooking something very obvious :/

I used two different approaches so far. One, i used the VANG function between SHIP:FACING:VECTOR and SHIP:UP:VECTOR to get pitch and similarly got the heading, but since this approach uses vectors there is just x,y and z but no roll information to work with (or am i wrong in that and just not seeing it?). (Link to script here)

The second one is the approach from the tutorial, though again there is no roll information (that i can see) since only vectors are used, and at the end of the tutorial it uses the roll information included in UP to lock the steering to an attitude with a defined roll value.

I don't see how doing something like in either of those two approaches with the up vector from the vessel and the up vector of the body to get the roll since i'd have to again use vectors and thus only get x, y and z information but not the roll.

Sorry to bother you again.

[Dunbaratu]

Thank you for that hint, sadly i'm still stuck. I feel like i am overlooking something very obvious :/

I used two different approaches so far. One, i used the VANG function between SHIP:FACING:VECTOR and SHIP:UP:VECTOR to get pitch and similarly got the heading, but since this approach uses vectors there is just x,y and z but no roll information to work with (or am i wrong in that and just not seeing it?). (Link to script here)

When you think of it, just like pitch can be obtained by the angle between UP and forward, roll can be obtained by the angle between UP and "my starboard". The starboard can be obtained by rotating SHIP:FACING by 90 degrees first:

Set rightDir to ( SHIP:FACING*R(0,90,0) ).

Set rightVec to rightDir:Vector.

Now take VANG(rightVec,SHIP:UP:VECTOR).

I may have the rotation wrong. It might be R(90,0,0) or R(0,90,0) or R(0,0,90) - I don't remember which axis it's supposed to be. But it's one of those.

The second one is the approach from the tutorial, though again there is no roll information (that i can see) since only vectors are used, and at the end of the tutorial it uses the roll information included in UP to lock the steering to an attitude with a defined roll value.

If possible, I'd like to see that wiki die.

It was from a bygone era when Nivek, the original author, didn't document and the documentation was maintained by the user community trying to guess how things worked. Some of what it says is wrong because it's out of date and some of it is wrong because it was wrong to begin with because people (me included) were trying to work it out from trial and error.

[Cairan]

Awesome to hear your kid is interested and it's great you are teaching him all those things haha, (i say those things cause i don't know for instance what procedural flow is).

Procedural programming was the only game in town before the event-driven programming came into being... yet even in triggered events, you still need a procedural algorithms. The good 'ol days of BASIC, COBOL and other stuff picking dust on my bookshelf was almost exclusively procedural only... you had to think from start to finish of an application all the events that could happen and when they could happen...

[Cairan]

If possible, I'd like to see that wiki die.

It was from a bygone era when Nivek, the original author, didn't document and the documentation was maintained by the user community trying to guess how things worked. Some of what it says is wrong because it's out of date and some of it is wrong because it was wrong to begin with because people (me included) were trying to work it out from trial and error.

...let's call a hitman then...

[erendrake]

So let's start by asking the relevant questions... can kOS read all the values from FAR?

0.14.2 cannot and 0.15 is a little bit of a complicated answer

0.15 will let you read from any value that is present on the Right-click menu for a part. FAR currently by default have much data in there but you can on all kinds of cool data that you can then access in kOS.

Some of the other values from far we cannot get but that will come in time.

[Dunbaratu]

I made some tweaking as i was trying to use it and some syntax errors showed up... the "when" doesn't go with {}, it needs "THEN" after the condition... IF on the other hands, does need {} instead of THEN

I have NEVER been happy with the fact that WHEN is a weird exception case that doesn't work with the same syntax as the rest of them.

It's an artifact left over from Nivekk's original design, where originally WHEN didn't allow curly braces and only allowed one statement. At that time it needed the THEN to be the keyword separating the boolean check from the code to run, like so:

WHEN x > 2 THEN print "x bigger than 2".

The problem is that if we remove it now, we'd have to make the curly braces *mandatory* rather than optional to do so, because the following cannot be parsed by a LL(1) parser:

WHEN x > 2 print "x bigger than 2".

It has to lookahead more than 1 step to see if there's more coming to the boolean check or if it's seeing the start of the statement.

Potentially, it would be possible to change the syntax so all of the following are legal:

WHEN x > 2 { print "x bigger than 2". }

WHEN x > 2 THEN { print "x bigger than 2". }

WHEN x > 2 THEN print "x bigger than 2".

But the following would not be legal:

WHEN x > 2 print "x bigger than 2".

That's still a bit inconsistent, but maybe not so bad as what it does now?

[falcoiii]

KSP .25 - windows 32 bit. KOS .142.

Running one main script that runs different mission scripts that run other small scripts. After a bunch of scripts are called to land on duna and relaunch to orbit, this error shows up. It appears after a small launch subscript is finished (dlaunch) and the mission script (ikemission) should go on to the next command (a print statement for debug purposes).

Here are a screenshot of the KOS window and a snippet from the KSP.log file showing a stack trace. Any help would be appreciated.

http://imgur.com/kmm9nzs

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

Packing 2b for orbit

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

Reference Frame: Inertial

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

Unpacking 2b

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

kOS: FlightControlManager: ToggleFlyByWire: throttle True

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

kOS: FlightCtrlParam: Enabled: throttle True

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

kOS: FlightControlManager: ToggleFlyByWire: steering True

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

kOS: FlightCtrlParam: Enabled: steering True

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

kOS: FlightControlManager: ToggleFlyByWire: throttle True

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

kOS: FlightCtrlParam: Enabled: throttle True

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

At ikemission on 1, line 1

copy dlaunch from 0.

^

Called from d on 1, line 19

run ikemission.

^

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

System.ArgumentOutOfRangeException: Argument is out of range.

Parameter name: index

at System.Collections.Generic.List`1[system.Object].get_Item (Int32 index) [0x00000] in <filename unknown>:0

at kOS.Execution.Stack.Pop () [0x00000] in <filename unknown>:0

at kOS.Execution.CPU.PopStack () [0x00000] in <filename unknown>:0

at kOS.Execution.CPU.PopValue () [0x00000] in <filename unknown>:0

at kOS.Function.FunctionCopy.Execute (kOS.SharedObjects shared) [0x00000] in <filename unknown>:0

at kOS.Execution.CPU.CallBuiltinFunction (System.String functionName) [0x00000] in <filename unknown>:0

at kOS.Compilation.OpcodeCall.Execute (kOS.Execution.CPU cpu) [0x00000] in <filename unknown>:0

at kOS.Execution.CPU.ExecuteInstruction (kOS.Execution.ProgramContext context) [0x00000] in <filename unknown>:0

at kOS.Execution.CPU.ContinueExecution () [0x00000] in <filename unknown>:0

at kOS.Execution.CPU.Update (Double deltaTime) [0x00000] in <filename unknown>:0

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

Code Fragment

File Line:Col IP opcode operand

---- ----:--- ---- ---------------------

1/ikemission 25:1 6555 return

1/ikemission 5:1 6556 push $program-dlaunch*

1/ikemission 5:1 6557 push 0

1/ikemission 5:1 6558 store

1/ikemission 14:1 6559 push $program-incline*

1/ikemission 14:1 6560 push 0

1/ikemission 14:1 6561 store

1/ikemission 21:1 6562 push $program-ike*

1/ikemission 21:1 6563 push 0

1/ikemission 21:1 6564 store

1/ikemission 25:1 6565 push $program-land*

1/ikemission 25:1 6566 push 0

1/ikemission 25:1 6567 store

1/ikemission 1:6 6568 push dlaunch

1/ikemission 1:6 6569 push from

1/ikemission 1:19 6570 push 0

1/ikemission 1:19 6571 call copy() <<--INSTRUCTION POINTER--

1/ikemission 3:7 6572 push starting dlaunch

1/ikemission 3:7 6573 call print()

1/ikemission 4:6 6574 push 2

1/ikemission 4:6 6575 wait

1/ikemission 5:1 6576 call 6516

1/ikemission 6:6 6577 push 2

1/ikemission 6:6 6578 wait

1/ikemission 7:7 6579 push done dlaunch

1/ikemission 7:7 6580 call print()

1/ikemission 8:6 6581 push 2

1/ikemission 8:6 6582 wait

1/ikemission 9:8 6583 push dlaunch

1/ikemission 9:8 6584 push null

1/ikemission 9:8 6585 call delete()

1/ikemission 10:8 6586 push warpfast

1/ikemission 10:8 6587 push null

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

Stack dump:

001 SubroutineContext: {CameFromInstPtr 99}

000 SubroutineContext: {CameFromInstPtr 40}

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

kOS: Popping context 2

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

kOS: FlightControlManager: ToggleFlyByWire: throttle False

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

kOS: FlightCtrlParam: Enabled: throttle True

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

kOS: FlightControlManager: ToggleFlyByWire: steering False

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

kOS: FlightCtrlParam: Enabled: steering True

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

kOS: Removed Context File Line:Col IP opcode operand

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

kOS: Deleting 0 pointers and restoring 0 pointers

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

kOS: New current context File Line:Col IP opcode operand

(Filename: C:/BuildAgent/work/d63dfc6385190b60/artifacts/StandalonePlayerGenerated/UnityEngineDebug.cpp Line: 49)

SCREENSHOT!!

[GabeTeuton]

0.14.2 cannot and 0.15 is a little bit of a complicated answer

0.15 will let you read from any value that is present on the Right-click menu for a part. FAR currently by default have much data in there but you can on all kinds of cool data that you can then access in kOS.

Some of the other values from far we cannot get but that will come in time.

In regards to this, I already have a basic idea of what i will need, I just need to write it somewhere other than my memory, and start ordering the data needed... I imagined that most of the FAR data I may need was not going to be accesible from kOS, but if those values are static it's just a matter of having the user of the autopilot set them... Once I have a clear idea of what i need, i'll post it here and also ask ferram how the math works...

I have NEVER been happy with the fact that WHEN is a weird exception case that doesn't work with the same syntax as the rest of them.

It's an artifact left over from Nivekk's original design, where originally WHEN didn't allow curly braces and only allowed one statement. At that time it needed the THEN to be the keyword separating the boolean check from the code to run, like so:

WHEN x > 2 THEN print "x bigger than 2".

The problem is that if we remove it now, we'd have to make the curly braces *mandatory* rather than optional to do so, because the following cannot be parsed by a LL(1) parser:

WHEN x > 2 print "x bigger than 2".

It has to lookahead more than 1 step to see if there's more coming to the boolean check or if it's seeing the start of the statement.

Potentially, it would be possible to change the syntax so all of the following are legal:

WHEN x > 2 { print "x bigger than 2". }

WHEN x > 2 THEN { print "x bigger than 2". }

WHEN x > 2 THEN print "x bigger than 2".

But the following would not be legal:

WHEN x > 2 print "x bigger than 2".

That's still a bit inconsistent, but maybe not so bad as what it does now?

At first, (let's say a couple of days ago), everything was pure chinese to me (native language for me being spanish), but now I kind of find it easier to understand code, and to even write it, (once it works haha), it's not that I have everything clear at all, 'cause that won't be true... but I feel I'm learning a little bit a time thanks to practice and of course thanks to you guys!