[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Dunbaratu]

Right, as I started to doubt myself at this point, I thought it was time to quantify things. After looking around I found that FRAPS is able to output frames per second versus time.

Your output seems to indicate that the only problem case is when the SCS parts exist and are actually running kOS code, which is what I'd have expected and wouldn't consider a bug but just normal behavior. Adding them but leaving them powered off seems to have no effect, (which differs from what you reported earlier that had left me baffled.)

The only real condition remaining that may be a real problem is if leaving them turned on but not running code also gives you a similar dip as leaving them powered on AND running code. That data which isn't shown yet, is the clincher.

[WandusPrime]

hi, first lemme say amazing mod!

I'm not sure if i installed it right, or maybe i missed something while installing it but every time i open a file a second screen comes up, and i have to do my code there. is this intended? doesn't seem like it would be because i didn't see this screen in any of the videos.

-ok that pic didnt work. let me set it up better.

-ok pic working now.

Edited October 11, 2014 by WandusPrime

[Camacha]

Your output seems to indicate that the only problem case is when the SCS parts exist and are actually running kOS code, which is what I'd have expected and wouldn't consider a bug but just normal behavior. Adding them but leaving them powered off seems to have no effect, (which differs from what you reported earlier that had left me baffled.)

I ran the second test (no kOS unit in world, kOS installed) again and this time it represents my experience a little better, though the graph does not show the actual nature of the lag that well as I think the dips are smoothed out by how FRAPS records things. The game is running smoothly, however, every few seconds the screen just freezes for a fraction of a second. It is rather reminiscent of the behaviour of the earlier bug where KSP would lag when running a looped script. After that everything looks and feels fine again and the frames per second quickly climb back to 75 fps mark. This start-stop nature makes it a little annoying.

You know what, I am a bit tired, so tomorrow I will make sure I have eliminated all other factors and will test again, just to make sure I am not overlooking anything obvious. I wouldn't want to bother you with something that is not a real problem.

Edit: tested a third time with results matching the first one. I have no idea what is going on.

Y = frames per second, X = time in seconds.

Edited October 11, 2014 by Camacha

[Dunbaratu]

I ran the second test (no kOS unit in world, kOS installed) again and this time it represents my experience a little better, though the graph does not show the actual nature of the lag that well as I think the dips are smoothed out by how FRAPS records things. The game is running smoothly, however, every few seconds the screen just freezes for a fraction of a second. It is rather reminiscent of the behaviour of the earlier bug where KSP would lag when running a looped script. After that everything looks and feels fine again and the frames per second quickly climb back to 75 fps mark. This start-stop nature makes it a little annoying.

You know what, I am a bit tired, so tomorrow I will make sure I have eliminated all other factors and will test again, just to make sure I am not overlooking anything obvious. I wouldn't want to bother you with something that is not a real problem.

Edit: tested a third time with results matching the first one. I have no idea what is going on.

http://tweakers.net/ext/f/l1liQtIFkL4nWSfe0JyGUjH1/full.png

Y = frames per second, X = time in seconds.

This is going to be very hard for me to work with personally if it does turn out to be a real provable problem because I never get anywhere near 60 FPS in the first place when running stock, not even close, so a problem that's only noticable on a faster computer is going to be one I can't reproduce in front of my own eyes to debug it. I don't know if erendrake can.

[Dunbaratu]

hi, first lemme say amazing mod!

I'm not sure if i installed it right, or maybe i missed something while installing it but every time i open a file a second screen comes up, and i have to do my code there. is this intended?

If you're talking about the editor window, then that's normal. It was easier to use the textedit widget built in to Unity than it was to keep the old in-terminal one working.

[WandusPrime]

ok thx, just wanted to make sure i had everything hooked up right.

[madlemur]

If you're talking about the editor window, then that's normal. It was easier to use the textedit widget built in to Unity than it was to keep the old in-terminal one working.

Also, you can edit the files in (KSP home) /plugins/plugindata/archive or somewhere close to that. Currently, they are. txt files, and any edits you make are immediately available from the archive.

On my phone, so hopefully I'm understandable, or some kind soul will explain better. Frankly, I dislike the editor, and use vim to directly edit the scripts.

[Camacha]

Frankly, I dislike the editor, and use vim to directly edit the scripts.

The editor is nice when you need to quickly test or adjust something, but for comprehensive coding an external editor is much preferred.

[FrancoisH]

This plug in is fabulous. I spent a night trying to make a nice launch sequence to launch my 3 staged rocket.

I ran into some problems because I attempted to do an auto-staging but, was quite hard to get it working.

I had to set variable for liquid fuel being used or not at the current stage because the initial solid fuel boosters were staged by the liquid fuel routine and same for the liquid one. Took me some time to understand what was happening!

I had to rotate my ship because the tutorial way made my rocket not rolling to the correct pitch but doing a turn and so being of trajectory... I got another issue trying to mess out with the heading thing and my rocket this time does a 270° turn... so I finally ended up rotating it and using vectors rather than the shortcuts.

I would like to know if there's a better way to handle this, maybe i didn't spent enough time reading the documentation.

As well, I would like to know if there's a way to set the throttle to 0 or check if it's at 0 before launch, if I don't, when the program terminate, it revert to the previous setting, so you could screw your orbit.

Below is the code, please tell me what you think of it. (was my first attempt).

P.S. The Ignition/Launching part is to release the clamps 1sec after ignition.

CLEARSCREEN.


PRINT "Launching sequence. Set your throttle to 0...".


WAIT 5.


SET cd TO 5.
PRINT "Launching in...".
UNTIL cd = 3 {
   PRINT "..." + cd.
   SET cd TO cd - 1.
   WAIT 1.
}.


PRINT "...3 - Throttle and steering locked.".
LOCK THROTTLE TO 1.0.
LOCK STEERING TO R(0,305,180).
WAIT 1.


PRINT "...2".
WAIT 1.


PRINT "...1 - Ignition...".
STAGE.
WAIT 1.


PRINT "...0 - Launching...".
STAGE.
WAIT 5.


PRINT "Rotating...".
LOCK STEERING TO HEADING(90,90).


SET Liquid TO 0.


WHEN STAGE:SOLIDFUEL < 0.10 THEN {
   IF Liquid = 0 {
      PRINT "Staging now...".
      STAGE.
      SET Liquid TO 1.
   }.
}.


WHEN SHIP:ALTITUDE > 10000 THEN {
   PRINT "Initiating turn. Aiming to 45° pitch...".
   LOCK STEERING TO HEADING(90,45).
}.


WHEN STAGE:LIQUIDFUEL < 730.00 THEN {
   IF Liquid = 1 {
       PRINT "Staging now...".
       STAGE.
       SET Liquid TO 2.
   }.
   IF Liquid <= 1 {
      PRESERVE.
   }
}.


WHEN SHIP:ALTITUDE > 40000 THEN {
   PRINT "Initiating turn. Aiming to 90° pitch...".
   LOCK STEERING TO HEADING(90,0).
}.


WAIT UNTIL APOAPSIS > 100200.
PRINT "Expected apoapsis altitude > 90km...".
LOCK THROTTLE TO 0.0.
LOCK STEERING TO PROGRADE.
WAIT 2.
PRINT "Waiting for circularisation...".


WAIT UNTIL ETA:APOAPSIS < 15.
PRINT "Beginning circularisation...".
LOCK THROTTLE TO 1.0.


WAIT UNTIL PERIAPSIS > 99500.
PRINT "Circularisation complete...".
LOCK THROTTLE TO 0.0.
PRINT "CAUTION: Be sure your throttle in off. Terminating in 10 seconds".
WAIT 10.

Edited October 12, 2014 by FrancoisH

[Dunbaratu]

As well, I would like to know if there's a way to set the throttle to 0 or check if it's at 0 before launch, if I don't, when the program terminate, it revert to the previous setting, so you could screw your orbit.

Yeah the way kOS works was perfect before SQUAD made their annoying decision to default the throttle to 50% instead of the sane and sensible 0% it used to be. The logic is "when the software quits, leave the throttle back the way it was when the program was first begun." That handled both the case where you want a script that controls the rocket from the start or when you want a script that just does one small thing then returns to full manual control afterward. The change squad made screwed us and no matter what solution we pick it will be wrong for some cases that it previously worked for.

The solution I'd prefer is to be able to override the controls with a setting to put them back to when the program quits, and have this be a setting you manually create at the start of the script, something like this:

Set EXIT_CONTROL:THROTTLE to 0.0.

Set EXIT_CONTROL:BRAKES to True.

SET EXIT_CONTROL:... etc....

.. DO rest of program here...

Then whenever the program exits, whether from intentional exit or from premature error, it uses those settings as it quits.

That would be my preferred solution as it allows the greatest flexiblity. But at the moment it's not there yet. One consequence of this is that if you run a program automatically as soon as it is on the launchpad, using the boot feature, you never had the chance to set the throttle to zero before the program started ,so the program is incapable of leaving it at zero when it stops. The boot system is sort of unusable at this point as a result of the fact that the only way to make the program able to put the throttle at zero when it's over is to manually zero the throttle before you start the launch program.

[Dunbaratu]

I found out what's been causing the problem that causes fuel to not burn all the way to zero some of the time. The problem is that KSP itself *tries* to burn oxidizer and liquidfuel in the right amounts causing both to reach zero together. But it's doing this using floating point numbers registering very tiny incremental changes each lasting only a fraction of a second. That sort of operation causes the tiny floating point precision errors to compound on top of themselves thousands of times over. What this means is that some of the time the ratio of liquidfuel to oxidizer consumption isn't exactly 9 to 11 like it's meant to be, and therefore one runs out a little bit before the other does.

When you see the liquidfuel in the resource bar still sitting at 0.01 and it won't burn down to zero, it's because the oxidizer is at 0.0 but you're not seeing the oxidizer bar to notice this.

So all the places where people have been doing this check:

if stage:liquidfuel < 0.01

to try to catch not-quite-zero fuel, you can probably get the effect you want by checking BOTH liquid and oxidizer like so:

if stage:liquidfuel = 0 OR stage:oxidizer = 0

To catch the case where one ran out before the other did.

[Camacha]

My preference would be to have a set throttle and lock throttle command. The function of the latter is known, the former will leave the user able to interfere with it - so it is possible to control the craft together with kOS - and does not return after ending a script. It is just as if a second user is messing with the throttle.

A third command of reading the actual current throttle setting might be useful. I think the current lock command is useful, but it can be a bit of a pain that the user is totally locked out while kOS is interacting with the vessel. Having the two options does not only makes sense looking back at how kOS and KSP used to do things, it will also allow users to implement safety controls where he can use and/or interfere with operations until a safety limit is reached. By that point the system can take over and lock the user out until everything is returned to a safe condition again.

[dr.phees]

I have a VTOL design, where I use twekables to balance the vertical thrust (reduce thrust for one of the engines). But when using kOS's maxthrust query, I only get the maximum thrust value for the untweaked engines. Using TWR to calculate throttle settings is impossible that way.

I can work around that with the :SENSORS:ACC query, but still, would be nice. Also, tweaking the engine from within kOS would allow to balance unstable craft (losing an engine and similar). That would be brilliant. Oh, and getting the thrust and maxthrust as a vector would be brilliant. That would actually allow hovering together with perpendicular engines to work.

My wish list would be:

- maxthrust AND/OR tweaked maxthrust

- actual thrust

- tweaking or engine thrust via kOS

- maxthrust/tweaked maxthrust/actual thrust as vectors

Nice checklist, eh?

By the way, 0.14.2 is working fine, so far. All my old scripts seem to work and I am very much looking forward to the coming changes!

[Dunbaratu]

My preference would be to have a set throttle and lock throttle command. The function of the latter is known, the former will leave the user able to interfere with it - so it is possible to control the craft together with kOS - and does not return after ending a script. It is just as if a second user is messing with the throttle.

Whatever solution happens *MUST* deal with the fact that scripts can crash unexpectedly in the middle from a runtime error. Thus why I'm talking about the idea of being able to set the exit throttle - which has no current effect but tells the system where to put the throttle upon program crash or exit. Reading throttle is useful but doesn't do anything if you are helpless to tell the script where to put the throttle when it's done.

Annoyingly, it seems the way KSP deals with mods fiddling with controls is that you put a control override on TOP of the user's controls, rather than adjusting the user's own controls themselves, which makes the things you're talking about hard to do. I agree that it would be better that way, but I'm not sure yet how it could be implemented.

[Camacha]

Whatever solution happens *MUST* deal with the fact that scripts can crash unexpectedly in the middle from a runtime error.

Ideally kOS would just leave the throttle where it was when the script crashed, though I am unaware of the technical implications and limitations of that. I see it pretty much as the rocket engine valve(s) being left at the position they were in. It's the same as would happen if you knock a human controller over the head with a structural plate.

Annoyingly, it seems the way KSP deals with mods fiddling with controls is that you put a control override on TOP of the user's controls, rather than adjusting the user's own controls themselves, which makes the things you're talking about hard to do. I agree that it would be better that way, but I'm not sure yet how it could be implemented.

I would love to build a kind of fly by wire system that keeps your antics in check and slaps your wrist when you get too giddy. I'm sorry Jeb, I'm afraid I can't do that.

Additionally, it would be really nice if you could achieve complete separation from the system, i.e. disconnecting the user inputs and the kOS outputs totally to get a true and proper fly-by-wire system. That would enable you to design alternate input methods, such as a Canadarm type system, walking robots and other complex movements. I do realize that this would complicate matters tremendously, so just getting KSP to let us directly fiddle with the inputs without locking the user out would be pretty useful and nice already.

Edited October 12, 2014 by Camacha

[Whirligig Girl]

How do I load something from a folder? in Gamedata/kOS/Plugins/PluginData/archive is kerbal2.txt. I would like to load this script.(I created /archive, because I saw some stuff about it in other threads in other places). Typing

run Kerbal2

does not work.

EDIT: also, is there any way to streamline this:

wait 1.
print "Five".
wait 1.
print "Four".
wait 1.
print "Three".
wait 1.
print "okay, two now.".
wait 1.5.
print "ONE!".
wait 0.2.

Edited October 12, 2014 by GregroxMun

[Camacha]

How do I load something from a folder? in Gamedata/kOS/Plugins/PluginData/archive is kerbal2.txt. I would like to load this script.(I created /archive, because I saw some stuff about it in other threads in other places). Typing

run Kerbal2

does not work.

You have to either switch to Archive first, or copy from Archive.

copy Kerbal2 from 0.
run Kerbal2.

switch to 0.
run Kerbal2.

EDIT: also, is there any way to streamline this:

Not in that way, but something like this might do:

clearscreen.
//Just to make sure.

set count to 5.
print "Launch in" at (0,0).
until count < 1 {
  print count at (10, 0)
  set count to count - 1.
  wait 1.
}.

Edited October 12, 2014 by Camacha

[Whirligig Girl]

Okay, so that didn't work. Is my Archive set up correctly?

File 'kerbal2' not found
at interpreter history, line 2
run Kerbal2.
    ^ 

Edited October 12, 2014 by GregroxMun

[Dunbaratu]

How do I load something from a folder? in Gamedata/kOS/Plugins/PluginData/archive is kerbal2.txt.

Wrong location.

kOS currently violates the "put everything in gamedata" rule for reasons I don't really agree with, and instead puts them here:

Plugins/PluginData/Archive/

NOT HERE:

GameData/kOS/Plugins/PluginData/Archive.

[Whirligig Girl]

Aaaarg! Now I got it working, but it ends after the first staging event! (launch event) throttle back. Here's the code:

clearscreen.
toggle SAS.
toggle RCS.
lock throttle to 1.0.
wait 1.
print "Five".
wait 1.
print "Four".
wait 1.
print "Three".
wait 1.
print "okay, two now.".
wait 1.5.
print "ONE!".
wait [U]1.0[/U]
print "launch now, dammit!".
stage. 
when ship:surfacespeed >90 then lock throttle to [U]0.6.[/U] //it ends here for some reason.
[I]when ship:surfacespeed >200 then lock throttle to 0.4.[/I]
when stage:[U]liquid[/U]fuel <0.001 then {print "Out of fuel ya git, now stage me for kraken's sake!". stage.}.
when ship:verticalvelocity <0 then {print "We're falling! deploy the kraken-damn parachute you piece of Kerbal Krap!". wait 2. stage.}.

EDIT: I fixed "fuel" by changing it to "liquidfuel", yet it still ends at the same place.

EDIT2: Also fixed 6.0. to 0.6.

EDIT3: Added another throttleback, shown in the code with italics. fixed code is underlined. Still stops after Lock Throttle to 0.6.

EDIT4: Another little bit is I changed 0.2 to 1.0 in the last wait before launch.

Edited October 12, 2014 by GregroxMun

[Camacha]

I am sad to report that I am still getting the tiny lags. A fresh installation and no problem, but adding a kOS unit causes the behaviour. I am still not sure about what exactly is going on when no kOS unit is loaded, but it is very clear when a unit is. Everything just freezes for one to three tenths of a second or so, having a much more severe impact than the dips in the charts I posted yesterday suggest.

[Whirligig Girl]

kOS has caused no lags for me. Keep in mind that 0.25 does NOT even SLIGHTLY support x64 KSP.

But I'm still getting problems with coding, because I'm a n00b at coding.

[Camacha]

Is there a way of doing operations on strings? Looking for certain phrases or combinations of letters, cutting off the beginning or the end, that kind of stuff? For as far as I can tell this is only possible with numbers, not with strings. Is that right?

kOS has caused no lags for me. Keep in mind that 0.25 does NOT even SLIGHTLY support x64 KSP.

That's not relevant, as I do not run x64. I must say the lag is more pronounced on a clean installation, as a more cluttered one tends to be less smooth anyway.

But I'm still getting problems with coding, because I'm a n00b at coding.

That's the only way to learn.

Edited October 12, 2014 by Camacha

[Whirligig Girl]

Well some indication as to what's WRONG with the script would be nice.

[Camacha]

Well some indication as to what's WRONG with the script would be nice.

kOS is returning more than ever about what is wrong. And I know it is not the answer you want to hear, but debugging is going to learn you a lot about computers and their abstract and absolute operation. Peel it apart and see what makes it tick - or not. Comment in printed messages, have variables print too, fiddle with the variables and something will probably come up.