Jump to content

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


Recommended Posts

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

 

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

 

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

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

 

Link to post
Share on other sites

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

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 by Stone Blue
Link to post
Share on other sites

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

Link to post
Share on other sites

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:

Clipboard01.jpg

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 by JebIsDeadBaby
Link to post
Share on other sites
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:

Clipboard01.jpg

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

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

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

Link to post
Share on other sites

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?

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

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