[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Sebra]

1 minute ago, maculator said:

Right now I'm using this:

you should add at least

return false.

after if

or better

function circa {
	parameter a, b, tolerance.
	return (a - tolerance) < b and (a + tolerance) > b .
}

Edited April 9, 2017 by Sebra

[maculator]

Okay I will, I just thought since I'm only waiting for it to be true there would be need for a else.

Since you seem to know stuff:

How can I check if my ship is facing retrograde for good?

This is what I'm doing right now, but it somehow wobbles arround retrograde and I have to wait a long time for it to lock it:

Spoiler

wait until (lpad:distance)/1000 < 500.
set warp to 1.
wait until (lpad:distance)/1000 < 400.
set warp to 0.
lock steering to ship:retrograde.
wait 10.

 

edit: those 10 seconds arent enough and the ship is basically just a pod, a tank and a terrier.

Edited April 9, 2017 by maculator

[Sebra]

http://ksp-kos.github.io/KOS_DOC/math/vector.html#function:VANG

For example

FUNCTION RDV_STEER {
  PARAMETER vector.

  LOCK STEERING TO vector.
  WAIT UNTIL VANG(SHIP:FACING:FOREVECTOR, vector) < 2.
} 

 

Edited April 9, 2017 by Sebra

[maculator]

Thanks alot now I got enough stuff to test and tinker

[Meltdown]

14 minutes ago, maculator said:

I'll search for mod in the documentation, thanks.

Right now I'm using this:

function circa {
	parameter a, b, tolerance.
	
	if (a - tolerance) < b and (a + tolerance) > b {
		return true.
	}
}

 

function circa {
parameter a,b,tollerance.
return abs(a-b) <= tollerance.
}

"abs(a.b) <= tollerance" is already a boolean expression which will return true or false so you can use it this way, too.

[pellinor]

46 minutes ago, maculator said:

This is what I'm doing right now, but it somehow wobbles arround retrograde and I have to wait a long time for it to lock it:

To cope with oscillations, you could either wait until both the angle and the angular velocity (Ship:AngularVel) are small, or fiddle with the PID parameters in the SteeringManager structure.

[Dunbaratu]

8 hours ago, Frank Einstein said:

 

Thank you for your reply.

I think it is important to say that I am using the last version of kOS (1.0.3) with the last version of KSP (1.2.2). I am using around 80 addons with KSP, so I guess that my kOS bug is much probably coming from a compatibility problem with an other addon. I tried to look in the log for other errors but there is so many it's not an easy task. I have to mention every of my addons are all working fine despite of many errors in the log file. kOS is also working fine, I can run scripts, copy them, delete them, etc... The only problem is the toolbar button that is not working in any of the scenes. (Space Center, VAB, Ship, etc...) I found that the bug that doesn't allow me to paste in the kOS terminal comes from the MechJeb2 addon (MuMech), which is the last release.

If it can help you to find the bug about my non-working toolbar button, I uploaded my full log file on Mediafire. During this log, all I did is open my last saved game, clicked the kOS toolbar button a few times, then I went into a ship with a kOS module and I tried to paste some text into a kOS terminal, then I closed the game.

KSP_2017-04-09_00h48.log

(By the way, try to avoid using mediafire in the future.  It's an obnoxious site full of pop-ups, some of which are vectors for trojan infection.  I have a separate instance of firefox I use for those links that runs in a sort of sandboxed environment that I then throw away.)

Looking at your log, it looks like something is breaking when it tries to read the config settings as it opens up the window.  Was this a saved game that previously existed in an older version of kOS or KSP, and it got migrated over to a new version?  At any rate, what happens if you try starting a new game from scratch in a new installation of kOS/KSP - will it open the window then? If it works then, then we know it's something corrupted in that particular save.  If that's the case it may be possible to fix it by a careful edit of the saved game file, but let's wait to see if that's the case before going that route.  It's a possibly dangerous thing to do.

 

Edited April 9, 2017 by Steven Mading

[EpicSpaceTroll139]

Ok, so I've been looking through the kOS documentation, and as far as I can tell this is not a thing, but I figure I'll ask in case anyone has a workaround. What I'm looking for is a way for kOS to get the length/width/height of my vessel. Whether it does this by looking at the craft itself or by looking at the craft file does not matter particularly for my purposes, but I suspect if it exists, it would use the craft file, since there is this line (the 5th if the description doesn't use multiple lines) there that is formatted like this: size = width, height, length. 

At the moment I have two very-WIP codes that this would be useful for. One is a script for manipulating the rotor of an otherwise stock helicopter, for which it would be useful to have the script know the exact length of the rotor blades, for a better approximation of tip speed. However, the more important application is in a terrain hugging program. My program is able to obtain predictions for the terrain height along the path of flight for the point directly underneath the fuselage, and this is usually reasonable for very small planes, however for medium to large size planes, it would be useful to know the distance to my left and right the wingtips are (which would presumably be width/2), as it does no good for my fuselage to be kept above the ground if my wing slams into the side of a mountain.

[Frank Einstein]

14 hours ago, Steven Mading said:

(By the way, try to avoid using mediafire in the future.  It's an obnoxious site full of pop-ups, some of which are vectors for trojan infection.  I have a separate instance of firefox I use for those links that runs in a sort of sandboxed environment that I then throw away.)

Looking at your log, it looks like something is breaking when it tries to read the config settings as it opens up the window.  Was this a saved game that previously existed in an older version of kOS or KSP, and it got migrated over to a new version?  At any rate, what happens if you try starting a new game from scratch in a new installation of kOS/KSP - will it open the window then? If it works then, then we know it's something corrupted in that particular save.  If that's the case it may be possible to fix it by a careful edit of the saved game file, but let's wait to see if that's the case before going that route.  It's a possibly dangerous thing to do.

When you say "it looks like something is breaking when it tries to read the config settings" do you mean ".\GameData\kOS\Plugins\PluginData\kOS\config.xml" ? And can you please tell me which line(s) in my log file told you about this "config settings" problem?

I started playing KSP very recently on version 1.2.2 so my game save is not migrated from an older KSP version.

I always try to use the last release of addons compiled for KSP 1.2.2 but some of the best addons aren't updated yet for 1.2.2 so in few cases I'm using the latest old version (if it's still working on 1.2.2) or I'm using an unofficial recompiled release. I guess it could be the cause of this kind of bug. (Example: I'm using "Infernal Robotics" for KSP 1.1.2 recompiled for KSP 1.2)  I'll try to temporary uninstall some suspected addons to find which one is the culprit of this incompatibility, assuming it's caused by an other addon... (The problem here is that KSP is taking a long time to load so it's going to take hours to do this for all my 80 addons...)

I'm just an amateur programmer (batch, bash, python, javascript, c++ and I'm new to C#) but I'll do my best to find this annoying bug because I really like your addon. I never made a KSP addon from scratch but sometimes I like to modify and compile some KSP addon's source codes. I'm using "SharpDevelop" for editing and compiling my KSP addons.

Also, I'd like to know if there is some addons that are known for causing problems with kOS.

Again, thank you for you help.

[maculator]

Just wanted to thank the guys that answered all my questions.

I made it and convert my script into a list of functions this weekend. Next time I play I can tweak it function after function should make it easier.

For now I stored it since I didn't really play the weekend and spent most time in notepad++

If you want to check it out:

https://github.com/maculator/KOS-Stuff/blob/master/tko2.ks

[Dunbaratu]

8 hours ago, Frank Einstein said:

When you say "it looks like something is breaking when it tries to read the config settings" do you mean ".\GameData\kOS\Plugins\PluginData\kOS\config.xml" ? And can you please tell me which line(s) in my log file told you about this "config settings" problem?

 

I was reading through older Pull Reqeusts in kOS to try getting some of them merged in and I ran across this one which looks like it may be related:

https://github.com/KSP-KOS/KOS/pull/1902

 

[kcs123]

39 minutes ago, Steven Mading said:

I was reading through older Pull Reqeusts in kOS to try getting some of them merged in and I ran across this one which looks like it may be related:

https://github.com/KSP-KOS/KOS/pull/1902

 

I'm not 100% sure that is exact same error. Looks very similar, though.  There should be my posts within this forum about same Blizzy toolbar topic. Private build that hvacengi made for testing purposes have worked fine with that PR. My best guess is that is still not merged to main public release.

I didn't deleted log files from my dropbox folder, so those should be available to download too, but can't tell exact links from top of my head, sorry about that.

[Meltdown]

18 hours ago, EpicSpaceTroll139 said:

Ok, so I've been looking through the kOS documentation, and as far as I can tell this is not a thing, but I figure I'll ask in case anyone has a workaround. What I'm looking for is a way for kOS to get the length/width/height of my vessel. Whether it does this by looking at the craft itself or by looking at the craft file does not matter particularly for my purposes, but I suspect if it exists, it would use the craft file, since there is this line (the 5th if the description doesn't use multiple lines) there that is formatted like this: size = width, height, length. 

At the moment I have two very-WIP codes that this would be useful for. One is a script for manipulating the rotor of an otherwise stock helicopter, for which it would be useful to have the script know the exact length of the rotor blades, for a better approximation of tip speed. However, the more important application is in a terrain hugging program. My program is able to obtain predictions for the terrain height along the path of flight for the point directly underneath the fuselage, and this is usually reasonable for very small planes, however for medium to large size planes, it would be useful to know the distance to my left and right the wingtips are (which would presumably be width/2), as it does no good for my fuselage to be kept above the ground if my wing slams into the side of a mountain.

You can use vectoralgebra and 'part:position - ship:position' to get the length of an object.

[danielboro]

On 8.4.2017 at 10:08 AM, Frank Einstein said:

1 - When I click on the kOS icon, nothing happens. It's not working either with the stock toolbar and the blizzy78's addon.

stok button works fine for me

but  kos has a long standing bug whit blizzy78's addon and KOS wont work whit it as of 1.0.3 (broke some time bifor 1)

[plonk]

23 hours ago, danielboro said:

but  kos has a long standing bug whit blizzy78's addon and KOS wont work whit it as of 1.0.3 (broke some time bifor 1)

there's hope that this will be fixed soon

https://github.com/KSP-KOS/KOS/pull/1902

Edited April 11, 2017 by plonk
typo

[Probus]

Can someone link how to use PID loop command?

[Sebra]

4 minutes ago, Probus said:

Can someone link how to use PID loop command?

http://ksp-kos.github.io/KOS_DOC/structures/misc/pidloop.html

[podbaydoor]

I noticed that actions taken by a running script don't take effect if the vessel loses connection (stock comms system, using either comms manager). E.g. if I run my "execute_node" script before losing connection, but pass behind a planet and lose connection while burning, the `lock throttle to 0.` at the end doesn't happen. The graphical throttle actually goes to zero, so I know the script is working, but the engine stays on.

I'm not sure what subset of commands won't work when out of comms - kOS seems to be able to unlock steering while out of comms, for example.

I get why this behavior makes sense in some cases - you don't want people controlling their ship through the terminal to get around lack of connection, but in my situation this functionality kinda defeats the purpose of scripting. Wouldn't being able to hold attitude or burn through comms blackouts be a huge motivation to use kOS? Isn't that (and communication delay) why space probes can run autonomously IRL?

Edited April 12, 2017 by podbaydoor
Edited to clarify that not all actions are affected

[Probus]

2 hours ago, Sebra said:

http://ksp-kos.github.io/KOS_DOC/structures/misc/pidloop.html

Thanks!

[Dunbaratu]

20 hours ago, podbaydoor said:

I get why this behavior makes sense in some cases - you don't want people controlling their ship through the terminal to get around lack of connection

This is not deliberate.  When the stock comms system came out we had a reassurance that they would only lock out the use of the controls from the manual user interface code, and not from the underlying API (so autopilots could still work just fine).  In practice that was not true when it comes to the throttle.  The stock game is locking it out even when we try to change it in the C# code and not through the user interface.  We had a kludge workaround that used to work, as far as I knew.  (I was not the one who implemented it, but I did look at what was done as part of code review) The stock control lockout was causing our attempts to change the throttle to be denied... so our ugly fix was to do the following in 3 consecutive statements: Temporarily turn off the stock comms difficulty option that locks the controls.  2. Change the throttle. 3. Reset the difficulty option back to whatever it was.  That used to work to bypass this annoyance in the stock API.  But apparently it doesn't anymore.

I'm not sure what's going on but this is NOT deliberate on our part.  In the meantime you'll just have to change that stock difficulty setting to allow kOS to work.

 

[podbaydoor]

2 hours ago, Steven Mading said:

This is not deliberate.  When the stock comms system came out we had a reassurance that they would only lock out the use of the controls from the manual user interface code, and not from the underlying API (so autopilots could still work just fine).  In practice that was not true when it comes to the throttle.  The stock game is locking it out even when we try to change it in the C# code and not through the user interface.  We had a kludge workaround that used to work, as far as I knew.  (I was not the one who implemented it, but I did look at what was done as part of code review) The stock control lockout was causing our attempts to change the throttle to be denied... so our ugly fix was to do the following in 3 consecutive statements: Temporarily turn off the stock comms difficulty option that locks the controls.  2. Change the throttle. 3. Reset the difficulty option back to whatever it was.  That used to work to bypass this annoyance in the stock API.  But apparently it doesn't anymore.

I'm not sure what's going on but this is NOT deliberate on our part.  In the meantime you'll just have to change that stock difficulty setting to allow kOS to work.

 

Thanks for the explanation. Out of curiosity, does Remote Tech handle things better?

I submitted an issue for this to Squad. Let's see what happens.

[danielboro]

@maculator

i had a look at the functions

you are using when in stagecheck

add preserve and move stagecheck out of the until loops or

change it to if

a when gets chked every phys tick. you are adding more checks every time you loop

Edited April 14, 2017 by danielboro

[maculator]

@danielboro thanks.

It's a simple script so I didn't notice any lag, but good to know for the future.

I got problems with understanding flow control. I can't really tell the difference between if and when besides the fact that when is a trigger and activates once and if does loop until the condition isn't true anymore.

[Sebra]

2 minutes ago, maculator said:

I can't really tell the difference between if and when besides the fact that when is a trigger and activates once and if does loop until the condition isn't true anymore.

"When" is not a loop. It waits for condition in background.

[danielboro]

@maculator

when is a trigger- it loop until the condition is true- tested at phis tick every tick

if is a single test- tested only if you are at the line its in