[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Chabadarl]

Youpi!

[meyerweb]

19 hours ago, hvacengi said:

• Introducing a new terminalinput structure for keyboard interaction from within scripts! Currently support is only provided for getting single characters. (#1830)

This alone makes the update worth it to me, even with single-character support.  Fantastic work as always, kOS team!  Looking forward to the 1.2 compatible release, since as far as I’m concerned, 1.2 isn’t really out until kOS works on it.

(Please don’t read that as “hurry up already!!1!”—I’m so buried in work right now that I’m intentionally not upgrading to 1.2 until probably after Thanksgiving, because if I do it any sooner I’ll get sucked in and fall even further behind on the work I’m already criminally behind on…)

[hvacengi]

3 hours ago, meyerweb said:

(Please don’t read that as “hurry up already!!1!”—I’m so buried in work right now that I’m intentionally not upgrading to 1.2 until probably after Thanksgiving, because if I do it any sooner I’ll get sucked in and fall even further behind on the work I’m already criminally behind on…)

It isn't as though we want to cause you to fall further behind, but if it takes us until Thanksgiving to make a release I think I'll pull my hair out.

I think we're actually very close to basic 1.2 compatibility, so hopefully a pre-release can be out soon.  But I've made good headway with commnet and system setting integration as well.  With any luck and no surprises with my own job, we should have another strong update out very soon.

Edited October 12, 2016 by hvacengi

[meyerweb]

15 minutes ago, hvacengi said:

I think we're actually very close to basic 1.2 compatibility, so hopefully a pre-release can be out soon.  But I've made good headway with commnet and system setting integration as well.  With any luck and no surprises with my own job, we should have another strong update out very soon.

Sounds perfect.  Really looking forward to it.

One thing I did notice from the 1.2 release notes was the change of orbital anomaly values:
 

Quote

 

All anomalies (ObT, mean anomaly, eccentric anomaly, true anomaly) are now consistently negative when approaching the periapsis for both elliptical and hyperbolic trajectories (previously, only hyperbolic trajectories used negative anomalies). This means that eccentric anomaly and true anomaly are now in the range -pi..pi instead of 0..2pi for elliptical trajectories.

 

As I had just gotten to working with those kinds of values before I had to put KSP aside for work, I’m very curious if kOS will translate the new values into the old scheme to keep scripts from breaking, or if this will be a bite-the-bullet change, or if there’s another solution in the works, or what.

[hvacengi]

1 minute ago, meyerweb said:

As I had just gotten to working with those kinds of values before I had to put KSP aside for work, I’m very curious if kOS will translate the new values into the old scheme to keep scripts from breaking, or if this will be a bite-the-bullet change, or if there’s another solution in the works, or what.

You aren't the only one concerned about it.  I actually posted a reply regarding the same topic: https://www.reddit.com/r/Kos/comments/570f3g/kos_v101_lets_take_some_input/d8odzcv

Quote

Most of those readings are internally normalized to 0-360° by kOS (because they used to report silly numbers at times). I think we'll need to see if KSP actually exposes those negative values to the user through the UI, since our default position is to agree with the UI wherever possible. It's my understanding however that measures like anomalies should be given in the 0-360 range for eliptical orbits rather than -180-180, and so I'd prefer to keep anomalies reported this way. In hyperbolic orbits a negative value is more helpful, as the hyperbolic functions treat -90° different from 270°, while normal trig will return the same value.

I'd also prefer to simply not break the existing scripts if we can help it. So I really don't want to change the range

 

[hvacengi]

v1.0.2-pre   

WARNING - May contain multiple bugs. Please report any issues you find!

Download

Github: https://github.com/KSP-KOS/KOS/releases/tag/v1.0.2-pre

Notes

• There is no CommNet integration, range and connections will not be enforced.
• Some suffixes may not actually be right. We have a few To Do notes in the code (see #1835 for a list).
• RemoteTech support has not been tested.
• If you select "Require Signal For Control" in dificulty settings (see below) kOS will not be able to fully control the ship when out of signal. Controls should still be manipulated properly if you support partial probe control instead.

Spoiler

Edited October 16, 2016 by hvacengi

[Hooty256]

Thanks for the prompt update. 

[SP_S6]

I've been looking everywhere to find out how the poster of this video got kOS to show the map view in flight. Does anyone know how to do this?

https://youtu.be/Enn3WPSjDnQ?t=2m

[Luis]

The video displays a 'not available' error for me, but from the comments it sounds as if he is displaying the map in the terminal, which would be wild.

[theJesuit]

That would be so cool.

6 hours ago, SP_S6 said:

I've been looking everywhere to find out how the poster of this video got kOS to show the map view in flight. Does anyone know how to do this?

https://youtu.be/Enn3WPSjDnQ?t=2m

My guess though is that he ran a kOS script that did the burn then quickloaded and ran the script again in map view then imposed the map view recording over the terminal window in post production.

But I'd be very happy to be wrong.

Peace.

Edit - it appears I am correct but was ninjad by 4 hours by the kos subreddit where you also asked.  My answer was a little more detail though

Peace out.

Edited October 25, 2016 by theJesuit
Ninja timing

[Luis]

I may have found a bug in the 1.2 pre-release. I'm using a very simple airplane takeoff script, early in career:

function D{parameter m. hudtext(m, 4, 2, 60, yellow, false).}
D("R to launch").
wait until rcs=true. rcs off.
set H to 90. set P to 10. set T to 1.
lock throttle to T.
set ship:control:pilotmainthrottle to 0.
stage.
lock steering to heading(H, P).
wait until alt:radar>10.
set P to 35.
wait until alt:radar>300.
set P to 20.
wait until altitude>1000.
D("Manual control").

This is my airplane:
http://imgur.com/8mow1Wu

The script will initially rotate the tail fins to aim the plane upwards but as it picks up speed on the runway, they slowly turn themselves horizontal again. Eventually the plane has enough speed to take off anyway, but it never attempts to pitch up. If I fly the plane manually, it is capable of lifting into the air at about 35m/s. I have rebuilt the same craft with the same script in 1.1.3 with the 1.1.3 version of KOS and it takes off correctly.

If I fly the plane manually

[kcs123]

11 hours ago, SP_S6 said:

I've been looking everywhere to find out how the poster of this video got kOS to show the map view in flight. Does anyone know how to do this?

https://youtu.be/Enn3WPSjDnQ?t=2m

Based on 2:00 time on video, he shows map inside terminal window. IIRC, kOS actualy draw small chunk of bitmap on terminal window, for each character. It does not support true type font, it is hacky way to show regular text on terminal window.

So, since API for draw something inside terminal window obviously exist, my best guess is that he exploit this somehow to draw map.
Not too difficult to do if you know memory area for regular map draw and memory area for terminal window. Finding proper API functions for both, that is another story.

Probably you need to examine a lot of documentation and source code for unity game engine, KSP API and kOS. Maybe a bit less if you are lucky and have some previous experience with unity.

Anyhow, nice video and usage of kOS.

[Drew Kerman]

3 hours ago, kcs123 said:

Based on 2:00 time on video, he shows map inside terminal window. IIRC, kOS actualy draw small chunk of bitmap on terminal window, for each character. It does not support true type font, it is hacky way to show regular text on terminal window.

So, since API for draw something inside terminal window obviously exist, my best guess is that he exploit this somehow to draw map.
Not too difficult to do if you know memory area for regular map draw and memory area for terminal window. Finding proper API functions for both, that is another story.

Probably you need to examine a lot of documentation and source code for unity game engine, KSP API and kOS. Maybe a bit less if you are lucky and have some previous experience with unity.

Anyhow, nice video and usage of kOS.

@theJesuit already answered this (correctly) two posts above yours. It was just some video compositing

[plonk]

EDIT: Post does not tackle the problem

 

9 hours ago, Luis said:

I may have found a bug in the 1.2 pre-release. I'm using a very simple airplane takeoff script, early in career:

function D{parameter m. hudtext(m, 4, 2, 60, yellow, false).}
D("R to launch").
wait until rcs=true. rcs off.
set H to 90. set P to 10. set T to 1.
lock throttle to T.
set ship:control:pilotmainthrottle to 0.
stage.
lock steering to heading(H, P).
wait until alt:radar>10.
set P to 35.
wait until alt:radar>300.
set P to 20.
wait until altitude>1000.
D("Manual control").

This is my airplane:
http://imgur.com/8mow1Wu

The script will initially rotate the tail fins to aim the plane upwards but as it picks up speed on the runway, they slowly turn themselves horizontal again. Eventually the plane has enough speed to take off anyway, but it never attempts to pitch up. If I fly the plane manually, it is capable of lifting into the air at about 35m/s. I have rebuilt the same craft with the same script in 1.1.3 with the 1.1.3 version of KOS and it takes off correctly.

If I fly the plane manually

Did not check it in KSP, but I can see that your changes to P are never affecting the steering. You must construct a new direction like you did in line 8 everytime you want to change the pitch or heading and assign it to the locked variable. So this one _should_ at least try to steer pitch up (untested)

function D{parameter m. hudtext(m, 4, 2, 60, yellow, false).}
D("R to launch").
wait until rcs=true. rcs off.
set H to 90. set P to 10. set T to 1.
lock throttle to T.
set ship:control:pilotmainthrottle to 0.
stage.
set S to heading(H, P).
lock steering to S.
wait until alt:radar>10.
set P to 35.
set S to heading(H, P).
wait until alt:radar>300.
set P to 20.
set S to heading(H, P).
wait until altitude>1000.
D("Manual control").

Hope that helps.

EDIT: Ah, and turn off SAS in case you did not.

Edited October 25, 2016 by plonk
Forgot SAS; Post's no help

[hvacengi]

5 minutes ago, plonk said:

Did not check it in KSP, but I can see that your changes to P are never affecting the steering. You must construct a new direction like you did in line 8 everytime you want to change the pitch or heading and assign it to the locked variable. So this one _should_ at least try to steer pitch up (untested)

[... snip ...]

Hope that helps.

Actually, that is incorrect.  In the original script steering is locked to "heading(H, P)." which will automatically update once per physics tick, refreshing the current value of both H and P.  While your solution will work as well, the original code is not at fault.  That being said, if he was calling that steering lock in a loop I'd be right on your band wagon, because all to often I see people try to repeatedly lock the steering which is redundant.  In addition, your method is technically more memory and instruction efficient, because you aren't constructing a new "direction" every single physics tick, just the ones where pitch changes.

9 hours ago, Luis said:

The script will initially rotate the tail fins to aim the plane upwards but as it picks up speed on the runway, they slowly turn themselves horizontal again. Eventually the plane has enough speed to take off anyway, but it never attempts to pitch up. If I fly the plane manually, it is capable of lifting into the air at about 35m/s. I have rebuilt the same craft with the same script in 1.1.3 with the 1.1.3 version of KOS and it takes off correctly.

Do you have a video showing what you describe?  I've added a reference to your forum post for an existing issue also asking about the use of control surfaces in 1.2 (https://github.com/KSP-KOS/KOS/issues/1852).  The behavior that you're describing could be a product of multiple things, and it may be a need to tune the steering manager, or it may be an internal issue with how kOS calculates torque.  I've asked the other reporter to do some troubleshooting to see what we can find.

[hvacengi]

11 hours ago, Luis said:

The script will initially rotate the tail fins to aim the plane upwards but as it picks up speed on the runway, they slowly turn themselves horizontal again. Eventually the plane has enough speed to take off anyway, but it never attempts to pitch up. If I fly the plane manually, it is capable of lifting into the air at about 35m/s. I have rebuilt the same craft with the same script in 1.1.3 with the 1.1.3 version of KOS and it takes off correctly.

It looks like we're going to need some more information, like a craft file to test.  I just created a similar plane and launched it using your script without any issue.  Which makes me think that whatever issue you're running into might be affected by vessel configuration.  If you could share I'd appreciate it.

[hvacengi]

Ok, I take it back again.  I was able to recreate the issue, sort of.  Some configurations of control surfaces seem to result in negative torque values.  So I'm going to edit the steering manager to be tolerant of negative torque values.  It should be fixed in the next (pre)release.

[Luis]

That's great news. Many thanks for looking into this so promptly.

[Warp11]

Is there a way to query which biome you're in and/or if you're in space low, high etc? Thanks a lot!

[Ger_space]

3 hours ago, Warp11 said:

Is there a way to query which biome you're in and/or if you're in space low, high etc? Thanks a lot!

not in the basic kOS. But here is a addon for that:

https://github.com/GER-Space/KOS-Biome/releases
 

I'll compile a KSP 1.2 release in a few hours and add some documentation to the githup. For now you find the documentation here:

https://www.reddit.com/r/Kos/comments/4tn9wo/kosaddon_biome/

 

[Warp11]

@Ger_space  Thank you! I won't be using 1.2 since I am playing on Realism Overhaul and that's not ready for that but I'll gladly take your addon.

[Scorp1579]

Looks like with 1.2.1 its a little broken. It doesn't correctly read engine flame out and fails to correctly read an apoapsis correctly

[hvacengi]

2 hours ago, scorpianz1525 said:

Looks like with 1.2.1 its a little broken. It doesn't correctly read engine flame out and fails to correctly read an apoapsis correctly

I have recompiled using 1.2.1 locally and everything seems to be working correctly.  We'll probably try to get another pre-release out soon, but it won't be until after we've had a chance to address a couple of issues that are currently outstanding (like CommNet).  If we weren't so close to having those ready, I'd just post another build.  Until then, compiling for yourself from the source should work.  We'll try to post binaries as soon as is feasible.

[Scorp1579]

13 hours ago, hvacengi said:

I have recompiled using 1.2.1 locally and everything seems to be working correctly.  We'll probably try to get another pre-release out soon, but it won't be until after we've had a chance to address a couple of issues that are currently outstanding (like CommNet).  If we weren't so close to having those ready, I'd just post another build.  Until then, compiling for yourself from the source should work.  We'll try to post binaries as soon as is feasible.

Is it difficult to compile them? Never done it before

[MaxRebo]

@scorpianz1525 Not really difficult, no. But extremely tedious if for some reason or another you can't use the newest version of Visual Studio. I wish more mods would use a GNU-style build system - and I say this as an almost exclusively Windows user... I for one am going to wait

If you never used Visual Studio before than that most likely also means that there is nothing stopping you from using it, so just go grab the most recent version of VS Community and give it a go. In many cases it's as simple as double-clicking the solution file (.sln) and hitting Ctrl+Shif+B.

Edited November 3, 2016 by MaxRebo
forgot they renamed Express to Community...