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

[stephm]

hi !

@Dunbaratu  i answered you  here  I'm ok for testing !

(I give you a link to a recompiled kOS.DLL file on my google drive)  Ok for that.

Steph.

[MacLuky]

Hi. can i find the old docs somewhere? i am on ro/rss and using an older version of kos, lacking deltav info i discovered

[garwel]

On 1/25/2021 at 1:05 AM, Dunbaratu said:

As far as an exit - yeah I know.  It got stuck in limbo because I kept waffling on whether or not programs should have exit codes.  But it should be dealt with.

Personally, I never felt the need to return a value from a script (and I could do it with global variables anyway).

I also encounter the same problem as @JebIsDeadBaby: RCS keeps firing for too long, and the ship "swings" back and forth for a long time. In one case, when my vessel's CoM was a bit off, it used all the monopropellant (which was supposed to be enough for a long journey) and still failed to orient itself correctly. I also use MandatoryRCS, and KSP is 1.11.

[JebIsDeadBaby]

@garwel - you can use this for the time being

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

RCS will work flawlessly then. Engine gimballing will be a little too aggressive for a change but nothing game breaking. 

[Dunbaratu]

2 hours ago, garwel said:

Personally, I never felt the need to return a value from a script (and I could do it with global variables anyway).

I also encounter the same problem as @JebIsDeadBaby: RCS keeps firing for too long, and the ship "swings" back and forth for a long time. In one case, when my vessel's CoM was a bit off, it used all the monopropellant (which was supposed to be enough for a long journey) and still failed to orient itself correctly. I also use MandatoryRCS, and KSP is 1.11.

Reading through the MandatoryRCS code on github, it appears that its nerfing of reaction wheels is done in a way that is problematic for other mods that also have an OnFlyByWire() pass like kOS.

I say this because the order of events seems to be this:

1 - In its Update(), kOS queries the sum of all torque capability provided by all parts (RCS, reaction wheel, engine gimbal, etc).
2 - In its OnFlyByWire(), kOS uses that value to choose how it should set the pitch/yaw/roll controls.
3 - In its OnFlyByWire(), MandatoryRCS nerfs the reaction wheel capability now that it's too late for kOS to see the change.
4 - Now the stock game physically affects the ship by applying the pitch/yaw/roll controls  that kOS assigned in step 3 above.
5 - Now the stock game resets the reaction wheels' torque back to stock values for the next pass.
6 - Back to step 1.

This order of events makes the nerfing that MandatoryRCS does be invisible to kOS, since that nerfing only exists temporarily in between kOS's passes.  By the time kOS queries the values again next pass, they're back to their stock settings again, and won't get re-nerfed until after kOS's OnFlyByWire() control settings have been locked in.

It might be possible to work around this by having kOS move its torque capability query to its OnFlyByWire() instead of its Update(), and also continually check the Delegate dispatch chain order of OnFlyByWire()s and if kOS's hook comes before MandatoryRCS's hook, have kOS move it's hook to the end of the chain to guarantee it lets MandatoryRCS go first (swapping the order of step (2) and step (3) in my above description.)  But that's a weird ad-hoc fix to a problem I'm not really sure is kOS's fault.

At any rate, you can do as @JebIsDeadBabysuggested above, which tells kOS "pretend the torque is only 10% as powerful as it claims to be, and act accordingly".  This is not an ideal solution (because it globally nerfs the measure of the SUM of all sources of torque, including RCS thrusters, rather than just nerfing the reading from the parts with the problem, which are the reaction wheels).

Edited January 28, 2021 by Dunbaratu
previous version said the same thing like 3 times over.

[Dunbaratu]

3 hours ago, MacLuky said:

Hi. can i find the old docs somewhere? i am on ro/rss and using an older version of kos, lacking deltav info i discovered

Unfortunately the web server that github provides for gh-pages only really serves up the most recent version of the html, and doesn't have a means to automatically let you select an older version.  But, you CAN get access to an older commit of the HTML files copied locally onto your own computer, and have your browser render the local HTML files using a local file:/// url.

First you have to be set up to be able to clone github repos (and that's a long topic in itself, but the information is freely available online for how to do that).

If you are set up to be able to clone git repos, and you have gitbash, do the commands below to get the docs for kOS 1.2.0.0, which I assume is what you want because that was the last documentation change before kOS stopped supporting KSP 1.8:

git clone [email protected]:KSP-KOS/KOS_DOC.git
cd KOS_DOC
git checkout gh-pages
git checkout af93a757

If you want to know where "af93a757" came from, it was from looking at the KOS_DOC commit history on this page and finding the commit that was labeled as being for that kOS version: https://github.com/KSP-KOS/KOS_DOC/commits/gh-pages

That *should* give you a local copy of the HTML files so you can just point your browser at the index.html and go from there.

Edited January 28, 2021 by Dunbaratu

[garwel]

Thanks, I've reported it in the MandatoryRCS thread.

[MacLuky]

Oh yes, that works! Bummer that I lost the delta-v stuff, but I'll see if I can port that through kerboscript. Thank you so much for the detailed instructions!

[stephm]

Tested Method with python work too

to create a html doc. 

Follow the method python 2.7 install+pip

+ sphinx (on github) 

After that, make html create a full folder with all sections for kos docs. 

Steph

Edited January 28, 2021 by stephm

[garwel]

I removed the MandatoryRCS DLL, but I still have the oscillation. I think the problem arises when you have no or very weak reaction wheels: kOS can't stabilize the vessel only using RCS and the engine. Strangely, it worked reasonably well in the past (although sometimes it used too much monoprop for preventing roll).

I noticed that it gets better when I manually turn off RCS about halfway between towards the target orientation at every oscillation. Then I manage to reduce the amplitude and have the (more or less) needed orientation. So my idea is that the PID just keeps firing RCS thrusters for too long. It may cause any issues when you have strong reaction wheels, because they'll eventually stabilize the craft, but with weaker (and more realistic) RW, you are doomed to have this endless swinging.

I'm not very good with PID settings, so I'm wondering if this is something that can be addressed in scripts (other than using more stronger reaction wheels).

[MacLuky]

I am having some problems with COPYPATH. Is there a way to debug this? 

SET startupScript TO SHIP:NAME + ".ks".
SET remoteCopy TO "0:/" + startupScript.
SET localCopy TO "1:/" + startupScript.

COPYPATH (remoteCopy, localCopy).
RUNPATH (localCopy).

As you can see I have a file "Hammer-D0-06.ks" on volume 0 that i want to copy to volume 1. The command does not result in an error, but no file gets copied. I've also checked the logfile and can't find a clue. Any idea? I am on KOS 1.2.1.0

 

[garwel]

1 hour ago, MacLuky said:

I am having some problems with COPYPATH. Is there a way to debug this? 

SET startupScript TO SHIP:NAME + ".ks".
SET remoteCopy TO "0:/" + startupScript.
SET localCopy TO "1:/" + startupScript.

COPYPATH (remoteCopy, localCopy).
RUNPATH (localCopy).

As you can see I have a file "Hammer-D0-06.ks" on volume 0 that i want to copy to volume 1. The command does not result in an error, but no file gets copied. I've also checked the logfile and can't find a clue. Any idea? I am on KOS 1.2.1.0

 

Check that you have enough disk space on the kOS CPU volume. If you don't, it just silently skips copying.

[MacLuky]

Ah thanks! yes that was it. It means I should either write more condensed or write a "compiler" that simplifies the script

[MacLuky]

Confirmed, that was the case. Thanks man!

[klh1228]

Hey all - No idea how this happened but every time my game saves now, I am getting a console error:

https://1drv.ms/u/s!AnWBehSzp6LgmBrGGMzccURNQjt-?e=VEDXYB

The game seems to be saved OK, but the message appearing constantly is pretty distracting.  I've tried various things, including uninstalling and reinstalling the KOS mod, to try to get it to go away, but with no luck.  I can't figure out what the root cause (no pun intended) might be.

Any ideas on how to track this down, and eliminate it?    Thanks!

[Dunbaratu]

4 hours ago, klh1228 said:

Hey all - No idea how this happened but every time my game saves now, I am getting a console error:

https://1drv.ms/u/s!AnWBehSzp6LgmBrGGMzccURNQjt-?e=VEDXYB

The game seems to be saved OK, but the message appearing constantly is pretty distracting.  I've tried various things, including uninstalling and reinstalling the KOS mod, to try to get it to go away, but with no luck.  I can't figure out what the root cause (no pun intended) might be.

Any ideas on how to track this down, and eliminate it?    Thanks!

Since it's talking about plugin configuration in XML format it's probably talking about having trouble loading this file:

GameData/kOS/Plugins/PluginData/kOS/config.xml

That file contains your global kOS settings that are not savegame-specific (mostly the stuff you see in the toolbar panel for kOS).  There might be something corrupt in that file.  Have a look at it.  If you can't figure it out you might be able to just wipe that file with a new copy taken from the kOS ZIP file (it will lose your kOS settings but you should be able to put them back like you had them after that)

[Dunbaratu]

23 hours ago, garwel said:

I removed the MandatoryRCS DLL, but I still have the oscillation. I think the problem arises when you have no or very weak reaction wheels: kOS can't stabilize the vessel only using RCS and the engine. Strangely, it worked reasonably well in the past (although sometimes it used too much monoprop for preventing roll).

I noticed that it gets better when I manually turn off RCS about halfway between towards the target orientation at every oscillation. Then I manage to reduce the amplitude and have the (more or less) needed orientation. So my idea is that the PID just keeps firing RCS thrusters for too long. It may cause any issues when you have strong reaction wheels, because they'll eventually stabilize the craft, but with weaker (and more realistic) RW, you are doomed to have this endless swinging.

I'm not very good with PID settings, so I'm wondering if this is something that can be addressed in scripts (other than using more stronger reaction wheels).

You have a zillion mods installed, if I remember.

Can you reproduce the problem on a stock install with just kOS and no other mods?  It would make it a heck of a lot easier for me to look at.

I spent a heck of a long time with people who using all kinds of realism settings and play in RO/RP-1 to get the new steering to work for the case of heavy ships that only have RCS for rotation and they've reported much improvement over the old steering.  You're the only one who said it got worse than it was before.  There's got to be something different about your test case from what I was testing, and I need to find out what it is.

Edited January 30, 2021 by Dunbaratu

[danielboro]

On 1/29/2021 at 8:43 PM, MacLuky said:

Confirmed, that was the case. Thanks man!

you can use if copypath()
copypath returns false if it fails to copy

[klh1228]

On 1/30/2021 at 12:57 AM, Dunbaratu said:

Since it's talking about plugin configuration in XML format it's probably talking about having trouble loading this file:

GameData/kOS/Plugins/PluginData/kOS/config.xml

That file contains your global kOS settings that are not savegame-specific (mostly the stuff you see in the toolbar panel for kOS).  There might be something corrupt in that file.  Have a look at it.  If you can't figure it out you might be able to just wipe that file with a new copy taken from the kOS ZIP file (it will lose your kOS settings but you should be able to put them back like you had them after that)

You, sir, are a scholar and a gentleman.   This file was empty, so I just deleted it and I'm not seeing the error on saves any longer.  Thanks so much!

[JebIsDeadBaby]

Hello again.

while docking two ships I get CTD with no error messages about one second after successful connection . These are the last entries in the log:

[LOG 17:08:55.939] 2/4/2021 5:08:55 PM,kOS-IRWrapper,Attempting to Grab IR Types...
[LOG 17:08:55.952] [FAR v0.16.0.1]: Updating vessel voxel for Space Station-2
[LOG 17:08:56.360] [FAR v0.16.0.1]: Voxel Element CrossSection Area: 0.00980822366822485
Std dev for smoothing: 3 voxel total vol: 167.724347110611 filled vol: 32.2048617377845

If I remove FAR the last entry is kOS, I just wanted to show that kOS is not the last mod trying  to do something on this newly merged ship. I can't remove kOS for further testing as there are kOS cores on merging ships. So I just want to ask you if in your opinion, whatever kOS is trying to do here, may be a cause for CTD? 

[Dunbaratu]

6 hours ago, JebIsDeadBaby said:

Hello again.

while docking two ships I get CTD with no error messages about one second after successful connection . These are the last entries in the log:

[LOG 17:08:55.939] 2/4/2021 5:08:55 PM,kOS-IRWrapper,Attempting to Grab IR Types...
[LOG 17:08:55.952] [FAR v0.16.0.1]: Updating vessel voxel for Space Station-2
[LOG 17:08:56.360] [FAR v0.16.0.1]: Voxel Element CrossSection Area: 0.00980822366822485
Std dev for smoothing: 3 voxel total vol: 167.724347110611 filled vol: 32.2048617377845

If I remove FAR the last entry is kOS, I just wanted to show that kOS is not the last mod trying  to do something on this newly merged ship. I can't remove kOS for further testing as there are kOS cores on merging ships. So I just want to ask you if in your opinion, whatever kOS is trying to do here, may be a cause for CTD? 

I can't imagine how it could be.  exceptions thrown in kOS tend to get caught and just ruin kOS, not the whole game.  And even if they're not, the stock game itself tends to catch exceptions mods throw, in general.  But it's impossible to prove where it crashed without a post-mortem crash file to load into a debugger, and try as I might i have *never ever* gotten debugging to work right with KSP.  (As in, trying to look at the kOS code in the Visual Studio debugger.)  There were some instructions how modders can attach the debugger to a running process of KSP, but following them led to ... nothing happening and no error messages explaining why so.... I just gave up.  Meaning, I have a hard time proving anything about a crash that won't show any messages in the logs.  Also look at KSP.log, as it may be more low level than player.log and might say something more.

Edited February 4, 2021 by Dunbaratu

[stephm]

hi !

I have some problems with Kos especially when launching the ship on the track, the script in the boot folder loads well, I included this as indicated in the docs

wait until ship:unpacked.

then I go into the cockpit and I launch KOS from the MFD with Kpm, I use the enter button for the page, and in the KOS script I have a pause that unlocks the script once the Enter key press, I access it by the dedicated function kpm:addons

to give the illusion that the MFD Enter buttons starts the script.

the problem is that when the script turns (for the first time) it does not always react to the action of the enter button, sometimes it works but most of the time not.

The fact turn off by the stby button terminal and turn it back on, restarts the script (boot) and this time the script reacts to the mfd key enter!

I trained to access the "kOSProcessor" module, but on the other hand when I look at the doc KOS there is this:

Quote

structurekOSProcessor

Suffix	Type	Description
All suffixes of PartModule		kOSProcessor objects are a type of PartModule
MODE	:ref:`string <string>`	OFF, READY or STARVED
ACTIVATE	None	Activates this processor
DEACTIVATE	None	Deactivates this processor
TAG	:ref:`string <string>`	This processor’s name tag
VOLUME	Volume	This processor’s hard disk
BOOTFILENAME	:ref:`string <string>`	The filename for the boot file on this processor
CONNECTION	:struct:`Connection	Returns your connection to this processor

There is no example on this page, I have no idea to accede to his commands.

Are these functions accessible by the moduledoaction thing ?,

or is there another way? to accede to it.

I'm lost.....

steph.

 

 

[Dunbaratu]

I can't comment about the MFD, as I don't use Rasterprop monitor, and the kOSPropMonitor mod is done by someone else.

But I can answer this:

4 hours ago, stephm said:

I trained to access the "kOSProcessor" module, but on the other hand when I look at the doc KOS there is this:
 

kOSProcessor is the type returned by the bound variable CORE.

So for example:
 

print "The core is currently " + CORE:MODE.
print "The core's boot filename is currently " + CORE:BOOTFILENAME.

 

[stephm]

hi ! 

@Dunbaratu  I tested the CORE structure but only the suffixes of the Core docs page.

I tested CORE:ELEMENT, CORE:VERSION and CORE:TAG very useful to recover the module "KosProcessor"

I did not think that the suffixes of the page kOSProcessor worked too.

I'll tested it right away thank you!

Steph.

EDIT:

ok it works, it was simple actually, but it does solve the problem of my ENTER button, at the first boot of the script that does not react, it does not matter in fact, it's just that can not synchronize my effect of initialization of the MFD, unless to put a wait very long but it's not very controlled.

 

Edited February 6, 2021 by stephm

[Emilienj]

Hello,

Firstly thanks for this beautiful mod. 
i want to know if is it possible to have the same function as the function « at » does for « print » but for the function Hudtext ? If yes how can i do this ?

thanks