[1.3] kOS Scriptable Autopilot System v1.1.3.0

[hypervelocity]

5 hours ago, EpicSpaceTroll139 said:

I'm not an expert, but from my limited experience I would suggest changing the trigger from "WHEN SHIP:WATER=144 THEN..." to "WHEN SHIP:WATER<144 THEN..." (or >, whatever works best for you).

Or is it throwing some kind of error message? In that case I probably don't know what to do.

Thanks for the reply @EpicSpaceTroll139, much appreciated! However I believe if I set my trigger to WHEN SHIP:WATER<144 that will not operate as I want -> I need the Drills to shut down once they filled up my Water tanks, with your proposed suggestion they would be shutting down as soon as the program reaches that part of the code since SHIP:WATER will always be < 144.

[EpicSpaceTroll139]

Just now, hypervelocity said:

Thanks for the reply @EpicSpaceTroll139, much appreciated! However I believe if I set my trigger to WHEN SHIP:WATER<144 that will not operate as I want -> I need the Drills to shut down once they filled up my Water tanks, with your proposed suggestion they would be shutting down as soon as the program reaches that part of the code since SHIP:WATER will always be < 144.

Hmmm... maybe set it to shut down at WHEN ROUND(SHIP:WATER,0) = 144? All I know is that sometimes things don't work when the script is expecting to get some exact value (apparently numbers often end up actually being something like 143.9999991 or something oddball like that.

[hypervelocity]

9 minutes ago, EpicSpaceTroll139 said:

Hmmm... maybe set it to shut down at WHEN ROUND(SHIP:WATER,0) = 144? All I know is that sometimes things don't work when the script is expecting to get some exact value (apparently numbers often end up actually being something like 143.9999991 or something oddball like that.

Thanks again, I tried that but did not work. 

My gut feeling tells me the Trigger is not being preserved and hence not working.

Tried RETURN = TRUE but had no effect either

Anyone else willing to lay a helping hand?

[ElWanderer]

6 hours ago, hypervelocity said:

The code I have written is the following:

CLEARSCREEN. PRINT "==== EXECUTING DRILLING SCRIPT - DRILLING PROGRAM ACTIVATED".

WAIT UNTIL SHIP:ELECTRICCHARGE>100.
 {
  TOGGLE AG2.                                    //Action Group that deploys the Drills
  PRINT "===== DRILLS ACTIVATED".
  SET AG2 TO FALSE.
 }

WAIT UNTIL SHIP:ELECTRICCHARGE<100.
 {
  TOGGLE AG3.                                    //Action Group that shuts-down the Drills
  PRINT "===== DRILLS SHUT-DOWN".
  SET AG3 TO FALSE.
 }

WHEN SHIP:WATER=144 THEN {                       //Trigger I am having issues with and cannot make it work
 TOGGLE AG3.                                     //Trigger I am having issues with and cannot make it work
 PRINT"===== WATER FULL, DRILLS SHUT-DOWN".      //Trigger I am having issues with and cannot make it work
 PRESERVE.}.                                     //Trigger I am having issues with and cannot make it work
RUN DRILLING.                                    //VERY LAME solution for not being able to work the WHEN/THEN statements. 
                                                 //As I don't know how to make my code to keep checking if EC is < or > than 100, I need to
                                                 //do this to get the code running again (would love to learn how to avoid this very disgraceful solution)

 

...and...

5 hours ago, EpicSpaceTroll139 said:

I'm not an expert, but from my limited experience I would suggest changing the trigger from "WHEN SHIP:WATER=144 THEN..." to "WHEN SHIP:WATER<144 THEN..." (or >, whatever works best for you).

Or is it throwing some kind of error message? In that case I probably don't know what to do.

I don't think SHIP:WATER exists in stock + kOS, but I'm guessing it's a resource added by another mod that could be picked up automatically... otherwise I'd expect that to throw an error and crash the script. Going via something like SHIP:RESOURCES is more complicated (you need to loop through the resource entries in the list until you find the one with the right name), but should allow access to any resource.

If it exists, SHIP:WATER is probably a floating point value, in which case, yes, it's highly unlikely to equal any value precisely, so a less than or greater than kind of check *is* preferable. As you're looking for "full" tanks, you probably want something like 'greater than 143'. If you use SHIP:RESOURCES, you can actually find out what the capacity of the specific resource is and so react once the resource amount is over 99% (say) of the full capacity.

Also, do you want to re-enable the drills if the level of water drops back below 144 units? If enabling and disabling via separate triggers, you want to check they don't conflict with each other or fire all the time. I would set a global variable that declares whether the drills are on or off and check that in the logic for each trigger. I'd also combine the checks on electric charge with those on the water level (the bits inside braces are pseudocode):

GLOBAL (drills are on/off) // pick a starting value and then set the drills to that condition.

(set drills to on/off)

WHEN ((water level is over 99%) OR (electric charge is below 10%)) AND (drills are on) { (turn drills off) (set that drills are off) PRESERVE. }

WHEN (water level is below 99%) AND (electric charge is above 10%) AND (drills are off) { (turn drills on) (set that drills are on) PRESERVE. }

Ah, I see there were several respones while I was typing!

Edited January 14, 2017 by ElWanderer

[hypervelocity]

Thanks for the prompt reply @ElWanderer !!!

Indeed, Water is added by Realism Overhaul and I checked it is a working resource, it is visible under SHIP:RESOURCES and I am able to PRINT its amount on any given moment.

Your suggestion is really good and was my initial approach, that is trying to nest both conditions (EC & Water Level), but as I couldn't make any WHEN/THEN Triggers work I just moved on to the code I shared here.

I have checked WHEN SHIP:WATER > 143 to avoid precision issues but still no cigar

My WHEN/THEN is not being PRESERVED for some reason

Edited January 14, 2017 by hypervelocity

[hypervelocity]

OK, so I figured out that in my previous script, the code was stuck waiting for WAIT UNTIL SHIP:ELECTRICCHARGE < 100 and hence the WHEN SHIP:WATER < 143 was never executed.

Nevertheless, I just can't seem to figure out these WHEN/THEN statements.

Re-wrote the code as follows and the program prints "DRILLING PROGRAM ACTIVATED" and ends. Ship resources are EC > 100 & Water < 143

CLEARSCREEN. PRINT "==== DRILLING PROGRAM ACTIVATED".

SET EC TO 0.
SET WATER TO 0.
SET READYTODRILL TO EC + WATER.

WHEN SHIP:ELECTRICCHARGE > 100 THEN {
    SET EC TO 1.
    PRESERVE. }

WHEN SHIP:WATER < 143 THEN {
    SET WATER TO 1.
    PRESERVE. }

WHEN READYTODRILL = 2 THEN {
    PRINT "===== DRILLS ACTIVATED".
    TOGGLE AG2.
    PRESERVE. }

WHEN READYTODRILL <> 2 THEN {

   PRINT "===== DRILLS SHUT-DOWN".
   TOGGLE AG3.
   PRESERVE. }

EDIT: After running the script, I tried PRINT EC, PRINT WATER & PRINT READYTODRILL and all read 0. Clearly the WHEN/THEN statements are not being executed/just wrong somehow not working.

Edited January 15, 2017 by hypervelocity

[EpicSpaceTroll139]

7 minutes ago, hypervelocity said:

<snip>

Uhh... do you mean to have "WHEN READYTODRILL < 2..." on that last statement? It looks like you put "<>" by accident... or does "<>" have some function in K-OS that I'm not aware of?

[hypervelocity]

@EpicSpaceTroll139, I believe "<>" means "not equal to".

 

 

Edited January 15, 2017 by hypervelocity

[ElWanderer]

WHEN/THEN commands do not work as you're possibly thinking. They don't stop code execution; instead they're stored as triggers to be run each tick. This means that the script will continue executing, but if there is no more code to run, the script will end. Try sticking a WAIT UNTIL FALSE. at the bottom of the script so it never ends.

[hypervelocity]

12 minutes ago, ElWanderer said:

WHEN/THEN commands do not work as you're possibly thinking. They don't stop code execution; instead they're stored as triggers to be run each tick. This means that the script will continue executing, but if there is no more code to run, the script will end. Try sticking a WAIT UNTIL FALSE. at the bottom of the script so it never ends.

Sorry I meant the WAIT UNTIL was preventing the code moving from forwards

What I meant was: if currently my Ship's EC is > 100 and Water is < 143 why PRINT EC and PRINT WATER are both 0 when I have the following in my code?

WHEN SHIP:ELECTRICCHARGE > 100 THEN {
    SET EC TO 1.
    PRESERVE. }

WHEN SHIP:WATER < 143 THEN {
    SET WATER TO 1.
    PRESERVE. }

 

Edited January 15, 2017 by hypervelocity

[ElWanderer]

1 minute ago, hypervelocity said:

Sorry I meant the WAIT UNTIL was preventing the code moving from forwards

I was referring to the be script you posted that had only WHEN statements, to which you added: "EDIT: After running the script, I tried PRINT EC, PRINT WATER & PRINT READYTODRILL and all read 0. Clearly the WHEN/THEN statements are not being executed/just wrong." My last post was explaining why it'll exit without doing anything useful.

[ElWanderer]

20 minutes ago, hypervelocity said:

What I meant was: if currently my Ship's EC is > 100 and Water is < 143 why PRINT EC and PRINT WATER are both 0 when I have the following in my code?

WHEN SHIP:ELECTRICCHARGE > 100 THEN {
    SET EC TO 1.
    PRESERVE. }

WHEN SHIP:WATER < 143 THEN {
    SET WATER TO 1.
    PRESERVE. }

 

The contents of those triggers won't get executed until the start of the next physics tick, by which time your script has already ended.

[hypervelocity]

@ElWanderer, gotcha!  Sorry for being such a noob.

I added WAIT UNTIL FALSE, which had the aforementioned effect.

Now I notice my previous code was missing the Triggers for setting back the EC & WATER variables back to 0, so the Drills could re-start after resource levels met the WHEN/THEN conditions again.

I updated the code as follows, tested it with enough resources on my Ship to meet the initial criteria and start drilling. The code activated AG2 and started to continuosly print "====== DRILLS ACTIVATED". However, once my Ship's Water levels rose above 143, AG3 was not executed, "===== DRILLS SHUT-DOWN" was not printed and my defined variable WATER did not get SET TO 0 again

CLEARSCREEN. PRINT "==== DRILLING PROGRAM ACTIVATED".

SET EC TO 0.
SET WATER TO 0.
SET READYTODRILL TO EC + WATER.

WHEN SHIP:ELECTRICCHARGE > 100 THEN {
    SET EC TO 1.
    PRESERVE. }.
WHEN SHIP:ELECTRICCHARGE < 100 THEN {
    SET EC TO 0.
    PRESERVE. }.

WHEN SHIP:WATER < 143 THEN {
    SET WATER TO 1.
    PRESERVE. }.
WHEN SHIP:WATER > 143 THEN {
    SET WATER TO 0.
    PRESERVE. }.

WHEN EC = 1 AND WATER = 1 THEN {
    TOGGLE AG2.
    PRESERVE. }.

WHEN EC = 0 OR WATER = 0 THEN {
    TOGGLE AG3.
    PRESERVE. }.

ON AG2 {
    PRINT "===== DRILLS ACTIVATED".
    PRESERVE. }.

ON AG3 {
    PRINT "===== DRILLS SHUT-DOWN".
    PRESERVE. }.

WAIT UNTIL FALSE.

 

Edited January 15, 2017 by hypervelocity

[danielboro]

its possible you need to add AG2 off and AG3 off.
i remember having some problems whit AG only working wen going from off to on.
so i needed {toggle AGX. toggle AGX.} for it to work the second time
actually what i did was {AGX on. AGX off.}

 

UNTIL FALSE {
  if SHIP:ELECTRICCHARGE > 100 and SHIP:WATER < 143 {TOGGLE AG2. PRINT "===== DRILLS ACTIVATED".} else {TOGGLE AG3. PRINT "===== DRILLS SHUT-DOWN".}
wait X.
}

i think this is better.
set X to the number of seconds bittwin testing or 0 to test every tick
 

[EmbersArc]

Okay I've got a (hopefully less confusing) bug report. The whole thing is quite complicated but I'll do my best to explain it.

I've noticed that command seats on a vessel can significantly impact the way it flies. If they are empty it's fine, unless you grab vessels with them with a claw. Here's a little gif of what I mean: http://i.imgur.com/E1MeiRe.gifv (First grabs a vessel without then with command seat)

If they have a Kerbal in them, the behavior is very similar. Then it doesn't matter if you grab it first or not. As soon as a Kerbal boards the seat the whole thing loses control. This is independent from when the script is launched. http://i.imgur.com/JSTlTcY.gifv

The behavior is similar to what you would expect if the script runs very slowly and variables are not updated often enough. 

Here's a log for all four situations and some more info (The last one is the random steering bug). https://gist.github.com/EmbersArc/b17cf12ab8ce4401a7d8c86f92b38197

[EpicSpaceTroll139]

I have what is probably a dumb question, but I'm currently stumped. Is there a way to find the current thrust on a craft? I know there's VESSEL:MAXTHRUST, VESSEL:MAXTHRUSTAT(), VESSEL:AVAILABLETHRUST, VESSEL:AVAILABLETHRUSTAT(), ENG:THRUSTAT(), etc, but for the life of me, looking through the documentation, I can not find a command to get the current total thrust.

Also is there a way to get the combined input from sas and pilot, instead of just the pilot?

Edited January 16, 2017 by EpicSpaceTroll139

[Dunbaratu]

6 hours ago, EmbersArc said:

Okay I've got a (hopefully less confusing) bug report. The whole thing is quite complicated but I'll do my best to explain it.

I've noticed that command seats on a vessel can significantly impact the way it flies. If they are empty it's fine, unless you grab vessels with them with a claw. Here's a little gif of what I mean: http://i.imgur.com/E1MeiRe.gifv (First grabs a vessel without then with command seat)

If they have a Kerbal in them, the behavior is very similar. Then it doesn't matter if you grab it first or not. As soon as a Kerbal boards the seat the whole thing loses control. This is independent from when the script is launched. http://i.imgur.com/JSTlTcY.gifv

The behavior is similar to what you would expect if the script runs very slowly and variables are not updated often enough. 

Here's a log for all four situations and some more info (The last one is the random steering bug). https://gist.github.com/EmbersArc/b17cf12ab8ce4401a7d8c86f92b38197

When a kerbal gets in the seat, the stock game changes the "control from here" part, which can rotate its notion of which way is the "front" of the ship pointed.  (A similar thing happens when you use 'C' to toggle cockpit view - if you had previously been using a probe core to drive from, now the cockpit that the kerbal is inside of becomes the "control from here" part the instant you go to cockpit view.)

Do you think this might be causing the behviour you see or does it look like something else?

[EmbersArc]

5 hours ago, Steven Mading said:

When a kerbal gets in the seat, the stock game changes the "control from here" part, which can rotate its notion of which way is the "front" of the ship pointed.  (A similar thing happens when you use 'C' to toggle cockpit view - if you had previously been using a probe core to drive from, now the cockpit that the kerbal is inside of becomes the "control from here" part the instant you go to cockpit view.)

Do you think this might be causing the behviour you see or does it look like something else?

I thought I had ruled that out but just tested it again. Yes you're right. It somehow didn't happen when it grabbed a vessel with a tilted probe core on it. Luckily kOS has a way to set the control point. Thanks!

[meyerweb]

On 1/13/2017 at 3:52 PM, Steven Mading said:

We could maybe add the ability to pick a "frequency" to triggers to get the same effect:

EVERY 0.5 ON AG10 { stuff },  or EVERY 0.5 WHEN Foo THEN { stuff }

That would be pretty sweet.

[meyerweb]

I’ve been running into a situation where sometimes, the stage resources show as zero because (it turns out) the ship’s fuel tanks have been demoted to stage number `-1`.  This happens most often when a craft launches with both liquid and solid fuel engines, such as the stock GDLV3.  Once the GDLV3 reaches space, having staged off the solid boosters, the Rockomax 64 fuel tank is in stage `-1` (along with the OKTO, the struts, the KAL9000 I slapped on the side, and several other parts).  Having the R-64 in stage `-1` means the current active stage calculates as having a dV of 0, because the ship is currently on stage 2, as is the Skipper engine.  Staging to stage 1 moves the Skipper to stage 1, but the R-64 stays at stage `-1`.

Is there a way to prevent this?  I’d prefer a programmatic way to prevent or fix it, as opposed to restructuring the craft or its staging in the VAB just to accommodate this.

[hvacengi]

5 hours ago, meyerweb said:

I’ve been running into a situation where sometimes, the stage resources show as zero because (it turns out) the ship’s fuel tanks have been demoted to stage number `-1`.  This happens most often when a craft launches with both liquid and solid fuel engines, such as the stock GDLV3.  Once the GDLV3 reaches space, having staged off the solid boosters, the Rockomax 64 fuel tank is in stage `-1` (along with the OKTO, the struts, the KAL9000 I slapped on the side, and several other parts).  Having the R-64 in stage `-1` means the current active stage calculates as having a dV of 0, because the ship is currently on stage 2, as is the Skipper engine.  Staging to stage 1 moves the Skipper to stage 1, but the R-64 stays at stage `-1`.

Is there a way to prevent this?  I’d prefer a programmatic way to prevent or fix it, as opposed to restructuring the craft or its staging in the VAB just to accommodate this.

If our reading matches the stock in game GUI (with "stage only" selected) then it's the best we can do.  We replicate the exact same system the UI uses, and short of writing our own more complicated system that's the best way we have to be close to correct.  If it doesn't match the GUI though we need to fix it.  Unfortunately we don't have any kind of a means to adjust the stage numbers, and it's my understanding that all kinds of crazy things happen to the stages if you try to re-arrange them in flight (though I've never tested it myself).  I don't have a good solution, but I'll try to keep it in mind when I look at testing the stage resource info.

[ElWanderer]

KSP's behaviour with "stage" resources has been annoying me too. I've had to write my own fuel-finding functions that recursively negotiate the parts tree, starting from any currently-ignited engines. I'm not aware of any way to take into account fuel lines, though

Is there a way in kOS to find which part a fuel line transfers fuel to? A search pulled up an old Reddit post saying fuel lines had their own module, but it had nothing useful accessible https://m.reddit.com/r/Kos/comments/35wu8o/fuel_zones_or_remaining_deltav_fuel_per_engine/

[meyerweb]

12 hours ago, hvacengi said:

If our reading matches the stock in game GUI (with "stage only" selected) then it's the best we can do.  We replicate the exact same system the UI uses, and short of writing our own more complicated system that's the best way we have to be close to correct.  If it doesn't match the GUI though we need to fix it.  Unfortunately we don't have any kind of a means to adjust the stage numbers, and it's my understanding that all kinds of crazy things happen to the stages if you try to re-arrange them in flight (though I've never tested it myself).  I don't have a good solution, but I'll try to keep it in mind when I look at testing the stage resource info.

Hmmm, that’s a good point about in-flight stage rearrangement.  I don’t think I did that, but it’s possible, so I’ll do some more testing just to make sure.

Speaking of making sure, when you say “with ‘stage only’ selected”, do you mean selecting the “stage view” button in the stock resources panel?

[meyerweb]

On 1/12/2017 at 9:02 PM, hvacengi said:

KOS-StockCamera

  

A kOS addon for manipulating the camera from inside scripts.

Initial public release.

See README.md for documentation.

Download: https://github.com/hvacengi/KOS-StockCamera/releases

Nice!  Any plans for creating built-in structures to allow things like the stationary flyby cameras found in other camera-manipulating mods, geographic/world coordinates, and similar?  I assume these could be calculated from what’s already provided, but it would be nice to have a way to say “plop a camera here in the world and don’t move it while still staying pointed at the craft”.  Example: put a camera on the ground 500 meters from the launchpad and track the craft as it takes off.

[hvacengi]

8 hours ago, meyerweb said:

Speaking of making sure, when you say “with ‘stage only’ selected”, do you mean selecting the “stage view” button in the stock resources panel?

Yeah, I forgot the phrasing and didn't open KSP to check.  "Stage View" is the correct option.

7 hours ago, meyerweb said:

Nice!  Any plans for creating built-in structures to allow things like the stationary flyby cameras found in other camera-manipulating mods, geographic/world coordinates, and similar?  I assume these could be calculated from what’s already provided, but it would be nice to have a way to say “plop a camera here in the world and don’t move it while still staying pointed at the craft”.  Example: put a camera on the ground 500 meters from the launchpad and track the craft as it takes off.

No, I don't have any intention to do anything like that.  That's more complicated because you need to manage when that camera controller lives/dies/becomes a ravenous zombie bent on eating my brain (maybe not that last option).  There are some other mods that do things like that and I may make an addon to interact with them instead.

I did forget to link the example library I built to help users manage the camera easily.  So here it is (if you didn't already find it): https://github.com/hvacengi/KOS-StockCamera/blob/master/Example Scripts/libcamera.ks (I'll update the README to point at it too).

12 hours ago, ElWanderer said:

KSP's behaviour with "stage" resources has been annoying me too. I've had to write my own fuel-finding functions that recursively negotiate the parts tree, starting from any currently-ignited engines. I'm not aware of any way to take into account fuel lines, though

Is there a way in kOS to find which part a fuel line transfers fuel to? A search pulled up an old Reddit post saying fuel lines had their own module, but it had nothing useful accessible https://m.reddit.com/r/Kos/comments/35wu8o/fuel_zones_or_remaining_deltav_fuel_per_engine/

In theory, that's exactly what the GUI and our methods are supposed to do.  We query each engine to see if it's activated, and then ask it "what fuel tanks are you connected to?".  And it should use the exact internal fuel flow logic, so it should show the exact value available to all currently active engines.