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

[danielboro]

14 hours ago, Luovahulluus said:

I know how to pass parameters to a program. I haven't found a way to RETURN from program.

1- post a link

2- you can rewrite the program file as a function

[Chabadarl]

16 hours ago, Luovahulluus said:

I know how to pass parameters to a program. I haven't found a way to RETURN from program.

If the return is serializable, you can also write it as a json file.

 

Create a function like that inside your program to call.

function lookforpath(){

    log "" to "1:/templookforpath".
    deletepath("1:/templookforpath").

    runpath("My Programm").

    set MyReturn to readjson(1:/templookforpath).

    return MyReturn.
}

 

And add a :

writejson(<whatever variable is your path>,"1:/templookforpath").

at the end of the program that create the path

I have not tested this particular code and wrote it in notepad, so expect a mistake or two but the principle works (I used it to handle persistance of variables trough reboot).

 

 

 

 

Edited November 5, 2018 by Chabadarl

[SiRCrashaLot]

Was wondering if anyone figured this out or if it was possible.. Can KOS simulate a key press from a non standard key.. IE P or O or anything..?

 

I have a mod called atmospheric autopilot that uses those keys I tried to switch to WSAD and it did not work. I was wondering if there was a way to force press a key within KOS? my other alternative which I have no idea how to do is to turn on prec control with KOS.

v/r

[Chabadarl]

Kos can take input from user but not replace it. Krpc is what you need i think.

There is no option i know of to trigger precision control but you can tweak the pid parameters of the steeringmanager (see the docs) to achieve what i think you want to do...

[Drew Kerman]

On 10/17/2018 at 9:45 PM, DunaManiac said:

Will there be a 1.5 version?

On 10/17/2018 at 11:06 PM, Steven Mading said:

We're in the middle of running regression tests on the current 1.4.5 version's ZIP (it takes time because it involves having scripts actually play out the game for reals, not just unit testing).  So far it looks good with nothing changing.  If everything is fine, then all I have to do is edit one small number in a file and CKAN should start allowing it for KSP 1.5 without needing a new release.

In the meantime you can try the current release ZIP that was for KSP 1.4.5 on  KSP 1.5 - I've been doing that for my testing and it has been working so far.

Latest release is still working fine for me but just curious how the next update is coming along.

Also, wondering if I should add a new feature request to the Github tracker - would it be possible to intercept the Recover Vessel event? I would like it if kOS could dump any onboard data to the archive that couldn't be transmitted because RT signal was lost. So like, I launched a sub-orbital rocket, it came down over the horizon from KSC but was still logging telemetry data. I want to have that data on the archive, out of the game SFS file, before the vessel is recovered and its onboard data destroyed. Right now the only thing I can do is use HyperEdit to relocate it back to KSC after it splashes down so I can regain a connection and enter commands to move the data over before initiating recovery

Edited November 26, 2018 by Drew Kerman

[EpicSpaceTroll139]

So, this may be a bit of a niche question, but is there any way to have kOS lock and unlock the pivot of a klaw?

I did some testing and there does not appear any such an action amongst the various accessible modules of the claw part, but perhaps there's something I'm missing?

Spoiler

I had a mini-script do

For mod in part:allmodules {Log part:getmodule(mod:name):allactions to My_Log.txt.}. 

and it spat out the following, appearing to show that toggling the pivot is not an available action.  I however know the claw to be a bit of an oddball part, so I wanted to check that this action isn't accessible from some different route?

Spoiler

LIST of 3 items:
[0] = "(callable) release grapple, is KSPAction"
[1] = "(callable) decouple node, is KSPAction"
[2] = "(callable) control from here, is KSPAction"
LIST of 1 items:
[0] = "(callable) toggle arming, is KSPAction"
LIST of 0 items:

LIST of 0 items:

LIST of 0 items:

LIST of 0 items:

The reason I'm asking is because I've created an engine-gimbaling system that uses claws and small verniers to give high gimbal to mainsails, for use on a space shuttle.  It would be ideal to allow the script to unlock them after timewarping to the launch window, and lock/unlock them for times during the launch when change in gimbal angle is not being requested (thus saving fuel on the verniers).

UPDATE: I may have found a solution to my problem, using EVENT instead of ACTION.  Will have to check when I get home

 

 

Edited November 27, 2018 by EpicSpaceTroll139

[BlkBltChemie]

49 minutes ago, EpicSpaceTroll139 said:

The reason I'm asking is because I've created an engine-gimbaling system that uses claws and small verniers to give high gimbal to mainsails, for use on a space shuttle.  It would be ideal to allow the script to unlock them after timewarping to the launch window, and lock/unlock them for times during the launch when change in gimbal angle is not being requested (thus saving fuel on the verniers).

This sounds really cool! 

I am by no means very fluent at kOS having only written a script to get a very basic rocket to orbit before, but I did have an idea you might consider trying - can you set the pivot to an action group in the VAB and then toggle the action group in your script?  Certainly not as elegant as working directly through kOS to access the module directly like your mini-script above but it may provide a workaround.

[EpicSpaceTroll139]

1 hour ago, BlkBltChemie said:

This sounds really cool! 

I am by no means very fluent at kOS having only written a script to get a very basic rocket to orbit before, but I did have an idea you might consider trying - can you set the pivot to an action group in the VAB and then toggle the action group in your script?  Certainly not as elegant as working directly through kOS to access the module directly like your mini-script above but it may provide a workaround.

Unfortunately it appears that the pivot toggle cannot be added to an action group in the editor. 

Edit: In case you're interested, this video (less than a minute long) shows the prototype for the system I'm putting on the shuttle.

Spoiler

 

 

Edited November 27, 2018 by EpicSpaceTroll139

[ElWanderer]

4 hours ago, EpicSpaceTroll139 said:

UPDATE: I may have found a solution to my problem, using EVENT instead of ACTION.  Will have to check when I get home

If it is available as an option on the part action window (i.e. what pops up when you right-click on a part), it should be available as an event.

As you've seen, the availability of actions is a bit hit and miss, and depends on what the KSP devs decided to make actionable.

[EpicSpaceTroll139]

6 minutes ago, ElWanderer said:

If it is available as an option on the part action window (i.e. what pops up when you right-click on a part), it should be available as an event.

As you've seen, the availability of actions is a bit hit and miss, and depends on what the KSP devs decided to make actionable.

From what I've read in the kOS documentation, Events include all things you can activate via the part right-click menu, whereas Actions only include those that can be assigned to an action group in the editor. 

Lock/unlock pivot is not available to be assigned to action groups, thus it is not available in Actions, but it is available in right click menu (if a part has been grappled), so it should be in the Events list.  Atleast, that's my new understanding.  I'll have to test this when I get home.

Edited November 27, 2018 by EpicSpaceTroll139

[BlkBltChemie]

5 hours ago, EpicSpaceTroll139 said:

Unfortunately it appears that the pivot toggle cannot be added to an action group in the editor. 

Edit: In case you're interested, this video (less than a minute long) shows the prototype for the system I'm putting on the shuttle.

  Reveal hidden contents

 

 

Really cool video, thanks for sharing!  Sorry the action group idea did not work, but glad to hear you have made some progress looking into the Events.  Good luck!

[Luovahulluus]

A suicide burn: I'm trying to find the altitude where is should throttle up, but this code stops my rocket way too early (It should stop a little early as it doesn't take into account the lost mass, but I don't think the effect is this big). I can't figure out where my error is.

 

clearscreen.
set ship:control:mainthrottle to 0.
SAS on.
rcs off.

LOCK LocalGee TO constant:G * BODY:Mass / (BODY:RADIUS+ship:altitude)^2.
LOCK maxVertAcc TO SHIP:AVAILABLETHRUST / SHIP:MASS - LocalGee. //max acceleration in up direction the engines can create

LOCK sBurnTime TO verticalspeed / maxVertAcc.
lock sBurnDistance TO verticalspeed*sBurnTime + 0.5*maxVertAcc*(sBurnTime^2).

until false
{
	print "SHIP:AVAILABLETHRUST: " + round(SHIP:AVAILABLETHRUST, 5) + "       " at(1,1).
	print "sBurnDistance:        " + round(sBurnDistance, 5) + "       " at(1,2).
	print "alt:radar:            " + round(alt:radar, 5) + "       " at(1,3).
	wait 0.
	If sBurnDistance > alt:radar and rcs = true
	{
			set ship:control:mainthrottle to 1.
	}

} 

Edit: this line seems to work

lock sBurnDistance to ship:verticalspeed^2 / (2 * maxVertAcc).

 

Edited December 1, 2018 by Luovahulluus

[scimas]

6 hours ago, Luovahulluus said:

(It should stop a little early as it doesn't take into account the lost mass, but I don't think the effect is this big).

Actually that changes it a lot. The burn time changes exponentially with the required delta V. I suggest taking it into account. Look up the specific impulse and terminology pages on the KSP wiki. Those two have all the additional equations you will need for delta V and burntime calculation. 

[Luovahulluus]

3 hours ago, scimas said:

Actually that changes it a lot. The burn time changes exponentially with the required delta V. I suggest taking it into account. Look up the specific impulse and terminology pages on the KSP wiki. Those two have all the additional equations you will need for delta V and burntime calculation. 

This is for a rover script. I can't imagine the burn being more than a hundred meters at most. At that distance the difference doesn't matter, especially as I have a PIDloop doing a lot of the work.

I figured out what was wrong with the formula I used. I was missing a minus sign. This gives the correct value:

lock sBurnDistance TO abs(verticalspeed)*sBurnTime + 0.5*-maxVertAcc*(sBurnTime^2).

 

Edited December 1, 2018 by Luovahulluus

[dakhr]

Hi 

I'm trying to change name of separated boosters without success.Only main core booster name changes.

This is my code:

STAGE.
    wait 1.
  //here I'm on active core vessel
        SET SHIP:NAME TO "fhCore".
    wait 1.

kuniverse:forcesetactivevessel(VESSEL("fhCore3_full Probe")).   //this is how ksp names stage after separation "fhCore3_full Probe" I'm getting successful switch
        
        SET SHIP:NAME TO "fhBooster1". //looks like this not changes name
        wait 1.

//after above I should have "fhCore" ,fhBooster1 instead I'm having still old names  


kuniverse:forcesetactivevessel(VESSEL("fhCore3_full Probe")).
SET SHIP:NAME TO "fhBooster2".
wait 1.

//after this command core stage changes name to fhBooster2 ,separated boosters are still "fhCore3_full Probe"

kuniverse:forcesetactivevessel(VESSEL("fhCore")).//here I'm getting message "fhCore not found ",which is obvious because only core name changes to last name change

 

Kind regards

Edited December 3, 2018 by dakhr
Code

[Dunbaratu]

8 hours ago, dakhr said:

Hi 

I'm trying to change name of separated boosters without success.Only main core booster name changes.

This is my code:

STAGE.
    wait 1.
  //here I'm on active core vessel
        SET SHIP:NAME TO "fhCore".
    wait 1.

kuniverse:forcesetactivevessel(VESSEL("fhCore3_full Probe")).   //this is how ksp names stage after separation "fhCore3_full Probe" I'm getting successful switch
        
        SET SHIP:NAME TO "fhBooster1". //looks like this not changes name
        wait 1.

//after above I should have "fhCore" ,fhBooster1 instead I'm having still old names  


kuniverse:forcesetactivevessel(VESSEL("fhCore3_full Probe")).
SET SHIP:NAME TO "fhBooster2".
wait 1.

//after this command core stage changes name to fhBooster2 ,separated boosters are still "fhCore3_full Probe"

kuniverse:forcesetactivevessel(VESSEL("fhCore")).//here I'm getting message "fhCore not found ",which is obvious because only core name changes to last name change

 

Kind regards

It's a little difficult for me to follow what you are describing here.

Are you saying that you perform this command:

kuniverse:forcesetactivevessel(VESSEL("fhCore3_full Probe")).

And then this command:

        SET SHIP:NAME TO "fhBooster1". //looks like this not changes name
        wait 1.

On the *same* kOS CPU?

Because switching the active vessel doesn't cause the kOS CPU to change which vessel is "SHIP".

"SHIP" is always supposed to be the vessel the kOS CPU that runs the command  is attached to, whether that is the active vessel or not.

(But I'm not sure I understand your description of what you are doing.  There *is* a bug you might be running into here that I've seen before, but there might not.  In order for me to tell I need to know which kOS CPU is running which of those commands.)

 

[dakhr]

58 minutes ago, Steven Mading said:

It's a little difficult for me to follow what you are describing here.

Are you saying that you perform this command:

kuniverse:forcesetactivevessel(VESSEL("fhCore3_full Probe")).

And then this command:

        SET SHIP:NAME TO "fhBooster1". //looks like this not changes name
        wait 1.

On the *same* kOS CPU?

Because switching the active vessel doesn't cause the kOS CPU to change which vessel is "SHIP".

"SHIP" is always supposed to be the vessel the kOS CPU that runs the command  is attached to, whether that is the active vessel or not.

(But I'm not sure I understand your description of what you are doing.  There *is* a bug you might be running into here that I've seen before, but there might not.  In order for me to tell I need to know which kOS CPU is running which of those commands.)

Yes I'm calling other vessels (stages)from core booster CPU and I'm trying yo change their names. Does this mean, I have to call /activate CPU on other stage? Then I will be able to rename it? How to do that?

58 minutes ago, Steven Mading said:

 

 

[Dunbaratu]

1 hour ago, dakhr said:

Yes I'm calling other vessels (stages)from core booster CPU and I'm trying yo change their names. Does this mean, I have to call /activate CPU on other stage? Then I will be able to rename it? How to do that?

 

A CPU is only allowed to change things about its own vessel.  It can query things about other vessels, but not change them.

You could make a CPU send a message to another CPU that the other CPU chooses to respond to, but a CPU is not allowed to directly force another CPU to run a command.

[scimas]

Is there a way to have a processor turned off when launching a rocket from KSC?

[ElWanderer]

49 minutes ago, scimas said:

Is there a way to have a processor turned off when launching a rocket from KSC?

Give it a boot script that checks the vessel's status and turns off the processor if it is pre-launch, IF(SHIP:STATUS = "PRELAUNCH"), or whatever condition you want to check for. That way it'll stay running if powered up after launch.

Turning off a script's own processor is as simple as: CORE:DOEVENT("Toggle Power").

Turning other CPUs on or off is a bit more complicated, and probably involves part tags to identify things.

[scimas]

Yeah, boot script works. I was just wondering if it was possible to have it deactivated right from VAB, like extendable antennas. But it isn't a big deal.

[ElWanderer]

13 minutes ago, scimas said:

Yeah, boot script works. I was just wondering if it was possible to have it deactivated right from VAB, like extendable antennas. But it isn't a big deal.

I don't think that's possible. Would be nice to have.

I would say I'd use it if it were... but actually I generally need my CPUs to run on the launchpad to download all the scripts they need when there is a guaranteed connection, in case there is no signal when they're run up "for real" later in the mission.

[Ricovandijk]

Hey all,

Sorry if this has been answered before, but I cannot find it.

Until now I have done my booster staging with smart parts, but I would like to add the function in my  scripts:

Because my boosters use the same fuel type as the main engine (similar to the R7 rocket). need something like:

when (available thrust of one of the booster engines <0) then stage.

Many thanks!

PilotNL.

[Pand5461]

You may either tag booster engines and check their thrust or poll ship:maxthrustat(0) every guidance cycle and compare it to the previous value. Once the current maxthrust is less than the previous one, some engines have went out (or there was a malfunction, if you play with a failure mod, but that's outside the scope of this recipe).

[Dunbaratu]

1 hour ago, Ricovandijk said:

Hey all,

Sorry if this has been answered before, but I cannot find it.

Until now I have done my booster staging with smart parts, but I would like to add the function in my  scripts:

Because my boosters use the same fuel type as the main engine (similar to the R7 rocket). need something like:

when (available thrust of one of the booster engines <0) then stage.

Many thanks!

PilotNL.

This is exactly the criterion I use for staging (when any engine is done, stage).

function maybe_stage {
  local engs is 0. // just to make the variable local - this will be overwritten.
  list engines in engs.
  local reason is "no ignited engines right now". // default if none found ignited in the list below.
  for eng in engs {
    if eng:ignition {
      set reason to "none". // good that at least one engine is ignited.
      if eng:flameout {
        set reason to "flameout of " + eng:name. // but bad that it is flamed out.
        break.
      }
  }
  if reason <> "none" {
    print "Staging because of " + reason + ".".
    stage.
    wait 0. // not sure if it's needed, but it ensures KSP notices the new vessel config and updates everything.
  }
}

Then just keep calling maybe_stage() from inside your program's main loop so it keeps checking.  As long as you keep calling it again and again, it will keep trying to stage again and again until the vessel is in a state where there is at least one engine is ignited, and none of the ignited engines are flamed out.  Note the game enforces a cooldown timer on staging, so you may hear it going "click click click click" as it tries to stage a second time again and again till it works, but that's fine.

Be aware that I typed this mostly from memory.  It may have bugs, but this is the basic idea.