[1.3] kOS Scriptable Autopilot System v1.1.3.0

[John FX]

That`s good, it seems mostly the same, I`m glad there are lists of what will break stuff from version to version. That will help a lot.

Now I just need to figure out what the sam my code is doing (I don`t document my code nearly enough) and then update it.

TYVM

[Dunbaratu]

Well it looks like 0.90 broke kOS (as expected).

erendrake has started looking into it. For my part I plan to play a bit of stock 0.90 KSP for a day or two first to understand the new features from a player's viewpoint before I look at how those changes affect the kOS mod.

[Cairan]

Well it looks like 0.90 broke kOS (as expected).

erendrake has started looking into it. For my part I plan to play a bit of stock 0.90 KSP for a day or two first to understand the new features from a player's viewpoint before I look at how those changes affect the kOS mod.

Same story here... ever since it became obvious 0.90 was around the corner it's been hard not to wait for the changes to come to light...

[erendrake]

New Pre-Release v0.15.4

this is a shoot from the hip update that we put together in a few hours. it has almost no testing so please let us know if you have any trouble with it.

Dev Thread

Edited December 16, 2014 by erendrake

[hexd86]

Thanks for the update, erendrake!

Meanwhile, I wanted to ask a question about the "GeoCoordinates:TerrainHeight" parameter. I've tested it on a rover around KSC and for some reason it gives very erratic output when driving around on mostly flat land. Sometimes it would give adequate values (Example1), and sometimes would be comepletely wrong, telling me I was under the surface of terrain (Example2). These two screenshots were made within 500m driving distance around KSC.

What could be causing such a erratic behaviour?

Link to reddit/KOS discussion, with code:

Thanks in advance.

[xZise]

I'm using kOS 0.15.3.0 on KSP 0.25 and wondering if there are something like exceptions (or simply exiting the script) and if it's possible to request an action of the user to ask if the script shall continue.

[Dunbaratu]

I'm using kOS 0.15.3.0 on KSP 0.25 and wondering if there are something like exceptions (or simply exiting the script) and if it's possible to request an action of the user to ask if the script shall continue.

Both user keyboard input and an "exit" are not there yet. Part of the reason why is that both, while they'd be simple on their own, are tied up with more complex changes we want to do that affect how they get implemented. Key input is tied to making the terminal better and more dynamic, changeable, and remoteable. The 'exit' is tied to making proper functions (because of the need to decide if we want exit codes from RUN commands, or return objects from functions, or both).

Sometimes when I've needed an emergency "exit" in a script, I cheated and deliberately caused a runtime error to force the program to quit. (for example, trying to divide by zero).

[Dunbaratu]

It is using the following algorithm:

1 - Try calculating the terrain height using the ideal terrain function (PQS) which represents a smooth curve of terrain as seen from high up in space, not the actual polygons that approximate it once you get low down.

2 - Try doing a raycast to hit the terrain polygons.

If the raycast worked, return that, else return the ideal PQS value.

I suspect the raycast is intermittently failing, because it's notoriously unreliable unless you call it with precisely the right timing. It's a problem I've encountered in another mod I was writing and trying to diagnose why it randomly misses is a royal mess. The docs in Unity explaining how you're supposed to use it do NOT cover all the tricky timing issues that break it so trying to figure out what's wrong is pure random guesswork based on user community suggestions (that contradict each other).

Fixing it is not a high priority because usually you use geocordinates to work with terrain at any arbitrary point that could be far away - so the polygon hits aren't really usable for that anyway. For local polygon hits right under you, the alt:radar is good.

[Camacha]

Do I understand correctly that, as of 0.15, kOS has the ability to intercept player inputs which kOS is free to interpret and alter before passing them on to KSP?

Edit: confirmed. This. Is. Awesome!

Edited December 17, 2014 by Camacha

[erendrake]

Do I understand correctly that, as of 0.15, kOS has the ability to intercept player inputs which kOS is free to interpret and alter before passing them on to KSP?

That is the plan we ran into a problem where the autopilot was appearing as well as user controls we have a fix in the works and should be in pretty soon.

http://ksp-kos.github.io/KOS_DOC/structure/control/index.html

Its the pilot section at the bottom.

[Masaker]

I have problem with HEADING property. If I write print HEADING. It always return 0 or very small value. What is wrong?

[Camacha]

Its the pilot section at the bottom.

I already tested it yesterday with some analogue goodness from my controller At first I felt a bit like a cat that finally caught the mouse and doesn't know what to do with it, but I realized I could use it to finally fix an annoyance with how KSP looks at controllers. The triggers are on the same axis, meaning that one trigger is only half an axis, which in turn means that using it as a manual hovering throttle is not optimal. Now I can just have kOS double up my throttle input, giving me full throttle range on a single axis. Well, I guess you in lose some resolution, as every step is now two units rather than one, but since the resolution of the analogue controls is pretty fine-grained anyway I do not think it will be noticeable*. Not the most sophisticated of scripts, but useful.

Another use I could think of right away is a safety system for my favourite little runabout air plane. Ever since Ferram added certain aerodynamic stresses to FAR, I tend to rip the tail off of it when doing steep turns. I hope to figure out some sort of variable or metric or combination of a couple of them that could serve as an indicator for imminent doom. That way I can have kOS dial back the input et voilà, no disassembly.

*I could not help myself and had to look into this a bit. Apparently, the triggers on the Xbox 360 controller have 256 levels (so they are 8 bits), meaning you are left with 128. The sticks seem a bit more sophisticated with 65536 levels (256 * 256 levels, so 16 bits). Pretty cool tech.

[erendrake]

Another use I could think of right away is a safety system for my favourite little runabout air plane. Ever since Ferram added certain aerodynamic stresses to FAR, I tend to rip the tail off of it when doing steep turns. I hope to figure out some sort of variable or metric or combination of a couple of them that could serve as an indicator for imminent doom. That way I can have kOS dial back the input et voilà, no disassembly.

you can currently kick FAR into a debug mode that will add the stress data to the right click menu for each part. that way you can monitor the parts that you are overstressing and tell kos to not let you exceed it. a real fly by wire system would be pretty cool

[Camacha]

that way you can monitor the parts that you are overstressing and tell kos to not let you exceed it.

Can I have kOS readout those values directly or are you suggesting a more indirect approach?

a real fly by wire system would be pretty cool

Those would be the very humble beginnings of one, I suppose

[erendrake]

Can I have kOS readout those values directly or are you suggesting a more indirect approach?

Those would be the very humble beginnings of one, I suppose

well, because we now let you query any value that is in the right click menu. As soon as FAR adds that debug information you can get it and do whatever you want with it

http://ksp-kos.github.io/KOS_DOC/command/shipquery/index.html

[Camacha]

Steven has very kindly answered my question in the Infernal Robotics thread:

Yes you can control IR from kOS now (although kOS is in a state of flux at the moment because KSP 0.90 broke some stuff about how autopiloting works. KSP's 0.90 changes are VERY much in the same areas that kOS has its fingers in, so don't expect kOS to be 0.90 compatible for a while yet. We kOS devs aren't part of the experimentals group so we only just got our first chance to be aware of the changes yesterday.)

A simple dumb example of manipulating an IR part from a kOS script:

// Assuming THEPART is a part that is an infernal robotics part, move that 
// part in the "+" direction for 1 second, then stop moving:
SET robotModule TO THEPART:GETMODULE("MUMECHTOGGLE").
robotModule:DOACTION("MOVE +", true).
WAIT 1.
robotModule:DOACTION("MOVE +", false).

More full descriptions can be found here (for now - the docs are about to move to a new location) :

http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_parts_and_modules/index.html

This is wonderful, but being the greedy little bugger I am I want more. It there any way to read or set the positional/angle values of a hinge or other IR part, or the speed? My apologies if I overlooked this information in the link provided, I am still trying to get to terms with these functionalities.

well, because we now let you query any value that is in the right click menu. As soon as FAR adds that debug information you can get it and do whatever you want with it

Enough with the awesomeness already!

I found something else I was looking for in a link behind your link too. Looks like I have some reading up to do.

[Camacha]

I have a little trouble locking certain values. When I set engine_0:thrustlimit to ship:control:pilotmainthrottle it is not a problem, but when I try to lock the same value by using lock engine_0:thrustlimit to ship:control:pilotmainthrottle kOS throws an error. Any suggestions?

I also noticed the (really nice) kOS button/menu is not working most of the time.

Edited December 18, 2014 by Camacha

[Camacha]

Sorry for the spam You wanted testing, you get testing!

There is something weird going on. When I run the following script in combination with my Xbox 360 controller, the ship:control:pilotmainthrottle follows my controller trigger nicely whatever I do with the trigger. However, the variable that is calculated based on the same value only follows when the trigger is moved in a somewhat slow and controlled fashion. If I release the trigger quickly, only ship:control:pilotmainthrottle follows suit, but the value that is based on it stays where it is. At first I thought the controller or KSP was to blame, but since the ship:control:pilotmainthrottle is correct every time I think the problem is with kOS somehow. So:

Trigger neutral:

ship:control:pilotmainthrottle = 0,5

((ship:control:pilotmainthrottle - 0.5) * 2) = 0

Trigger pressed:

ship:control:pilotmainthrottle = 1

((ship:control:pilotmainthrottle - 0.5) * 2) = 1

Trigger released slowly:

ship:control:pilotmainthrottle = 0,5

((ship:control:pilotmainthrottle - 0.5) * 2) = 0.

Trigger released quickly

ship:control:pilotmainthrottle = 0,5

((ship:control:pilotmainthrottle - 0.5) * 2) = between 1 and 0,6 depending on how quickly.

clearscreen.
lights off.

until lights=true {
	print ship:control:pilotmainthrottle at (0,1).
	print ((ship:control:pilotmainthrottle - 0.5) * 2) at (0,2).
}.

Edited December 18, 2014 by Camacha

[Dunbaratu]

I have a little trouble locking certain values. When I set engine_0:thrustlimit to ship:control:pilotmainthrottle it is not a problem, but when I try to lock the same value by using lock engine_0:thrustlimit to ship:control:pilotmainthrottle kOS throws an error. Any suggestions?

Locking does not work with suffixes of any type.

LOCK AAAAA:BBBBB TO CCCCCC.

Will fail for *any* AAAAA, BBBBB, or CCCCC.

The LOCK command only works on simple single values. This is a limitation of it that I'd like to fix some day, but working out the right thing to do is a bit messy if the chain of suffixes is itself changeable.

For example, it you:

LOCK SHIP:PARTSTAGGED("my engine")[0]:THRUSTLIMIT TO TWR*1.2.

The problem is in having to work out which of these was meant:

option 1:

First, Up front:

Get the parts tagged "my engine". get the zeroth such engine, and get a handle to its thrustlimit.

Then, continually update each time:

That thrustlimit's value to TWR*1.2, regardless of how PARTSTAGGED("My engine") might change.

option 2:

First, Up front:

Do nothing.

Then, continually update each time:

Re-run PARTSTAGGED("my engine") to recalculate what the zeroth such part is at the MOMENT, just in case that changes, then set it's thrustlimit to TWR*1.2.

Option 2 would correctly handle the case where the suffix changes what it means from one moment to the next, but it would be wastefully expensive for the majority of cases where it doesn't.

I don't know the right answer for choosing between option 1 or option 2, which is why I haven't addressed this hole in the language yet. By deliberately not picking one or the other, I force the script writer to do it explicitly if they want lock-like behavior - they have to do it in their own trigger, where their own code would decide which way to do it.

Option 1 can be implemented this way:

SET FOO TO SHIP:PARTSTAGGED("my engine")[0]. // calculate this part just once.

WHEN TRUE THEN { SET FOO:THRUSTLIMIT TO TWR*1.2. PRESERVE. }. // recalculate this part over and over.

Option 2 can be implemented this way:

WHEN TRUE THEN { SET SHIP:PARTSTAGGED("my engine")[0]:THRUSTLIMIT TO TWR*1.2. PRESERVE. }. // Recalculate the whole chain of suffixes over and over.

Warning, Option 2 is very expensive because it does a walk of the whole parts tree every update, which is why I'm reluctant to implement LOCK this way even though it would be linguistically more correct with how the language probably is meant to work.

I also noticed the (really nice) kOS button/menu is not working most of the time.

Can you elaborate? It's intended to work like the other buttons up there where it's mutually exclusive with the other panels (i.e. you hover the mouse to bring the panel up temporarily, or click to leave it up and click again to make it go away, and it won't appear if one of the other panels is up instead (i.e. the resource panel).

Edited December 18, 2014 by Steven Mading
Tagged the box for disabling the F***ing smilieys. Why on earth can't I set that as my default dammit!!

[Camacha]

Can you elaborate? It's intended to work like the other buttons up there where it's mutually exclusive with the other panels (i.e. you hover the mouse to bring the panel up temporarily, or click to leave it up and click again to make it go away, and it won't appear if one of the other panels is up instead (i.e. the resource panel).

Come to think of it, I think I saw the panel once. Now I can click or hover all I want, I don't get a panel. All other panels do what they are expected to do. If I have some time I might see whether I can reproduce this in a fresh installation.

Edited December 18, 2014 by Camacha

[Drew Kerman]

hey guys, I need to barge in with something out of left field. I'm trying to track down an issue with KSPTOT and it led me to pull the orbital period values of Minmus, Mun and Ike from kOS. This is what I got from the body:obt:period property for each:

None of these values match what KSPTOT is giving me for the orbital periods of these bodies. And I actually put their orbital properties (LAN, EPH, LPE, SMA, MNA) into Mission Architect to calculate the orbital period. The orbital period calculated by KSPTOT matches what is stated for sidereal orbital period by the KSP wiki for these bodies.

Any ideas as to the discrepancy here?

[Dunbaratu]

hey guys, I need to barge in with something out of left field. I'm trying to track down an issue with KSPTOT and it led me to pull the orbital period values of Minmus, Mun and Ike from kOS. This is what I got from the body:obt:period property for each:

http://i.imgur.com/eSgKNaf.png

None of these values match what KSPTOT is giving me for the orbital periods of these bodies. And I actually put their orbital properties (LAN, EPH, LPE, SMA, MNA) into Mission Architect to calculate the orbital period. The orbital period calculated by KSPTOT matches what is stated for sidereal orbital period by the KSP wiki for these bodies.

Any ideas as to the discrepancy here?

It's only off by a little bit, and what we are returning is *exactly* what the KSP API says for Orbit.period. Given that we are just returning what the API directly says, I'd be more inclined to believe the wiki is wrong than that our number is wrong.

Also note that there's multiple different kinds of measurements for period, depending on what you take as the "same" point the body comes back to, in a constantly moving reference frame with a parent body that isn't in the same place it was when your orbit cycle began. Sadly, the utter lack of documentation for the KSP API means we're not being told which kind of period it is giving. These slightly different versions of Period give slightly different, but close to each other, values.

My guess is that it's referring to the period according to the local raw SOI space (which kOS hides from you by always making all positions get reported relative to the CoM of the CPU's vessel) - how long would it take to return to the same XYZ grid coords relative to the parent planet if those grid coords remained fixed and didn't switch reference (i.e. if you kept the same vessel focused for a whole orbit).

In the real world, if you want to take a period measurement in an inertial reference frame where you don't take into account the rotation of the planet itself or its orbit around its primary body, then you have to do it against the starfield "backdrop" of the solar system (which itself is still changing too, of course, but it's changing slowly enough that you can use it like it was fixed in space). In KSP you get that same sort of meaning (the period in properly behaved linear inertial reference frame that's not rotating as the objects move) NOT by doing it against the starfield but by doing it against the local subspace coordinate grid to which the primary body's SOI is fixed.

And that's a meaning of "period" that you're just not going to find in any real world astronomy manual because it's purely an artifact of the KSP simulation that doesn't actually map to a real world phenomenon.

But this is pure guesswork because SQUAD never documents their API. What we're returning is "whatever SQUAD means when THEY say 'period' in the API."

[Drew Kerman]

Thanks Steven, that's what I was afraid was going on. It would seem that the frame of reference used by KSPTOT to calculate period is different from that of the game. I'm sure Arrowstar can work this out now that he knows about it. Not sure where the wiki got its orbital periods from, but I'm guessing Arrowstar checked his math against them instead of the game's values. This small difference in orbital period I think would be enough to account for the minor inaccuracies I've been seeing when plotting out trajectories from one SOI to another in KSPTOT. Around the bodies themselves things match up fine.

[Drew Kerman]

Can anyone run the commands you see in the image I posted above and tell me their results? I just had toadicus over in the VOID thread show me that in his game kOS is giving him numbers that align with the orbital periods given by KSPTOT and the wiki:

I can't imagine what mod would affect this but it seems I may have something screwing up my install.

[erendrake]

http://i.imgur.com/eSgKNaf.png

Can anyone run the commands you see in the image I posted above and tell me their results? I just had toadicus over in the VOID thread show me that in his game kOS is giving him numbers that align with the orbital periods given by KSPTOT and the wiki:

http://toad.homelinux.net/pics/KSP/VOID/kOS25-Mun_Minmus_Ike.png

I can't imagine what mod would affect this but it seems I may have something screwing up my install.

what other mods do you have installed?