[KSP 1.12.x] kOS v1.4.0.0: kOS Scriptable Autopilot System

[Dunbaratu]

On 3/31/2021 at 2:59 AM, garwel said:

You can test it out yourself with this save I've made: https://mega.nz/file/eyJ2mBIY#iblUThD75r7nQX98JbwNurpCRT0RUX11uQU_OAjhPrY

Mods used: kOS (v1.3.2), ReStock, ReStock+, Module Manager. KSP 1.11.1.

I had a brief window of time to test this today but this information wasn't true.  The save file is for KSP 1.11.2, not 1.11.1 so I have to re-download a fresh copy to perform the test on KSP 1.11.2, and that means I'll try tomorrow.  (I barely had an open window of time today and having to prep a different install of the game with the right mods etc pushes me over the time limit.)

[garwel]

8 hours ago, Dunbaratu said:

I had a brief window of time to test this today but this information wasn't true.  The save file is for KSP 1.11.2, not 1.11.1 so I have to re-download a fresh copy to perform the test on KSP 1.11.2, and that means I'll try tomorrow.  (I barely had an open window of time today and having to prep a different install of the game with the right mods etc pushes me over the time limit.)

Sorry about that. I haven't played KSP for a few months, so I forgot it got updated meanwhile.

[Dunbaratu]

13 hours ago, garwel said:

Sorry about that. I haven't played KSP for a few months, so I forgot it got updated meanwhile.

Okay I had a look at this today.  First I started by recreating your vessel in pure stock without Restock, to see if Restock was doing anything funny to it.  I got the same thing in pure stock that you were getting.

Also, you didn't tell me the reason it was taking 40 seconds was because it overshot the setpoint and kept oscillating back and forth across it.  That's relevant.  The picture I had in my head was that it was taking 40 seconds to turn agonizingly slowly toward the target, not a mere 3  seconds plus another 37 seconds wavering around before settling down.  That's a very different kind of problem, generally caused by kOS thinking there's way more torque available than there really is.  (So it thinks it can stop in an instant when it can't.)

I don't know yet why the torque values being reported are clearly weird, and I'll have to examine that in detail, but for the time being this seems to really help with that design, as a workaround:

set steeringmanager:pitchtorquefactor to 0.25.
set steeringmanager:yawtorquefactor to 0.25.
set steeringmanager:rolltorquefactor to 0.25.

This tells kOS "pretend the vessel's torque capability is only 1/4 as big as it's being reported to be, and act accordingly."

How I know the values are bogus - the R1-IX thruster should be doing 0.1 kN of thrust.  In any one rotation axis the best case is having 4 of them helping push that rotation (i.e. pitch by having two at the bottom push one way and two at the top push the other way).  The entire vessel is only about 5 meters long, so if we assume a Center of Mass halfway between one end and the other, that's a torque of 4 * 0.1kN * 2.5m or about 1Kn*m.

But the torque it was *claiming* was about 2.5to 3 Kn*m.  So something is probably wrong with the kOS TorqueProvider replacement code, and I'll have to look into that.  But that's a long term thing.  In the mean time, try the 3 lines above (put them somewhere temporary you can remove later if a future release of kOS fixes this).

 

[UltraJohn]

I'm getting a bunch of errors in the ksp.log

[EXC 15:22:26.836] ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
	System.ThrowHelper.ThrowArgumentOutOfRangeException (System.ExceptionArgument argument, System.ExceptionResource resource) (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0)
	System.ThrowHelper.ThrowArgumentOutOfRangeException () (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0)
	kOS.Screen.Interpreter.IsWaitingForCommand () (at <3ccb18ebae2a49929054690a1a176760>:0)
	kOS.Screen.TermWindow.ProcessUnconsumedInput () (at <3ccb18ebae2a49929054690a1a176760>:0)
	kOS.Screen.TermWindow.Update () (at <3ccb18ebae2a49929054690a1a176760>:0)
	UnityEngine.DebugLogHandler:LogException(Exception, Object)
	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
	UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

Log: https://www.dropbox.com/s/cgysg9a20jdxzug/KSP.log?dl=0

[Dunbaratu]

9 hours ago, John007qwe said:

I'm getting a bunch of errors in the ksp.log

[EXC 15:22:26.836] ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection.
Parameter name: index
	System.ThrowHelper.ThrowArgumentOutOfRangeException (System.ExceptionArgument argument, System.ExceptionResource resource) (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0)
	System.ThrowHelper.ThrowArgumentOutOfRangeException () (at <ad04dee02e7e4a85a1299c7ee81c79f6>:0)
	kOS.Screen.Interpreter.IsWaitingForCommand () (at <3ccb18ebae2a49929054690a1a176760>:0)
	kOS.Screen.TermWindow.ProcessUnconsumedInput () (at <3ccb18ebae2a49929054690a1a176760>:0)
	kOS.Screen.TermWindow.Update () (at <3ccb18ebae2a49929054690a1a176760>:0)
	UnityEngine.DebugLogHandler:LogException(Exception, Object)
	ModuleManager.UnityLogHandle.InterceptLogHandler:LogException(Exception, Object)
	UnityEngine.Debug:CallOverridenDebugHandler(Exception, Object)

Log: https://www.dropbox.com/s/cgysg9a20jdxzug/KSP.log?dl=0

This seems to be only happening during scene setup, and only with people who have lots of mods.  Once scene setup is done the messages stop.  I don't know the cause but it is harmless at the moment.  It seems kOS is being told to start running FixedUpdate() before the scene is done being set up, so kOS hasn't initialized everything yet. It may be a race condition that only occurs when there's a lot of mods so scene setup takes longer than normal.

Edited April 7, 2021 by Dunbaratu

[Dunbaratu]

 

On 4/2/2021 at 3:42 PM, Dunbaratu said:

I don't know yet why the torque values being reported are clearly weird, and I'll have to examine that in detail, but for the time being this seems to really help with that design, as a workaround:

set steeringmanager:pitchtorquefactor to 0.25.
set steeringmanager:yawtorquefactor to 0.25.
set steeringmanager:rolltorquefactor to 0.25.

 

@garwel I had some time today to look at the problem and I think I know what's wrong.  I don't know how to fix it yet, but I know the cause of the problem.

The problem also occurs in stock, not just restock, BUT  it is slightly exacerbated by restock.

But what *is* relevant is that the problem is caused by changes in KSP 1.11.x versus KSP 1.10.x.  It was correct before KSP 1.11.0.  Specifically it did this:

1. KSP RCS part modules have an array of all the rcs thruster transforms (position plus orientation) for the part.  i.e. the one-nozzle RCS thruster has just one thrust transform for the one nozzle, but the 4-way block has 4 thrust directions one for each nozzle.
2. kOS calculated the torque capability of the RCS part by iterating over these thruster directions and summing up the torque they can give based on where they are relative to center of mass
3. KSP 1.11 introduced the new feature that RCS parts have variants.  For example you can use the version of RCS block that angles the nozzles slightly out, or the variant that has them straight.
4. To implement the variants in KSP 1.11, the superset of *all* possible nozzles across all variants are defined in the array mentioned in bullet point (1) above.  Presumably there exists a place where it's specified which of them are actually present.
5. kOS didn't "know" about this change  so it was still assuming all the rcs nozzle definitions in the array are all present at once.  So it was calculating torque as if all the nozzles for variants other than the current variant will be thrusting too, and thus getting values much too high.
6. It's a bit worse with Restock because it apparently defined more variants.  (There are 9 variant nozzle positions in KSP 1.11 stock RCS 4-way blocks, and 18 variant positions in restock RCS 4-way blocks).

The fix will have to involve me finding out where in KSP it defines which of the variant rcsTransforms are the ones currently actually existing in the part, and ignoring the ones for other variants.

[Dunbaratu]

Update: I found a way to identify which of the thrusterTransforms are actually present in the current part variant and which are not, so I made a PR about it.

[garwel]

Great to hear you got to the root of the problem. Must be very frustrating having to fix something you didn't break.

[minerbat]

hi! i'm new to this mod and i'm wondering if it's possible to run commands/scripts using an action group?

[kcs123]

1 hour ago, minerbat said:

hi! i'm new to this mod and i'm wondering if it's possible to run commands/scripts using an action group?

Yes. There is example in kOS documentation about it. Trick is to create endless script that react on events or triggers, like action groups. For example:

// showing GUI on demand by pressing action group
on AG4 {
    Aircraft_GUI:show().
    preserve. // ensurance that AG is triggered again on demand
}.

Note that is just small snipset from larger piece of code. Without it it does not make much sense, but good enough for example. When showing GUI become available in kOS, I prefer to use events on GUI buttons pressed, released, etc. Using only one action group to toggle GUI window. Rest of AGs are used for other craft controls. You can use those events as you see how it fits your purpose, though.

[Janus92]

kOS is awesome!! Thanks for the hard work! I've been having a blast!

 

I couldn't help posting these gifs to show the progress I'm making thanks to kOS:

Returning from a Retrograde orbit:

And coming back from a Polar orbit:

Bill Kerman also says thanks! He lost his sandwich during the landing though. Must have fallen somewhere under the seat..

[New Horizons]

I have one simple question to file format of global files in drive 0. Docs mentions the suffix ".ks", but I get files without any ending when saving them in drive 0.

[Dunbaratu]

2 hours ago, New Horizons said:

I have one simple question to file format of global files in drive 0. Docs mentions the suffix ".ks", but I get files without any ending when saving them in drive 0.

"When saving them in drive 0" from kOS or from outside the game in some file manager or text editor?   I believe when kOS *reads* the files it can accept them without mentioning the .ks but when *writing* them you need to explicitly include it.  When in doubt just state it explicitly.

Also, if you are on Windows, be aware of the secret trap where the default settings for its file manager window actively lie to you about the filename by hiding the extension portion of the filename.  If you are on Windows, then in Windows Explorer (the file browsing window), open the folder Ships/Script and click folder options in the top of the window and then "view" and there should be a checkbox that hides extensions.  It's turned on by default and you need to change that so it will stop hiding the true filenames.

Edited May 24, 2021 by Dunbaratu

[New Horizons]

I actually activated file extension in Windows Explorer. I will try creating a file with ".ks" ending iin my external editor. But saving files ingame does create them without any ending and running them works fine.

[JebIsDeadBaby]

Question about creating directions by adding rotations to predefined directions, like this:

LOCK STEERING TO SHIP:PROGRADE + R(90,0,0).

where components of R are (pitch, yaw, roll). This should in effect point the ship to Radial Out. And it works like this while in Kerbin orbit. However, in Mun orbit, R seems to be build like this (yaw, pitch, roll). The same command will point the ship in the Normal direction. This was confusing me for quite some time but since I use rotations rarely, whenever this happened to me I thought I forgot something about coordinate systems again. But today I decided to check it out on two vessels (one orbiting Kerbin and one orbiting Mun in the same game session) and I'm positively 100% sure - the same command gives different results in different SOI's. Why is that?

[scimas]

Directions represent rotations, which should be multiplied. The addition of directions is supported but not well behaved as explained in the docs here https://ksp-kos.github.io/KOS_DOC/math/direction.html#operations-and-methods .

[surge]

...it's more likely you want R * V, rather than the more logical V *R... because that's the way matrices in maths work

 

On another topic, if someone wants to

set DEBUG to True.

and take a look at:

https://sourceforge.net/p/obtlib/code/HEAD/tree/head/Ships/Script/obtlib/lib/obtlib_mission.ks

https://imgur.com/z6uQoxk

(slightly more advanced, working copy - also points out another error in kOS

caused by "peeklog()")

 

I've been warned off trying to use the normal file access in kOS before, but for this case, JSON is far overdoing it and entirely unnecessary. All I need is a simple line by line access to files.

Also there's that "Contact the developers" thing. Normally I'd put this on github, but with the forced password changes a while back, I've lost access to my github account and I have little reason or desire to make a new one.

Cheers. (no, i'm not called Kevin

 

 

Edited June 6, 2021 by surge
bit of comedy, why not

[surge]

...just noticed i gave the head revision, you'll want r83 if you are looking at that URL in the future. "ooo time travel! magical"

[surge]

Janus92,

Do you plan to release your work? Those images are quite impressive. I've nearly perfected the same thing for bodies which have no atmosphere. Available at http://obtlib.sourceforge.net mentioned above - file landnatm.ks. I won't link to the direct file because it depends on a few other parts of the system.

I've had a go at atmospheric versions, but never really nailed it. A long time ago a guy made a similar thing:

His relied heavily on RCS and B.R.A.K.E.S. (or whatever they're called now) and quite a few fudge factors from memory. but he had some innovative vector calculations in there. I am too dumb to understand them, but seeing your cute little targeting triangles, I figure you might be interested.

 

Edited June 7, 2021 by surge

[surge]

After careful reading, I notice that the file descriptor iterators need a :next after opening a file. Sorry about that, problem solved.

The developers might want to change that error message to something less panicky, like "invalid iterator", though.

During my fiddling, I did notice that :atend does not work at all. Nothing in the docs about it, it *always* returns "False". The docs mention that :reset no longer works, I wonder if :atend lost its functionality in the process. Certainly worth a look.

 

[StarkRG]

It seems like in 1.12 the accelerometer sensor is giving an acceleration not including the gravity vector, so sitting still on a launch pad it returns approximately 0, but when falling on kerbin it will show approximately 9.8-ish, this is contrary to what's in the documentation, assuming I'm reading it correctly. Similarly the Grav sensor provides its reading in m/s (shows 9.8-ish on kerbin), not in terms of g as the documetnation states. Is anyone else getting this or is it just some weird mod interference on my install?

[Wercho]

Has anyone tried to change the appearance of scrollbars? I can't get the "thumb" to change appearance, despite getting everything else to change. Buttons, labels, textfields, boxes, even the scrollbar background all work, but not the thumbs.

I've tried setting all the different states :bg suffixes (eg. normal, normal_on, ... , focused_on) to no avail. 

Edited September 19, 2021 by Wercho

[Staticalliam7]

Is the docs in a pdf form that i can read offline? thanks

[ColKlonk2]

Next stop... Mun via the pole.

Spoiler

 

https://youtu.be/KAF2n9Ol9Q4

Edited October 10, 2021 by ColKlonk2

[Qwarkk]

It seems that kOS only recognises a part as belonging to the action group it is first assigned to. Hopefully this will explain what i mean:

Example 1: In VAB, part x is assigned to action group 1 followed by action group abort. This will not show when running print Ship:partsingroup("abort").

Example 2: In VAB, part x is assigned to action group abort followed by action group 1. This will show when running print Ship:partsingroup("abort").

Is this intentional behaviour for kOS? Is there a workaround?