kOS Scriptable Autopilot System 0.9

[Camacha]

Is it too hard to get isp, like we get maxthrust? that would be a pretty nice addition, also dry and/or fuel mass would be wonderful! KER and MJ have that info already!

I don't know. I really like to use maxthrust, but at the same time I realize it is not something you can realistically query in a real craft. That is even more the case with mass, which is impossible to accurately measure in flight. Yet with kOS it is possible.

I would like things like (individual) engine thrust, which can be realistically measured, along with individual engine control. That way you can write your own stabilisation control instead of just locking yourself to a heading.

[nothke]

how to check if RCS or SAS are NOT on?

"if SAS" works, but there is no negation.. "SAS = OFF" "!SAS" "NOT SAS" "SAS = 0" doesn't work...

Or do I need to set an int variable to do this (as I am doing right now)?

Also how to check when the gear has completed retracting / extending?

Edited November 25, 2013 by nothke

[Camacha]

how to check if RCS or SAS are NOT on?

"if SAS" works, but there is no negation.. "SAS = OFF" "!SAS" "NOT SAS" "SAS = 0" doesn't work...

This works:

If sas = "False" {print "SAS is not on".}.

Also how to check when the gear has completed retracting / extending?

I do not think you can check whether it is done retracting or extending. As soon as the command to extend/retract is given, the boolean will return True/False as if it was already done. The best solution would probably be to wait the time it takes to extend or retract.

[foma87]

Hi there. This is my first post. I´ve been a long time stalker on these forums and basically just registered because of KOS. I´d like to say that this is an incredible mod. Thanks for all the work!

Now I´m not sure if this is the right thread for it, since I don`t know if the problem I encounter with my script is a mathematical one or a bug in the mod. Anyway, since I´ve already started, I might as well just state my problem:

What I am trying to achieve is have a readout of the angle between 2 bodies orbiting the same body. I took Kerbin, a satellite in Kerbin orbit and the Mun as an example. This is basically what it looks like (excuse my paint):

The angle needed is γ. Now in order to get γ basic triangulation is used in the form of this formula, since the length of the sides of the triangle are known:

This is what it looks like when scripted:

//Altitude of the Satellite

set a to altitude.

//Altitude of the Mun

set b to 11400000.

//Distance between Satellite and Mun

set c to target:distance.

//Triangulation formula

set d to (b^2+a^2-c^2)/(2*a*.

set phi to arccos(d).

//Angle readout

print "phi".

Note: Explanations were added in this script. Additionally the original script loops this procedure.

The problem is, the "phi"-readouts are often NaN° (I´d be very thankful if anyone could explain this expression to me). Sometimes I get correct angle readouts (compared with VOIDmod current phase angles), and sometimes I get NaN°. Specifically when γ gets wide (from my impression I´d say when γ>120°). I say impression, because I haven`t found it to be always at the same degree.

I would like to ask if anyone else has tried using this method to calculate angles or knows any other method for getting precise angles, or if I completely messed up the approach to this problem. The angle would be used to compare the optimal ejection angle with the current phase angle, in order to script the transfer burn at exactly the right place. Would be much appreciated.

[nothke]

This works:

If sas = "False" {print "SAS is not on".}.

I do not think you can check whether it is done retracting or extending. As soon as the command to extend/retract is given, the boolean will return True/False as if it was already done. The best solution would probably be to wait the time it takes to extend or retract.

Thanks! It would be useful to add the SAS = "False" to the wiki.

[Sma]

Thanks! It would be useful to add the SAS = "False" to the wiki.

Maybe I just don't get it but why would you need to know if it was off or on? Other than for printing it to a script. You could always just set sas to off so then you know it's off and go from there. Me personally at the start of my launch script I set it to on, launch, wait until about 500m or 1000 meter then use my lock steering command of choice, and turn SAS off. When using lock steering there is really no need for SAS to be on and I've noticed in most cases having it on won't allow the lock steering command to work.

I can see more of a need to know the state of the gears though, although I don't know that it would actually return properly. Say if the gear took 10 seconds to deploy/retract, and you polled with in that 10 seconds, in my thinking it'd reply that it was in whatever state you asked about just because it's basically a boolean (off/on). Might be best, if you have something thats dependent on the gears being deployed/retracted (like a hover script waiting to land), to count how long it takes to deploy, then just issue a wait statement for however long it takes, plus maybe a second or two before continuing to descend.

[Dunbaratu]

What I am trying to achieve is have a readout of the angle between 2 bodies orbiting the same body. I took Kerbin, a satellite in Kerbin orbit and the Mun as an example. This is basically what it looks like (excuse my paint):

I see a few potential problems:

1 - You mention that the Mun's altitude is the length of line B. It is not. Altitude is the distance to the parent body's SURFACE, not to it's CENTER. TO get the distance of B you have to add Mun:Altitude to Kerbin's radius. (which is 600,000). The same is true for the length of A - you need to add your altitude to Kerbin's radius.

2 - Be aware that there is an annoying discrepency in the frame of referenced for reported numbers. A body's POSITION is given relative to your craft, but a body's VELOCITY is given relative to the body your craft is orbiting. I don't know why they're different, but as long as you are aware of it you can translate between the two frames of reference easily enough once you know your own position relative to the parent body, and if you transform your UP direction into a unit vector using tfDirToUnitV here: http://kos.wikia.com/wiki/Tutorial_with_example_-_Conversion_from_Directions_to_XYZs (once you turn your UP direction into a unit vector, if you multiply it by the scalar (body's radius + my altitude), you get your position relative to the parent body. So with that you can add that vector to the Moon's position relative to you, to get its position relative to the parent body.

The problem is, the "phi"-readouts are often NaN° (I´d be very thankful if anyone could explain this expression to me).

Without giving all the ugly details of how floating point numbers are stored in binary form, suffice it to say that there are some bit patterns that are invalid and don't really map to anything real. These patterns are used deliberately to store the fact that a numerical result is "impossible" or "infinite".

When KoS returns "Inf" for a number, it means "You tried dividing by zero". (Yes, I know dividing by zero doesn't *always* mean it's a phenomenon that approaches infinity, but computer numbers tend to assume it does.)

When kOS returns "NaN" for a number, it's an acronym that means, literally, "Not a Number". That might sound like something Kevin made up, but it's not. That's been a longstanding well known acronym in computer programming languages. NaN is used for situations where the resulting number is mathematically not possible to represent as a real number at all. Examples include:

- Trying to take the square root of a negative number returns NaN.

- Trying to use inverse trig functions like arccos on a value that cannot possibly be a cosine.

"NaN' is probably coming from your arccos. The value inside the expression is probably less than -1 or larger than +1 so there's no such angle which would have that cosine.

Edited November 26, 2013 by Steven Mading

[Dunbaratu]

This works:

If sas = "False" {print "SAS is not on".}.

In general the lack of an "else", combined with the lack of a "not" operator, makes some things a lot messier than they need to be.

[Camacha]

I can see more of a need to know the state of the gears though, although I don't know that it would actually return properly. Say if the gear took 10 seconds to deploy/retract, and you polled with in that 10 seconds, in my thinking it'd reply that it was in whatever state you asked about just because it's basically a boolean (off/on).

I tested it earlier this evening (see post above) and I just tested it again. I just noticed some behaviour that might come in handy:

- Gears will report whatever status was requested. As soon as you tell kOS gears on, it will report True, even when still deploying. The same goes for retraction; as soon as you give the command gears off it will report False, even when still retracting.

- Legs will report True only when fully deployed. When deploying or retracting legs will report False. When you ask about legs through the gears command however, they report like gears would.

Might be best, if you have something thats dependent on the gears being deployed/retracted (like a hover script waiting to land), to count how long it takes to deploy, then just issue a wait statement for however long it takes, plus maybe a second or two before continuing to descend.

I feel the nicest way to do this is to detect whether the gears are down or not. If not, deploy and wait. If so, go ahead with the program. Please note that this code will also wait when no legs are present. You can check for that by checking the status again. If it is still False, no legs were present.

That last bit is also the reason that polling for leg deployment instead of having a fixed count is probably not a good idea; when you wait for the legs to fully deploy and return True but no legs are on the craft, the program will get stuck in that loop.

if legs = "False" {legs on. wait 3.}.

In general the lack of an "else", combined with the lack of a "not" operator, makes some things a lot messier than they need to be.

I consider it a charming clunkiness for now. Pretty much everything is possible, you just need to get a little creative. We wouldn't want the coders to get lazy

[Camacha]

NaN is used for situations where the resulting number is mathematically not possible to represent as a real number at all. Examples include:

NaN also appears when a sensor is not turned on and in similar situations.

[Dunbaratu]

NaN also appears when a sensor is not turned on and in similar situations.

Useful to know.

I wasn't answering the "what does it mean in KOS" sort of question but more the "what does the acronym NaN mean" question in the general sense. The fact that kOS was designed to overload the meaning of NaN by also using it for disabled sensors (which makes sense and I didn't know that, thanks for the heads up) is sort of another layer on top of the question of just "I've never seen 'NaN' before what does it mean?".

But without an isNaN() check being implemented, returning NaN to the user isn't a very useful way to report that the sensor is turned off. Your script code can't respond to the condition because NaN doesn't work like normal numbers and you can't just put it in an expression like:

if value = NaN { ... do something ... }.

(And according to the IEEE standards, you're not *supposed* to be able to do that with a NaN. Languages are meant to provide some sort of a function call or macro syntax that lets you check it by saying isNaN( value ), apparently because there are multiple binary representations that all mean NaN so it's possible for one NaN to not equal another NaN if you just check them the raw way.)

[Camacha]

But without an isNaN() check being implemented, returning NaN to the user isn't a very useful way to report that the sensor is turned off. Your script code can't respond to the condition because NaN doesn't work like normal numbers and you can't just put it in an expression like:

if value = NaN { ... do something ... }.

Actually, you can do that. I have been using that on my Negative Gravioli Detector, since I always forget to turn it on. I like my craft to check as much as possible for themselves - that mitigates user error (and I am quite an erroneous user ). I use it in combination with Sensor Reporter, but I am sure the method can be used in other situations where I have seen NaN appear too.

if sensor!grav() = "NaN" {set x to sensor!grav!toggle().}.

Sensors are turned on in a peculiar way.

Edited November 26, 2013 by Camacha

[Dunbaratu]

Actually, you can do that. I have been using that on my Negative Gravioli Detector, since I always forget to turn it on. I like my craft to check as much as possible for themselves - that mitigates user error (and I am quite an erroneous user ). I use it in combination with Sensor Reporter, but I am sure the method can be used in other situations where I have seen NaN appear too.

Ah, I see. So when it says NaN for a number it is in fact casting it to a string so you can check against the literal "NaN". But why doesn't it complain about comparing a number to a string when sensor!grav() is a real number and not NaN?

[AeroEngy]

Hello kOS uber users. I just found this mod and so far so good. I was able to cobble together a PI throttle controller which holds my craft to within around 5/ms of terminal velocity (until the atmosphere thins out) and puts me in a decent circular orbit.

Anyway, I am trying to figure out this coordinate system when looking at various bodies bodyName:position and bodyName:body:position vectors. I don't really fully understand the difference and hope someone here can shed some light on what these represent, what is the origin for each is, etc. I read through the Wiki ... but couldn't find any information about these parameters. I know the origin moves around based on SOI and other factors but don't know how these are built in vectors for each body are handled. Actually it was shear luck that I stumbled upon these at all since I found no documentation regarding them.

I thought that maybe Duna:position was the position vector from my craft (in 100km orbit) to Duna for example. IF so where do the unit vectors along x, y, and z point (NED or something else)?

Similarly, I guessed that maybe Duna:body:positon was Duna's position vector from its parent Kerbol. However, when querying the magnitude of the vector it was larger than Duna's apoapsis ... which didn't make any sense. Also the Z direction was larger than I expected since I guessed that z was maybe perpendicular to orbital plane. My goal here is to define the position vector of Kerbin (Kerbin:body:position ???) and another planet like Duna relative to Kerbol. Then use the vector's to calculate the phase angle via dot product or 2-D arctans as an estimate.

I am guessing its not that simple or others would have done it already. Any help shedding some light would be appreciated.

[Dunbaratu]

Anyway, I am trying to figure out this coordinate system when looking at various bodies bodyName:position and bodyName:body:position vectors. I don't really fully understand the difference and hope someone here can shed some light on what these represent, what is the origin for each is, etc. I read through the Wiki ... but couldn't find any information about these parameters.

They're relatively recent and I'm thinking of overhauling the wiki page on XYZ coordinate system to talk about them.

One exceedingly annoying "feature" about them is that the origin of the coordinate system for a body's POSITION and the origin of the coordinate system for a body's VELOCITY are not the same. Since velocity and position are directly connected to each other, having them reported in different coordinate systems so you constantly have to shift the origin when using them together is really messy.

A body's VELOCITY is given in a coordinate system relative to your parent body you are currently orbiting.

BUT, a body's POSITION is given in a coordinate system relative to your craft's position as origin, NOT the body your craft is orbiting.

So for example if you are orbiting Kerbin, then Mun:POSITION is the position vector from YOU to the Mun. while Mun:VELOCITY is the velocity vector of the Mun relative to Kerbin, not relative to YOU.

To prove this get into an orbit around Kerbin and keep printing both Mun:POSITION:MAG and Mun:VELOCITY:MAG. as you orbit. As you change position and velocity going around Kerbin, Mun:POSITION is smaller when you're on the side of Kerbin closest to it, and it gets bigger when you're on the side of Kerbin facing away from it. BUT, Mun:Velocity is only changing by a tiny amount as it slowly orbits Kerbin, while if it was based on being relative to you like the position was, it should be giving drastically different numbers when you're flying toward, away from, or perpendicular to it as you orbit around Kerbin.

I'm not sure if this is KOS doing this or if this is just KOS exposing a weirdness about the underlying KSP C# API.

It's workable as it is, as long as you know this fact, as you can always adjust between the two frames of reference because you can get your position relative to the body you orbit, but it's really odd that you have to make the adjustment because the system is being inconsistent with itself.

[AeroEngy]

They're relatively recent and I'm thinking of overhauling the wiki page on XYZ coordinate system to talk about them.

BUT, a body's POSITION is given in a coordinate system relative to your craft's position as origin, NOT the body your craft is orbiting.

So for example if you are orbiting Kerbin, then Mun:POSITION is the position vector from YOU to the Mun.

I double checked this with my DUNA:POSITION vector's magnitude when duna and kerbin were more or less aligned got a magnitude of ~6.0x10^9 which seems about right for the distance between their orbits. However, I am still a bit confused as the actual vector was V(3.5*10^9, -1.2x10^7,-5.1x10^9). So what does the x, y, and z components of that vector represent? I thought maybe one of them was UP and the reference was rotating or something ... but I let my craft orbit to the other side of Kerbin so UP was in a new direction ... but the vector looked similar (no sign flips).

You didn't mention the bodyName:BODY:POSITION vector. While I was orbiting Kerbin I got the magnitude of both Kerbin:BODY:POSITION and DUNA:BODY:POSITION. Both vectors looked almost the same with magnitudes of 1.36x10^10 [V(-7.4x10^9, -1.0x10^3, 1.1x10^10)] ... which made me guess this is my craft's position with respect to Kerbol. So it seems that the NAME:BODY:POSITION vector is the same for each named body ... is this correct?? And if so ... again which direction are the components of the position vector pointing. Y is above the orbital plane? x and z are pointing to some fixed point or arbitrarily set at loading ?

Thanks,

[Dunbaratu]

You didn't mention the bodyName:BODY:POSITION vector. While I was orbiting Kerbin I got the magnitude of both Kerbin:BODY:POSITION and DUNA:BODY:POSITION.

That makes sense, because Kerbin:BODY and Duna:BODY are two different ways to refer to the same object - the Sun.

The special keywords Kerbin and Duna already *are* objects of type BODY. You probably should have just typed Kerbin:POSITION and Duna:POSITION.

Each object of type BODY has a property, also called BODY, which is referring to the parent body that body orbits (this is a holdover from the fact that when you type just BODY, it refers to the thing your craft orbits. I'd have preferred a less confusing term like "PARENTBODY".)

So when you said Kerbin:BODY you ended up referring not to Kerbin, but the thing Kerbin orbits - the Sun. This is why Kerbin:body and Duna:body are the same thing.

[Dunbaratu]

So what does the x, y, and z components of that vector represent?

You say you read through the Wiki. Have you seen this page?

http://kos.wikia.com/wiki/Tutorial_-_XYZ_system_of_KSP

Caveat: I wrote that based on guesswork and trial and error taking different readings at different positions until I'd worked it out. So I don't know if it's right or not. The coordinate system of KSP is weird because it keeps changing where the origin is depending on context.

[Bizz Keryear]

In general the lack of an "else", combined with the lack of a "not" operator, makes some things a lot messier than they need to be.

totally signed.

[wingnut]

Did any of you have a problem before, that running a script from the launchpad freezes your game?

[Dunbaratu]

Did any of you have a problem before, that running a script from the launchpad freezes your game?

There were some bugs that could cause that that I encountered in previous versions. I am not aware of any in the current version. Can you post the script you're trying to run?

[wingnut]

This is one of the scripts I'm trying to run and I'm almost certain that I did not change anything before it stopped working. But something significant must have been changed, why would it stop working then?:

declare parameter apo.
set var to altitude.
lock throttle to 1.
SAS ON.
STAGE.
wait until altitude > var.
PRINT "GET:"+round(missiontime)+" LIFTOFF".
log "GET:"+round(missiontime)+" LIFTOFF" to shiplog.
wait until altitude > 10000.
print "GET:"+round(missiontime)+" INITIATE PITCH PROGRAMME".
log "GET:"+round(missiontime)+" INITIATE PITCH PROGRAMME" to shiplog.
SAS OFF.
lock steering to heading 90 by 45.
print "GET:"+round(missiontime)+" PITCH TO 45".
log "GET:"+round(missiontime)+" PITCH TO 45" to shiplog.
wait until apoapsis > 70000.
lock steering to heading 90 by 0.
print "GET:"+round(missiontime)+" PITCH TO 90".
log "GET:"+round(missiontime)+" PITCH TO 90" to shiplog.
until apoapsis > apo {
	if stage:liquidfuel < 1 {
		break.
	}.
}.
lock throttle to 0.
print "GET:"+round(missiontime)+" MECO".
log "GET:"+round(missiontime)+" MECO" to shiplog.
log "GET:"+round(missiontime)+" "+ FLOOR(STAGE:LIQUIDFUEL) + "/" + FLOOR(STAGE:OXIDIZER) + " PROPELLANT/OXIDIZER REMAINING" to shiplog.
wait 1.
STAGE.
print "GET:"+round(missiontime)+" STAGE 1 SEPARATION".
log "GET:"+round(missiontime)+" STAGE 1 SEPARATION" to shiplog.
lock steering to PROGRADE.

wait until eta:apoapsis < 60.
set r to 600000.
set os to r*sqrt(9.807/(r+apoapsis)).
set vel to velocity:orbit.
set dv to sqrt(vel:x^2 + vel:y^2 + vel:z^2).
set dv to os - dv.
set bt to dv/(maxthrust/mass).
print "GET:"+round(missiontime)+" ORBIT INSERTION BURN. BT " + round(bt,2) + "s".
log "GET:"+round(missiontime)+" ORBIT INSERTION BURN. BT " + round(bt,2) + "s" to shiplog.
wait until eta:apoapsis < bt/2 + 1.
lock throttle to 1.
wait until periapsis > 70000.
until periapsis > 70000 {
	if stage:liquidfuel < 1 {
		break.
	}.
}.
set ecc to ((r+apoapsis) - (r+periapsis))/((r+apoapsis) + (r+periapsis)).
until ecc < 0.1 {
	set ecc TO ((r+apoapsis) - (r+periapsis))/((r+apoapsis) + (r+periapsis)).
	if ecc < ((r+apoapsis) - (r+periapsis))/((r+apoapsis) + (r+periapsis)) {
		break.
	}.
}.
lock throttle to 0.5.
until ecc < 0.05 {
	set ecc TO ((r+apoapsis) - (r+periapsis))/((r+apoapsis) + (r+periapsis)).
	if ecc < ((r+apoapsis) - (r+periapsis))/((r+apoapsis) + (r+periapsis)) {
		break.
	}.
}.
lock throttle to 0.3.
until ecc < 0.005 {
	set ecc TO ((r+apoapsis) - (r+periapsis))/((r+apoapsis) + (r+periapsis)).
	if ecc < ((r+apoapsis) - (r+periapsis))/((r+apoapsis) + (r+periapsis)) {
		break.
	}.
}.
lock throttle to 0.
TOGGLE AG2.
PRINT "GET:"+round(missiontime)+" INSERTION BURN COMPLETE".
log "GET:"+round(missiontime)+" INSERTION BURN COMPLETE" to shiplog.
set ecc to ((r+apoapsis) - (r+periapsis))/((r+apoapsis) + (r+periapsis)).
print "GET:"+round(missiontime)+" ECCENTRICITY " + round(ecc, 4).
log "GET:"+round(missiontime)+" ECCENTRICITY " + round(ecc, 4) to shiplog.
log "GET:"+round(missiontime)+" "+floor(STAGE:LIQUIDFUEL) + "/" + floor(STAGE:OXIDIZER) + " PROPELLANT/OXIDIZER REMAINING" to shiplog.
STAGE.
print "GET:"+round(missiontime)+" "PAYLOAD RELEASED".
log "GET:"+round(missiontime)+" "PAYLOAD RELEASED" to shiplog.

I have other scripts which cause the game to freeze as well when run from the launchpad. It doesn't matter if the script is run from the archive or copied to the vehicle's volume and run from there - both cases cause a freeze.

Edit: this is the previous version of the script which still works on the launchpad:

I checked it with Tortoise Merge and there are some changes of whitespaces in a couple of lines and I removed some print statements which were paired with log statements. I didn't have the time to investigate it more thoroughly yet.

declare parameter apo.
set var to altitude.
lock throttle to 1.
SAS ON.
STAGE.
wait until altitude > var.
PRINT "GET:"+round(missiontime)+" LIFTOFF".
log "GET:"+round(missiontime)+" LIFTOFF" to shiplog.
wait until altitude > 10000.
print "GET:"+round(missiontime)+" INITIATE PITCH PROGRAMME".
log "GET:"+round(missiontime)+" INITIATE PITCH PROGRAMME" to shiplog.
SAS OFF.
lock steering to heading 90 by 45.
print "GET:"+round(missiontime)+" PITCH TO 45".
log "GET:"+round(missiontime)+" PITCH TO 45" to shiplog.
wait until apoapsis > 70000.
lock steering to heading 90 by 0.
print "GET:"+round(missiontime)+" PITCH TO 90".
log "GET:"+round(missiontime)+" PITCH TO 90" to shiplog.
until apoapsis > apo {
if stage:liquidfuel < 1 {
print "GET:"+round(missiontime)+" TARGET APOAPSIS NOT REACHED".
log "GET:"+round(missiontime)+" TARGET APOAPSIS NOT REACHED" to shiplog.
break.
}.
}.
lock throttle to 0.
print "GET:"+round(missiontime)+" MECO".
log "GET:"+round(missiontime)+" MECO" to shiplog.
print "GET:"+round(missiontime)+" "+ FLOOR(STAGE:LIQUIDFUEL) + "/" + FLOOR(STAGE:OXIDIZER) + " PROPELLANT/OXIDIZER REMAINING".
log "GET:"+round(missiontime)+" "+ FLOOR(STAGE:LIQUIDFUEL) + "/" + FLOOR(STAGE:OXIDIZER) + " PROPELLANT/OXIDIZER REMAINING" to shiplog.
wait 1.
STAGE.
print "GET:"+round(missiontime)+" STAGE 1 SEPARATION".
log "GET:"+round(missiontime)+" STAGE 1 SEPARATION" to shiplog.
lock steering to PROGRADE.

wait until eta:apoapsis < 60.
set r to 600000.
set os to r*sqrt(9.807/(r+apoapsis)).
set vel to velocity:orbit.
set dv to sqrt(vel:x^2 + vel:y^2 + vel:z^2).
set dv to os - dv.
set bt to dv/(maxthrust/mass).
print "GET:"+round(missiontime)+" ORBIT INSERTION BURN. BT " + round(bt,2) + "s".
log "GET:"+round(missiontime)+" ORBIT INSERTION BURN. BT " + round(bt,2) + "s" to shiplog.
wait until eta:apoapsis < bt/2 + 1.
lock throttle to 1.
wait until periapsis > 70000.
until periapsis > 70000 {
if stage:liquidfuel < 1 {
break.
}.
}.
set ecc to ((r+apoapsis) - (r+periapsis))/((r+apoapsis) + (r+periapsis)).
until ecc < 0.1 {
set ecc TO ((r+apoapsis) - (r+periapsis))/((r+apoapsis) + (r+periapsis)).
if ecc < ((r+apoapsis) - (r+periapsis))/((r+apoapsis) + (r+periapsis)) {
break.
}.
}.
lock throttle to 0.5.
until ecc < 0.05 {
set ecc TO ((r+apoapsis) - (r+periapsis))/((r+apoapsis) + (r+periapsis)).
if ecc < ((r+apoapsis) - (r+periapsis))/((r+apoapsis) + (r+periapsis)) {
break.
}.
}.
lock throttle to 0.3.
until ecc < 0.005 {
set ecc TO ((r+apoapsis) - (r+periapsis))/((r+apoapsis) + (r+periapsis)).
if ecc < ((r+apoapsis) - (r+periapsis))/((r+apoapsis) + (r+periapsis)) {
break.
}.
}.
lock throttle to 0.
TOGGLE AG2.
PRINT "GET:"+round(missiontime)+" CIRCULARIZATION BURN COMPLETE".
log "GET:"+round(missiontime)+" CIRCULARIZATION BURN COMPLETE" to shiplog.
set ecc to ((r+apoapsis) - (r+periapsis))/((r+apoapsis) + (r+periapsis)).
print "GET:"+round(missiontime)+" ECCENTRICITY " + round(ecc, 4).
log "GET:"+round(missiontime)+" ECCENTRICITY " + round(ecc, 4) to shiplog.
print "GET:"+round(missiontime)+" "+floor(STAGE:LIQUIDFUEL) + "/" + floor(STAGE:OXIDIZER) + " PROPELLANT/OXIDIZER REMAINING".
log "GET:"+round(missiontime)+" "+floor(STAGE:LIQUIDFUEL) + "/" + floor(STAGE:OXIDIZER) + " PROPELLANT/OXIDIZER REMAINING" to shiplog.
print "GET:"+round(missiontime)+" ANTENNA DEPLOYED".
log "GET:"+round(missiontime)+" ANTENNA DEPLOYED" to shiplog.

Edited November 26, 2013 by wingnut

[AeroEngy]

You say you read through the Wiki. Have you seen this page?

http://kos.wikia.com/wiki/Tutorial_-_XYZ_system_of_KSP

Caveat: I wrote that based on guesswork and trial and error taking different readings at different positions until I'd worked it out. So I don't know if it's right or not. The coordinate system of KSP is weird because it keeps changing where the origin is depending on context.

I did read that but there are a couple of missing pieces that are still throwing me off:

1) As you said when I query Duna:position the vector's origin is my craft and not the Kerbin centered XYZ described in the Wiki. The wiki page explain the XYZ system when Kerbin is the origin but not when the the craft is the origin. I would need to transform Duna:position into a common coordinate system before doing any vector math. I am not sure how to do this since I don't know their systems orientation wrt each other.

2) Kerbin:BODY:position seems to give me my position with respect to a Sun centered origin. However, again this seems to have a different origin I would need some information to transform the coordinates.

Here is a crappy sketch of my thought process, what I believe each position vector represents and my issues,

A = Kerbin:BODY:position (origin at sun ?, xyz system unknown)

B = Kerbin:position (origin at craft, xyz system unknown)

C = Duna:position (origin at craft, xyz system unknown)

Goal determine vectors A+C and A+B (dashed lines) via simple vector addition. Calculate angle between using dot products.

However, I can't add the vectors until they are all in the same coordinate system with the same origin.

Edited November 26, 2013 by AeroEngy

[Sma]

- Legs will report True only when fully deployed. When deploying or retracting legs will report False. When you ask about legs through the gears command however, they report like gears would.

Thats good to know, wonder why the same isn't true for gears.

[Camacha]

The coordinate system of KSP is weird because it keeps changing where the origin is depending on context.

This might be of how KSP functions internally. Because Unity does not deal well with the vast scale of the Kerbin system, some trickery is involved where you do not move as much as you would think and the universe actually scales and moves around you. There are some interesting video's Squad made on this subject.

This is one of the scripts I'm trying to run and I'm almost certain that I did not change anything before it stopped working. But something significant must have been changed, why would it stop working then?:

These are your culprits.

print "GET:"+round(missiontime)+" "PAYLOAD RELEASED".
log "GET:"+round(missiontime)+" "PAYLOAD RELEASED" to shiplog.

Maybe there are more, but I am sure they will be of the same type. kOS does not like unmatched quotation marks at all. Leaving any in your code is bound to result in a lock-up. Your code should be:

print "GET:"+round(missiontime)+"PAYLOAD RELEASED".
log "GET:"+round(missiontime)+"PAYLOAD RELEASED" to shiplog.

The next time something like this happens, it helps to isolate bits of code. Just comment off everything except for the first few lines and uncomment them bit by bit working down, testing along the way. That way you will find out where the problem lies.