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

[Dunbaratu]

6 hours ago, Emilienj said:

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 

Not automatically, but you could write your own wrapper function that does something like this:

function warn_message {
  parameter text, col, row.
  
  hudtext(text, 5, 2, 20, white, false).
  print text at (col, row).
}

 

[SATNAV1122]

Hello,

 

Cool thing but can you send the earlier versions so i can use them with my 1.10.1 mods please?

Your sincearly,

Nikodem K******ki

[Dunbaratu]

18 hours ago, SATNAV1122 said:

Hello,

 

Cool thing but can you send the earlier versions so i can use them with my 1.10.1 mods please?

Your sincearly,

Nikodem K******ki

Go to the github page and see the "releases" link.  It should have older versions there.

 

[MuriloMoreira]

Someone with a script for FASA's Saturn V? I'm having trouble launching it and configuring MechJeb is also kind of complex, if anyone does I would be very grateful to share it.

[realjuliusPGKC]

im trying to add scripts from outside the game but it doesnt read it in game anyhelp?

 

[Black-Two-]

51 minutes ago, realjuliusPGKC said:

im trying to add scripts from outside the game but it doesnt read it in game anyhelp?

 

What folder are you placing them in and are you switching to the library in-game? 

[JebIsDeadBaby]

Hi, 

why KERBIN:VELOCITY:ORBIT = V(0,0,0)? If thought it should return orbital velocity of Kerbin around it's parent body, which is the Sun. 

[Dunbaratu]

6 hours ago, JebIsDeadBaby said:

Hi, 

why KERBIN:VELOCITY:ORBIT = V(0,0,0)? If thought it should return orbital velocity of Kerbin around it's parent body, which is the Sun. 

Well, it sort of does... but ... the reference frame SHIP:RAW that all the velocities are returned in is the reference frame the main game uses, which is centered around the active vessel's current Sphere of Influence body.

In other words, if you are currently orbiting Kerbin, then you are getting Kerbin's velocity relative to itself, which is why it's zero.

If you want its velocity relative to the Sun, you can just not care what's the reference frame it's using and just explicitly subtract one velocity vector from the other, like so:

print "Kerbin is orbiting The Sun at " + (kerbin:velocity:orbit - sun:velocity:orbit):mag + "meters per second.".

 

[JebIsDeadBaby]

Oh, OK. This is indeed explained on the Reference Frames page. It probably would be wise to repeat some of this info here, or at least put a link there. 

[MJRMatthew]

I've been learning Kos for a couple days and have started on a docking autopilot but I cant  get the target:facing:inverse function to work so I made it add 180 degrees to the targets pitch and yaw and then used mod to get the inverse but its like the program stops adding 180 to the angles idk why is this a bug or am I just stupid?

My code looks like this

Until false {

Set pt to ((target:facing:pitch) + 180).

Set yt to ((target:facing:yaw) + 180).

Set pm to mod (pt,360).

Set ym to mod(yt,360).

Lock steering to r (pm,ym,0).

}

 

Edit:

I am infact an idiot your supposed to inverse either the pitch or the yaw not both... Lol I was just doing the equivalent of 360 degree turn

Edited February 28, 2021 by MJRMatthew

[Stone Blue]

SO I've been trying to add part support for a mod I am working on, and I am getting a stream of exceptions as soon as I enter flight scene, with only a probe core and a kOS part attached. I thin there may be a confllict between kOS and another mod when installed in combination. the issue there, is when I enter flight scene, Kerbin turns black, sky is messed up, and most eyboard input does nothing. Hitting escape, launches the camera, super fast, into space. Only option is to hard-quit the game and restart. Kind of an odd issue to explain.

Anyway, with only kOS and few mods I wouldnt expect to cause problems with kOS, I get the kOS exceptions, but at least game behaviour is normal.
on 1.11.1 and latest kOS v1.3.2.0

EDIT: Ahhhh... so i just checed Issues on the repo, and it seems I am getting the same exception as noted in this recent logged issue, reported by @stephm & @JonnyOThan: Note that I do NOT have kOS Monitor installed. @Dunbaratu let me know if I can help with testing to help narrow this down.

https://github.com/KSP-KOS/KOS/issues/2888

Here is my log and a screen shot of my GameData:
https://drive.google.com/file/d/1BPvubD-kQNyDv0a_NU38VS-O4DCV5PS5/view?usp=sharing

https://drive.google.com/file/d/1f8n7x0gsv-pX3E_3GozOOY7ArK0XRTAt/view?usp=sharing

Edited March 15, 2021 by Stone Blue

[Stone Blue]

Also, it seems a user wont know this stream of exceptions is even happening when launching craft, unless they have on screen logging enanled, or come across it when troubleshooting or digging into other issues, as game behaviour can seem normal, otherwise.

I get this with every single kOS part.

If anyone else would like to try to confirm, they can see them right after launch, by opening the Alt-F12 menu, or just enable on-screen log messages using it. Just chec the "Show all log errors onscreen" & "Show all log exceptions on screen" boxes.

Edited March 15, 2021 by Stone Blue

[Dunbaratu]

6 hours ago, Stone Blue said:

Also, it seems a user wont know this stream of exceptions is even happening when launching craft, unless they have on screen logging enanled, or come across it when troubleshooting or digging into other issues, as game behaviour can seem normal, otherwise.

I get this with every single kOS part.

If anyone else would like to try to confirm, they can see them right after launch, by opening the Alt-F12 menu, or just enable on-screen log messages using it. Just chec the "Show all log errors onscreen" & "Show all log exceptions on screen" boxes.

Thanks for the information.  I'm taking further conversation to the github issue about it.

[JebIsDeadBaby]

I dunno if I'm again having trouble understanding frames of reference but can someone explain to me why do I get results like on this picture:

I want to get a direction pointing along body's rotation axis with up direction set to the Solar Prime Vector. I use BODY:ANGULARVEL to get the direction of the axis. As you can see both Kerbin and Mun return some proper vector. However I get very different results when plugging both vectors to LOOKDIRUP, while they should be almost identical. 

The vessel is in Mun's SOI in this case and I use JSNQ. 

Edited March 19, 2021 by JebIsDeadBaby

[Dunbaratu]

3 hours ago, JebIsDeadBaby said:

I dunno if I'm again having trouble understanding frames of reference but can someone explain to me why do I get results like on this picture:

I want to get a direction pointing along body's rotation axis with up direction set to the Solar Prime Vector. I use BODY:ANGULARVEL to get the direction of the axis. As you can see both Kerbin and Mun return some proper vector. However I get very different results when plugging both vectors to LOOKDIRUP, while they should be almost identical. 

The vessel is in Mun's SOI in this case and I use JSNQ. 

That is really strange.

Can you try this experiment: normalize the m and k vectors into unit vectors first, before you pass them into LOOKDIRUP().  Is the mun one still zero if you do that?

LOOKDIRUP() is letting Unity do the heavy lifting under the hood, and a lot of Unity's stuff only uses 32-bit floats.  It might be that the mun angular velocity is just too small to survive  the floating point error in the underlying Unity call.  As a rule of thumb, if you are doing an operation where you don't really care about the magnitude of your vectors, only their aim, then getting your vectors normalized before passing them through operations like lookdirup, vcrs, vdot, vang, etc, can help with precision. 

(Sometimes even when you *do* care about magnitude, you can make things more precise by first memorizing the vector's original magnitude, then normalizing it and running it through the vector operator, then multiplying the result by a scalar afterward to restore the proper magnitude.)

[JebIsDeadBaby]

32 minutes ago, Dunbaratu said:

Can you try this experiment: normalize the m and k vectors into unit vectors first, before you pass them into LOOKDIRUP().  Is the mun one still zero if you do that?

Dang, you're right on the money. Your trick does work. 

[Dunbaratu]

8 hours ago, JebIsDeadBaby said:

Dang, you're right on the money. Your trick does work. 

That makes me wonder if it would be worth it to have kOS spend a few clock cycles copying the vectors it receives into a normalized form when doing LOOKDIRUP() and VANG().  With VCRS() and VDOT() the magnitude is relevant so it can't do it there, but for LOOKDIRUP and VANG the magnitudes don't matter.  (VXCL() could do it to the first argument (the normal vector of the plane being projected onto) but not the second.)

Edited March 20, 2021 by Dunbaratu

[Nikola]

Its really unfortunate that the Principia addon to this died because the Principia side of things could not get a PR in, even when one existed.

[Kartoffelkuchen]

Is there still no support for axis-controlled robotics interaction from the Serenity Expansion?

[Dunbaratu]

12 hours ago, Kartoffelkuchen said:

Is there still no support for axis-controlled robotics interaction from the Serenity Expansion?

It was never something I worked on.  Not using a controller myself it's not a thing that's really on my radar much.

[garwel]

It's me again, and I'm going to talk about the same issue: latest version of kOS' handling of RCS.

I've done some testing with a simple vessel with RCS controls and no reaction wheels. With weak RCS (I used 8 ReStock's 0.1-strong RV-1X thrusters), stock SAS turns the sample vessel into the desired position in 6-7 seconds using just 1 unit of monoprop. kOS with cooked control takes about 40 s and 3.5 units of monoprop for the same maneuver.

If you install stronger RCS (8 RV-105 thrusters, 1 kN each), things get even worse. Stock SAS works just as quickly and just spends a bit more RCS fuel. kOS, however, never really managed to completely stabilize and spent at least a minute and 15 units of monopropellant to at least get close to the desired direction.

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. Vessel R1-105 uses strong RCS thrusters, vessel R1-1X uses weak ones. I tested by setting SAS to prograde and by using script that did "LOCK STEERING TO PROGRADE." (and a wait loop).

I am pretty certain things didn't look so bad in the older version of kOS steering. I used it extensively and the only problem I had was too small corrections when near the desired direction (and IIRC these mostly happened when the vessel was in the atmosphere). So far, my attempts to play with PID parameters haven't brought any good results.

Is it a bug or WAD? Is there a way to revert to the old system?

[Dunbaratu]

17 hours ago, garwel said:

It's me again, and I'm going to talk about the same issue: latest version of kOS' handling of RCS.

I've done some testing with a simple vessel with RCS controls and no reaction wheels. With weak RCS (I used 8 ReStock's 0.1-strong RV-1X thrusters), stock SAS turns the sample vessel into the desired position in 6-7 seconds using just 1 unit of monoprop. kOS with cooked control takes about 40 s and 3.5 units of monoprop for the same maneuver.

If you install stronger RCS (8 RV-105 thrusters, 1 kN each), things get even worse. Stock SAS works just as quickly and just spends a bit more RCS fuel. kOS, however, never really managed to completely stabilize and spent at least a minute and 15 units of monopropellant to at least get close to the desired direction.

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. Vessel R1-105 uses strong RCS thrusters, vessel R1-1X uses weak ones. I tested by setting SAS to prograde and by using script that did "LOCK STEERING TO PROGRADE." (and a wait loop).

I am pretty certain things didn't look so bad in the older version of kOS steering. I used it extensively and the only problem I had was too small corrections when near the desired direction (and IIRC these mostly happened when the vessel was in the atmosphere). So far, my attempts to play with PID parameters haven't brought any good results.

Is it a bug or WAD? Is there a way to revert to the old system?

I don't see this when I try it in stock so I'm going to have to try your exact mods and your exact save to see if I can reproduce it.  I'll try that tomorrow.

[JebIsDeadBaby]

@Dunbaratu - isn't it the case of this issue?

Edited April 1, 2021 by JebIsDeadBaby

[garwel]

6 hours ago, JebIsDeadBaby said:

@Dunbaratu - isn't it the case of this issue?

Sounds plausible.

PS: However, I've done tests with much heavier vessels (up to 13 t instead of 3 t in my original tests), which should be slower to turn and therefore free from this bug, and the result was still worse than desired: kOS overshot the target direction by about 90 degrees (in the first iteration), and took overall about 1 minute and 6 units of monoprop for the maneuver vs 30 s and 3-4 units of monoprop for stock SAS (which also moves very smoothly and doesn't overshoot at all).

Edited April 1, 2021 by garwel

[Dunbaratu]

10 hours ago, JebIsDeadBaby said:

@Dunbaratu - isn't it the case of this issue?

That should only happen when the total rotation time it takes to get aligned is less than 4 seconds.  The description says it's longer than that even in stock SAS.