[1.3] kOS Scriptable Autopilot System v1.1.3.0

[dsonbill]

@hvacengi, was the 3rd party API ever merged or something? I can't seem to find it in your branches any more.
I've been working on my own game so KSP hasn't been getting much love, but the new version incoming made me want to take a look at kOS again

[hvacengi]

54 minutes ago, dsonbill said:

@hvacengi, was the 3rd party API ever merged or something? I can't seem to find it in your branches any more.
I've been working on my own game so KSP hasn't been getting much love, but the new version incoming made me want to take a look at kOS again

Yes, it has been merged for the most recent release.  So feel free to go crazy and come up with some new addons.  You can find an example interaction from various addons by @Ger_space or my own Camera mod: https://github.com/hvacengi/KOS-StockCamera (for the time being, my camera mod is essentially the "reference" for an addon, though I have an example prepared that is purely instructional I just haven't had time to post it)

[Drew Kerman]

1 hour ago, dsonbill said:

@hvacengi, was the 3rd party API ever merged or something? I can't seem to find it in your branches any more.
I've been working on my own game so KSP hasn't been getting much love, but the new version incoming made me want to take a look at kOS again

best of luck on your game project, but do hope you get back to kOSPropMonitor sometime

[Scorp1579]

This is on my list of 'waiting to update before 1.2' -- Awesome mod!

[hvacengi]

2 hours ago, scorpianz1525 said:

This is on my list of 'waiting to update before 1.2' -- Awesome mod!

We won't make a release until KSP actually releases 1.2, but if you are comfortable building kOS I have a branch published that has been updated based on the pre-release/experimentals: https://github.com/hvacengi/KOS/tree/experimentals

VERY STRONG WARNING:

Your mileage may vary.  MM isn't updated, and all sorts of wonky stuff may happen.  If you find a kOS bug with the new version though, I'd love to know about it so that we can catch it by the time KSP 1.2 officially releases.

MAKE SURE TO ELIMINATE KOS BEFORE ATTEMPTING TO POST BUG REPORTS TO SQUAD.

Edited September 17, 2016 by hvacengi

[Scorp1579]

17 hours ago, hvacengi said:

We won't make a release until KSP actually releases 1.2, but if you are comfortable building kOS I have a branch published that has been updated based on the pre-release/experimentals: https://github.com/hvacengi/KOS/tree/experimentals

VERY STRONG WARNING:

Your mileage may vary.  MM isn't updated, and all sorts of wonky stuff may happen.  If you find a kOS bug with the new version though, I'd love to know about it so that we can catch it by the time KSP 1.2 officially releases.

MAKE SURE TO ELIMINATE KOS BEFORE ATTEMPTING TO POST BUG REPORTS TO SQUAD.

I have no idea how to build it. Can you not build a experimental version like persistent rotation has done?

[Waz]

I tested some of the things that changed in @hvacengi's experimental port for 1.2. Looks like ScienceData is hiding the transmit bonus - I've looked at all the values I could find and scienceData.transmitBonus is always zero, while scienceData.baseTransmitValue is always just the antenna-less value. So for example, a Mystery Goo on the launch pad should be worth 3 returned or 2.5 transmitted ("30% + 53% for good antenna connection = 83%" according to KSP dialog), however the scienceData.baseTransmitValue is 0.3 (the 30%). It looks like a bug - from the names of the fields, you'd surely think scienceData.baseTransmitValue should indeed be 0.3, but that scienceData.transmitBonus should be 0.53 (not 0).

And scienceData:title seems to hang, at least when I try to print it, as if it's got weird trailing control codes or something.

Edited September 19, 2016 by Waz

[hvacengi]

On 9/17/2016 at 2:04 PM, scorpianz1525 said:

I have no idea how to build it. Can you not build a experimental version like persistent rotation has done?

We aren't planning on releasing a 1.2 compatible version until 1.2 goes public.  As KSP is not in a stable release, an automated update to the pre-release could break any kOS binary that is uploaded.  And this helps to limit the potential for bugs being reported to Squad that are actually bugs in kOS.

16 hours ago, Waz said:

I tested some of the things that changed in @hvacengi's experimental port for 1.2. Looks like ScienceData is hiding the transmit bonus - I've looked at all the values I could find and scienceData.transmitBonus is always zero, while scienceData.baseTransmitValue is always just the antenna-less value. So for example, a Mystery Goo on the launch pad should be worth 3 returned or 2.5 transmitted ("30% + 53% for good antenna connection = 83%" according to KSP dialog), however the scienceData.baseTransmitValue is 0.3 (the 30%). It looks like a bug - from the names of the fields, you'd surely think scienceData.baseTransmitValue should indeed be 0.3, but that scienceData.transmitBonus should be 0.53 (not 0).

And scienceData:title seems to hang, at least when I try to print it, as if it's got weird trailing control codes or something.

Thanks for the info.  I haven't tried to look at science info much yet (I almost always play sandbox, so I don't have a testing configuration readily available for it).  I'll try to look into it more later tonight, and I'll get a bug report in if I can't find another suitable value.

[Waz]

5 minutes ago, hvacengi said:

Thanks for the info.  I haven't tried to look at science info much yet (I almost always play sandbox, so I don't have a testing configuration readily available for it).  I'll try to look into it more later tonight, and I'll get a bug report in if I can't find another suitable value.

Yeah, I just made a new save and gave myself maxed-out starting science and starting-cash so I could quickly get stuff. :-)

Edited September 20, 2016 by Waz

[LN400]

Given two numbers h and R when h is updated regularly and R is constant, which one of these two expressions is the quickest for kOS to work out?

((h+R)/R)² or

(h/R)² + 2h/R + 1

I would say the first but I need to make sure.

Edited September 20, 2016 by LN400

[Waz]

30 minutes ago, LN400 said:

Given two numbers h and R when h is updated regularly and R is constant, which one of these two expressions is the quickest for kOS to work out?

((h+R)/R)² or

(h/R)² + 2h/R + 1

I would say the first but I need to make sure.

Yes, the first - it is +, /, ², whereas the second is /, ², *, /, +, +. A computer, virtual or otherwise, does maths just as you do.

Edited September 20, 2016 by Waz

[LN400]

Just now, Waz said:

Yes, the first - it is +, /, ², whereas the second is /, ², *, /, +, +.

Thanks. Just had to ask in case kOS did things a bit differently.

[LN400]

Ok, one more question. I am doing a bit of concept study and need a small time interval dt. Below is the code so far.

The dt part is in the main loop at the bottom. There you will see 2 lines commented out containing dt. Those are my to-do steps but I need some help in finding the optimal way for what I hope can be a blistering fast code.

Also please shout out if you spot any mistakes, typos, errors etc etc. Gracias.

EDIT:

Rearranging hoping that will get the values for h and m to match better while making the code slightly shorter by baking a into the last expression:

Spoiler

//Concept study of Fixed Acceleration for Vertical Launch Stage 1

//INPUTS HERE
parameter m. // total start mass
parameter a0. // target acceleration m/s/s.
parameter Fv. //Max vacuum thrust AFTER VAB cap
parameter Fa. //Max ASL thrust AFTER VAB cap
Parameter Isv //vacuum Isp
Parameter T //Initial thrust % from 0 to 1 for fine tuning.

//CONSTANTS
set g0 to 9.80665.
set P to 5400. //Scale height
set R to 600000.//Kerbin radius

//VARIABLES
set dt to 0.

//PRE-CALCULATIONS OF CONSTANTS
set K to (a0^2 + a0)*g0.
set U to 1/(Isv * g0).//Exhaust gas velocity vacuum.
set Fd to Fv - Fa.
set Mft to Fv*U.//Mass loss rate full throttle.
set E to constant:e^(-1/P).
set RR to R^2.

//LOCK VAR
lock T to throttle.

SAS ON.
wait 0.5.
stage.

until maxthrust = 0
{
//get dt.
	set m = m - T*Mft*dt. //New mass.
//reset dt.
	set h to altitude.//Barometric altitude snapshot.
	set Fm to Fv - Fd*E^h. //Maximum available thrust at altitude h.
	set Ft to T*Fm. //Thrust at current throttle.
	set f to RR/(h+R)^2.//scaling factor for local g.
	set G to m*g0*f. //Local gravitational pull for vertical launch only.
	set T to max(min(K*m^2*f/((Ft - G)*Fm), 1), 0). //Corrected throttle value from 0 to 1.
}

 

 

Edited September 20, 2016 by LN400

[hvacengi]

1 hour ago, LN400 said:

Ok, one more question. I am doing a bit of concept study and need a small time interval dt. Below is the code so far.

The dt part is in the main loop at the bottom. There you will see 2 lines commented out containing dt. Those are my to-do steps but I need some help in finding the optimal way for what I hope can be a blistering fast code.

Also please shout out if you spot any mistakes, typos, errors etc etc. Gracias.

[... snip ...]

For starters, I assume you want to lock throttle to T. instead of locking T to the value of throttle.  Second, you need to add a wait to the end of your loop, otherwise it will repeatedly execute until you exceed the IPU instruction limit.

As for a dt, just store your last time you updated, and compare it.  "Lightning fast" is relative in kOS, since the VM has a lot of overhead.  Increasing the IPU from the default 200 to 2000 will probably have a more profound impact on performance than attempting to optimize your code.  As with most programming, focus first on getting something working (using good practices) and then see if you need to optimize to squeeze additional performance.

set t0 to time:seconds.
wait 0.
until false {
    set t1 to time:seconds.
    set dt to t1 - t0.
    // do something
    set t0 to t1.
    wait 0.
}

Edited September 20, 2016 by hvacengi

[LN400]

14 minutes ago, hvacengi said:

*snip*

Thank you for the input! and of course you're right. The t vs throttle was me staring too much going blind.

What I wonder is, how would waits affect the fake integral that is at the core of the functionality here? Wouldn't too much delay break it apart? I remember from some 2-3 years back how the PID I wrote was really sensitive to extra instructions and that had a much sturdier integral/derivate code than this. What I need here though is something as quick as I can possibly run it on kOS. Would a wait 0 do, just to get that tick?

I will look into speeding up the IPU, it might solve a few issues so thanks heaps for that, and the dt bit.

For testing though, that dt was absolutely essential to have anything working but now it seems I have enough for Test Part 1. Haven't even looked at drag yet, or curving the trajectory so more tests are coming in the future, and possibly more questions and silly mistakes

[hvacengi]

2 minutes ago, LN400 said:

I remember from some 2-3 years back how the PID I wrote was really sensitive to extra instructions and that had a much sturdier integral/derivate code than this. What I need here though is something as quick as I can possibly run it on kOS. Would a wait 0 do, just to get that tick?

Remember, kOS is not running in real time.  So the 200 to 2000 instructions you execute are all done in one tick.  Which means that without a wait, you would execute the same loop again.  Assuming 150 instructions per loop, at 200 IPU you would get 25% of the way through the loop before handing off to the next tick, making it so any values you read from KSP after that point would be from the next tick, while the initial readings came from the initial tick.  Any wait command will initiate a wait for at least one tick.  By passing a parameter of zero, it will end exactly on the next tick.  If you're referring to writing a PID in kOS 2-3 years ago, the sensitivity to instructions probably stemmed from the IPU limit causing your PID to actually span multiple ticks.  Especially if you were trying to do more than just the one loop.  We've also added a PIDLoop structure, which drastically cuts down the number of kOS instructions required for updating PID.  My docking script went from 1900+ instructions per update to 270 when I added the PIDLoop structure.

Because the IPU limit controls how much code is executed during a single tick, it can also affect KSP's performance.  Try to limit the number of expensive calls you make in loops like that.  Compiling a script to ksm 50 times per tick will slow the game to a crawl, since the game can't continue until kOS is finished.

[dlrk]

Has anyone been able to integrate the Trajectories API? I tried myself, but was unsuccessful.

[Waz]

Setting warp from kOS seems to be subtly different to changing it manually. KSP now throttles back warp to 3 to perfectly cross SoI's without screwing them up, but if you set warp from kOS and just wait, this auto-throttling fails and we get the old broken SoI-crossing problems.

Anyone successfully implemented a "warp to after next SoI change" script? I'm currently testing with 1.2, but kOS is unchanged in the warping code.

[hvacengi]

1 hour ago, Waz said:

Setting warp from kOS seems to be subtly different to changing it manually. KSP now throttles back warp to 3 to perfectly cross SoI's without screwing them up, but if you set warp from kOS and just wait, this auto-throttling fails and we get the old broken SoI-crossing problems.

Anyone successfully implemented a "warp to after next SoI change" script? I'm currently testing with 1.2, but kOS is unchanged in the warping code.

do you mean that this occurs with SET WARP TO 3. or with WARPTO(TIME:SECONDS + 10).?

[Waz]

2 hours ago, hvacengi said:

do you mean that this occurs with SET WARP TO 3. or with WARPTO(TIME:SECONDS + 10).?

Both. Even a trivial script that just does SET WARP TO 7 and then WAITs doesn't work - the games does do its usual automatic warp-reduction-prior-to-soi, but not quickly/correctly enough. It's as if there is a difference between manual and in-code setting the warp, where only the manual one activates the code that prevents SoI changes from screwing up patches. Any other ideas for testing, let me know.

[DBowman]

I'm having some trouble understanding NODE:BURNVECTOR. The doco reads like it's the node's burn expressed in a different co-ordinate system ( absolute space ) rather than the (normal, radial, prograde) that you use to setup the node.

I used kOS to make some nodes, each 50 m/s sec prograde (expect the last which is 30), about 17 seconds apart. When I print the MAGs out it looks like each node's BURNVECTOR is some cumulative measure. I then also printed the (Bi - Bi-1):MAG thinking it should be 50 (same vector different coordinate system) but it's not ....

 

Quote

DECLARE FUNCTION PrintBurns {
    local x is 1.
    SET vim1 to (ALLNODEs[0]:DELTAV - ALLNODES[0]:DELTAV).
    FOR ANM IN ALLNODES {
        SET vi to ANM:DELTAV.
        PRINT "Node."+x+": "+ ANM:BURNVECTOR:MAG +" "+(vi-vim1):MAG.
        SET vim1 to vi.
        set x to x+1.
    }.
}.
 

this is my printing function.

Can anyone tell me something about what's going on?

[ElWanderer]

9 hours ago, Waz said:

Setting warp from kOS seems to be subtly different to changing it manually. KSP now throttles back warp to 3 to perfectly cross SoI's without screwing them up, but if you set warp from kOS and just wait, this auto-throttling fails and we get the old broken SoI-crossing problems.

Anyone successfully implemented a "warp to after next SoI change" script? I'm currently testing with 1.2, but kOS is unchanged in the warping code.

I used to use WARPTO to a time three minutes before the predicted SoI change, then run WARP 3 until the BODY changed. This worked fine as long as the predicted transition was accurate... but I found it was often out of whack, either due to the intersect prediction finding a later intercept (should be better in KSP 1.2) or because the orbit calculations changed between real-time and rails. Quite a few Minmus transfers went wrong because it'd shoot through the transition. WARPTO can only be cancelled by a key press, so the script couldn't break out early on detecting a transition.

I've since written my own warp function that will set the desired WARP based on how far away the target time is (took a bit of tuning to stop it overshooting) and an optional function delegate parameter that can be used to end the warp early e.g. on SoI transition. If we get an unexpected transition, it still takes a while to slow down warp, so we tend to overshoot and potentially end up in a different orbit to what we wanted. This is better, but not great. One solution is to warp to a time much earlier than the predicted transition and then do a series of short hops. This takes longer, but ensures you're going slower near transition.

[hvacengi]

13 hours ago, Waz said:

Both. Even a trivial script that just does SET WARP TO 7 and then WAITs doesn't work - the games does do its usual automatic warp-reduction-prior-to-soi, but not quickly/correctly enough. It's as if there is a difference between manual and in-code setting the warp, where only the manual one activates the code that prevents SoI changes from screwing up patches. Any other ideas for testing, let me know.

8 hours ago, ElWanderer said:

I used to use WARPTO to a time three minutes before the predicted SoI change, then run WARP 3 until the BODY changed. This worked fine as long as the predicted transition was accurate... but I found it was often out of whack, either due to the intersect prediction finding a later intercept (should be better in KSP 1.2) or because the orbit calculations changed between real-time and rails. Quite a few Minmus transfers went wrong because it'd shoot through the transition. WARPTO can only be cancelled by a key press, so the script couldn't break out early on detecting a transition.

I've since written my own warp function that will set the desired WARP based on how far away the target time is (took a bit of tuning to stop it overshooting) and an optional function delegate parameter that can be used to end the warp early e.g. on SoI transition. If we get an unexpected transition, it still takes a while to slow down warp, so we tend to overshoot and potentially end up in a different orbit to what we wanted. This is better, but not great. One solution is to warp to a time much earlier than the predicted transition and then do a series of short hops. This takes longer, but ensures you're going slower near transition.

As near as I can tell the only difference in kOS setting the warp rate directly is that we always tell it to not be "instant" while stock has the ability to change the warp setting instantly.  

As far as `warpto` is concerned, we call the same method as the map UI button, with the only difference being that the map UI explicitly specifies two parameters while kOS relies on the default values for those same parameters.  My first reaction was that those parameters must be the cause, except the map UI values are the exact same as the default values.

So in both cases, it literally should be no different than if you had clicked the UI buttons.  Which makes sense, as the UI buttons are how I figured out how to implement `warpto`.  When I check references to the methods kOS calls, the stock UI calls the same methods.

On a secondary note, I'm expecting to introduce a new structure accessible from `kuniverse` that would allow us to expose more information about warp data.  That way you could find the actual multiplier and/or timestep, as well as have access to the ability to cancel `warpto` (when that feature was first introduced there was no way to cancel the warp from a mod, that has since been added).

Edited September 24, 2016 by hvacengi

[ElWanderer]

13 minutes ago, hvacengi said:

[we can add] access to the ability to cancel `warpto` (when that feature was first introduced there was no way to cancel the warp from a mod, that has since been added).

Ah, excellent. I didn't know that was possible, and it would be very handy to have.

[DBowman]

Can anyone tell me the best way to save some data (maneuver nodes) from one vessel so I can pick them up from another? The mental model I had was like a dictionary of flight plans at KSC that vessels could access. I see vessels can message each other but that doesn't seem to fit naturally for what I wanted to do. I see there are file manipulation functions - maybe I have to use those if I want things to persist as I switch vessel to vessel?