[1.3] kOS Scriptable Autopilot System v1.1.3.0

[ElWanderer]

My code calculates the available delta-v for the current stage prior to each manoeuvre, so as to determine if it needs to stage, which affects the burn time estimate. When I recently started testing against KSP v1.2.2/kOS v1.0.3, I noticed I was getting 0m/s printed out a lot indicating STAGE:LIQUIDFUEL/OXIDIZER were both zero. Toggling stage view in the KSP resources tab showed the same data: no fuel. Yet the engine was active and had fuel (and the engine part gauge in the staging list in the bottom left showed access to liquid fuel).

I had a bit of a play, and got the impression that staging and stage (re-)ordering seemed to matter. KSP didn't seem to like me firing the next stage at the same time as triggering the decoupler. Separating those into two steps seemed to help. I say "seem" because my testing was definitely not rigourous.

One example that stuck in my mind was when my upper stage was reported as having no resources except for 16 units of solid fuel; that fuel was in two sepratrons mounted on the stage to deorbit it, but naturally they weren't activated at the time (they were set-up to activate along with the decoupler above). This is fairly common in my designs, and may be the reason why I'm suddenly seeing this with almost everything I launch (compared to launching the same craft in KSP v1.1.3/kOS v1.0.1).

Another example was a ship that docked to another craft, then undocked. On undocking, KSP reported it no longer had any fuel in the stage. I added an empty stage below the current one and triggered it. Then the stage fuel numbers appeared. In this example, I think I was using my docking tester, which has a single stage once in orbit, but it's possible that I was using my crew shuttle that has extra stages (decoupler, chutes, heat shield jettison if I'd forgotten to remove it) to confuse matters.

I'm sorry I don't have any concrete examples; I don't get much time to play the game itself.

Edit: I should point out that none of my current designs use fuel pipes so that's not a factor in these examples. I know the kOS v1.0.2 release notes explicitly mentioned asparagus staging as an area where you'd expect to see changes in behaviour.

Edited January 18, 2017 by ElWanderer

[Jebs_SY]

@hvacengi

Regarding this NRE, it happens on KSP load even before save game loading. So it seems to want to access the useblizzy option from the save game while the save game isn't loaded, yet. Hope this helps. o/

[kcs123]

1 hour ago, Jebs_SY said:

@hvacengi

Regarding this NRE, it happens on KSP load even before save game loading. So it seems to want to access the useblizzy option from the save game while the save game isn't loaded, yet. Hope this helps. o/

Be patient until fix is merged with official release. As noted in this post , private build was send to MaxRebo and me for testing. It worked properly for me, feedback provided by MaxRebo is probably same.

[Jebs_SY]

Would be happy to test it, also.  Some less NRE in the log of the highly modded install.

[meyerweb]

17 hours ago, hvacengi said:

Yeah, I forgot the phrasing and didn't open KSP to check.  "Stage View" is the correct option.

Okay, cool.  I just tested this with the GDLV3 stock craft.  My only change to the stock craft was to slap a KAL-9000 on the side of the OKTO probe core, so I could run my test programs.  On the pad, the Rockomax 64 fuel tank shows as being in stage -1 when I use kOS to crawl the part tree.  The Skipper engine is in stage 2, as the stock staging has it.  The Rockomax never leaves -1, and the “Stage View” Resources view never shows any resources, even while the craft is in flight and clearly burning fuel.

I then tried recreating the GDLV3 in the VAB, and got similar results.  In most arrangements, I got a stage of -1 for the R64, and in a few I managed to get it into stage 0.  In no case did its resources show up in “Stage View” while in flight (and while its fuel was being drained by the Skipper).  This was true whether or not I left the FL-T800 tank on top of the structure, or removed it.

So this definitely seems to be a problem with KSP, not kOS.  Annoying, but unless the devs are interested in implementing their own tree-traversal resource calculations (and I can’t imagine why they would) it’s just something we’ll have to deal with.

[Cairan]

Greetings Earthlings,

I had not updated my KSP installation in quite some time, and I reinstalled kOS to do some coding with my son... Unfortunately, many of my scripts are now broken. That's to be expected...

One of my issues right now is that strings seem to be no longer iterable, despite the fact that the documentation says so... I've looked at the forums and it seems this has been the case for a year.

So how do we now parse a string to get individual characters?

UPDATE:

Well after poking around I used this method, but if there is a cleaner way to do it in kOS nowadays, please, enlighten me!

  FROM {local strpos IS 0.} UNTIL strpos = str:LENGTH STEP {set strpos TO strpos+1.} DO { 
    some_function(str[strpos], ...).
  }

 

Edited January 21, 2017 by Cairan
Figured a way...

[Dunbaratu]

3 hours ago, Cairan said:

One of my issues right now is that strings seem to be no longer iterable, despite the fact that the documentation says so.

 

 

Do you mean using a for loop like this used to work but now doesn't?
 

for ch in "ABCD" {
  print  ch.
}
A
B
C
D

(It's not a feature I've ever used before.  I'm just used to thinking of getting characters by index numbers.) 

[Cairan]

5 hours ago, Steven Mading said:

Do you mean using a for loop like this used to work but now doesn't?
 

for ch in "ABCD" {
  print  ch.
}
A
B
C
D

(It's not a feature I've ever used before.  I'm just used to thinking of getting characters by index numbers.) 

Precisely. Using this method, which is in the documentation, puts out a kOS "Iterator" exception and crashes the script...  

SET str TO "abcde".

FOR c IN str {
  PRINT c.
}

 

[Dunbaratu]

11 hours ago, Cairan said:

Precisely. Using this method, which is in the documentation, puts out a kOS "Iterator" exception and crashes the script...  

SET str TO "abcde".

FOR c IN str {
  PRINT c.
}

 

I was just working on this tonight.  There's a PR ready for it (but of course that doesn't mean it will be in public release soon, unless you compile kOS from the github source yourself).

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

[Cheesecake]

I have a little issue. I use RT and when launching my vessel kOS says "signal lost. waiting to re-aquire signal". There is a RT-Connection and I choose the RT-profile of kOS.

[hvacengi]

6 hours ago, Cheesecake said:

I have a little issue. I use RT and when launching my vessel kOS says "signal lost. waiting to re-aquire signal". There is a RT-Connection and I choose the RT-profile of kOS.

Do you have a probe core on the ship?  RT doesn't know to tell us that a vessel is connected if there isn't a probe core, even though the connection lines will still work and you can control the vessel manually.

[Cheesecake]

Yes, there is a probe core, an antenna and I can fly the Launcher manually.

[Lookerksy]

How can I get the Drag of my vessel when moving vertically?
Now I calculate the drag value by Acceleration, Mass and Gravity.
Has any other way more simple?
Thanks.

[Lookerksy]

I find I can get the position of BDA missile by the order "list targets.".
But I don't know how to get the position of BDA bullets.
Anyone know something about this? Thanks.

[Redshift OTF]

Hello, I am a KOS noob, but I love it! I need some help though.

Scenario is: I have a submarine with detachable torpedoes. I have written a script for the torpedoes to home in to a selected target and explode near it at a set range. How do I get the script to run automatically on the torpedoes when I stage them from the submarine? I don't mind having a script running on the submarine if needed, I just don't want the same script as I don't want the submarine to start homing in on the target too. The torpedo will remain in physics range of the submarine.

Thanks.

[MalevolentNinja]

16 minutes ago, Redshift OTF said:

Hello, I am a KOS noob, but I love it! I need some help though.

Scenario is: I have a submarine with detachable torpedoes. I have written a script for the torpedoes to home in to a selected target and explode near it at a set range. How do I get the script to run automatically on the torpedoes when I stage them from the submarine? I don't mind having a script running on the submarine if needed, I just don't want the same script as I don't want the submarine to start homing in on the target too. The torpedo will remain in physics range of the submarine.

Thanks.

Off the top of my head I would add a kOS part on each torpedo with a boot script defined. The boot script would need to check if the torpedo was still attached to the sub and if so, quit.

 

[Redshift OTF]

19 hours ago, MalevolentNinja said:

Off the top of my head I would add a kOS part on each torpedo with a boot script defined. The boot script would need to check if the torpedo was still attached to the sub and if so, quit.

 

Thanks for this. It mostly works however I have hit a snag. As soon as the torpedo has decoupled I can't get it to set a target as apparently you can only set a target for the active vessel. I think the only way around this is to run the script from the submarine and change all my commands to affect the detached vessel by name if that makes sense.

[Redshift OTF]

OK, I'm making headway. Does anyone know how to use the Part:controlfrom() function? When I stage a torpedo it is being controlled from the cpu part and doesn't use the control surfaces so I want to switch to the probe core on the torpedo. But I don't really understand the syntax of this command.

[kcs123]

12 minutes ago, Redshift OTF said:

OK, I'm making headway. Does anyone know how to use the Part:controlfrom() function? When I stage a torpedo it is being controlled from the cpu part and doesn't use the control surfaces so I want to switch to the probe core on the torpedo. But I don't really understand the syntax of this command.

I'm not realy sure if I understand question properly, but I will try to answer. Part:controlfrom()  should give you same result as if you right clicked on dock port or another probe on vessel. You still control same vesel, but navbal is oriented in different way  - changing left/right up/down reference points. Craft still respond on control input sending values to control surfaces and/or engine gimbals. Take this info with a grain of salt, as I can't actualy check in game this right now and it is being a while since I have messed with those.

Now, I only assume that, when you have staged, you have released torpedo and it is no longer part of your main ship, but you still want to control torpedo and somehow guide it to target. For that kind of purposes, you might need that your torpedo contains some battery, control probe and another kOS CPU.

kOS CPU on torpedo should have software capable to listen mesages send to it and respond to those messages. Check out communication chapter of kOS documentation. So, you need to programm some AGs on main craft/CPU to send some messages, like go UP/DOWN or just send bearing/velocity where torpedo should lock their steering to. I think it should be possible to read heading from some camera somehow and send that info to torpedo/rocket to lock on.

Or you can track bearing/distance from main craft and targeted craft, do some calculation and simply send heading/pitch info where torpedo should lock on.
 

That should work, in theory, but I didn't have chance to try something like this in game, it is on my "to do in KSP" list, but real life issues put me away from playing KSP for a while, right now.

[Redshift OTF]

18 minutes ago, kcs123 said:

I'm not realy sure if I understand question properly, but I will try to answer. Part:controlfrom()  should give you same result as if you right clicked on dock port or another probe on vessel. You still control same vesel, but navbal is oriented in different way  - changing left/right up/down reference points. Craft still respond on control input sending values to control surfaces and/or engine gimbals. Take this info with a grain of salt, as I can't actualy check in game this right now and it is being a while since I have messed with those.

Now, I only assume that, when you have staged, you have released torpedo and it is no longer part of your main ship, but you still want to control torpedo and somehow guide it to target. For that kind of purposes, you might need that your torpedo contains some battery, control probe and another kOS CPU.

kOS CPU on torpedo should have software capable to listen mesages send to it and respond to those messages. Check out communication chapter of kOS documentation. So, you need to programm some AGs on main craft/CPU to send some messages, like go UP/DOWN or just send bearing/velocity where torpedo should lock their steering to. I think it should be possible to read heading from some camera somehow and send that info to torpedo/rocket to lock on.

Or you can track bearing/distance from main craft and targeted craft, do some calculation and simply send heading/pitch info where torpedo should lock on.
 

That should work, in theory, but I didn't have chance to try something like this in game, it is on my "to do in KSP" list, but real life issues put me away from playing KSP for a while, right now.

Thank you very much for the help! However, I have managed to work it out.

The torpedoes have a cpu part on them but not the main ship. The torpedoes have a probe core on them as well as everything needed to power them. You select a target in the ship and this is stored as a variable, myTarget, so that when the torpedo is decoupled it steers towards the target using the - lock steering to myTarget:position - option. I printed the output of ship:controlpart and found that the torpedoes control part was actually the radial decoupler when the torpedo is decoupled so it was no wonder it didn't steer much.

My trouble was understanding how to implement the part:controlfrom() function in code but I worked it out. Part is replaced by a variable, in this case cp, and it is important to get the name right or the code doesn't run. I managed to get the part name by using - for cp in ship:partsnamed("probeCoreOcto2") - and then adding - {cp:controlfrom().} - after it.

Anyway, I might do a video on it a post the whole code as it is quite fun watching air dropped torpedoes chase a moving sub.

[Sebra]

Hi!

I'm new here and was not able to read the whole thread. But I have a little problem with kOS.

When I tune my action groups, I see some strange thing: I can Open, Close or Toggle Terminal (or Light), but only Toggle Power of kOS script controller whole. Why there are no On and Off options? Of course kOS can toggle itself off by proper script. So absence of turn off is minor. But how can I turn kOS on but not to interrupt it if was on already?

Also cannot filter kOS parts by manufacturer, But that is also minor.

 

[APlayer]

I am having trouble with a script...

I am trying to get a certain module of a part with --

SHIP:PARTSDUBBED("<name>")[0]:GETMODULE("<name>")

-- but there is more than one module with this name. How would I get the second, third, ... module with the same name as the preceding ones?

 

EDIT: ve2dmn on the IRC Channel found an issue raised on GitHub which described exactly this problem, and apparently there is an undocumented workaround, "GETMODULEBYINDEX(<integer>)" which gets a (you guessed it) module, by its index.

Edited February 19, 2017 by APlayer

[FXgamer247]

Hi! I'm new here but I've been trying to connect remotely with telnet from my android phone but honestly am stuck now. When I turn loopback off it shows this:

I can't find anything explaining what to do, would really appreciate a simple how to on this.

[kcs123]

9 hours ago, FXgamer247 said:

Hi! I'm new here but I've been trying to connect remotely with telnet from my android phone but honestly am stuck now. When I turn loopback off it shows this:

I can't find anything explaining what to do, would really appreciate a simple how to on this.

Reason for this is that telnet show IPV6 instead of IPV4 as local adress. IIRC it is already raised issue about it on github, some time ago. In theory, if your telnet client on android phone is capable to connect on IPV6 adress and port 5410 it can work, but it can't work if your telnet client on phone can only work with old IPV4 protocol.

[podbaydoor]

I'm trying to call the trajectory prediction functions (`positionat` and `velocityat`) on a landed vessel to do some precision landings. I was hoping this would be a clean way to account the changing absolute position of the landed vessel as the parent body rotates. However I just get NaN vectors back. Am I doing something wrong or does `positionat` not work on unloaded or landed vessels?

If trajectory prediction won't work here, does anyone have code for computing the position of a landed vessel in the future, accounting for rotation speed, elevation, latitude, etc?