kOS Scriptable Autopilot System 0.9

[check]

So maybe it's something that I haven't noticed before and it's a problem with KSP in general... but what the heck is going on with longitude???

-447 degrees??

Does longitude just go stupid when you're in orbit?

[Dunbaratu]

And I don't know if it is already possible, but is it possible to determine the targeted steering value from the actual steering value? So I can start my engines as soon as the craft is aligned correctly, because it takes a bit of time to orient to the targeted vector.

I have the same problem - the first time I lock steering to BLAH, for any BLAH, The craft tumbles around for a while until it gets itself sorted out and then finally gets re-oriented to the direction I gave even when it was already pointed that way to begin with. (For example open the terminal window, lock SAS and launch straight up, kill SAS and type 'lock sterring to up.' in the terminal. Even though it's already pointed up, it tumbles around trying to find up, before settling on the right direction again.)

At the moment I just have a wait 10 seconds in the script to get the tumbling over with but that's not good enough for the general case. If we had access to the XYZ components of a vector, which Kevin said are in his plans for the future, and we had access to the craft's actual 3-D heading (not the 2-D ground heading in the HEADING variable) then we could perform a cross product or dot product of the heading with the desired vector to figure out if they're close or not. As they get closer to being lined up, the cross product should approach zero, or the dot product should approach the value of just multiplying the scalar magnitudes together.

Edited September 11, 2013 by Steven Mading

[Dunbaratu]

-447 degrees??

I've had this problem a LOT in KSP long before installing kOS. I think this is stock KSP's fault, not KOS. And I don't even have to be in orbit. Even landed craft often appear on the map view as having a longitude that's calculated the "wrong" way around the world, and sometimes is calculated going around more than once. Because of the cyclical nature of the polar coordinate system, these "wrong" values are technically right, in the sense that they are equivalent to the right value. (i.e. you'll find that the location of your -447 degrees is actually at the same place as the game at other times would report as -87 degrees (-447 + 360), so it's technically the right spot, just calculated wrapping around the world more than once for some odd reason. ).

[Metapher]

So iam going to mess around with kOS, but i still have some questions:

is there a inline "-help" or "-command" to list all commands or something?

and am i able to call (like dos-batch call) different scriptfiles inside another scriptfile?

like when my ascent-script is finished, i would like to call my transfer-script.

[Payload]

So iam going to mess around with kOS, but i still have some questions:

is there a inline "-help" or "-command" to list all commands or something?

and am i able to call (like dos-batch call) different scriptfiles inside another scriptfile?

like when my ascent-script is finished, i would like to call my transfer-script.

You can make calls to run other scripts. The issue is the first script will not close even if it is finished. That keeps any subsequent program from controlling steering or throttle. Still waiting on a solution to this.

Edited September 11, 2013 by Payload

[Dunbaratu]

(EDIT: Taking my own advice, I moved this bug report post over to the support forum and out of the showcase forum. )

See:

http://forum.kerbalspaceprogram.com/showthread.php/49603-kOS-0-5-Getting-same-rotation-on-two-different-axes-with-R%28%29

Edited September 11, 2013 by Steven Mading

[rhoark]

With FAR, rockets will tumble if bottom-heavy. Nothing to do with kOS.

[synik4l]

whats up with status = "landed" throwing errors?

[FaceDeer]

I have the same problem with reading status. I'm using "ALT:RADAR < 1" as a workaround for now (modify the number if your CoM is higher than that when landed, of course)

[Dunbaratu]

I have the same problem with reading status. I'm using "ALT:RADAR < 1" as a workaround for now (modify the number if your CoM is higher than that when landed, of course)

Warning: If over the sea: ALT:RADAR returns -1 at any height so this could screw things up if you pass over water - as soon as you're over water it will think you're already landed.

I use the following in my scripts:

set altAGL to alt:radar.

if altAGL < 0 { set altAGL to altitude. }.

(Use altAGL in place of alt:radar.)

[razark]

Warning: If over the sea: ALT:RADAR returns -1 at any height...

From what I've seen, it's reading off the bottom of the ocean. Close to shore you will get a positive reading, but once the sea floor falls off, it goes to -1. Either way, it's not a valid altitude, but if you're over water close to shore, your trick will fail. Just something to be aware of.

[dlrk]

Any chance of a radial version?

[kilman54]

This should work for radar in all cases.

set altAGL to alt:radar.

if altAGL < 0 or altitude < altAGL { set altAGL to altitude. }.

[KevinLaity]

Any chance of a radial version?

The stack version took me, frankly way too long for me to make.

I'm hoping someone will step forward to help me with modelling new parts.

Does a radial version make sense? Maybe for rovers...

EDIT: The part I did make even has some weird interactions with physics if it touches the ground directly, even though it's a simple cylinder!

[dlrk]

Kevin,

Even a radial version that shared an existing model would be fine. It could be put in an antenna, for example. The stack only fits small rockets, and can't really be 'bolted on' to a well-developed vehicle I just want to automate.

[razark]

Just add

MODULE
{
	name = kOSProcessor
}

to any part you want. I've added it to all the capsules and probe cores.

[Kalista]

Kevin,

Even a radial version that shared an existing model would be fine. It could be put in an antenna, for example. The stack only fits small rockets, and can't really be 'bolted on' to a well-developed vehicle I just want to automate.

2 other ways this can be done as well. Can be done like I'm currently doing and port over the module files from the .cfg to all your pods so you always have it. Second and less invasive way would be to add in a module manager cfg and have it port over the files to all your command pods ( could also do it for the popular mods like b9 and firespitter if you wanted to go that far) so me personally feel that another part for it is time that could be better used elsewhere.

[Dunbaratu]

Is there any chance you'd be willing to alter the definition for all the spaces in the language so they accept runs of 1 or more spaces instead of just exactly 1 space?

So in other words trying to write code like this:

set eastVal  to   5.
set upVal    to  40.
set northVal to 100.

Currently gives a syntax error because of the extra spaces before "to" and the extra spaces before the values. It would be nice if it was possible for people to write code that lines up in columns as shown in the example there. Most languages are structured so that a run of consecutive spaces is the same thing as just a single space as far as the grammar cares.

I was peeking at the regular expressions in your GitHub code, and see that this expectation of exactly one space, nor more, no less, exists in many places, not just the 'set' command. If it's your goal to make the language as beginner-friendly as possible it might be a good idea to change those all to runs of 1 or more whitespaces. (i.e. replace the single spaces in the regular expressions with space-space-asterisk.) A beginner will be very confused as to why "set x to 2." fails when "set x to 2." works.

Edited September 12, 2013 by Steven Mading

[Gaius]

Better yet, use "\s+" to match one or more of any whitespace character.

[Dunbaratu]

Better yet, use "\s+" to match 1 or more of any whitespace character.

True, but most of my programming experience has been in UNIX, so I'm not that familiar with C#. I didn't know which variant of regular expressions are in use by the code. There's zillions of implementations and not all of them have all the same things implemented. So I kept my example down to the simple "space-space-asterisk" because that I know at least universally works in all of them. If better whitespace matches are available then by all means use them.

[Gaius]

Good point -- I'm honestly not sure how robust the regex parser in C# is. Being able to use tabs as whitespace is a desirable feature, though.

[Payload]

Warning: If over the sea: ALT:RADAR returns -1 at any height so this could screw things up if you pass over water - as soon as you're over water it will think you're already landed.

I use the following in my scripts:

set altAGL to alt:radar.

if altAGL < 0 { set altAGL to altitude. }.

(Use altAGL in place of alt:radar.)

HAHA guess who found that out the hard way? This guy<=======.

I said your landed if you alt:radar is less than 3 bro. Floated out over the water testing hover script. Kills Jeb for 100billionth time.

[xZise]

Better yet, use "\s+" to match one or more of any whitespace character.

But don't remove spaces in quotes/strings I don't know how the parser works so maybe the strings get sorted out first and then you can remove all spaces which are to much.

I have the same problem - the first time I lock steering to BLAH, for any BLAH, The craft tumbles around for a while until it gets itself sorted out and then finally gets re-oriented to the direction I gave even when it was already pointed that way to begin with. (For example open the terminal window, lock SAS and launch straight up, kill SAS and type 'lock sterring to up.' in the terminal. Even though it's already pointed up, it tumbles around trying to find up, before settling on the right direction again.)

At the moment I just have a wait 10 seconds in the script to get the tumbling over with but that's not good enough for the general case. If we had access to the XYZ components of a vector, which Kevin said are in his plans for the future, and we had access to the craft's actual 3-D heading (not the 2-D ground heading in the HEADING variable) then we could perform a cross product or dot product of the heading with the desired vector to figure out if they're close or not. As they get closer to being lined up, the cross product should approach zero, or the dot product should approach the value of just multiplying the scalar magnitudes together.

I have to check if, but maybe it is possible when you "buffer" the variable:

LOCK target_steer TO prograde.
LOCK steering TO target_steer.

IF ABS(target_steer:pitch - steering:pitch) < 2 AND ABS(target_steer:yaw - steering:yaw) < 2 {
  print "Aligned!".
}.

So maybe it's something that I haven't noticed before and it's a problem with KSP in general... but what the heck is going on with longitude???

[…snip…]

-447 degrees??

Does longitude just go stupid when you're in orbit?

I personally would say stuff like this should be reported there: https://github.com/Nivekk/KOS/issues As it seems it is KSP's failure but I don't see why kOS simply but it into a (-360;+360) or [0;+360) interval prior to giving it to your script.

Fabian

[Dunbaratu]

I have to check if, but maybe it is possible when you "buffer" the variable:

LOCK target_steer TO prograde.
LOCK steering TO target_steer.

IF ABS(target_steer:pitch - steering:pitch) < 2 AND ABS(target_steer:yaw - steering:yaw) < 2 {
  print "Aligned!".
}.

The problem is that for all intents and purposes, "steering" appears to be a write-only variable. You can "LOCK steering to BLAH" but you can't "PRINT steering".

[CoriW]

Hello, so I've been having a problem recently with a script, every time try to run it my KSP will crash and I have to use the task manager to end the process. Pretty much what I'm trying to do with the script is make something that will give me basic heading control for prograde, retrograde, normal +, normal -, radial +, and radial -.

I've looked over the script many times but just can't seem to figure out what's wrong with it.

SET V TO 0.

ON AG5 SET V TO V + 1.

IF V = 0
{
	UNLOCK ALL.
	PRINT "NO VECTOR".
}.
IF V = 1
{
	LOCK STEERING TO PROGRADE.
	PRINT "PROGRADE".
}.
IF V = 2
{
	LOCK STEERING TO RETROGRADE.
	PRINT "RETROGRADE.
}.
IF V = 3
{
	LOCK STEERING TO PROGRADE + V(1,0,0).
	PRINT "NORMAL +".
}.
IF V = 4
{
	LOCK STEERING TO PROGRADE + V(-1,0,0).
	PRINT "NORMAL -".
}.
IF V = 5
{
	LOCK STEERING TO PROGRADE + V(0,1,0).
	PRINT "RADIAL +".
}.
IF V = 6
{
	LOCK STEERING TO PROGRADE + V(0,-1,0).
	PRINT "RADIAL -".
}.
IF V = 7
{
    SET V TO 0.
}.

EDIT: It also doesn't seem to help that I don't think I actually understand V(X,X,X).

Edited September 12, 2013 by CoriW