[1.3] kOS Scriptable Autopilot System v1.1.3.0

[DomDiaemus]

Pardon for this basic question if has been put before in all these pages... but under which directory are the saved scripts located since this doesn't seem to be covered on the wiki and references. Thanks

[Astraph]

Ok, I'm at a loss.

I've been trying to write a short program that'd basically allow my probe to get down to Eve with its antennas retracted, but I just can't get a hold of the throttle command:

clearscreen.
Print "Initiating landing procedure".

Print "Step 1: Retrograde thrust".
lock steering to retrograde.
wait 10.
lock throttle to 1.0.

when ship:altitude < 100 then {
Print "Step 2: Atmospherical reentry".
lock throttle to 0.0.
lock steering to prograde.
toggle AG2.
}.

when ship:altitude < 10000 then {
Print "Step 3: Deploying chutes".
Stage.
wait 2.
lock steering to up.
toggle legs.
}.

when ship:surfacespeed = 0 then {
Print "Landed safetly".
toggle AG2.
}.

The first three lines fire smoothly - I get the message, the craft turns retrograde, waits 10 secs... And I get a "program ended" message, with no burn performed. When I tried typing "loch throttle" command manually, it worked well... :/ I'm using a 64-bit build - could this be causing some issues?

[TDW]

but under which directory are the saved scripts located

The scripts are saved to the active volume (either on the current kOS core or whichever you have switched to) Scripts saved to a kOS core are saved in the persistence file (save game file) in the ship structure. Scripts saved to the Archive (volume 0) are in .../Kerbal Space Program/Plugins/PluginData/Archive/.

@Astraph

Camach did a better job of explaining this than my garbled attempt so i will quote.

There is nothing to keep your script from ending, so it ends. When does something else than until and while. Those last two loop the script, the last one will only be triggered when the situation occurs but will be passed over until then. Since there is nothing more to run, the script ends.

If you use "WAIT UNTIL" instead of "WHEN .... THEN" your script should work.

clearscreen.
Print "Initiating landing procedure".

Print "Step 1: Retrograde thrust".
lock steering to retrograde.
wait 10.
lock throttle to 1.0.

WAIT UNTIL ship:altitude < 100.
Print "Step 2: Atmospherical reentry".
lock throttle to 0.0.
lock steering to prograde.
toggle AG2.

WAIT UNTIL ship:altitude < 10000.
Print "Step 3: Deploying chutes".
Stage.
wait 2.
lock steering to up.
toggle legs.

WAIT UNTIL ship:surfacespeed = 0.
Print "Landed safetly".
toggle AG2.

Edited October 19, 2014 by TDW

[Astraph]

OK, will try this, thanks My only doubt: I understand why the code terminates at "when"; but why doesn't the lock throttle command fire up?

[TDW]

why doesn't the lock throttle command fire up?

It does . When it is used in a script LOCK THROTTLE will revert back to the default / what ever it was set to before you ran the script when the script ends. Because your script ends so soon after locking the throttle (possibly within a single physics update) you don't see any sign that it has run.

[Astraph]

Oh. Now this makes perfect sense Once I get back to KSP in the evening I'll test the updated code - many thanks again!

[Trewor007]

Hi.

Can someone help me with, a clock formula for a rover.

I divided the distance by speed and I get number of seconds remaining. I got the program to show minutes and seconds but im strugling to write a corect code for hours and sadly i cant put a :clock sufix on it

I would be very grateful for some tips.

set czas to spot:distance/gaz.
set minuty to round(czas/60).
set sekundy to mod(czas, 60).

[TDW]

@Trewor007

You should be able to do:

set czas to (time + spot:distance/gaz) - time.
print czas:clock.

This should force the variable from a number to a time, so that you can use :clock.

If you want to do it by calculations (i am assuming that czas is the time you have calculated) then

Set hours to floor(czas/3600). // 3600 is 60 seconds *60 minutes (note floor always rounds down so 59min will round to 0 hours not 1).
Set min to floor((czas-hours*3600)/60). // take the time in seconds then remove the number or hours (in seconds) and / 60 to get minutes.
Set sec to round(czas - min*60 - hours*3600). // seconds remaining after you remove the hours and minutes already accounted for.

[Trewor007]

Thank for the info. The program runs smooth witch the 2 method. KOS didn't want a suffix on a double.

[Camacha]

Just a bit of teaser to tide people over while we keep plugging away at kOS v0.15

I am looking forward to this, although I already loathe the amount of time I will burn playing with this

[SnappingTurtle]

Hi, I got kOS a few days ago to work with RemoteTech 2. I've been looking at the wiki to try to understand it and came up with this script to execute a circularization burn since I could see the probe would be out of contact at that time. I used the following script but it never stopped waiting for nextnode:eta < 2.

print "Executing next node".

sas off.

lock steering to nextnode:burnvector.

wait until nextnode:eta < 2.

lock throttle to 1.

wait until nextnode:deltav:mag < 10.

lock throttle to 0.

unlock steering.

sas on.

print "Node complete".

I looked at the node executor in the maneuvering modules of the wiki but the script was too complicated, not well commented and relied on other scripts. It looked like something made to be used rather than understood so it didn't help me much.

Can someone tell me why my script didn't work? Thanks.

[erendrake]

Hi, I got kOS a few days ago to work with RemoteTech 2. I've been looking at the wiki to try to understand it and came up with this script to execute a circularization burn since I could see the probe would be out of contact at that time. I used the following script but it never stopped waiting for nextnode:eta < 2.

I looked at the node executor in the maneuvering modules of the wiki but the script was too complicated, not well commented and relied on other scripts. It looked like something made to be used rather than understood so it didn't help me much.

Can someone tell me why my script didn't work? Thanks.

There is a config setting to turn on remoteTech integration. In the terminal type

SET CONFIG:ENABLERT2INTEGRATION TO True.

you can also go into the kOS plugin folder and find the config file and change the value manually.

[SnappingTurtle]

Thanks for the info, I've changed the config now. Is that why the script wasn't working? It did turn off SAS and hold its heading correctly but it never opened the throttle.

[Camacha]

Thanks for the info, I've changed the config now. Is that why the script wasn't working? It did turn off SAS and hold its heading correctly but it never opened the throttle.

Are you sure the condition wait until nextnode:deltav:mag < 10 isn't met the second you enter the loop?

[SnappingTurtle]

I wrote that code for a specific burn which was about 185m/s. The engine never fired up. It's hard to repeat test these things on a hard mode save file. I was going to make an easy mode sandbox save to test this stuff until I remembered I'd have to launch a constellation of comsats which would take some doing.

Edited October 21, 2014 by SnappingTurtle

[Camacha]

I wrote that code for a specific burn which was about 185m/s. The engine never fired up. It's hard to repeat test these things on a hard mode save file. I was going to make an easy mode sandbox save to test this stuff until I remembered I'd have to launch a constellation of comsats which would take some doing.

Debugging in a hard mode save can be... painful. Good luck

[NoPanShabuShabu]

Hi, I got kOS a few days ago to work with RemoteTech 2. I've been looking at the wiki to try to understand it and came up with this script to execute a circularization burn since I could see the probe would be out of contact at that time. I used the following script but it never stopped waiting for nextnode:eta < 2.

I looked at the node executor in the maneuvering modules of the wiki but the script was too complicated, not well commented and relied on other scripts. It looked like something made to be used rather than understood so it didn't help me much.

Can someone tell me why my script didn't work? Thanks.

I think it might work if you set the nextnode to a variable and use that:

...

set x to nextnode.

lock steering to x:burnvector.

wait until x:eta < 2.

lock throttle to 1.

wait until x:deltav:mag < 10.

...

[SnappingTurtle]

Well that's... interesting. I'll try that next opportunity I get.

Edit:

For future reference that solution does work.

Edited October 23, 2014 by SnappingTurtle

[Dunbaratu]

Debugging in a hard mode save can be... painful. Good luck

Yeah the only way to run "simulations" in your hard mode game is to copy the game folder to a new name and play in there. I don't consider that "cheating" because it's like running the autopilot inside a simulator which a real space program would have a chance to do. It only becomes "cheating" if you then copy the effect of the test back into the main game, because then you're esentially just allowing yourself a "revert to VAB" option through the back door (and I assume that you're playing hard mode to avoid "revert to VAB").

I've always been annoyed that the main game doesn't have a "simulator" mode. It would be a lot LIKE having a revert to VAB but instead of choosing *after* you see the results whether or not you'd like to keep them, you decide *before* you lift off whether or not you'll be keeping the results. "Revert" lets you try and then decide to keep the result if it worked, or undo it if it failed. "Simulate" would require that you pick FIRST and commit to whether or not this flight will "really count" or not before you see how it goes. At some point after trying it a few times in simulate mode, you'd have to commit to the "real thing" and then that flight wouldn't be revertable.

Actually, that sounds like an easy mod to make - it would just copy the savegame folder to a new save, let you jump into it, run a while, and then return back, with the caveat that it will not retain the new savegame folder and it will remove it the next time you go back to the KSC.

[Camacha]

I've always been annoyed that the main game doesn't have a "simulator" mode. It would be a lot LIKE having a revert to VAB but instead of choosing *after* you see the results whether or not you'd like to keep them, you decide *before* you lift off whether or not you'll be keeping the results. "Revert" lets you try and then decide to keep the result if it worked, or undo it if it failed. "Simulate" would require that you pick FIRST and commit to whether or not this flight will "really count" or not before you see how it goes. At some point after trying it a few times in simulate mode, you'd have to commit to the "real thing" and then that flight wouldn't be revertable.

Squad once explained they do not see a simulator mode as viable because it would force people to launch and, if successful, do the exact same thing again. I can see how this would be unintersting for the majority of the players, which can probably be considered pretty casual players. If you are more into roleplaying a space program, like a lot of people obviously are too, it suddenly becomes a much more interesting and necessary option.

Nothing a little restraint will not solve, but having it for real would be a bit more fun. I tend to use a seperate save and Hyperedit for this purpose, though even then some restraint is needed, as NASA had trouble properly testing supersonic Mars parachutes too. Some things are just hard to emulate in an Earth/Kerbin environment. That being said, the KSC desperately needs some testing facilities, wind tunnels, sand pits et cetera.

Actually, that sounds like an easy mod to make - it would just copy the savegame folder to a new save, let you jump into it, run a while, and then return back, with the caveat that it will not retain the new savegame folder and it will remove it the next time you go back to the KSC.

I seem to recall seeing a mod that did pretty much that not too long ago, but I cannot find it right now. I will have another look for you later.

Edited October 21, 2014 by Camacha

[TDW]

The kerbal construction time mod does simulated launches for a minor cost (it also handles spent stage recovery and makes rescue missions challenging when you have a life support mod)

[Lorentz]

Is there a kOS "best practices" tutorial anywhere? If not, I am willing to (help) write it as I have learned a lot about what seems to work and what doesn't. I imagine it to be a "Part 2" after the Quick Start Tutorial. Or maybe the "game" is to figure these out yourself? What do you guys think?

BTW, I love this mod! Easily the best among the large number I've tried.

[Camacha]

The kerbal construction time mod does simulated launches for a minor cost (it also handles spent stage recovery and makes rescue missions challenging when you have a life support mod)

I know of that one, but I think I saw another one that just does simulation. I feel the Construction Time mod is a little... contrived.

[madlemur]

OK, in a likely futile attempt to spur myself into action, I'm going to try to get an RPM integration done. Maybe just a read-only display for now, but we'll see what can be done. Possibly a custom-made volume navigator to manage and run scripts. And it'll have to be able to switch from CPU to CPU, too... Hrmmm... That means I need to enumerate all the kOS CPUs and volumes (separately, since there's at least one volume that has no CPU, and mayhap we'll soon have a decoupling of CPUs and volumes).

I'll be thrilled just to get a single-CPU vessel to display anything on an RPM screen...

[erendrake]

OK, in a likely futile attempt to spur myself into action, I'm going to try to get an RPM integration done. Maybe just a read-only display for now, but we'll see what can be done. Possibly a custom-made volume navigator to manage and run scripts. And it'll have to be able to switch from CPU to CPU, too... Hrmmm... That means I need to enumerate all the kOS CPUs and volumes (separately, since there's at least one volume that has no CPU, and mayhap we'll soon have a decoupling of CPUs and volumes).

I'll be thrilled just to get a single-CPU vessel to display anything on an RPM screen...

Advice i would give anyone trying to do this:

Start with the very simplest and smallest form first. If there is enough interest in that then you can expand it to cover more and more cases. I am excited to see this