[1.3] kOS Scriptable Autopilot System v1.1.3.0

[hvacengi]

14 minutes ago, pellinor said:

I don't see what this is supposed to do. Furthermore it does not depend on the 'eng' variable so why is it inside of the FOR loop?

In my understanding ship:partstagged("something") will return a list of parts. Probably the IF is trying to convert that list to a bool. In some languages this is equivalent to "the list is non-empty", but I don't think that kOS supports that.

Um, good point.  How did I not catch that?  That block is all kinds of messed up.

[BevoLJ]

16 minutes ago, pellinor said:

I don't see what this is supposed to do. Furthermore it does not depend on the 'eng' variable so why is it inside of the FOR loop?

In my understanding ship:partstagged("something") will return a list of parts. Probably the IF is trying to convert that list to a bool. In some languages this is equivalent to "the list is non-empty", but I don't think that kOS supports that.

What I am trying to do is get the information from only certain engines. I can figure out how to list engines.  And I can figure out how to get info like eng:maxthrust or eng:visp. But I'd like to get that info for only some engines, not all.

So my thinking was for the engines in a list if one is tagged something then it gets the info from that engine. Maybe if I pulled its UID out? Or any suggestions on another direction I could go to try to get the info?

[hvacengi]

3 minutes ago, BevoLJ said:

What I am trying to do is get the information from only certain engines. I can figure out how to list engines.  And I can figure out how to get info like eng:maxthrust or eng:visp. But I'd like to get that info for only some engines, not all.

So my thinking was for the engines in a list if one is tagged something then it gets the info from that engine. Maybe if I pulled its UID out? Or any suggestions on another direction I could go to try to get the info?

If you just want to know if the engine is tagged, check it's own tag suffix.

local en is list().
local coreEngines is list()
list engines in en.
for eng in en {
    if eng:tag = "CoreEng" {
        coreEngines:add(eng).
        local eng_isp is eng:visp.
        print "An engine exists with ISP = " + eng_isp.
    }
}
// do something with coreEngines

20 minutes ago, Camacha said:

Is there any way to turn off the console bleep?

There is a configuration setting for that http://ksp-kos.github.io/KOS_DOC/structures/misc/config.html#attribute:CONFIG:AUDIOERR

Edited April 30, 2016 by hvacengi

[BevoLJ]

Ah, that works perfectly!. Thanks!

[Dunbaratu]

29 minutes ago, Camacha said:

Is there any way to turn off the console bleep?

 

It's in the kOS control panel.  It's one of the check lights you can turn off.

 

[Horman]

Hey folks,
I need some help to understand what I am doing wrong here.

I am trying to set up my throttle to a certain TWR (in this example its 1.6). To do this i put up the following function:
 

FUNCTION thrott {
	SET MAXTWR TO MAXTHRUST /(SHIP:MASS *(SHIP:BODY:MU / ((SHIP:BODY:RADIUS + ALTITUDE) ^2))).
	Set thr to (1.6/MAXTWR).
	LOCK THROTTLE TO thr.
}

Now I call this later in my scipt at some different points...
At certain moments in the ascent there are some steering ajustments, so I call this function with an until loop, up to that point, where I have some ajustments to do.
First one looks like this, later its at an altitude of 30000m...
 

UNTIL VERTICALSPEED > 50 {
	thrott.	
}

The first call gives my the right throttle value, but from that moment on, it doesn't change anymore.
My guess is, that it only calculates MAXTWR once, so it doesn't update during flight.
Maybe I am totaly on the wrong way.
I know there are many scripts, where I may "copy" the code, but I want to learn kOS this from the beginning..
Any help for this blind guy lost in the upper atmosphere?

[hvacengi]

19 minutes ago, Horman said:

I need some help to understand what I am doing wrong here.

Well, for starters you only need to call `lock throttle to thr` once.  The purpose of `lock throttle` is that it will automatically update itself every phyisics frame.  Which brings us to another option, you have, which is you can have the function `thrott` return the deisred throttle point and simply `lock throttle to thrott.`  It is not preferred that you repeatedly `lock throttle` because that internally causes the processor to disable and re-enable throttle control every time you call it.

Your until loop doesn't have a `wait` anywhere in it, which means it's wasting time recalculating the throttle until it hits the IPU limit, even though you can only really change the throttle once per frame.

And probably the part that matters most to you, if you stop the until loop at 50m/s vertical velocity, you haven't given yourself much space for the 1.6TWR to need to adjust the throttle.  After you hit 50m/s up, you the throttle value would freeze.

Here is how I would do the part you have shown (you'll need to change the termination of the script, since I imagine yours is substantially longer than this shows):

function thrott {
    set maxTwr to maxThrust /(ship:mass *(ship:body:mu / ((ship:body:radius + altitude) ^2))).
    set thr to (1.6/maxTwr).
    return thr.
}
lock throttle to thrott().
until someCondition {
    print "throttle is " + throttle.
    wait 1.
}

Edited April 30, 2016 by hvacengi

[Horman]

10 minutes ago, hvacengi said:

Well, for starters you only need to call `lock throttle to thr` once.  The purpose of `lock throttle` is that it will automatically update itself every phyisics frame.  Which brings us to another option, you have, which is you can have the function `thrott` return the deisred throttle point and simply `lock throttle to thrott.`  It is not preferred that you repeatedly `lock throttle` because that internally causes the processor to disable and re-enable throttle control every time you call it.

Your until loop doesn't have a `wait` anywhere in it, which means it's wasting time recalculating the throttle until it hits the IPU limit, even though you can only really change the throttle once per frame.

And probably the part that matters most to you, if you stop the until loop at 50m/s vertical velocity, you haven't given yourself much space for the 1.6TWR to need to adjust the throttle.  After you hit 50m/s up, you the throttle value would freeze.

Here is how I would do the part you have shown (you'll need to change the termination of the script, since I imagine yours is substantially longer than this shows):

function thrott {
    set maxTwr to maxThrust /(ship:mass *(ship:body:mu / ((ship:body:radius + altitude) ^2))).
    set thr to (1.6/maxTwr).
    return thr.
}
lock throttle to thrott().
until someCondition {
    print "throttle is " + throttle.
    wait 1.
}

Ha,
great! Thats it! That works!

So just to sum this up for me:
No LOCK THROTTLE inside my function nor in this case inside the loop, but return of the value it has to be locked to (btw. do I always have to call functions with using () even when not using any parameters?).

Thx a lot!
 

[hvacengi]

1 hour ago, Horman said:

So just to sum this up for me:
No LOCK THROTTLE inside my function nor in this case inside the loop, but return of the value it has to be locked to (btw. do I always have to call functions with using () even when not using any parameters?).

Well, more like "don't loop calls to locks".  You don't have to use the parenthesis when calling a function without parameters, I just do to remind myself which ones are functions and which ones are variables.  It simply makes things easier to keep track of, and it helps if you want to use a function defined out of the current scope (but that's an advanced topic that you don't need to know about... until you do).

[leocrumb]

Please help, newbie

How do abort a program, I can work out. Does every program need to run to the end? or can you abort it?

Edited May 1, 2016 by leocrumb

[kcs123]

6 hours ago, leocrumb said:

Please help, newbie

How do abort a program, I can work out. Does every program need to run to the end? or can you abort it?

CTRL+C works on programs that don' tprovide exit function trough AG. Please note that you need a focus on kOS terminal, otherwise you will send command to the craft instead.

[leocrumb]

2 hours ago, kcs123 said:

CTRL+C works on programs that don' tprovide exit function trough AG. Please note that you need a focus on kOS terminal, otherwise you will send command to the craft instead.

Thankyou, much appreciated

 

[Horman]

Does it matters, what order I use the arguments in the LOCK STEERING command?
My goal is to let my rocket rotate, so the kerbals will fly in head-down-position and to pitch eastward.
I tried it this way:

LOCK STEERING TO R(0,0,180) + HEADING(90,80).

Is it a known behavior, that, although, I am aiming east, that I get an increasing inclination?


Are the expressions UP and EAST for the STEERING command not working anymore (got this from the kOS Documentation)?

Edited May 1, 2016 by Horman

[EasyAce]

I've turned it of... I chosen the option to only use kOS with a third part toolbar and now I can't find the button to operate it.

Anyone know how to bring it back?

[hvacengi]

On 5/1/2016 at 9:47 AM, Horman said:

Is it a known behavior, that, although, I am aiming east, that I get an increasing inclination?

It would be an expected behavior that your inclination would continue to change.  Because the KSC is not at latitude 0°, launching due east will not result in a 0° inclination.  If you would like to reach a true 0° inclination, you will first need to offset the launch angle such that you will cross the 0° latitude mark, and correct your velocity at that point.  That being said, it probably shouldn't be continuing to dramatically increase your inclination (if accelerating due East, you don't increase or decrease your North/South velocity directly, so you should be traveling according to the initial inclination).  There are inaccuracies in steering (it's impossible not to have them), but in order to comment I'd have to know significantly more detail about your course.  Increasing inclination could mean anything from a 30°to 0.03° shift.

35 minutes ago, EasyAce said:

I've turned it of... I chosen the option to only use kOS with a third part toolbar and now I can't find the button to operate it.

Anyone know how to bring it back?

You can modify the config setting in the configuration file itself (GameData\kOS\Plugins\PluginData\kOS\config.xml) deleting the "BLIZZY" entry.  Either that or select the button as visible in Blizzy's toolbar.

[EasyAce]

2 hours ago, hvacengi said:

You can modify the config setting in the configuration file itself (GameData\kOS\Plugins\PluginData\kOS\config.xml) deleting the "BLIZZY" entry.  Either that or select the button as visible in Blizzy's toolbar.

Thank you, Blizzy's toolbar it must have been. I did have that toolbar, but maybe it got lost in the 1.1.2 update.
Edit: Wierd fact is that all the other mods are visible on Blizzy's toolbar, but not this one.

Thank you for the help, I will modify the config setting.

[Beechnutk Jr.]

I am sorry if this has already been asked, but I did not see it in the replies. Any plans for 1.1.2 compatibility? This is essential to my modpack, since I am using remotetech. Any news would be welcome. 

 

Thanks!!

[hvacengi]

7 hours ago, Beechnutk Jr. said:

I am sorry if this has already been asked, but I did not see it in the replies. Any plans for 1.1.2 compatibility? This is essential to my modpack, since I am using remotetech. Any news would be welcome. 

 

Thanks!!

Everything except setting the target works with the existing release (compared to for KSP 1.1.0) (as far as we're aware).  We have a large number of pending revisions, and want to get them integrated before our next release.  Hopefully that will be soon, but it's a lot to review and various devs have been short on time recently.

Edited May 5, 2016 by hvacengi

[Beechnutk Jr.]

1 hour ago, hvacengi said:

Everything except setting the target works with the existing release (compared to for KSP 1.1.0) (as far as we're aware).  We have a large number of pending revisions, and want to get them integrated before our next release.  Hopefully that will be soon, but it's a lot to review and various devs have been short on time recently.

Ok thanks. I will be watching for the update still though.

[erbmur]

Hi all,

 

I have something of a strange issue.  I am copying the example code from the KOS-github site:

SET P TO SHIP:PARTSNAMED("GooExperiment"].
SET M TO P:GETMODULE("ModuleScienceExperiment").
M:DOEVENT("observe mystery goo").

But i still get an error saying that that specific do event does not exist, even though it lists it in the containing error that it prints.

Edited May 5, 2016 by erbmur

[hvacengi]

5 hours ago, erbmur said:

Hi all,

I have something of a strange issue.  I am copying the example code from the KOS-github site:

SET P TO SHIP:PARTSNAMED("GooExperiment"].
SET M TO P:GETMODULE("ModuleScienceExperiment").
M:DOEVENT("observe mystery goo").

But i still get an error saying that that specific do event does not exist, even though it lists it in the containing error that it prints.

This looks like you probably already have observed the goo for that experiment.  Doing a quick test on a fresh vessel (and fixing a couple copy/past errors), I was able to observe the goo just fine the first time, but a 2nd attempt threw the same error.  If you look at the print of the module, you should see that the KSPAction for "observe mystery goo" is still listed but the KSPEvent is no longer there.  If this is not the case, we would need a log file and probably a copy of the save file in order to further troubleshoot.

If you continue further down the page, you will find that there are additional suffixes which are much easier for you to manipulate experiments.  This includes the ISOPERABLE suffix which tells you if the experiment can be run.

[Warp11]

Is it possible to run a program from a different volume without switching to that volume? It seems like it should be but I cant find the command for it. Thank you

 

Edited May 5, 2016 by Warp11

[meyerweb]

I think I’ve found a fascinatingly weird interaction with kOS parts and Surface Mounted Lights parts.  If I have a craft that has both a kOS part and a SurfaceLights (to use its mod ID) part, it will yaw slightly to the left (as I look at the YAW display) whenever SAS is off, building up rotational speed.  I noticed this on a small probe I’d built, and then on a large craft with a very different configuration.

I’ve launched variants of both craft with just kOS parts but no SurfaceLights; they did not yaw.  Then I sent up variants with SurfaceLights but no kOS parts; again, no yaw.  It’s only seen when both kinds of parts are on the same craft.  These tests were all done without any other non-Squad mods installed, so it really seems to be an interaction between these two mods.

Here’s a gist of the small probe that has the yaw problem: https://gist.github.com/meyerweb/b479f062b29266c2eb4b0f327bceaf5d .  Note that while this craft has the light atop the kOS processor part, I observed the same problem in another craft where the KAL9000 part was attached to the craft, and no lights were anywhere near it.  When I launched that same craft again without KAL9000, there was no yaw.

I’ve reported this over at the SurfaceLights thread as well, in case it’s their part (which seems more likely) and not the kOS part, but I wanted to give a heads-up here just in case.

 

[hvacengi]

3 hours ago, meyerweb said:

I think I’ve found a fascinatingly weird interaction with kOS parts and Surface Mounted Lights parts. 

... Snip ...

When you saw that it's yawing to the left, do you mean that the controls are actively pushing the yaw control to the left?  Or do you mean that the ship slowly begins to yaw to the left and the controls do not try to pull it back to the right?  Any chance you could post a video, with and without `steeringmanager:showsteeringvectors` and `steeringmanager:showfacingvectors`turned on?  Is it always yaw, and never any other direction?

Surface mounted lights doesn't have an official 1.1.x compatibility release that I'm aware of.  But I know there have been a couple people trying to update it.  A quick look through the code makes me think that it isn't doing anything that should affect game physics.

In theory, you should be able to make a MM patch that removes the SurfaceLight module, and replace it with kOSLightModule (which offers some similar function) and see if that changes the behavior.

4 hours ago, Warp11 said:

Is it possible to run a program from a different volume without switching to that volume? It seems like it should be but I cant find the command for it. Thank you

Not presently.  The run command is very picky, it has to do with a number assumptions made under the hood.  We are actively working on changing this, but there are many different sub-systems that all have to change to allow it to work.

Edited May 5, 2016 by hvacengi

[Warp11]

24 minutes ago, hvacengi said:

Not presently.  The run command is very picky, it has to do with a number assumptions made under the hood.  We are actively working on changing this, but there are many different sub-systems that all have to change to allow it to work.

Ok, thanks