[1.3] kOS Scriptable Autopilot System v1.1.3.0

[damerell]

So, this is supposed to be local code running on the craft itself - I switched off the RT option in the kOS settings. When I run the program and press 1, AGX bypasses signal delay and the console immediately outputs "Pitching!" and yet it takes the current signal delay (65s) for the pitch command to actually take effect.

The only issue here seems to be that "Pitching" is printed too soon. I presume that's because although kOS is nominally on the local vessel, it's a lot easier to let RT handle the lag in things actually happening than to try and work out if "player pressed AG1" or not.

[Drew Kerman]

The only issue here seems to be that "Pitching" is printed too soon.

That's not an issue, it is working as it should be - AGX is bypassing RT signal delay and triggering the action group immediately, which is set to a Script Trigger action that runs the code in the trigger.

I presume that's because although kOS is nominally on the local vessel, it's a lot easier to let RT handle the lag in things actually happening than to try and work out if "player pressed AG1" or not.

what lag?? If the program is supposed to be running on the local vessel why would there be any lag from RT? It is supposed to be tied directly into the ship controls in this instance.

[MunGazer]

Hey guys, I've been googling this for a while and can't figure it out. I want to turn off the fuel flow for a specific part/tank on my ship. It keeps telling me :resources isn't the suffix to a part. I'm trying to set " mypart:resources:enable to false " or something along those lines. Could anyone just provide a quick line of example syntax/code that would accomplish this for a specific fuel tank on a ship? Not all of them, just the cruise missile it's carrying

Edit: I've been informed that this particular fuel flow shut off for fuel tanks is not accessible via kOS. Sounds like an opportunity for a simple mod... if only I knew how to do it, I'd make it.

Edited September 18, 2015 by MunGazer

[Dunbaratu]

More kOS twitch streaming in a few hours (sorry for the late notice)

http://forum.kerbalspaceprogram.com/calendar.php?do=getinfo&e=219&day=2015-9-17

Edited September 17, 2015 by Steven Mading
(gave it a title to stand out)

[MunGazer]

More kOS twitch streaming in a few hours (sorry for the late notice)

http://forum.kerbalspaceprogram.com/calendar.php?do=getinfo&e=219&day=2015-9-17

I started watching that particular stream, first timer here and I must say in the 8:13 I already learned a lot about how to land more efficiently in vacuum, I really enjoyed the lesson up to that point and you are well spoken. I'll have to watch more of your stuff when my internet is working better - for some reason your vid kept stopping at 8:13 and I'm certain it's a problem on my end - you tube was doing the same thing to me a bit ago.

[Dunbaratu]

I'll be continuing the topic of the CA land script, probably on Sunday, which I hope to be the last episode of that topic, as I think I understand the problem and have a solution.

I was going to do so tonight, but when I went to add it to the calendar, I saw that it collided with the SQUADCAST by MaxMaps, and that would be a bad thing to collide with.

[Drew Kerman]

ok I decided to give kOS another test thinking that maybe it knew it was dealing with an action group trigger and thus routed the steering commands through RemoteTech since action groups without Local Control would only be coming from a remote command however many seconds away. So I wrote a straight-up script on the local volume to pitch for 3 seconds and then neutralize

print "pitching in".
print "3".
wait 1.
print "2".
wait 1.
print "1".
wait 1.
set ship:control:pitch to 0.5.
print "nulling pitch in".
print "3".
wait 1.
print "2".
wait 1.
print "1".
wait 1.
set ship:control:pitch to 0.

I typed that from memory, program ran fine so any typos in that just ignore. The pitching happened 65 seconds after the program ended, the current amount of signal delay. This is definitely a bug, but I have no idea who is messing up here. Although I filed an issue report with kOS on Github yesterday, I think now it actually may be RemoteTech stealing the commands and running its signal delay on them rather than kOS sending its commands through RemoteTech. If the kOS devs think the former, I'll go file a report on the RT Github.

Edited September 19, 2015 by Gaiiden

[Kobymaru]

Hi guys, I have a question:

I have a kOS CompoMax Radial Tubeless processor onboard a probe which claims to requires 0.24 ec/s. If I use the "Toggle Power" button in the part menu, the power use is succesfully stopped. However, the readout still says "Required Power: 0.24". Is that intentional? Shouldn't that display the current power usage?

[Dunbaratu]

Hi guys, I have a question:

I have a kOS CompoMax Radial Tubeless processor onboard a probe which claims to requires 0.24 ec/s. If I use the "Toggle Power" button in the part menu, the power use is succesfully stopped. However, the readout still says "Required Power: 0.24". Is that intentional? Shouldn't that display the current power usage?

I disagree. You shouldn't have to turn on a device to learn how much power it uses. You don't have to actually turn on a light to find out that it uses 40 Watts - you can just read the label.

[Kobymaru]

I disagree. You shouldn't have to turn on a device to learn how much power it uses. You don't have to actually turn on a light to find out that it uses 40 Watts - you can just read the label.

Well, I would agree, but this is out of line with the stock parts:

The Solar Panels always show the current flow, the Engines show zero kN thrust and zero fluel flow when idle and zero ISP when not activated.

RemoteTech also shows zero power usage when the antenna is deactivated.

So while you may be right individually, I feel that sometimes consistency is more important than being right.

Either way, I think there needs to be a clue right inside the action menu whether the processor is enabled and drawing power or not.

[Dunbaratu]

Well, I would agree, but this is out of line with the stock parts:

The Solar Panels always show the current flow, the Engines show zero kN thrust and zero fluel flow when idle and zero ISP when not activated.

RemoteTech also shows zero power usage when the antenna is deactivated.

So while you may be right individually, I feel that sometimes consistency is more important than being right.

Either way, I think there needs to be a clue right inside the action menu whether the processor is enabled and drawing power or not.

There should be a status line added to the menu for it's current state, you're right there. But I'm not going to remove useful information just because everyone else does.

[damerell]

I typed that from memory, program ran fine so any typos in that just ignore. The pitching happened 65 seconds after the program ended, the current amount of signal delay. This is definitely a bug

No, it isn't. If the vessel is unkerballed then there should be a 65s delay between you deciding to pitch and the pitch happening. There was such a delay. So where's the bug?

It is slightly infelicitous that the program appears to run at the wrong time, immediately rather than 65s after being invoked, but I gather from the RT documentation that is planned to be fixed.

There would only be a bug if you somehow found a way to short-circuit the signal delay.

[Drew Kerman]

No, it isn't. If the vessel is unkerballed then there should be a 65s delay between you deciding to pitch and the pitch happening. There was such a delay. So where's the bug?

It's a local program on the local volume, I specified that in the post you quoted. I edited the file directly on the local vessel volume. That means it is on the ship, not on a computer millions of kilometers away. That means it is supposed to be tied directly into the ship controls, not through a remote connection, or any connection for that matter. Therefore, no signal delay should be happening, therefore - bug.

Anyways, it's being looked into.

[Dunbaratu]

No, it isn't. If the vessel is unkerballed then there should be a 65s delay between you deciding to pitch and the pitch happening. There was such a delay. So where's the bug?

There should be a delay for STARTING the script, but not a delay once it's running. The delay reported was a delay occurring after the program had already been started (after the 65s lag had already passed), in between two consecutive statements of the program (the print statement, then the next statement tries to move the controls, which instead of happening right after the print statement, happens 65 seconds after the print statement).

This is not normal behavior, but it's a difficult problem to reproduce. In simple tests it works fine, so there's got to be something very specific happening to trigger it that isn't clear what it is. If this is what it did normally by default when we try using it, that would have been noticed immediately and prevented releasing it.

Edited September 22, 2015 by Steven Mading

[Drew Kerman]

This is not normal behavior, but it's a difficult problem to reproduce. In simple tests it works fine, so there's got to be something very specific happening to trigger it that isn't clear what it is. If this is what it did normally by default when we try using it, that would have been noticed immediately and prevented releasing it.

Hrrrmmm... I will put some time tonight into investigating this further since I can reliably reproduce. My mix of mods is rather... extensive I have suspects...

--Later--

Ok so the issue seems to be that I disabled the RT option in the kOS settings. Here is my local control script:

set running to true.
set locked to true.

// exit the program
on AG8 { set running to false. }.

// kill rotation
on AG1 {
  set ship:control:neutralize to true.
  lock steering to ship:facing.
  set locked to true.
  preserve.
}.

// pitch up
on AG2 {
  if locked {
    set locked to false.
    unlock steering.
  }
  set ship:control:pitch to -0.25.
  preserve.
}.

// pitch down
on AG3 {
  if locked {
    set locked to false.
    unlock steering.
  }
  set ship:control:pitch to 0.25.
  preserve.
}.

// roll left
on AG4 {
  if locked {
    set locked to false.
    unlock steering.
  }
  set ship:control:roll to -0.25.
  preserve.
}.

// roll right
on AG5 {
  if locked {
    set locked to false.
    unlock steering.
  }
  set ship:control:roll to 0.25.
  preserve.
}.

// yaw left
on AG6 {
  if locked {
    set locked to false.
    unlock steering.
  }
  set ship:control:yaw to -0.25.
  preserve.
}.

// yaw right
on AG7 {
  if locked {
    set locked to false.
    unlock steering.
  }
  set ship:control:yaw to 0.25.
  preserve.
}.

// initialize
clearscreen.
print "Local control enabled".
lock steering to ship:facing.

// program loop
until not running {
  wait 0.01.
}.

// reset controls
unlock steering.
set ship:control:neutralize to true.
print "Local control terminated".

Now, when I have the RT option turned off, if I run the program and it starts immediately but all ship:control commands I send via action group bypassing RemoteTech via AGX take however long the signal delay is to execute even though all other program commands are immediate. If I turn on the RT option then the initial script execution takes however long the signal delay is (which it should, this is proper behavior) and then once the run command has reached the craft and the script is running I have instant ship:control response when I bypass RemoteTech with AGX to trigger the action groups immediately.

So again, RT option off things don't work as they should. RT option on, things all work as expected.

Edited September 23, 2015 by Gaiiden

[Dunbaratu]

So again, RT option off things don't work as they should. RT option on, things all work as expected.

In this case I'm going to close the issue you made on github for it.

[damerell]

It's a local program on the local volume, I specified that in the post you quoted.

I know that. That is why I said there was an infelicity in that the program runs immediately after the decision to run it rather than 65s later, but you get the right result - 65s lag between your decision and it being implemented.

... and I see, in fact, this infelicity has only arisen because you _turned off_ RT integration in kOS when using RT and then were surprised it didn't quite work.

This is all part of the ongoing quest to play with RT signal delay and then not be affected by RT signal delay. This is silly.

Edited September 23, 2015 by damerell

[Dunbaratu]

I know that. That is why I said there was an infelicity in that the program runs immediately after the decision to run it rather than 65s later, but you get the right result - 65s lag between your decision and it being implemented.

Not quite. The thing you keep missing is that the line of code to print words to the screen and the line of code to move the steering were *adjacent to* each other in the program, with no conditional branches or anything between them, and nothing that depends on signal delay occurring in between them. Therefore if there's a delay between the print command and the steering command that comes immediately afterward, that would be a problem. The 65 second delay should only occur when the program starts, or when the action group is pressed, but this delay was in between two *adjacent* commands, AFTER the triggering had already happened. Regardless of how the triggering happened, or how "cheaty" a technique was used to do that, once it does trigger, the two *adjacent* commands should have happened right away back to back. That would still have been a bug had it not been merely caused by turning RT support off as was later admitted.

This is all part of the ongoing quest to play with RT signal delay and then not be affected by RT signal delay. This is silly.

Probably. Gaiiden just wasted precious developer time when we're trying to get our last changes merged in for a release before KSP 1.1 drops, which does irk me. I'd be more sympathetic had the flag been off by accident, because it's easy for new users of kOS to not know what it does, but he clearly knew what it was for and turned it off deliberately to attempt to get that sort of halfway enforced RT in the same game that nobody else wants, and then had forgotten that it was off.

That being said, wanting to disable RT's rules (entirely, not just signal delay) for some saved games on the same installation as the saved game where you're using it for career is entirely legit, and RT refuses to support that either, which is annoying. (i.e. the stock game doesn't say that just because you are using hardmode on one saved game that you have to use it on all the others too. Having a second saved game for experimental sandbox play is entirely legit and within the game's intended play style, and RT makes it a real pain to do.).

[Drew Kerman]

Gaiiden just wasted precious developer time when we're trying to get our last changes merged in for a release before KSP 1.1 drops, which does irk me. I'd be more sympathetic had the flag been off by accident, because it's easy for new users of kOS to not know what it does, but he clearly knew what it was for and turned it off deliberately to attempt to get that sort of halfway enforced RT in the same game that nobody else wants, and then had forgotten that it was off.

Ok, first off this is from my original post about this issue here on this thread:

... I switched off the RT option in the kOS settings.

aaaand this from my issue report on Github:

RT integration was disabled through the kOS control panel when this script was run

So at no time did I forget or try to hide the fact that I was running this script with the option turned off.

That would still have been a bug had it not been merely caused by turning RT support off as was later admitted.

I'm sorry but I'm still unclear on how this is not a bug. I switched off support for RemoteTech. Why then is RemoteTech still influencing commands sent by my program? This makes no sense to me whatsoever, and nothing I've found in the documentation here, here or here explains this to me. You claim I know what the RT support option is for, and I thought I did too, but if this is indeed not a bug I actually don't fully understand its intended use at all.

Edited September 23, 2015 by Gaiiden

[Dunbaratu]

So at no time did I forget or try to hide the fact that I was running this script with the option turned off.

Okay, sorry about that. It's easy to miss since you're doing something no other human being wants to.

I'm sorry but I'm still unclear on how this is not a bug. I switched off support for RemoteTech.

kOS has to go out of its way to prevent RT from imposing the delay. kOS isn't causing the delay. RT treats all attempts to move the controls as if they came from the human pilot by default, unless a mod explicitly tells RT "This particular control movement isn't human, so get out of the way and allow it to work" in a sort of inverse captcha.

As an experimental feature, it doesn't just try to autodetect RT to enable the experimental code that tells RT to get out of the way. When the feature stops being experimental, the user ability to toggle the flag will go away and it will get turned on only by trying to autodetect RT. Once upon a time the feature didn't work well, and trying to autodetect RT was a problem anyway because there were multiple versions of it floating around, and not all of them used the same API for the "inverse captcha" call I was talking about.

It was considered better to just let the user tell us that they need the RT support turned on than for us to rely on the autodetection.

Eventually, that will go away and you won't be able to toggle it off if we detect RT has been installed. There's no longer two different versions of RT, and the code in RT to allow robot pilots to sanction themselves has settled down and become consistent, so it will probably go away after the next release.

Edited September 23, 2015 by Steven Mading

[Drew Kerman]

It's easy to miss since you're doing something no other human being wants to.

seriously? that wasn't really called for and doesn't change the fact that all anyone had to do was read what I wrote instead of rolling your eyes at what I was trying to do. Well, what I ended up doing I should say, because it works and I'd like to thank damerell for suggesting I use kOS - even though an "exploit" (in his opinion) probably isn't what he intended

kOS has to go out of its way to prevent RT from imposing the delay. kOS isn't causing the delay. RT treats all attempts to move the controls as if they came from the human pilot by default, unless a mod explicitly tells RT "This particular control movement isn't human, so get out of the way and allow it to work" in a sort of inverse captcha.

As an experimental feature, it doesn't just try to autodetect RT to enable the experimental code that tells RT to get out of the way. When the feature stops being experimental, the user ability to toggle the flag will go away and it will get turned on only by trying to autodetect RT. Once upon a time the feature didn't work well, and trying to autodetect RT was a problem anyway because there were multiple versions of it floating around, and not all of them used the same API for the "inverse captcha" call I was talking about.

It was considered better to just let the user tell us that they need the RT support turned on than for us to rely on the autodetection.

Eventually, that will go away and you won't be able to toggle it off if we detect RT has been installed. There's no longer two different versions of RT, and the code in RT to allow robot pilots to sanction themselves has settled down and become consistent, so it will probably go away after the next release.

Ok, I admit I should have indeed known all that since I've followed this mod for long enough to have remembered why the RT option was originally added. I suppose with the increased RT support in the latest version I assumed (wrongly, and should have known better since it wasn't in the change log) the RT toggle had become more of an actual on/off switch for dealing with RemoteTech through kOS.

[Dunbaratu]

seriously? that wasn't really called for and doesn't change the fact that all anyone had to do was read what I wrote instead of rolling your eyes at what I was trying to do.

I'm sorry. I was defending WHY it was so easy for us to miss it (all kOS devs who read your report missed that vital point, not just me).

There have been cases in the past of people being unaware of the CONFIG:RT option entirely, and therefore issuing a false bug report based on them not realizing it's there. But in your case you knew about enough to talk about it in the bug report, but talked about it with an inverted understanding of what the flag means. Yours is the first case of someone being aware of it but getting its meaning backward, which is why it was easy to miss that you were describing its effects backward and that this was the actual source of the misunderstanding. You're the first person who has *had* that misunderstanding, which is why it was easy not to notice it. It's not something we've encountered before.

I'm sorry for being a bit snippy. We're in crunch time, have no idea when KSP 1.1 will drop because they never tell anyone ahead of time, and with everyone having limited free time there's a bit of a worry about getting things out in time to be ready for all the work that 1.1 will require. Into that environment someone comes along who issues a bug report that consumes hours of work because what it seems to be describing would be quite severely broken - a major major enormous flaw in kOS - if it was truely broken. It is very frustrating to find out after wasting those hours that it was an invalid bug report all along, due to a misunderstanding on the part of that user as to what a flag means - a misunderstanding that was unique to that user and that user alone.

So yes I shouldn't have been as dismissive as I was, but for your part you should be aware that that was borne of the frustration of your "bug" report causing me to waste a few hours of work I could have been doing something productive with on the mod.

[damerell]

That being said, wanting to disable RT's rules (entirely, not just signal delay) for some saved games on the same installation as the saved game where you're using it for career is entirely legit, and RT refuses to support that either, which is annoying. (i.e. the stock game doesn't say that just because you are using hardmode on one saved game that you have to use it on all the others too. Having a second saved game for experimental sandbox play is entirely legit and within the game's intended play style, and RT makes it a real pain to do.).

I think we agreed in the RT thread that that would be a desirable RT feature.

[Gaarst]

OK, first of all: total noob in kOS here (and in programmation in general), just to set things clear

I've been following the "Quick Start" tutorial from the kOS website given in the mod description and I encounter several issues:

1) The heading doesn't work properly: the engine's gimbal just wobbles like crazy and the rocket doesn't keep straight up. It often ends up flipping and crashing.

2) The staging doesn't work either: it seems to trigger right after launch, sometimes decoupling, sometimes not, and doesn't do anything when liquid fuels run out on the first stage.

Rocket has two stages:

1st: LV-45+FL-T800 with or without fins;

2nd: LV-909+FL-T400

And up is the payload: a nosecone, probe core, kOS part and cargo bay with RTGs

I have the two following mods (in addition to kOS): KER and Stock Bug Fix Modules. Both up to date, but I don't think any of them changes the physics or behaviour of the craft. I made a clean install to test kOS, so no other mod has ever been installed on this game.

print "..." + countdown.
wait 1.
}
print "Main throttle up. 2 seconds to stabilise it.".
lock throttle to 1.0.
lock steering to up.
wait 2.
when stage:liquidfuel < 0.001 then {
print "No liquid fuel. Attempting to stage.".
stage.
preserve.
}
until ship:maxthrust > 0 {
wait 0.5.
print "Stage activated.".
stage.
}
wait until ship:altitude > 70000.

print "Counting down:".from {local countdown is 10.} until countdown = 0 step {set countdown to countdown -1.} do {

Has anything significantly changed in kOS or KSP since the tutorial was written, or am I just doing is wrong ?

Any anwser is appreciated !

[Dunbaratu]

OK, first of all: total noob in kOS here (and in programmation in general), just to set things clear

I've been following the "Quick Start" tutorial from the kOS website given in the mod description and I encounter several issues:

1) The heading doesn't work properly: the engine's gimbal just wobbles like crazy and the rocket doesn't keep straight up. It often ends up flipping and crashing.

The next kOS release "any day now" has better LOCK STEERING behavior - waaay better. But in the meantime, one suggestion I always have is this:

Have you ever been slightly annoyed that stock KSP puts your rocket on the launchpad such that when launching to the east, as you typically do, you have to YAW rather than PITCH to do so? (i.e. press the "D" key rather than the "S" or "W".) Well actually that's related to this common problem in kOS. kOS, when trying to aim UP is also trying to roll into its default orientation, which isn't the one that KSP puts you in by default, and that roll right off the launchpad confuses it a bit as it tries to wind its way around to the desired situation.

So try this first before trying anything else: In the VAB, grab the root part with your mouse (such that you're now moving the whole vessel, leaving behind no detached pieces). Then rotate the entire vessel by 90 degrees so its bottom is now facing east, and its top is facing west. (I cant remember if this is the "A" or the "D" key that you want to use, but basically make the roof of the craft aim toward the back of the VAB and the belly of the craft face toward the big open warehouse doors.) Save it like this and launch it. If you've done it right, the navball should show, when still on the launchpad, that the "north" red line is now to your right, rather than on top as it usually is).

If you start your launch from this position it might reduce the initial roll quite a bit. I may have gotten the above orientation a bit wrong - try it again rotated a few different ways if it doesn't work the first time.

2) The staging doesn't work either: it seems to trigger right after launch, sometimes decoupling, sometimes not, and doesn't do anything when liquid fuels run out on the first stage.

KSP has a really annoying bug in the stock game, that kOS inherits and makes it look like it's kOS's fault when it's really the stock game's fault. This bug is when it comes to calculating resources in the current stage. To see if you are having this bug, click the resources window open in the main KSP toolbar and then click the checkbox for "stage only", which changes the display to showing only the resources in the current stage. Leave this window open as you launch the rocket and watch what it's showing for liquidfuel. If it shows lots of liquidfuel left when clearly you have no liquidfuel in the current stage, that's the bug. What it's doing is failing to realize that the fuel in some of the other tanks are for different stages - it's adding them to the current stage when it shouldn't. kOS is passing this bug on to you when you do STAGE:LIQUIDFUEL.

(And the annoying thing is that kOS used to calculate stage values itself in older versions, and it was changed to just believing what KSP tells it because we *thought* that would be better than doing the work ourselves. At any rate, I expect the bug won't last much longer since KSP is revamping so much in 1.1.)

If this is the problem you're having there's a few workarounds:

1 - Redesign the staging list to ensure that the decouplers and the engines are in different stages. Having a stage where it does a decouple at the same time as it activates an engine seems to be what triggers this bug. Having two different stages, one where it decouples, and the next where it activates the next engine, seems to help avoid the bug. (Exception - If you have launch clamps - DO put those in the same stage as the first engine - don't fire the launch clamps before the engines are lit or it will fall to the launchpad.).

or

2 - Change this:

when stage:liquidfuel < 0.0001 then {

to this instead:

when ship:maxthrust = 0  then {

So it will just never bother using the buggy stage:liquidfuel check at all and instead base the check on the fact that the engine is flamed out and has no thrust.

In fact if you do #2 , you can even remove the "until" loop that follows, entirely.

And yes, the tutorial is dated because it was written before this stage:liquidfuel bug manifested. It's been re-written already but the new version won't show up until the next time kOS has a release (real soon now???).