[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Dunbaratu]

@GabeTeuton :

Try changing this:

set ag9 to "set l to l+i".
set ag10 to "set l to l-i". 

To this instead:

on ag9 { set l to l+i. Preserve. }.
on ag10 { set l to l-i. Preserve. }. 
wait until false. // press CTRL-C in the terminal to end program or it will sit on this line forever.

You need to add a line similar to that "wait" at the bottom or else the program will just finish at the bottom and release all controls when it quits.

When a kOS program quits, it releases all its controls. You have to do something to keep it running for it to continue doing anything.

[mideg]

Hey everyone!

I hope I'm not in the wrong thread. I started using kOS a couple days ago after reading about it for some weeks. Since I use RemoteTech in my main (career) game, I was hoping I could use kOS to automate the first couple satellites for my RemoteTech communications network. (I know how to do it without, but I figured it's more fun to do a truly automated launch.)

Unfortunatly, after finally learning about the config-setting in kOS that's supposed to enable RemoteTech integration I tested that a couple days ago but kOS still looses control of the vessel after going out of range. Am I doing something wrong or does it currently not work? (It is supposed to override the lack of connection, right?)

If needed, I can do further testing.

I know that this was brought up before, but this is how I'd imagined it'd work: While in range, the control of a local run kOS-script circumvents the signal delay of RT. When not in range, a program that's running can still control the vessel without signal delay. Optionally program cannot be started while not in range and program starts are subject to signal delay, though the last two options are really just optional. I'd love to be able to make fully autonomous satellites with kOS and RT that don't require a satellite network to begin with or manned launches to start. :-)

Thanks and again I'm sorry if in the wrong thread.

[GabeTeuton]

Hey everyone!

I hope I'm not in the wrong thread. I started using kOS a couple days ago after reading about it for some weeks. Since I use RemoteTech in my main (career) game, I was hoping I could use kOS to automate the first couple satellites for my RemoteTech communications network. (I know how to do it without, but I figured it's more fun to do a truly automated launch.)

Unfortunatly, after finally learning about the config-setting in kOS that's supposed to enable RemoteTech integration I tested that a couple days ago but kOS still looses control of the vessel after going out of range. Am I doing something wrong or does it currently not work? (It is supposed to override the lack of connection, right?)

If needed, I can do further testing.

I know that this was brought up before, but this is how I'd imagined it'd work: While in range, the control of a local run kOS-script circumvents the signal delay of RT. When not in range, a program that's running can still control the vessel without signal delay. Optionally program cannot be started while not in range and program starts are subject to signal delay, though the last two options are really just optional. I'd love to be able to make fully autonomous satellites with kOS and RT that don't require a satellite network to begin with or manned launches to start. :-)

Thanks and again I'm sorry if in the wrong thread.

As far as I know, from videos I've seen last night, if the program you are running is on your vessels volume, it should run regardless of connection status, though you do need conection to access the console once and issue the run command, from then on connection status is my undertanding that is irrelevant, though if your program doesn't make it to the satellite orbit that you want, it's useless until you have a proper satellite network to contact this one, keep in mind that your software can open antennas, you should be able to make it open them above 40k mtrs and regain connection, the basic omni for remote tech, commutron 16 i believe has enough range to get almost to kerbostationary...

@Steven Mading thanks for that advise will try it as soon as i wake up!

[mideg]

As far as I know, from videos I've seen last night, if the program you are running is on your vessels volume, it should run regardless of connection status, though you do need conection to access the console once and issue the run command, from then on connection status is my undertanding that is irrelevant, though if your program doesn't make it to the satellite orbit that you want, it's useless until you have a proper satellite network to contact this one, keep in mind that your software can open antennas, you should be able to make it open them above 40k mtrs and regain connection, the basic omni for remote tech, commutron 16 i believe has enough range to get almost to kerbostationary...

Thanks for the quick reply.

I tested this, as said, thoug ofc I might have just done something else wrong. Here's what I did and what happened:

1. Installed just Mechjeb, kOS and RT2.
   
2. Launched sandbox game.
   
3. Constructed simple rocket (without Mechjeb-module or antenna).
   
4. Put rocket on launchpad, open kOS and enable the RT-setting.
   
5. Write a program that locks thrust to 1.0 and changes heading back and forth every couple seconds to see something.
   
6. At a certain height (once RT looses connection), the throttle cuts to 0.5. AFAICT the program is running but RT still prevents it from keeping throttle to 1.0 or changing the heading. Once the rocket drops back into connectivity range, kOS regains control.
   
7. Rince and repeat until out of fuel.
   

(Written down from memory, so there might be some inaccuracies in this report. As said, I can test this again, if needed.)

[madlemur]

Did you enable RT support in kOS? Also, manually kill your throttle before starting your program. Otherwise, your satellites will wander off as soon so the program ends.

[mideg]

Did you enable RT support in kOS?

I think so, yes.

Put rocket on launchpad, open kOS and enable the RT-setting.

[madlemur]

I think so, yes.

GameData/kOS/Plugins/PluginData/kOS/config.xml: set EnableRT2Integration to 1

[mideg]

GameData/kOS/Plugins/PluginData/kOS/config.xml: set EnableRT2Integration to 1

Does setting this setting ingame work, too?

[madlemur]

Does setting this setting ingame work, too?

How are you setting it in-game? Unless there's a configuration screen I haven't seen, you have to edit the config.xml file by hand.

[erendrake]

How are you setting it in-game? Unless there's a configuration screen I haven't seen, you have to edit the config.xml file by hand.

you can actually set all of the in game configuration in the terminal

http://ksp-kos.github.io/KOS_DOC/structure/config/index.html

[madlemur]

you can actually set all of the in game configuration in the terminal

http://ksp-kos.github.io/KOS_DOC/structure/config/index.html

Oh... Well, then... I'll go back to reading up on VT100/VT220 specs...

[erendrake]

Thanks for the quick reply.

I tested this, as said, thoug ofc I might have just done something else wrong. Here's what I did and what happened:

1. Installed just Mechjeb, kOS and RT2.
   
2. Launched sandbox game.
   
3. Constructed simple rocket (without Mechjeb-module or antenna).
   
4. Put rocket on launchpad, open kOS and enable the RT-setting.
   
5. Write a program that locks thrust to 1.0 and changes heading back and forth every couple seconds to see something.
   
6. At a certain height (once RT looses connection), the throttle cuts to 0.5. AFAICT the program is running but RT still prevents it from keeping throttle to 1.0 or changing the heading. Once the rocket drops back into connectivity range, kOS regains control.
   
7. Rince and repeat until out of fuel.
   

(Written down from memory, so there might be some inaccuracies in this report. As said, I can test this again, if needed.)

and you wrote this program on the local volume? it wasnt in the archive or the 0 volume? The remotetech integration is still in beta as of 0.14.2 which is why it is turned off by default. let me try it tonight and see if i have trouble with it.

[GabeTeuton]

Guys i'm trying really hard to make it work haha, but i believe i'm too much of an idiot to understand it... not sure what i'm doing wrong... i'm trying to learn how print works, and specifically how to keep a value printed as it changes... so i went to the wiki and first tried to print the resources, specially liquidfuel to then try to make the print stay there while consuming it... the wiki had the following example:

PRINT "THESE ARE ALL THE RESOURCES ON THE SHIP:".
LIST RESOURCES IN RESLIST.
FOR RES IN RESLIST {
  PRINT "Resource " + RES:NAME + ": value = " + AMOUNT +
        " which is " + ROUND(100*RES:AMOUNT/RES:CAPACITY) + "% full.".
}.

it says variable amount it not defined...

I want it to show me the liquid fuel while it's being consumed... nothing fancy, the goal is to learn how to make the print liquidfuel to stay there until the program ends...

HELP! haha

[Cairan]

I am puzzled as to the behaviour of kOS when calling other scripts... I've written an autoabort script which takes care of pulling the capsule away from a rocket during launch if things go south...

PRINT "A B O R T ! ! !".
LOCK THROTTLE TO 0.
LOCK STEERING TO UP.
WAIT 0.1.
RCS ON.
PRINT "MOVING AWAY ! ! !".
LOCK THROTTLE TO 1.
LOCK STEERING TO HEADING(270,80).
WAIT 3.
UNLOCK STEERING.
SAS ON.
LOCK THROTTLE TO 0.
PRINT "STANDBY FOR CHUTES ! ! !".
WAIT UNTIL SHIP:VERTICALSPEED < 0.
CHUTES ON.
RCS OFF.
SAS OFF.
WAIT UNTIL ALT:RADAR < 150.
LEGS ON.
WAIT UNTIL SHIP:VERTICALSPEED > -1.
PANELS ON.
LIGHTS ON.
SHUTDOWN.

It works great if I call RUN AUTOABORT from the terminal, but when I try

ON ABORT {
  RUN AUTOABORT.
}.

...and hit the ABORT key the abort action group triggers but even separatron engines linked to the action group do not engage, the chutes deploy and it ignores the WAIT / WAIT UNTIL directives and goes right to the end without pauses...

Any ideas on what is going on?

I've also tried calling RUN AUTOABORT from a test script with no triggers whatsoever, just a simple one-liner "RUN AUTOABORT" and it exhibits the same behaviour...

Edited October 29, 2014 by Cairan

[madlemur]

Guys i'm trying really hard to make it work haha, but i believe i'm too much of an idiot to understand it... not sure what i'm doing wrong... i'm trying to learn how print works, and specifically how to keep a value printed as it changes... so i went to the wiki and first tried to print the resources, specially liquidfuel to then try to make the print stay there while consuming it... the wiki had the following example:

PRINT "THESE ARE ALL THE RESOURCES ON THE SHIP:".
LIST RESOURCES IN RESLIST.
FOR RES IN RESLIST {
  PRINT "Resource " + RES:NAME + ": value = " + AMOUNT +
        " which is " + ROUND(100*RES:AMOUNT/RES:CAPACITY) + "% full.".
}.

it says variable amount it not defined...

I want it to show me the liquid fuel while it's being consumed... nothing fancy, the goal is to learn how to make the print liquidfuel to stay there until the program ends...

HELP! haha

You have a bare AMOUNT. Change it to RES:AMOUNT and you should be good.

[Dunbaratu]

it says variable amount it not defined

AMOUNT should be RES:AMOUNT.

looks like the doc is wrong.

[GabeTeuton]

You have a bare AMOUNT. Change it to RES:AMOUNT and you should be good.

Okay now it works, but how do i make like a resource panel to show me that those resources are being consumed... in other words, the full liquid fuel tank has 300 units, how do i make it stay on screen printed while updating??? 'cause the preserve command tells me it's just for when and on...

the whole point of this is to know how to keep the print on screen so i can see when i'm affecting L by adding I to it on the previous script.

Edited October 29, 2014 by GabeTeuton

[madlemur]

Okay now it works, but how do i make like a resource panel to show me that those resources are being consumed... in other words, the full liquid fuel tank has 300 units, how do i make it stay on screen printed while updating??? 'cause the preserve command tells me it's just for when and on...

the whole point of this is to know how to keep the print on screen so i can see when i'm affecting L by adding I to it on the previous script.

... Loop through resources, looking for the liquid fuel ...
LOCK LqdFuel TO RES:AMOUNT.

PRINT AT (0,0) "Liquid fuel:".

WHILE 1 {
  PRINT AT (13, 0) LqdFuel.
  WAIT.
}.

Note that the WHILE loop will be the only thing running, except for any UNTIL events. OK for maintaining the display, just be aware nothing else is happening...

edit: Also, I may have the PRINT AT syntax wrong... Check the docs...

[Kertherina]

Hello again, i have another problem.

I'm working on a custom steering algorithm now since LOCK STEERING is not working for my RSS rockets and i am stuck. I have figured out how to determine the real pitch and heading of the craft from "SHIP:FACING", but i don't know how to get the real roll and without the roll angle i can't use raw controls. After several hours of trying stuff and googling / looking in the forum i am near giving up, so any help would be very appreciated

Thanks in advance for any suggestions~

[madlemur]

Hello again, i have another problem.

I'm working on a custom steering algorithm now since LOCK STEERING is not working for my RSS rockets and i am stuck. I have figured out how to determine the real pitch and heading of the craft from "SHIP:FACING", but i don't know how to get the real roll and without the roll angle i can't use raw controls. After several hours of trying stuff and googling / looking in the forum i am near giving up, so any help would be very appreciated

Thanks in advance for any suggestions~

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.

[Cairan]

Greetings to all...

I've resolved my issues by hacking together a little trick...

I set a flag with the abort status, both in memory and on the kOS volume:

ON ABORT {
  SET EDS TO 1.
  SWITCH TO Kerbston.
  LOG "ABORT" TO ABTSWF.
}

Then, in my display update routine, I added a flag check, which reboots the kOS module on aborts:

IF EDS = 1 {
  PRINT "ABORT" AT (2,2).
  UNLOCK ALL.
  REBOOT.
} ELSE {
...
}.

Finally, I added a check in my bootloading script which, on reboot, looks for a file named "ABTSWF" (Abort Switch File).

// Bootloader
// This script will copy every program in the Archive into Volume 1.
CLEARSCREEN.
SET ABTSW TO 0.
RENAME VOLUME 1 TO Kerbston.
SWITCH TO Kerbston.
LIST FILES IN ls.
FOR file IN ls {
  IF file = "ABTSWF" {
    SET ABTSW TO 1.
  }.
}.
IF ABTSW = 1 {
  RUN AUTOABORT.
} ELSE {
...
}.

It is not as elegant as I'd like, but it now works flawlessly. So from any scripts I can now set a local file for, reboot, and if the file exists it triggers the automated abort routine.

[mideg]

and you wrote this program on the local volume? it wasnt in the archive or the 0 volume? The remotetech integration is still in beta as of 0.14.2 which is why it is turned off by default. let me try it tonight and see if i have trouble with it.

I'm not sure anymore, it's been some days. I'm sure though that if I wrote it on archive, I've copied it before running. I watched out for those things as that was what I wanted to test. :-)

[Darren9]

Could someone explain how to, or link to an example of "get a handle on a part", long story short I want to switch control to a second command pod, it's a unique part, I know its name, how would I select it and apply the "SET PART:CONTROLFROM" to it?

Thanks in advance.

[hvacengi]

I am puzzled as to the behaviour of kOS when calling other scripts... I've written an autoabort script which takes care of pulling the capsule away from a rocket during launch if things go south...

...snip...

Any ideas on what is going on?

I've also tried calling RUN AUTOABORT from a test script with no triggers whatsoever, just a simple one-liner "RUN AUTOABORT" and it exhibits the same behaviour...

I see that you posted what you found as a work around. The issue is that the "on" trigger can't contain much logic, since it interrupts the virtual cpu stopping all other functions until the code finishes. Wait commands get ignored in it, as do run commands. Your work around is really the best option. Use the trigger to set a flag to true when the trigger occurs, and then maintain an loop that checks these flags. Since it sounds like you have a loop that updates the screen regularly anyways, using that existing loop was a great idea. In a more simple application, you can also use "wait until" to block the processing until that flag flips true. (for instance, if you wanted to just wait to launch until you activated ag1).

It's easy to mix up interrupts with the way that events work in a multi-threaded environment. It was probably the most frustrating lesson to try and learn when I moved from PC programming to microcontroller programming.

[hvacengi]

I'm not sure anymore, it's been some days. I'm sure though that if I wrote it on archive, I've copied it before running. I watched out for those things as that was what I wanted to test. :-)

For a while, I would include the line to enable RT2 support at the beginning of every boot script (just because I was paranoid). But in my experience, kOS still has control when leaving comm range, I've even had code executed on the far side of the sun.

Do you know what version of kOS you are using and of RemoteTech? RemoteTech made a change at version 1.5 (iirc) that forced erendrake to change the internal checks in kOS. So if you have a version mismatch, it will behave the way you've described. That would be the first place I'd check.