[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Pure_Diamond]

How does this interact with Remotech?

[steddyj]

Ok, back again I just downloaded the latest Version of kOS but the problem still exsists.

I tried to following with a new "clean" install of KSP 32-bit.:

SET shipsparts TO SHIP:PARTS.
PRINT shipsparts.
SET mainengine TO SHIP:PARTSDUBBED("liquidEngine2").
PRINT mainengine.
SET enginemodule TO mainengine:MODULES.
PRINT enginemodule.

but it still returns the problem I reported in my first post http://forum.kerbalspaceprogram.com/threads/68089-0-25-kOS-Scriptable-Autopilot-System-v0-15-0-2014-11-16?p=1547961&viewfull=1#post1547961

Sinza -

I ran into this the other day. The issue is that you're assuming (as I was the other day) that SHIP:PARTSDUBBED("liquidEngine2") will return an instance of a Part structure, when instead it's a List structure. You'll see this when you PRINT mainengine., it will say it's a LIST of (probably) one item. If you only expect one return from that output, you can set main engine to the first output of the PARTSDUBBED command like like this:

SET mainengine TO SHIP:PARTSDUBBED("liquidEngine2")[0].

I swear there's also example code in the documentation that shows this including how to add error checking, but I'll be damned if I can find it right now. Here's what I used in my satellite deployment script.

IF ship:partstagged("payload_dcplr"):LENGTH = 0 {
	PRINT "Payload decoupler could not be identified.  Manual abort required".
	Print "Hit CTRL+C to abort deployment".
	set x to 1.
	Wait until x = 0.
} ELSE IF ship:partstagged("payload_dcplr"):LENGTH > 1 {
	PRINT "Multiple Payload decouplers identified.  Manual abort required".
	Print "Hit CTRL+C to abort deployment".
	set x to 1.
	Wait until x = 0.
} ELSE set deploy_device to ship:partstagged("payload_dcplr")[0].
set deploy_ctrl to deploy_device:getmodule("ModuleDecouple").

Since I'm tossing this code up anyway, does anyone know of a command to abort an executing script? The only thing documented in the Flow COntrol section of the docs is BREAK, which only works in loops. EXIT and ABORT didn't seem to do anything, so I set up the infinite loops prompting a manual abort shown.

EDIT: I found the doc I was looking for, it's the Ship Parts and Modules doc: http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_parts_and_modules/index.html

Edited November 20, 2014 by steddyj

[Dunbaratu]

IF ship:partstagged("payload_dcplr"):LENGTH = 0 {
	PRINT "Payload decoupler could not be identified.  Manual abort required".
	Print "Hit CTRL+C to abort deployment".
	set x to 1.
	Wait until x = 0.
} ELSE IF ship:partstagged("payload_dcplr"):LENGTH > 1 {
	PRINT "Multiple Payload decouplers identified.  Manual abort required".
	Print "Hit CTRL+C to abort deployment".
	set x to 1.
	Wait until x = 0.
} ELSE set deploy_device to ship:partstagged("payload_dcplr")[0].
set deploy_ctrl to deploy_device:getmodule("ModuleDecouple").

Pro tip: the queries performed by these can be expensive at times depending on your ship's part count. If re-using the same query multiple times, store it in a variable first for faster execution, like so:

set decouplers to ship:partstagged("payload_dcplr").
if decouplers:length = 0 { 
  stuff
} else if decouplers:length > 0 {
  stuff
} else {
  set deploy_device to decouplers[0].
}.

Since I'm tossing this code up anyway, does anyone know of a command to abort an executing script?

Doesn't exist yet. You'll have to wrap things in if checks and set flags to descend to the bottom of the program. Part of the problem is that we don't yet know how functions or procdures will be incorporated into the language, which sort of affects what the right way to implement such a thing would be (there being more than one kind of premature exit - full exit, function return with value, etc - not knowing how that will look in the end is making us not want to make any early commitments to one way over another.)

[politas]

I'm getting these messages in my ksp.log (tracking down what I think is an unrealated issue.) I'm running on Linux, kOS 0.15.2

[LOG 19:31:39.463] KOSToolBarWindow: Now making instance number 2 of KOSToolBarWindow
[WRN 19:31:39.465] UnityEngine.GUISkin must be instantiated using the ScriptableObject.CreateInstance method instead of new GUISkin.
[LOG 19:31:39.465] custom styles is null
[LOG 19:31:39.540] The SpaceNavigator driver is a Windows-Only feature at the moment.

[Dunbaratu]

I'm getting these messages in my ksp.log (tracking down what I think is an unrealated issue.) I'm running on Linux, kOS 0.15.2

[LOG 19:31:39.463] KOSToolBarWindow: Now making instance number 2 of KOSToolBarWindow
[WRN 19:31:39.465] UnityEngine.GUISkin must be instantiated using the ScriptableObject.CreateInstance method instead of new GUISkin.
[LOG 19:31:39.465] custom styles is null
[LOG 19:31:39.540] The SpaceNavigator driver is a Windows-Only feature at the moment.

Actually that's quite useful. I was annoyed at the fact that there's no proper copy constructor for UnityEngine.GUISkin. The documentation for Unity (which is just about as bad as the documentation for KSP) didn't make a mention anywhere on the page for GUISkin of the fact that the reason there's no copy constructor is because there's a factory method instead for creating GUISkins.... That one piece of the log said a mouthful there.

[Sinza]

Hello steddyi,

thank you for your response. After some fiddling around on yesterdays evening I finally found out how to work with it.

So if someone is interestet in my first "complete" (regarding to launching and landing) script, here you can find the script and the craft:

https://www.dropbox.com/sh/ln3g3o2l1k3krwr/AAABpRkNyyMdC4kGFRRTSnKWa?dl=0

Any comments are welcome, I would really like to know if I could make something better.

PS: Instead of

 LOCK THROTTLE TO 1. 

I also tried

 SET control TO SHIP:CONTROL. SET control:MAINTHRUST TO 1. 

but this method only worked by executing it directly inside the kOS window and not when being embebbed into the script I wrote. Was that my fault or a error in kOS?

clearscreen.
PRINT "Starting ILL - Ignition, Launch and Landing program.".
LOCK THROTTLE TO 0.
WAIT 2.
LOCK STEERING TO UP.
PRINT "                                                                       ".
PRINT "                                                                       ".
PRINT "                                                                       ".
PRINT "                                                                       ".
PRINT "                                                                       ".
PRINT "                                                                       ".
PRINT "                                                                       ".
PRINT "                                                                       ".
PRINT "                                                                       ".
PRINT "                                                                       ".
PRINT "                                                                       ".
PRINT "                                                                       ".
PRINT "                                                                       ".
PRINT "                                                                       ".
PRINT "                                                                       ".
PRINT "                                                                       ".
SET x TO 0.
UNTIL  x = 5 { PRINT "Loading program..." AT (0,2). WAIT 1. PRINT  "                          " AT (0,2). WAIT 1. SET x TO x + 1. }.
WAIT 1.
PRINT "Program loaded.              " AT (0,2).
WAIT 2.
PRINT "Starting Engine..." AT (0,4).
WAIT 2.
SET engine TO SHIP:PARTSDUBBED("liquidengine").
SET enginemodule TO LIST().
FOR eng IN engine { enginemodule:ADD(eng:GETMODULE("ModuleEngines")). }.
FOR eng IN enginemodule { eng:DOEVENT("Activate Engine"). }.
PRINT "Engine Running!" AT (0,6).
WAIT 1.5.
PRINT "Throttle up and release at Countdown = 0!" AT (0,8).
WAIT 2.
PRINT "Countdown:" AT (0,10).
WAIT 2.
SET x TO 10.
UNTIL  x = 0 { PRINT x AT (11,10). SET x TO x - 1. WHEN x < 5 THEN { LOCK  THROTTLE TO 0.2. }. WAIT 1. PRINT "        " AT (11,10). WAIT 0.5. }.
PRINT "0" AT (11,10).
WAIT 0.1.
LOCK THROTTLE TO 0.5.
WAIT 0.8.
SET clamps TO SHIP:PARTSDUBBED("launchClamp1").
SET clampmod TO LIST().
FOR c IN clamps { clampmod:ADD(c:GETMODULE("LaunchClamp")). }.
FOR c IN clampmod { c:DOEVENT("Release Clamp"). }.
PRINT "Liftoff!" AT (0,12).
WAIT 2.
LOCK THROTTLE TO 1.
WAIT 3.
CLEARSCREEN.
PRINT " ".
PRINT " ".
PRINT " ".
PRINT " ".
PRINT " ".
PRINT " ".
PRINT " ".
PRINT " ".
PRINT " ".
PRINT " ".
PRINT "Status:" + STATUS AT (0,0).
WAIT UNTIL ALTITUDE > 2000.
LOCK THROTTLE TO 0.
WAIT 0.8.
SET pchutes TO SHIP:PARTSDUBBED("parachuteRadial").
SET chutesmod TO LIST().
FOR p IN pchutes { chutesmod:ADD(p:GETMODULE("ModuleParachute")). }.
SET landinglegs TO SHIP:PARTSDUBBED("landingLeg1-2").
SET legsmod TO LIST().
FOR l IN landinglegs { legsmod:ADD(l:GETMODULE("ModuleLandingLeg")). }.
WHEN ALTITUDE < 1700 THEN { PRINT "Starting landing sequence" AT (0,2). }.
WHEN ALTITUDE < 1500 THEN { PRINT "Lowering Landing Legs" AT (0,4). FOR l IN legsmod { l:DOEVENT("Lower Legs"). }. }.
WHEN ALTITUDE < 1080 THEN { PRINT "Firing Parachutes!" AT (0,6). }.
WHEN ALTITUDE < 1000 THEN { FOR p IN chutesmod { p:DOEVENT("Deploy Chute"). }. }.
WHEN  ALTITUDE < 500 THEN { PRINT "Shutting down the engine." AT (0,8).  FOR eng IN enginemodule { eng:DOEVENT("Shutdown Engine"). }. }.
WAIT UNTIL STATUS = "LANDED".
WHEN STATUS = "LANDED" THEN { PRINT STATUS AT (7,0). }.
WAIT 2.

Greetings.

Edited November 20, 2014 by Sinza

[Reddy]

In relation to my previous post and a related issue 389. I have found the same strange response to steering attempt in a craft that could only use control surfaces and engine gimbal to maneuver - rapid wiggling of the control elements, also visible on the GUI indicator (see the video I attached to the post mentioned). Thus, the rocket fails to align with the given yaw angle.

Reproduction steps on the 32-bit KSP v0.25.0.642 & kOS v0.15.1: build a 3.75m rocket with the KR-2L and two large tanks, some winglets at the bottom, but no reaction wheel modules (or get the said rocket from here). Launch it and run the following script (or download it):

SET c_pitch TO 0.
SET c_throttle TO 1.
RCS OFF.
SAS OFF.
LOCK c_steering TO UP+R(0,0,180)+R(0,-c_pitch,0).
LOCK STEERING TO c_steering.
LOCK THROTTLE TO c_throttle.
STAGE.

UNTIL SHIP:ALTITUDE >= 2000 { WAIT 0.1. }.
LOCK THROTTLE TO 0.8.
UNTIL SHIP:APOAPSIS > 100000 {
    //    should smoothly pitch the craft from 0 degrees on 2km altitude to 90 degrees on 36.5km
    SET c_pitch TO 0.002727*SHIP:ALTITUDE-8.18182.
    IF c_pitch < 0 SET c_pitch TO 0.
    IF c_pitch >90 SET c_pitch TO 90.

    CLEARSCREEN.
    PRINT "Rocket now pitched " + ROUND((UP+R(0,0,180)):YAW-SHIP:FACING:YAW,1).
    PRINT "Should instead be  " + ROUND(c_pitch,1).
    WAIT 0.5.
}.

//The code uses the word "pitch" for the variable, though we'll actually observe yaw being changed.

A similar effect to the one displayed on my

should be observed. The script will also continuously notify on the difference between the given pitch and the observed.

@Steven: I feel this is strongly related, and if I'm right it would prove that not only the RCS auto steering is broken, but all other means except for the reaction wheels as well.

Edited November 21, 2014 by Reddy
terminology: SAS vs. reaction wheels

[hvacengi]

Has anyone else had an issue with getting boot files to work after the update to 15.x? I had been using a boot.txt file before the update without any issue. Now, boot.ks doesn't seem to launch or get copied to the local volume. I have run a simple script of just

wait 10.
clearscreen.
toggle ag10.

where ag10 opens the console. I wait and nothing happens. If I open the console manually, the standard boot text is there (though it identifies as v0.15.1 even though I've confirmed it is v0.15.2), and the clearscreen command has obviously not cleared anything. Listing files shows a single boot file on the local volume, but attempts to edit, copy, or rename all return that the file doesn't exist (edit displays [New File] on the terminal). The file size is pretty close to the actual size of the boot file (using the windows file properties dialog). My first thought was that it was complication due to me storing all of the scripts in dropbox and a directory link to point the script folder there, but the same holds true if I use a normal folder. I have also tried it both with compression turned on and without. If I switch to the archive and then "run boot." the boot script executes fine.

I wanted to check and see if any one else has had this issue, or if I'm just completely crazy, before issuing an issue on the github page.

Thanks!

[Trewor007]

hvacengi there was some issues with boot files in v0.15 but as far as i know they was due to changes, not bugs. The problem You described allow happened tu me but only on loading existing ship. After i recopied the files from archive to ship and quicksaved, the problem was gone. So that is more of a inconvenience than a bug.

Reddy This wiggling of the flaps etc. is kinda normal, the script is pointing the vessel in a very and i mean VERY specific position that is changing very fats with almost 0 margin for error, i remember MJ had the same issue( i don't know if it still have it).

Edited November 20, 2014 by Trewor007

[Cairan]

I've experienced an issue with "boot.ks" being copied to Volume 1, but without the ".ks" extension... I'll look into it, probably something related to the new file extension system.

[gkorgood]

could anyone tell me why the following ascent program will not run?

[FONT=Courier]SET countdown TO 10.[/FONT]
[FONT=Courier]PRINT "COUNTING DOWN:â€Â.[/FONT]
[FONT=Courier]UNTIL countdown = 0 {[/FONT]
[FONT=Courier]    PRINT "..." + countdown.[/FONT]
[FONT=Courier]    SET countdown TO countdown - 1.[/FONT]
[FONT=Courier]    WAIT 1.[/FONT]
[FONT=Courier]}.[/FONT]
[FONT=Courier]PRINT “LOCKING STEERING TO UP. 1 SECOND TO STABILIZE.â€Â.[/FONT]
[FONT=Courier]LOCK STEERING TO UP.[/FONT]
[FONT=Courier]WAIT 1.[/FONT]
[FONT=Courier]PRINT "MAIN THROTTLE UP.  2 SECONDS TO STABILIZE.â€Â.[/FONT]
[FONT=Courier]LOCK THROTTLE TO 1.0.[/FONT]
[FONT=Courier]WAIT 2.[/FONT]
[FONT=Courier]UNTIL SHIP:MAXTHRUST > 0 {[/FONT]
[FONT=Courier]    WAIT 0.5.[/FONT]
[FONT=Courier]    PRINT "STAGE ACTIVATED.â€Â.[/FONT]
[FONT=Courier]    STAGE.[/FONT]
[FONT=Courier]}.[/FONT]
[FONT=Courier]WHEN STAGE:LIQUIDFUEL < 0.001 THEN {[/FONT]
[FONT=Courier]    PRINT “STAGE EMPTY. STAGING.â€Â.[/FONT]
[FONT=Courier]    STAGE.[/FONT]
[FONT=Courier]    PRESERVE.[/FONT]
[FONT=Courier]}.[/FONT]
[FONT=Courier]WHEN STAGE:SOLIDFUEL < 0.001 THEN {[/FONT]
[FONT=Courier]    PRINT “STAGE EMPTY. STAGING.â€Â.[/FONT]
[FONT=Courier]    STAGE.[/FONT]
[FONT=Courier]    PRESERVE.[/FONT]
[FONT=Courier]}.[/FONT]
[FONT=Courier]WHEN ALTITUDE = 10000 THEN {[/FONT]
[FONT=Courier]    PRINT “STARTING ROLL PROGRAM.â€Â.[/FONT]
[FONT=Courier]    LOCK STEERING TO HEADING(90,45).[/FONT]
[FONT=Courier]    WHEN HEADING = (90,45) THEN {[/FONT]
[FONT=Courier]        PRINT “ROLL PROGRAM COMPLETE.â€Â.[/FONT]
[FONT=Courier]    }.[/FONT]
[FONT=Courier]}.
[/FONT]

like it's not even malfunctioning during execution, it just doesn't run

[hvacengi]

like it's not even malfunctioning during execution, it just doesn't run

Does it stage the one time? Because it looks like you're code is missing a closing delay. As long as it stages, adding "wait until altitude > 70000." (not a good choice of altitude permanently, but OK for proof of concept) should keep the script running. But the way you have it written, the when triggers get unloaded because there is no wait.

[steddyj]

Pro tip: the queries performed by these can be expensive at times depending on your ship's part count. If re-using the same query multiple times, store it in a variable first for faster execution

Yeah, I was being lazy. For some reason I've never like using throwaway vars, probably an old happen from learning in C when they had to be declared at the top of your function.

Part of the problem is that we don't yet know how functions or procdures will be incorporated into the language, which sort of affects what the right way to implement such a thing would be (there being more than one kind of premature exit - full exit, function return with value, etc - not knowing how that will look in the end is making us not want to make any early commitments to one way over another.)

Honestly you're probably going to have to add in both a full stop and an exit with a return code. Sometimes an error will just need to terminate its own instance, and sometimes it'll be a fatal error requiring everything to halt. I would recommend adding both, or a method which could handle either case.

[Reddy]

This wiggling of the flaps etc. is kinda normal, the script is pointing the vessel in a very and i mean VERY specific position that is changing very fats with almost 0 margin for error, i remember MJ had the same issue( i don't know if it still have it).

Turns out you're wrong Running the exact same script on the same rocket, but with 5 additional large reaction wheel modules between the tanks gives optimal performance.

So I'm still going to say that LOCK STEERING is broken on anything that has no RW torque.

Edited November 21, 2014 by Reddy
terminology: SAS vs. reaction wheels

[Dunbaratu]

Terminology error: You're not using the word SAS correctly. Not only does LOCK STEERING not require SAS, but rather just the opposite. It doesn't even work *at all* with SAS.

You say "SAS" when I think you mean "torque wheels". They are not the same thing because SAS is still called SAS regardless of the mechanism it uses. It's still called SAS even when it's using monopropellant fuel to accomplish it.

"SAS" refers to the *mode* you toggle with the "T" key, not the hardware that mode makes use of.

It could be the case that LOCK STEERING doesn't work properly without torque wheels, but if so it's very very weird that it doesn't, because all LOCK searing does is take control over the "stick and rudder", overriding the player's WASDQE controls with its own. In other words when LOCK steering wants to pull up a bit, all LOCK STEERING DOES is tell KSP "set the yoke to 50% back" and leaves it up to KSP to decide whether that means to use torque wheels or RCS or both. I haven't had my hands down in that code for a while. I didn't write it and have pretty much left it alone as a black box.

The only thing I think it might be is that in order to decide how to set the controls it seems to be asking the KSP API for some information about the vessel's rotational forces and that API might be only taking into account torque wheels. If so, the math would get very wonky indeed as it would end up dividing things by nearly zero values.

Edited November 21, 2014 by Steven Mading

[Reddy]

EDIT: You were right, I had the two confused. The posts are corrected now, should be legible for everyone.

I don't know how does the LOCK STEERING work, under the hood. I have no experience in Unity, no knowledge of KSP code, and an aversion to C# - looked into the source anyways and only found that comment line in Utilities/SteeringHelper.cs:

// I take no credit for this, this is a stripped down, rearranged version of MechJeb's attitude control system

Although, there is a good chance I wasn't even looking into the right file.

Edited November 21, 2014 by Reddy

[Kertherina]

Hello again. I recently finally figured out how to also get roll of the ship, now i can start to write my own PID controller Many thanks to all who helped me in the past!

I did run into a bug after updating to the current version. I have a cfg that adds the kOS module to every command part to avoid having to add the physical kOS processors with this code:

@PART
[*]:HAS[@MODULE[ModuleCommand]]:Final{
	MODULE
	{
		name = kOSProcessor
		diskSpace = 10000
	}
}

It used to work perfectly. After updating kOS, when i try to launch something with a probe core i get a weird bug: After getting something to the launchpad (even only a probe core) my orbital velocity is 0 and instead i start with surface velocity of 400 m/s (Realism Overhaul). It doesn't move, but the Navball shows these velocities. If i activate an engine the craft accelerates as if there was no gravity holding it back, also heating acts as if i was really going at the 400+ m/s, so all kinds of strange stuff happening.

Having a probe core without using the cfg that adds the kOS module to every command part and a separate kOS processor part works. Also, command capsules don't produce this bug which is what confuses me even more.

Obviously, this is not the end of the world, i am mainly curious how something like this can cause a bug and want to let you all know. And for the record, i am using a lot of mods, list here.

[gkorgood]

Does it stage the one time? Because it looks like you're code is missing a closing delay. As long as it stages, adding "wait until altitude > 70000." (not a good choice of altitude permanently, but OK for proof of concept) should keep the script running. But the way you have it written, the when triggers get unloaded because there is no wait.

I didn't even think of that, thank you. going to test rn

EDIT: that worked beautifully, the code runs now. however, i've encountered an issue I'm sure has been brought up before; how does one get the program to stage only once? i tried adding wait commands at each instance of stage, but kOS won't let me because some staging occurs in "WHEN" clauses

Edited November 21, 2014 by gkorgood
Update

[undercoveryankee]

I didn't even think of that, thank you. going to test rn

EDIT: that worked beautifully, the code runs now. however, i've encountered an issue I'm sure has been brought up before; how does one get the program to stage only once? i tried adding wait commands at each instance of stage, but kOS won't let me because some staging occurs in "WHEN" clauses

Your problem may be that you're testing STAGE:SOLIDFUEL and STAGE:LIQUIDFUEL in separate WHEN triggers. Meaning that as soon as your last SRB burns out, SOLIDFUEL will remain zero and that trigger will keep triggering until you're out of stages. If you want ship-agnostic auto-staging code, testing for whether any engines are flamed out is probably the most general approach.

[gkorgood]

Your problem may be that you're testing STAGE:SOLIDFUEL and STAGE:LIQUIDFUEL in separate WHEN triggers. Meaning that as soon as your last SRB burns out, SOLIDFUEL will remain zero and that trigger will keep triggering until you're out of stages. If you want ship-agnostic auto-staging code, testing for whether any engines are flamed out is probably the most general approach.

that is exactly what happens. my first instinct was to add a delay after each trigger, but the only thing i could think of was WAIT commands, and kOS gives me an error for having "WAIT"s in "WHEN"s

[hvacengi]

that is exactly what happens. my first instinct was to add a delay after each trigger, but the only thing i could think of was WAIT commands, and kOS gives me an error for having "WAIT"s in "WHEN"s

I think it was Steven who posted this fun little code block that I now use for staging. It's much more generic, and doesn't care which fuel you ran out of. It will also work with asparagus staging, assuming you have everything in the right order.

set stagemaxthrust to ship:maxthrust.
when (ship:maxthrust<stagemaxthrust or ship:maxthrust<1) then {
    print "Stage!".
    stage.
    set stagemaxthrust to ship:maxthrust.
    preserve.
}

You could also add a check in the when...then code for each fuel "if not stage:liquidfuel < 0.001 { stage. }" in the solid fuel loop, and vice versa in the liquid fuel loop. I also like to add a counter to my staging. So that it stops the preserve command if you stage more than a given number of times (say 20, since I can't recall having a rocket with that many stages).

Wait's in when...then code don't work because that code is executed outside of the timer execution. You also cannot use "run" from within when...then.

[howkong]

Is there a way to preserve a "when" trigger in a few seconds after activating the trigger?

An immediate preserve sometimes causes trouble, but the "wait" method cannot be used in a "when" trigger...

[Dunbaratu]

Is there a way to preserve a "when" trigger in a few seconds after activating the trigger?

An immediate preserve sometimes causes trouble, but the "wait" method cannot be used in a "when" trigger...

Let's say you have this when-trigger right now:

when whateverCondition then {
  dostuff.
  PRESERVE.
}.

And you'd like to change it into one in which it has a 3 second cooldown time before it can trigger again.

Then edit it to be this instead:

set coolDownMark to 0.

when TIME:SECONDS > coolDownMark and whateverCondition then {
  set coolDownMark to TIME:SECONDS + 3.

  dostuff.
  PRESERVE.
}.

[Gfurst]

Finally gathering enough courage to delve into this type of automated flight.

One quick question:

Does SHIP:TERMVELOCITY actually gathers out terminal velocity, as in FAR flightdata, or does it calculate in a stock way? In other words, does it show a FAR compatible value?

And one quick suggestion:

Maybe you could think of linking up with the Kerbal Engineer mod , if its enabled, and use some of its reading data and stuff. After all it can require a part as simulation of the data being processed.

This could reduce the same data being processed in two different mods, but the main advantage is to make kOS a whole lot more intuitive to use.

Reduce the need of the user on burning his brain trying to come up with even simplest stuff. And potentially be more welcoming to lot of new users.

Lastly, how updated is the doc stuff?

[Dunbaratu]

Finally gathering enough courage to delve into this type of automated flight.

One quick question:

Does SHIP:TERMVELOCITY actually gathers out terminal velocity, as in FAR flightdata, or does it calculate in a stock way? In other words, does it show a FAR compatible value?

kOS doesn't have any special cases to handle the fact that FAR breaks parts of the KSP API. kOS is just currently returning the stock game's notion of terminal velocity.

And one quick suggestion:

Maybe you could think of linking up with the Kerbal Engineer mod , if its enabled, and use some of its reading data and stuff. After all it can require a part as simulation of the data being processed.

In general there should be external chunks of code to make kOS work with other mods that can be updated by other modders easily enough. I.E. a way to let other modders write kOS function calls that kOS scripts can use. In the meantime there is the ability to read things on a PartModule's fields, but not necessarily everything every other

mod calculates.

This could reduce the same data being processed in two different mods, but the main advantage is to make kOS a whole lot more intuitive to use.

Reduce the need of the user on burning his brain trying to come up with even simplest stuff. And potentially be more welcoming to lot of new users.

Lastly, how updated is the doc stuff?

It's accurate as of kOS 0.15.2, just a week ago.