[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Waz]

On 12/10/2016 at 6:10 PM, kcs123 said:

@Waz, thanks, and no worries, everything is in alpha stage in development, so changing behaviour back and forth is expected. Just sometimes is done on purpose and sometimes become different when it is not itended. Only using same kind of GUI may help to notice difference in behaviour.

Sorry for the delay in fixing this (the TextField not working) - it was caused by some odd code in kOS that I wanted to fix. Instead, I've just not used it, and so this is fixed in alpha11 (updated now).

Edited December 13, 2016 by Waz

[sardia]

Would someone be able to use this to create 1 keystroke macros? Might be useful to install this mod instead of three or four other mods to get some extra functionality. Like the transition from jet engines to rocket on a ssto requires you shut off intakes, turn on rocket and pitch up to 35 degrees. 

Or do you lose control of the craft while this is running?

[hvacengi]

1 hour ago, sardia said:

Would someone be able to use this to create 1 keystroke macros? Might be useful to install this mod instead of three or four other mods to get some extra functionality. Like the transition from jet engines to rocket on a ssto requires you shut off intakes, turn on rocket and pitch up to 35 degrees. 

Or do you lose control of the craft while this is running?

Yes, among other things you could set kOS to respond to action group input (easiest when the terminal is closed, since the action group buttons go to the terminal if it's focused).  You only loose manual control when kOS is trying to use the same control.  So you can't both lock steering in the script, and still control pitch/yaw/roll manually (though you can write the script to pilot input like that).  And once you have your macros configured, you just need to write a script to recognize the same condition you use to decide to toggle that action group.  Then you can write your script to perform the action without your manual input.

[hvacengi]

I think I've managed to figure out how fix the Blizzy Toolbar support, but at least it stops throwing exceptions.  But I can't get the toolbar to show up for me to test... @kcs123 and @MaxRebo if I PM you a link to try can you test the build to see if it works with your local copy where the toolbar is working?

[MaxRebo]

@hvacengi Sure thing. And sorry, I kind of got sidetracked and forgot about filing the issue on github... but I'll gladly help testing now

[kcs123]

@hvacengi, sure, I will make a copy of existing game and mod setup (KSP 1.2.1) and also with latest KSP 1.2.2. to see if there is any difference.
Send a PM for details.

[soulsource]

Hi! Sorry if this has been asked already, but I didn't find it in a quick search.

What exactly is an "instruction" in kOS, and how does it count against the IPU limit? Is an instruction a line of source code, is it an opcode in the compiled file, or is it something completely different?

I'm asking because I'd like to know if it makes any sense to factor out variables. As an example, which of the following two snippets will take less instructions counted against the IPU limit?

SET x TO a*b*c+d+e*f.
SET y TO x+2^x+3^x.

SET y TO (a*b*c+d+e*f)+2^(a*b*c+d+e*f)+3^(a*b*c+d+e*f).

In traditional programming the first variant would of course be the faster one, but if the whole SET instruction counts as a single instruction towards the IPU limit, the second variant would be preferable.

[hvacengi]

39 minutes ago, soulsource said:

In traditional programming the first variant would of course be the faster one, but if the whole SET instruction counts as a single instruction towards the IPU limit, the second variant would be preferable.

It's a little complicated to explain without pointing you directly to the opcodes (which is the direct answer to your question, every opcode is an instruction).  Basically every math operation is an instruction, as is evey variable set, and function call, and the like.  The underlying execution is much like any traditional program, except that built in functions themselves only count as a single instruction (pushing each parameter is an additional instruction).  If you want to get an idea of how kOS is performing, you can check the built in code profiling tool: http://ksp-kos.github.io/KOS_DOC/bindings.html#profileresult  That's also the best way to understand how script translates to instructions.

Edited December 15, 2016 by hvacengi

[Dunbaratu]

5 hours ago, soulsource said:

Hi! Sorry if this has been asked already, but I didn't find it in a quick search.

What exactly is an "instruction" in kOS, and how does it count against the IPU limit? Is an instruction a line of source code, is it an opcode in the compiled file, or is it something completely different?

I'm asking because I'd like to know if it makes any sense to factor out variables. As an example, which of the following two snippets will take less instructions counted against the IPU limit?

SET x TO a*b*c+d+e*f.
SET y TO x+2^x+3^x.

SET y TO (a*b*c+d+e*f)+2^(a*b*c+d+e*f)+3^(a*b*c+d+e*f).

In traditional programming the first variant would of course be the faster one, but if the whole SET instruction counts as a single instruction towards the IPU limit, the second variant would be preferable.

The first way would be fewer instructions in kOS as well.

In a nutshell, a statement like

SET x to A*B

 gets compiled in kOS's head when your program is first being RUN.  What it turns into is something like this:

push $x 
push a
push b
mult // pops the top two stack things, then pushes their product
store // pop a value, then pop an identifier, store value in identifer.

And that's what actually executes.

So SET X TO A*B actually costs 5 instructions from the IPU limit, not 1.

The default IPU limit of 200 is *very slow*, on purpose, to simulate a really really slow old computer.  (remember that one instruction in kOS is usually a bit more high-level still than a real machine language instruction, so it's not *quite* as slow as one might think, but one problem is that we don't weight the instructions by simulated clock cycles, so an expensive one is just as much as a simple math operation.  There's... difficulties in trying to weight them accurately as the only real runtime measure we have is the wall clock's elapsed time and that's subject to wide variation depending on what else is on your gaming computer at the time.  So for now we've punted and just said "pretend all instructions have the same weight, even though that's not really true."  It's still more accurate than making each line of code take the same amount of time and just executing one line of code per physics tick (which is how it originally worked ages ago before it had a proper compiler).

[soulsource]

Thanks a lot! When I have some spare time (meaning: more spare time than I could spend playing KSP...), I'll have a closer look at the kOS source code, as I'm quite curious about its inner workings.

For now I'm happy to know that each opcode counts as instruction, and that there's an option to profile code. This will hopefully allow me to get my script to finish in a single physics tick. I'm aware that I could just increase the IPU limit, but I like the challenge to get it running on tight resources .

[-ctn-]

I had a question, but when in doubt - reboot and try again, because now it works.

Edited December 21, 2016 by -ctn-

[hvacengi]

9 hours ago, -ctn- said:

I had a question, but when in doubt - reboot and try again, because now it works.

For a period I actually rebooted between each of my "phases" because there was a bug that was misaligning the stack for really long scripts.  Hopefully yours isn't an issue like that 

[EmbersArc]

The script for controlling a Dragon with differential throttling in action.

The reaction wheels and SAS are turned off and all steering happens with thrust adjustments on the four SuperDraco engines.
It can be commanded to fly to a predefined place and will do that without any further input.
This is the first step and I will improve the script to do some more crazy things.

On 12/6/2016 at 6:10 PM, hvacengi said:

I'm not sure what the steering manager would do with asymetric thrust like that, but you could try adjusting the thrust limiter based purely on the pitch and yaw error suffixes on steering manager.  I don't recall if those errors are signed however.

Using the error from the steering manager turned out to work perfectly for that.

[hvacengi]

2 hours ago, EmbersArc said:

The script for controlling a Dragon with differential throttling in action.

The reaction wheels and SAS are turned off and all steering happens with thrust adjustments on the four SuperDraco engines.
It can be commanded to fly to a predefined place and will do that without any further input.
This is the first step and I will improve the script to do some more crazy things.

I can't wait to see your "crazy things" that come next!  I'd love a chance to check out the code you used to go with that script.  Some of the logic may come in handy when working on targeted landing scripts.  And most of all, thanks for reminding me to go download the reusability expansion!

[EmbersArc]

18 hours ago, hvacengi said:

I can't wait to see your "crazy things" that come next!  I'd love a chance to check out the code you used to go with that script.  Some of the logic may come in handy when working on targeted landing scripts.  And most of all, thanks for reminding me to go download the reusability expansion!

Sure here you go: http://pasteall.org/163505  Tweaked it and added cascading attitude control: http://pasteall.org/164260

At the moment you can enter any position (lon, lat, alt) and it will try to fly there. I had another approach for landing where it controls the speed vector to always point at the target. It's more efficient but less reliable.

Edited December 24, 2016 by EmbersArc

[APlayer]

EDIT: Wow, I am stupid. I just requested the code. Nevermind, and you have official permission to execute me.

EDIT2: @EmbersArc: Still, would you mind commenting it better, so I can learn from it? I know the basic syntax of Kerboscript and kinda understand the tutorial, but I still don't get what your code does...

Edited December 24, 2016 by APlayer
---

[EmbersArc]

I've implemented cascading control for the Dragon's orientation which means that it can recover when it's spinning. Here it is starting a rotation on purpose and then recovering from it:

https://gfycat.com/somenaiveconey

 

On 12/24/2016 at 1:11 PM, APlayer said:

EDIT2: @EmbersArc: Still, would you mind commenting it better, so I can learn from it? I know the basic syntax of Kerboscript and kinda understand the tutorial, but I still don't get what your code does...

Honestly I don't think it's necessary. If there's a specific part that just doesn't make sense then don't hesitate to ask.

Here's the new code, it's a bit more elegant: http://pasteall.org/168444

Edited December 28, 2016 by EmbersArc

[Kartoffelkuchen]

Here's my latest progress on a reusable launcher using kOS code:

The rocket is based on a scaled up Blue Origin New Shephard, while the capsule will land propulsively, similarily to a Crew Dragon. All the algorithms behind this have been optimized over the last couple months (I showed off some early tests of such a script before) and have been enhanced, I am currently working on the boostback script. I will bundle the different functions into a library which I will release once I'm happy with it.

You can also check some of my previous videos to see how this evolved: https://www.youtube.com/channel/UCvEftEP1HK3N8YtGYG85-_Q/videos

 

[pellinor]

It seems like I can't set a target when KSP is out of focus (on windows non-fullscreen with option -popupwindow, if that makes any difference). When called from a boot file while KSP is not the active window, the following code gets stuck until I bring the KSP window to the top.

    local count is 0.
    until HasTarget {
      set Target to tgt.
      wait 0.
      set count to count+1.
    }
    if (count>1) print "WARNING: setTarget: count="+count.

It looks like only the "set target" is ignored while everything else runs normally.

Is this a known limitation? I remember a discussion about input locks in the past, maybe this is related?

[Dunbaratu]

On 12/30/2016 at 5:33 PM, pellinor said:

 

Is this a known limitation? I remember a discussion about input locks in the past, maybe this is related?

For some reason, the stock game made the setting of the target into one of the input locks, just like using WASDQE and so on, which means it will get blocked when the window is not focused.  If you're wondering why the game does this - why bother blocking things when the window isn't the focus - if it's not the focus shouldn't it not get the input events anyway - then remember how KSP used to have a click-through problem in windowed mode?  The way Unity was reading the mouse input, and the way KSP was using the Unity system, clicks were being seen by the game when the game wasn't the active window.  Locking out the things that clicking can do to the game (like setting the target) was probably how they solved it (rather than just ignoring all input events when not focused, they went with individually disabling the things the inputs would do, which has the side effect you found of disabling those things even when not happening via the GUI input.)

[Nerfclasher]

can mods like gravity turn be started using kos

[kcs123]

16 hours ago, Nerfclasher said:

can mods like gravity turn be started using kos

What you mean by that ? IIRC, gravity turn mod is plugin and all calculations/loging are done trough plugin. So, I'm not sure what you mean by starting gravity turn mod with kOS. Also, I'm not sure what would be difference, starting gravity turn mod by kOS or by yourself trough available mod GUI.

On the other hand, it is quite possible to write your own kOS scripts that would make same calculations as gravity turn does. Collect some data and write in log files, recalculate / create more optimized ascent slope based on loged data on second launch, etc. More fun and more stuff you will learn trough pure kOS aproach.

[tseitsei89]

Okay I just downloaded the mod and run into a problem. Sorry if this is a noobish/already answered question

http://imgur.com/eAshqMN

As you can see from the screenshot I created a new file to test how this works.

But the problem was when I tried to write PRINT "HELLO" I noticed that my R and E keys weren't working. So just to elaborate what my problem is I tried to wrote QWERTYASD after that. And as you can see R E and S keys are not registered.

Coincidentally those happen to be the letters used for (R)eload, (S)ave and (E)xit (the buttons at the top right corner of that window. So that is somehow blocking them I believe... But I couldn't quickly find a way to make it work so I thought I would ask here if anyone has faced the same problem and/or knows how to fix it...

[danielboro]

i play a lot AFK.

i plot the nav points then let my kids have the computer.

and i use mekjeb and kos as pilots. and KAC to not miss ship jumps.

i expect Nerfclasher has a similar play stile.

i cold use an option to start mods like GT from kos

no reason to reinvent the weal if i dont have to

[tseitsei89]

24 minutes ago, danielboro said:

i play a lot AFK.

i plot the nav points then let my kids have the computer.

and i use mekjeb and kos as pilots. and KAC to not miss ship jumps.

i expect Nerfclasher has a similar play stile.

i cold use an option to start mods like GT from kos

no reason to reinvent the weal if i dont have to

It could be fun and educational though