Jump to content

[KSP 1.10.1 and 1.11] kOS v1.31.0 : kOS Scriptable Autopilot System


Recommended Posts

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.)

Link to post
Share on other sites
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.

Link to post
Share on other sites
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).

 

Link to post
Share on other sites

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

Link to post
Share on other sites
Posted (edited)
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 by Dunbaratu
Link to post
Share on other sites

 

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.

Link to post
Share on other sites
  • 2 weeks later...
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.

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...