kOS Scriptable Autopilot System 0.9

[Dunbaratu]

Has anyone figured out how velocity:surface reports while on the mun? The method I'm using for kerbin gives nonsensical results, even though it appears to work perfectly on kerbin. It fits best on the mun if you assume that 144 should be added to the longitude, but that doesn't work quite correctly. The surface velocity code is shown below, can anyone spot any errors?

set lat to latitude.
set lon to longitude.
set vs to velocity:surface .

//calculate surface velocity in terms of unit vectors east, north, and up
set ve to vs:z * sin(lon) + vs:x * cos( lon ) .
set vu to vs:z * cos(lon)*cos(lat) - ( vs:x * sin(lon)*cos(lat) + vs:y*sin(lat) ) .
set vn to vs:z * cos(lon)*sin(lat) + vs:y*cos(lat) - vs:x * sin(lon)*sin(lat) .

There is a bug on github about something being broken with the velocity vector, and unfortunately it's broken as far back as 0.7 as well.

The thing that's broken about it is this: you can print the velocity vector and it shows all three parts just fine like so:

V(123,456,789).

But if you try to obtain a single component of it like so:

print velocity:x

It says:

NULL.

So something is wrong with KOS and the XYZ parts of velocity. I don't know why.

[check]

Has anyone figured out how velocity:surface reports while on the mun? The method I'm using for kerbin gives nonsensical results, even though it appears to work perfectly on kerbin. It fits best on the mun if you assume that 144 should be added to the longitude, but that doesn't work quite correctly. The surface velocity code is shown below, can anyone spot any errors?

Read through this: http://kos.wikia.com/wiki/Tutorial_-_XYZ_system_of_KSP

It explains the XYZ coordinate system in KSP. It's bizarre but apparently necessary to reduce errors.

[Dunbaratu]

Read through this: http://kos.wikia.com/wiki/Tutorial_-_XYZ_system_of_KSP

It explains the XYZ coordinate system in KSP. It's bizarre but apparently necessary to reduce errors.

But in this case there's also the secondary problem that trying to use the :x, :y, and :z operators on the velocity vector is bugged. So even if you know the coordinate system it still won't mean the code will run right.

[masTerTorch]

Just tried to write a little transfer script from LKO to Mun.

Print "Transfer to Mun..".
set b to 0.
set z to 0.
set c to 0.
clearscreen.
print "Looking for Encounter" at (20,15).
until encounter="Mun"{
print c.
if z=5{
set b to 0.
set z to 0.
}
set time2 to time+45.
set x to node(time2,0,0,850+.
add x.
if encounter = "None"{
remove nextnode.
set b to b+10.
set z to z+1.}
set c to c+1.
}

The Until loop will not stop when the first Mun encounter was found. Break this with ctrl+c, else wise you get lots of encounters.

Print "Transfer to Mun..".
set b to 0.
set z to 0.
set c to 0.
clearscreen.
print "Looking for Encounter" at (20,15).
until 0{
if encounter="Mun"{break.}
print c.
if z=5{
set b to 0.
set z to 0.
}
set time2 to time+45.
set x to node(time2,0,0,850+.
add x.
if encounter = "None"{
remove nextnode.
set b to b+10.
set z to z+1.}
set c to c+1.
}

with a never ending loop and an if-break statement it will work. Any thoughts on this?

[check]

Any thoughts on this?

Seems like it could work. Might be a bit slow to find an enounter though. You are missing a few periods at the end of some of your }s though. That could be mucking up your script. I've made the corrections:

Print "Transfer to Mun..".
set b to 0.
set z to 0.
set c to 0.
clearscreen.
print "Looking for Encounter" at (20,15).
until 0{
if encounter="Mun"{break.}.
print c.
if z=5{
set b to 0.
set z to 0.
}.
set time2 to time+45.
set x to node(time2,0,0,850+.
add x.
if encounter = "None"{
remove nextnode.
set b to b+10.
set z to z+1.}.
set c to c+1.
}.

[masTerTorch]

Seems like it could work. Might be a bit slow to find an enounter though. You are missing a few periods at the end of some of your }s though. That could be mucking up your script. I've made the corrections:

Hey check,

thanks for looking into this. Periods at the end of { aren´t necessary anymore. So I neglected them. The Problem I wanted to refer to is that having the condition

encounter="Mun"

in the until command won´t work (1st code). A work around is the if command with break (2nd code).

That seems to be a bug.

cheers

[check]

Seems like it could work. Might be a bit slow to find an enounter though. You are missing a few periods at the end of some of your }s though. That could be mucking up your script. I've made the corrections:

Hey check,

thanks for looking into this. Periods at the end of { aren´t necessary anymore. So I neglected them. The Problem I wanted to refer to is that having the condition

encounter="Mun"

in the until command won´t work (1st code). A work around is the if command with break (2nd code).

That seems to be a bug.

cheers

Oh, you don't need periods after } anymore? News to me. Excellent.

Yes, I've actually encountered the exact same problem with the until loop. I had UNTIL x : DISTANCE < 3000 { etc... and found that the first time I ran it, it would just chug along past when it was supposed to break from the loop. I did the same thing you did, ctrl+c and ran it again and it worked. Always works the second time, never the first.

What version of kOS are you using?

[Payload]

Seems like it could work. Might be a bit slow to find an enounter though. You are missing a few periods at the end of some of your }s though. That could be mucking up your script. I've made the corrections:

Hey check,

thanks for looking into this. Periods at the end of { aren´t necessary anymore. So I neglected them. The Problem I wanted to refer to is that having the condition

encounter="Mun"

in the until command won´t work (1st code). A work around is the if command with break (2nd code).

That seems to be a bug.

cheers

In my testing of ver .71,

Until can't be used with AND/OR or "STRING" operators.

If and When then both work with AND/OR.

And If is the only thing that works with "STRING".

Examples:

If works with all of the above operators.

This works.

set Goflag to 0.
Until Goflag = 1
 { if status = "LANDED" { set Goflag to 1. }. }.

This works.

when x =1 AND/OR y = 1 then
 { do these things. }.

Doesn't work.

Until status = "LANDED"
 { do these things. }.

Doesn't work.

when status = "LANDED" then
 { do these things. }.

Doesn't work.

until x = 1 AND/OR y = 2
 { do these things. }.

In ver .84.

Even with me masking the eta:apoapsis with a variable to get around that issue, it still errors on my scripts somewhere with no line error. It just shuts down. So I have stuck with .71 for now.

Edited October 11, 2013 by Payload

[Sma]

You mean: There was probably some problem at some point with something somewhere.

A bug description, that fits everywhere.

Lol exactly

Just tried to write a little transfer script from LKO to Mun.

...code was here...

The Until loop will not stop when the first Mun encounter was found. Break this with ctrl+c, else wise you get lots of encounters.

...Code was here...

with a never ending loop and an if-break statement it will work. Any thoughts on this?

Using until encounter="Mun" maybe you could also try setting a flag like having an if statement that sets a flag, maybe something like this

Print "Transfer to Mun..".
set b to 0.
set z to 0.
set c to 0.
clearscreen.
print "Looking for Encounter" at (20,15).
until encounter="Mun" or [B]foundEncounter = 1[/B] {
print c.
if z=5{
set b to 0.
set z to 0.
}
set time2 to time+45.
set x to node(time2,0,0,850+.
add x.

[B]if encounter = "Mun" {set foundEncounter to 1.}[/B]

if encounter = "None"{
remove nextnode.
set b to b+10.
set z to z+1.}
set c to c+1.
}

No idea if that'll fix the problem or not. Hopefully with the next update this won't be a problem, we can hope.

Edited October 11, 2013 by Sma

[Kaa253]

I am sorry if this has been asked before but after reading about 50 pages of this post and searching inside it cannot find an answer. I have just started trying this out and it is very cool however... I thought it let you keep a ship under control as long as you stayed focussed on something within the unloading range (default ~2.2 kms). The first video shows two ships flying together. I find that as soon as I switch to another ship the first one just goes engine cutoff. I am testing with a very simple script basically the same as the launch script in the video.

Did the ability to control one ship while focussed on another break with a version update of kOS or KSP?

[Payload]

This is what you get when Jeb writes your landing computer.

[Sma]

This is what you get when Jeb writes your landing computer.

Nice, but what is flyingbital? When I've had things like that i usually just have a line to print spaces whatever length is needed to clear the line.

Also, how about those high g's? what engine is that? lol

[masTerTorch]

Oh, you don't need periods after } anymore? News to me. Excellent.

Yes, I've actually encountered the exact same problem with the until loop. I had UNTIL x : DISTANCE < 3000 { etc... and found that the first time I ran it, it would just chug along past when it was supposed to break from the loop. I did the same thing you did, ctrl+c and ran it again and it worked. Always works the second time, never the first.

What version of kOS are you using?

I am using 0.84. Strings won´t work in until loops.

In my testing of ver .71,

Until can't be used with AND/OR or "STRING" operators.

If and When then both work with AND/OR.

And If is the only thing that works with "STRING".

Examples:

If works with all of the above operators.

Can confirm that strings seems to be buggy. Haven´t tried when yet.

until body="Mun"{print 1.} 

Is not working.

Using until encounter="Mun" maybe you could also try setting a flag like having an if statement that sets a flag, maybe something like this

No idea if that'll fix the problem or not. Hopefully with the next update this won't be a problem, we can hope.

Using flags for ending loops for now till it is fixed. Hope that it is fixed soon^TM.

New Bug:

I having problems with the exp function. In 0.71 it worked well. In 0.84 it seems to be broken.

 print e^1.

Gives "unrecognized term: e".

Anyone with 0.84 can confirm this one?

Also would love to see a way for targeting bodies. For transfer scripts we need to calculate phase angles and ejection angles. Also it would be awesome to have access to the ISP values of engines that are activated.

Edited October 11, 2013 by masTerTorch

[Kalista]

Another thing:

Sometimes parts which are on top of the kos unit will disappear. Updated to 0.84 today. This probe was launched with 0.71. Parts disappeared before update. Haven´t experienced disapearing parts since update. But will watch out for this.

I just had this bug happen to me while testing a landing program on the Mun. Only differences is I'm still using 0.71 and its everything below my probe core that vanished ( using kos off my probe cores rather than the dedicated part) same nul references and everything that steve got as well.

[doubleg]

Lol exactly

Using until encounter="Mun" maybe you could also try setting a flag like having an if statement that sets a flag, maybe something like this

Print "Transfer to Mun..".
set b to 0.
set z to 0.
set c to 0.
clearscreen.
print "Looking for Encounter" at (20,15).
until encounter="Mun" or [B]foundEncounter = 1[/B] {
print c.
if z=5{
set b to 0.
set z to 0.
}
set time2 to time+45.
set x to node(time2,0,0,850+.
add x.

[B]if encounter = "Mun" {set foundEncounter to 1.}[/B]

if encounter = "None"{
remove nextnode.
set b to b+10.
set z to z+1.}
set c to c+1.
}

No idea if that'll fix the problem or not. Hopefully with the next update this won't be a problem, we can hope.

I think that should work, but if it doesn't Here's the first portion of my encounter finding script (the second half is refining the encounter) I know using a break statement like this works.

set x to 1.
declare parameter delta.

add node(time + x, 0, 0, 870).
//Added so there will be a node to remove in first loop.

until encounter = "Mun" {
	remove nextnode.
	add node(time + x, 0, 0, delta).
	if encounter = "Mun" {break.}.
	set x to x + 5.
}.

[ettieapple]

Is it possible to control other ships throttle, direction etc.?

[aNewHope]

Is it possible to control other ships throttle, direction etc.?

Any ship can only be controlled by a kOS unit that is directly attached to it.

[Secret Squirrel]

Any ship can only be controlled by a kOS unit that is directly attached to it.

TT never unload. You can attach a kOS part to the upper stage, launch, release upper stage have it continue to a stable orbit using the kOS script and switch to lower stage to land it, If that's what your asking.

EDIT: Sorry quoted the wrong post this morning just realized it

Edited October 12, 2013 by Secret Squirrel

[ettieapple]

What I want is, for example, make one ship a command ship, wich controls other ships around him (also, with only having to type "run program" once). Or starting a ships program immediatly when my ship is getting close to it, without having to manually activate the ship's program.

[Kaa253]

Is it possible to control other ships throttle, direction etc.?

I asked a similar question yesterday as I was having trouble doing this. After much testing for possible problems with other mods, it seems my problem happens because I added the MechJebCore module statement to the part.cfg of all my pods. This seems to cause all control to be lost the instant the ship loses the focus. By this I mean all vanilla KSP control (except SAS it seems), not just MechJeb control. I am still investigating but it looks like I am going back to using the AR202 part because of this. Obviously this is not being caused by kOS but it is causing unexpected behaviour when using kOS. I can only report this effect, I have no clue as to why adding MechJeb to the part.cfg should be behaving differently to slapping an AR202 part on the outside of the command pod.

Nope: Ignore all the above. No idea.

Edited October 12, 2013 by Kaa253
still trying to make sense of it.

[rhoark]

It could be done, but somewhat unwieldy: have one ship write a log file to archive, and the other ship run it.

[ettieapple]

But then I still have to order the ships to run that log file manually, right?

[rhoark]

It could run a program that continually attempts to run another program that you write to.

[ettieapple]

I'm sorry, but could you be more specific?

[Bizz Keryear]

I'm sorry, but could you be more specific?

ship 1

switch to 0.
// eventually use a loop here
set a to "set ralt to "+ALT:RADAR.
delete rmh from 0.
log a to rmh.
//potential loop end

ship 2

set x to 0.
switch to 0.
util x=1 {
  run rmh. //it reads in the variable ralt which can now accessed.
  //e.g:
  if ralt = 120000 {
     //do something .. launch script or whatever
  }.
  //rest of script here
  //
  //example 2
  print "Craft 2 altitude: "+ralt.
  //more script
}.

Eventually you need a mod named "never unload" which keeps craft in ram and let ksp execute them like ones close by.