[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Drew Kerman]

what other mods do you have installed?

A lot. See my sig. I'll just have to do the binary sort troubleshoot. Strip to stock, confirm there's an issue, then add in half my mods and see if anything breaks, etc.

[Xenro66]

Can't wait for this to be updated. I have a triple VTOL jet backwards take-off to make, no idea how to code it but I'll start learning the different commands once it's updated

Edited December 19, 2014 by Xenro66

[Camacha]

Can't wait for this to be updated. I have a triple VTOL jet backwards take-off to make, no idea how to code it but I'll start learning the different commands once it's updated

The ad hoc version seems to work pretty decently, so I would dive right in!

[Drew Kerman]

Real Solar System was the culprit. I've made a report in their thread. Thanks for the assistance, Steven.

[VentZer0]

Hi, I'd like to know if is a way to get the rotation around the long axis of the craft without having to mess with any of the extremely vector methods?

Basically what I want is a way for my plane to recognize that it rolled X° to left or right and then stop the banking. I want it to fly a curve. The method that I found in the documentation is rather messy using ship:control:roll ... roll for X second at this amount .. it is highly dependant on the speed, at some speeds the roll will just be 45° at high speeds it might get over 90°, which is fatal if the plane is too low *boom* . I just want to prevent my drone from over banking.

What would be an easy way to do this? Or how can I read out the attitude data?

[MysticPing]

This has probably been suggested thousands of times but you should just scrap kerboscript and implement a custom version of lua instead.

At the moment only half the stuff work, and a lot that should work doesn't work.

EDIT: To be clear im not doing autopilot stuff, im just trying to figure out if a target is selected or not, so nothing that should be affected by 0.90

Edited December 19, 2014 by MysticPing

[Darren9]

Hi again, I have another question. When I set a heading it's "compass heading + degrees above/below horizon", when I get a heading (to a target for example) it only returns the compass heading. Is there a way to also get the degrees above/below horizon?

[MysticPing]

Try to do this.

Heading is a multiple variable, so do it like this

a, b = target:heading

(Might not work, not good with kOS)

[Dunbaratu]

Hi, I'd like to know if is a way to get the rotation around the long axis of the craft without having to mess with any of the extremely vector methods?

Basically what I want is a way for my plane to recognize that it rolled X° to left or right and then stop the banking. I want it to fly a curve. The method that I found in the documentation is rather messy using ship:control:roll ... roll for X second at this amount .. it is highly dependant on the speed, at some speeds the roll will just be 45° at high speeds it might get over 90°, which is fatal if the plane is too low *boom* . I just want to prevent my drone from over banking.

What would be an easy way to do this? Or how can I read out the attitude data?

Ohhh man I *really* *really* want to mention some tools that exist already in the update but aren't documented that do exactly this. The only reason I haven't mentioned them is that the docs are currently frozen because someone is writing a re-do in a better document system and I didn't want to publicly mention a thing that's not properly dealt with in the official docs.

[Dunbaratu]

Hi again, I have another question. When I set a heading it's "compass heading + degrees above/below horizon", when I get a heading (to a target for example) it only returns the compass heading. Is there a way to also get the degrees above/below horizon?

What you want is to take the position vector that points from your ship to the other ship, and work out what is the angle between it and the horizon-plane.

And the way you do that is to first work out what is the angle between that position vector and the NORMAL TO your local horizon plane is (your ship's current UP vector is normal to its current horizon plane), and then subtract it from 90 to get the "other half" of that angle. (i.e. a vector that is pitched up 30 degrees from horizon will be pitched DOWN 60 degrees from straight up: 90 - 60 = 30. A vector that is pitched DOWN 30 degrees from horizon will be pitched down 120 degrees from straight up: 90 - 120 = -30.)

So that thinking gets you this final formula:

SET PitchToOtherFromMe TO 90 - VANG( OTHERSHIP:POSITION, SHIP:UP:VECTOR ).

Where "OTHERSHIP" is obviously the other vessel.

As a side note, I dislike the fact that Kevin chose to use the same vocabulary term to mean both a 3-D direction ( HEADING(a, ) and also 2-D direction projected onto the ground (TARGET:HEADING). Those really shouldn't have been the same term.

Edited December 19, 2014 by Steven Mading
disabling the *&%*(! smileys. I shouldn't have to use advanced mode to make the forum do LESS. Auto-smilieys should NOT on by default.

[Dunbaratu]

This has probably been suggested thousands of times but you should just scrap kerboscript and implement a custom version of lua instead.

I'm fully in favor of letting someone else *add* a second langauge that kOS can use, provided I don't have to be the one to implement the second one. Making the system able to use a second language would take a bit of work because those other languages would have to be able to compile into our made-up machine language as their compile target. Not impossible, but not a trivial task, and there's other bigger problems to deal with.

Most of the stuff that can be described as "a lot of the stuff that should work doesn't work" is not the fault of the kerboscript language. Not anymore. It used to be a horrible mess but it's been fixed up as far as I know. That is most of what I was working on since I joined the project was the parsing of kerboscript. The current problems are that once the script requests us to do a thing, the stuff that the C# code does WITH that request has bugs. You won't fix those sorts of bugs by swapping out the language. You will get other benefits, but fixing the current crop of bugs that still exist isn't one of them.

But I'm fully *against* getting RID of kerboscript to add Lua. But be warned, that most of the limitations aren't in the language but in the virtual machine we're running itself. You'd have a hard time implementing a full OOP system on top of the "machine language" instructions we have so far. But that system is designed to be expanded. Unlike with a real hardware computer, we can just effectively "re-burn" the "chip"'s microcode, so to speak, with each new release.

[erendrake]

This has probably been suggested thousands of times but you should just scrap kerboscript and implement a custom version of lua instead.

At the moment only half the stuff work, and a lot that should work doesn't work.

EDIT: To be clear im not doing autopilot stuff, im just trying to figure out if a target is selected or not, so nothing that should be affected by 0.90

All of the contributers would like to see additional languages supported in kOS. Right now we are more focused on getting more features into the mod and I know i do not currently have time to split off and build any other languages. If we were going to do that I would like to see javascript, haskell or lua.

you are of course welcome to send us a pull request with this feature

[VentZer0]

Ohhh man I *really* *really* want to mention some tools that exist already in the update but aren't documented that do exactly this. The only reason I haven't mentioned them is that the docs are currently frozen because someone is writing a re-do in a better document system and I didn't want to publicly mention a thing that's not properly dealt with in the official docs.

Well, I guess I have to wait for the update then ^^

[Camacha]

Ohhh man I *really* *really* want to mention some tools that exist already in the update but aren't documented that do exactly this. The only reason I haven't mentioned them is that the docs are currently frozen because someone is writing a re-do in a better document system and I didn't want to publicly mention a thing that's not properly dealt with in the official docs.

If you are suggesting that you addressed the reference frame in the same update you implemented user inputs I might have to book a couple of tickets to hug you and erendrake in person.

[Darren9]

What you want is to take the position vector that points from your ship to the other ship, and work out what is the angle between it and the horizon-plane.

And the way you do that is to first work out what is the angle between that position vector and the NORMAL TO your local horizon plane is (your ship's current UP vector is normal to its current horizon plane), and then subtract it from 90 to get the "other half" of that angle. (i.e. a vector that is pitched up 30 degrees from horizon will be pitched DOWN 60 degrees from straight up: 90 - 60 = 30. A vector that is pitched DOWN 30 degrees from horizon will be pitched down 120 degrees from straight up: 90 - 120 = -30.)

So that thinking gets you this final formula:

SET PitchToOtherFromMe TO 90 - VANG( OTHERSHIP:POSITION, SHIP:UP:VECTOR ).

Where "OTHERSHIP" is obviously the other vessel.

As a side note, I dislike the fact that Kevin chose to use the same vocabulary term to mean both a 3-D direction ( HEADING(a, ) and also 2-D direction projected onto the ground (TARGET:HEADING). Those really shouldn't have been the same term.

Thanks, that works perfectly. I think I agree with your side note, I was expecting them to be the same thing.

[VentZer0]

Hi again, I am running into a brick wall here, think I am to stupid to figure this out in an elegant way.

I have my autopilot do perform basic tasks already. Take off, climbing to desired altitude and holding it, speed control. Now what I want is to have my drone bank to the side, that is closest to the next waypoint, got that too I think.

But I want to have it turn to the direction of the waypoint I specified beforehand. The banking should stop as soon as the drone gets within 0.1° or 0.5° of the desired course from either way where it is banking from to the this new course.

Basically like this, take off 90° east, reaching waypoint 1, course change to 35° NE, plane banks to left and pitches up, now the pitch should end when the plane gets to < 35,5° and level off.

This is the code I have already, but I think there should be a much easier way to code this and certainly more elegant.

http://pastebin.com/raw.php?i=3byqg7sG

Tthis part in particular :

SET myCRS to SHIP:BEARING.
IF myCRS < 0 {
    IF myWP1 = 0 OR myWP1 < 0.5 {SET myBEARING to 0.5.}.
    IF myWP1 = 360 OR myWP1 > 359.5 {SET myBEARING to 0.5.}.
    IF myWP1 = 180 OR myWP1 > 179.5 {SET myBEARING to 179.5.}.
    IF myWP1 > 0.5 AND myWP1 < 90 {SET myBEARING to ().}.
}.
IF myCRS > 0 {
    IF myWP1 = 0 OR myWP1 < 0.5 {SET myBEARING to 0.5.}.
    IF myWP1 = 360 OR myWP1 > 359.5 {SET myBEARING to 0.5.}.
    IF myWP1 = 180 OR myWP1 > 179.5 {SET myBEARING to 179.5.}.
    WAIT UNTIL abs(SHIP:BEARING) < myBEARING.
}.

[Darren9]

Is it possible, from a kOS CPU on a non-player controlled ship to detect which of the other vessels is the player controlled one?

[Camacha]

Is it possible, from a kOS CPU on a non-player controlled ship to detect which of the other vessels is the player controlled one?

Not by design, but you could hack something together. Communication via the Archive is an old method, though you need to be within range. Maybe that something else could be devised too, through detected something that the player can influence.

Of course, the npc craft should all be within close range, otherwise the kOS unit will not run.

[MysticPing]

set t_info to list().
set finished to false.
set target to body("Kerbin").
until finished = true {
clearscreen.
if (target <> body("Kerbin")) {
print "Target Acquired".
print "----------------".
print "Target Distance: " + target:distance.
print "Target Heading: " + target:heading.
}.
else {
print "Please select a target".
}.
wait 0.1.
}.

print "Gathering Target Info...".

This is the code i have so far, all i'm trying to do is to check if there is a target selected or not, i have tried every kind of way i can imagine but it doesn't work. On this particular try even when i DO select a target it keeps doing

		print "Please select a target".

Any help would be approciated

[Camacha]

Where in the game are you when you try to do this?

[MysticPing]

I'm on the runway, and there is a target i'm selecting on the launchpad

[Dunbaratu]

I think I can guess what's happening.

set target to body("Kerbin").

[..cut..]

	if (target <> body("Kerbin")) { 

When you PRINT an object in kOS, it "stringifies" it. (People who program in C# or Java will be familiar with the concept of all objects having a toString() method that is activated when you try using it in a string context.)

What you see when you print it is a plain string, even if it is NOT REALLY a string.

So when you try the comparator "<>", it's not using it like a string and it's detecting that they are not equal because they are two different wrappers around the same body object.

TARGET is returning a wrapper object AROUND the body, and so is Body("Kerbin"). They are wrappers around the same body object, but the equality checker is only comparing the wrapper, not the body itself.

There are ways to fix this, and one of my future goals is to do a better job of making our kOS wrappers around the C# objects behave more *like* they were really the native object in the first place, in checking for equality and other similar things. (And, NO, this would not be fixed by using a different scripting language. The problem is in the way kOS wraps KSP C# objects inside its own C# objects, which is at a layer underneath the layer where they start being exposed to the scripting language.)

In the meantime, you can force them to be treated like strings instead by using this ugly trick: Append them to a nullstring - it's a cheap way to get a "cast" without really doing a cast.

So try this:

	if ( (""+target) <> (""+body("Kerbin")) ) { 

That will force both to spit out their stringified values, and then it's comparing the strings they spit out, not the objects.

We really should expose the ToString() to the higher level system and just let people call ToString themselves in scripts.

[MysticPing]

Thank you for the help! That kinda makes sense.

EDIT: it now says "Object Reference not set to an instance of an object" with a pointer to the '+' before target

Edited December 20, 2014 by MysticPing

[VentZer0]

Is there a way to read out the MechJeb Surface Info ? There is a Roll indicator, if I could read this out that would help me A LOT. I was able to fix my previous issues with the code I am writing, but I want to have a safeguard in place that prevent the plane from banking to hard or to soft in the direction of the next waypoint. My last efford was to check if I am ascending or decending on based on that data reduce or give more roll to that side, but that is only semi-working, if the attitude is not optimal the drone starts spiraling out of control.

EDIT, Thanks to the VECDRAW function I figured out some things, all I need is a VECTOR or DIRECTION that rotates with the craft, all Vectors and Directions I could find in the documentation either point in weird directions or do not rotate with the craft. If someone can tell me how to get this Direction or Vector that rotates with the craft, I'd be VERY HAPPY.

Edited December 22, 2014 by VentZer0

[Snoman314]

I can't find any mention of this - is anyone else having weird problems when either of the kOS parts are attached to their ships? Weird things like parts falling off on the launchpad, rockets exploding for no reason during ascent etc?