kOS Scriptable Autopilot System 0.9

[Dunbaratu]

Ok, after some days of playing around, here are some things I would really love to see:

Logarithm function as well as e-function.

Readout of atmospheric density.

Also I have some trouble when doing calculations with angles.

eg.: arcsin(0.3) + 1

is not possible. Seems that arcsin returns to many digits.

Same for arccos and arctan. They all return 4 digits more.

Sin, cos and tan work.

This issue with inverse trig functions is probably not your fault.

There's a bug in the current version that makes it nearly impossible to use inverse trig functions like arcsin, arccos, and so on in mathematical expressions. The entire system uses single-precision floating point numbers, but a tiny error in how the values of the inverse trig functions were being calculated made them return double-precision numbers instead. Once you've used an arcsin in an expression, from then on that expression gets promoted to double-precision and stays that way. If you assign it to a variable, the variable becomes a double. From then on anywhere you use that value it won't ever get demoted back down to single-precision. and the entire rest of the KSP system makes the assumption that all numbers are single-precision. When you stuff double-precision numbers into things it starts going all wrong.

The fix for it is already in the development code according to what I see on Github, but it's not in a released version yet.

[Dunbaratu]

A program can be perfected to be reliable.

No it can't. In fact there are a number of mathematical PROOFS that it can't. You can only approach the asymptote of reliability without actually getting there. If you drop the word "perfected" I'd be more willing to agree with you. The program can be subjected to lots of test cases, bringing the reliability up. But it cannot actually achieve 100% reliability. That would require an omniscient programmer.

The difference in terms of reliability between a craft being piloted by a computer programmer ahead of time versus by a pilot who handles the controls "live" is the property of consistency. The computer programmer pilot doesn't have the luxury of being able to change his mind on the fly about what algorithm to follow. This is both a benefit and a hindrance at the same time. The meat pilot is more likely to make an error through inconsistency, but also more capable of reacting to exception cases. I would never want to fly in a plane that didn't have a pilot in the chair with the capacity to do a manual override.

Edited September 29, 2013 by Steven Mading

[Camacha]

If you drop the word "perfected" I'd be more willing to agree with you.

Well, this is getting all very semantic and off topic (and fun, I might add), but you can continuously perfect something without it ever being perfect. Perfecting is only possible with things that are not already perfect.

No it can't. In fact there are a number of mathematical PROOFS that it can't. You can only approach the asymptote of reliability without actually getting there. [...] The program can be subjected to lots of test cases, bringing the reliability up. But it cannot actually achieve 100% reliability. That would require an omniscient programmer.

I am not sure about your background as you do seem to know a bit about the subject. It is actually possible to mathmatically calculate every outcome for (simple) logic circuits or software. With more complex software this quickly becomes an impossible task, but this is actually used in systems that are highly mission critical. I believe a variety of this process used for software and hardware that gets sent to space, to ensure the weird flukes we all see on our home computers do not and will not happen.

http://en.wikipedia.org/wiki/Formal_verification

http://en.wikipedia.org/wiki/Independent_Verification_and_Validation_Facility

The difference in terms of reliability between a craft being piloted by a computer programmer ahead of time versus by a pilot who handles the controls "live" is the property of consistency. The computer programmer pilot doesn't have the luxury of being able to change his mind on the fly about what algorithm to follow. This is both a benefit and a hindrance at the same time. The meat pilot is more likely to make an error through inconsistency, but also more capable of reacting to exception cases. I would never want to fly in a plane that didn't have a pilot in the chair with the capacity to do a manual override.

I do believe we fully agree here.

[Dunbaratu]

Well, this is getting all very semantic and off topic (and fun, I might add), but you can continuously perfect something without it ever being perfect. Perfecting is only possible with things that are not already perfect.

Well I would argue that if you start from a thing that isn't perfect, and after working on it for a while you end with a thing that is better but still isn't perfect, that using the term "perfecting" isn't really correct and when people use the word that way they're doing is engaging in hyperbole rather than telling the literal truth. Part of the problem in declaring an autopilot to be perfected is that the same human error that can appear in the making of it can also appear in the judging of it. If the software is judged to be perfect you first have to ask by what criteria it's being judged as perfect, then you have to check if the judgement process itself is perfect, and then whether or not the judgement of the judgement process is perfect, and so on in an infinite regress.

I am not sure about your background as you do seem to know a bit about the subject. It is actually possible to mathmatically calculate every outcome for (simple) logic circuits or software.

Only when it contains no loops. Once there's a loop meant to execute a very large number of times this becomes a mathematical impossibility due to the fact that any program analyzing a loop is no more reliable at concluding and coming to a final answer than the loop itself is. (i.e. if you write a program to detect whether or not another program has an infinite loop, if it does have an infinite loop then the detector program gets stuck in an infinite loop as well when trying to analyze it - so the only answers you can get out are "it does terminate" or "I don't know if it does or not. Give me more time." You can never get the answer out "yes it does have an infinite loop.")

[Camacha]

Readout of atmospheric density.

This is pretty much what I am waiting for.

Well I would argue that if you start from a thing that isn't perfect, and after working on it for a while you end with a thing that is better but still isn't perfect, that using the term "perfecting" isn't really correct and when people use the word that way they're doing is engaging in hyperbole rather than telling the literal truth.

It is not a hyperbole as perfecting is - as mentioned before - up to the point of perfection, but never including it, as something perfect can not be perfected. Therefore, perfecting is always from a point less than perfect to another point less than perfect.

When we turn to a dictionary like the Oxford we see that the definition is as follows:

make (something) completely free from faults or defects; make as good as possible:

Your absolute definition is included, but as as good as possible is also included, perfection is not a requisite for perfecting.

[Payload]

Readout of atmospheric density.

set atmP to 2.718^((0-altitude)/5000).
set atmD to atmP * 1.2230948554874.

Atmospheric pressure and density.

http://wiki.kerbalspaceprogram.com/wiki/Atmosphere

The formula below will give you the force of drag at velocity. You will have to do some additional computation if you want to include a deployed parachute. The cD will change then, it wont be just 0.2.

Fd= 0.5 * atmDensity * (velocity)^2 * 0.2 * (mass*.008).

[Camacha]

set atmP to 2.718^((0-altitude)/5000).
set atmD to atmP * 1.2230948554874.

Atmospheric pressure and density.

http://wiki.kerbalspaceprogram.com/wiki/Atmosphere

The formula below will give you the force of drag at velocity. You will have to do some additional computation if you want to include a deployed parachute. The cD will change then, it wont be just 0.2.

Fd= 0.5 * atmDensity * (velocity)^2 * 0.2 * (mass*.008).

For me the benefit would be the ability to adjust thrust dynamically to any atmosphere for maximum efficiency. This solution is an excellent work around, but only works on Kerbin, which is exactly what I am trying to avoid by developing a universal solution. Then there is no need for knowing the exact properties of place X or Y, you can just measure them as you go.

[Dunbaratu]

It is not a hyperbole as perfecting is - as mentioned before - up to the point of perfection, but never including it, as something perfect can not be perfected. Therefore, perfecting is always from a point less than perfect to another point less than perfect.

Your absolute definition is included, but as as good as possible is also included, perfection is not a requisite for perfecting.

You've altered your definition in that last line. I added the boldfacing to show the contradiction. You changed your claim after looking it up. I'll admit I had it wrong if you ALSO admit you had it wrong. Saying not a requisite for allows for the first and second definitions in the Oxford dictionary to exist. What you said earlier does not allow the first definition to exist. What I said didn't allow the second definition to exist. We were both wrong.

Edited September 29, 2013 by Steven Mading

[Dunbaratu]

For me the benefit would be the ability to adjust thrust dynamically to any atmosphere for maximum efficiency. This solution is an excellent work around, but only works on Kerbin, which is exactly what I am trying to avoid by developing a universal solution. Then there is no need for knowing the exact properties of place X or Y, you can just measure them as you go.

But you can query the variable "body" to see the string name of your current body. So while this isn't ideal, and I'd rather be able to read the science instruments as well, you *can* at least make a routine that contains all the wiki-able stats about the planets and moons, and looks them up based on the string you pass in. Here's what I've done so far for just Kerbin, Mun, and Minmus. It's clear that the idea can be expanded to all the planets with a bit of time spent wiki-looking and typing. Seeing as how this isn't the interesting part of making an autopilot, but it is needed, I'd like to have this be a thing that people communally edit wiki-style for everyone to use. Once it includes all the stats for all the bodies it will become too big and will eat up most of the disk on a remote probe, but I have an idea that what you'd do with it is keep it at home on your archive and "beam" the stats to the probe like so:

//Running on Probe, if it has radio range:
switch to archive.
run bodyStats(body).
switch to 1.
// go on with rest of code.

To simulate the idea of the home base sending the data to the probe when it asks for it, rather than the probe having to know the stats about everything in the system.

The bodystats looks like this so far. Some of these parameters would be pulled out of it if it was for public use because they're just for my lander script:

// bodystats: sets up variables for use in programs
// that need stats about the orbital body that is the
// current SOI.  Looks up the body name and fills
// the appropriate variables.
clearscreen.
declare parameter forBody.

print "Settings for SOI body: " + forBody.
print " ".

// Placeholder Defaults in case I didn't code stats for current body.
// ------------------------------------------------------------------

set bodySurfaceGrav to 10.   // The m/s^2 at the body's surface.

set bodyRadius to 500000 .   // The radius from center to equator.

set bodyMaxElev to 4000.     // The peak of the highest mountain.

set bodyTVelTenKm to 999999. // Terminal velocity at 10,000 m.
                             // The actual math for term vel is complex.
                             // This data point is for fuzzy heuristics.
                             // Set really high for planets with no atmo.

set descendTop to 50000 .    // The highest AGL at which descents might start.

set descendBot to 100 .      // the AGL where a descending craft should hover.

set descendTopSpeed to 2000.0 . // Desired speed at top of descent profile.

set descendBotSpeed to 4.0 .    // Desried speed at bottom of desecnt profile.

set bodyLandingSpeed to 4.0.    // Desried speed to come down from hover to

set craneDropAGL to 10.    // AGLto drop skycrane payloads from.
                           // Warning this is measured from craft control
			   // unit, not from craft's bottom.

set throttleGentle to 100. // Throttle gentleness.
                           // too low and the throttle is twitchy.
                           // too high and its too slow to react.

set c to " ====== deviations for each body ===== ".
if forBody = "Kerbin" {
  set bodySurfaceGrav to 9.802 .
  set bodyRadius to 600000 .
  set bodyMaxElev to 6761 .
  set bodyTVelTenKm to 267 .
  set descendTop to 70000 .
  set descendBot to 100.
  set descendTopSpeed to 1800.0 .
  set descendBotSpeed to 6.0 .
  set descendLandingSpeed to 4.0 .
}.
if forBody = "Mun" {
  set bodySurfaceGrav to 1.63 .
  set bodyRadius to 200000 .
  set bodyMaxElev to 7061 .
  set descendTop to 20000 .
  set descendBot to 50 .
  set descendTopSpeed to 542.0 .
  set descendBotSpeed to 6.0 .
  set bodyLandingSpeed to 2.0 .
}.
if forBody = "Minmus" {
  set bodySurfaceGrav to 0.491 .
  set bodyRadius to 60000 .
  set bodyMaxElev to 5725 .
  set descendTop to 10000 .
  set descendBot to 30 .
  set descendTopSpeed to 274.0 .
  set descendBotSpeed to 5.0 .
  set bodyLandingSpeed to 2.0 .
}.

print " ".
print "bodySurfaceGrav  = " + bodySurfaceGrav.
print "bodyRadius       = " + bodyRadius.
print "descendTop       = " + descendTop.
print "descendBot       = " + descendBot.
print "descendTopSpeed  = " + descendTopSpeed.
print "descendBotSpeed  = " + descendBotSpeed.
print "bodyLandingSpeed = " + bodyLandingSpeed.
print "throttleGentle   = " + throttleGentle.
print " ".
print "('AGL' means Above Ground Level to distinguish ".
print "from sea level altitude.)".
print " ".
print "You may change these variables with the 'set' ".
print "command before running other programs to try ".
print "other settings.".
print " ".

I like this idea and would like to see it publicly developed. But first I'd like to see some better conventions for variable names than I used. I think mine are too wordy given the small size of things in KOS.

[Camacha]

But you can query the variable "body" to see the string name of your current body. So while this isn't ideal, and I'd rather be able to read the science instruments as well, you *can* at least make a routine that contains all the wiki-able stats about the planets and moons, and looks them up based on the string you pass in.

I agree that this is currently the best and probably only way of doing things. I am a little obsessed with making things as universal as possible though, so any system that can dynamically measure parameters instead of using fixed ones is more ideal in my eyes. That way you can do missions to unknown bodies (so no surprises like the Soviets had on Venus) and even bodies (currently) not in the Kerbal solar system without knowing exactly what is going on there.

I guess some values are hard to measure, like SOI and planet size, but I think we can expect a whole lot of sensors in the near future. Maybe something will come along that can dynamically measure stuff like that in a somewhat realistic fashion.

I actually was thinking about conventions for things like this. It would be nice if code was easily shared between people using the same variables.

You've altered your definition in that last line. I added the boldfacing to show the contradiction. You changed your claim after looking it up.

I know that there is a discrepancy between my statement and the definition of the Oxford dictionary. I looked up the definition to illustrate that both exclude perfection as a necessity for perfecting.

I did or do not change my claim as I can not fully agree with the definition given by the dictionary for reasons already explained; if you simply follow the logic, perfection should be excluded from the act of perfecting. However, my original statement was that a program can be perfected to be reliable and that seems to hold true either way. My logic is undeniable

Anyway, I think it is time to shake hands and go back to discussing kOS - even though I do enjoy conversations like this.

Edited September 29, 2013 by Camacha

[Dunbaratu]

I looked up the definition to illustrate that both exclude perfection as a necessity for perfecting.

I do not agree that both do so. But I've already shown exactly why I don't agree, so there's no point in me repeating the same thing I already said in response to you saying the same thing you already said.

Back to kOS.

Edited September 29, 2013 by Steven Mading

[Bizz Keryear]

• I highly suggest a round(<float>,<digits>) command.

___________________________________

set atmP to 2.718^((0-altitude)/5000).
set atmD to atmP * 1.2230948554874.

Atmospheric pressure and density.

http://wiki.kerbalspaceprogram.com/wiki/Atmosphere

The formula below will give you the force of drag at velocity. You will have to do some additional computation if you want to include a deployed parachute. The cD will change then, it wont be just 0.2.

Fd= 0.5 * atmDensity * (velocity)^2 * 0.2 * (mass*.008).

I'd like to have this in a reasonable context in the k-OS wiki. I would appreciate if you* do that, pretty PLEASE *making puppy eyes*.

___________________________________

I like this idea and would like to see it publicly developed. But first I'd like to see some better conventions for variable names than I used. I think mine are too wordy given the small size of things in KOS.

I also forget it often enough, but there is the possibility to add more than one computer and use more than one drive.

___________________________________

___________________________________

*= Cause I have trouble with the "reasonable context" part. In other words: That should be on the wiki, but I have no clue where to put it.

[Dunbaratu]

I actually was thinking about conventions for things like this. It would be nice if code was easily shared between people using the same variables.

It would be even nicer if we didn't HAVE to worry as much about the global namespace. I'm thinking in terms of the stuff needed to write helper library routines and one of the hard problems is that all variables are global in scope and there's no way to declare a variable to be local. (Only the DECLARE PARAMETERS are local, nothing else is.) While this certainly fits with Kevin's goal of making it easy to understand for the layperson it does have the problem that there's a good *reason* languages have a distinction between global and local variables. Local variables let you make subroutines that don't have to "know" the names of all the other variables in the rest of the code they are going to be mixed in with. They can use a variable with a short name like "x" or "i" or "front" or "count" without worrying that they may be clobbering a variable used by the calling program.

[Dunbaratu]

*= Cause I have trouble with the "reasonable context" part. In other words: That should be on the wiki, but I have no clue where to put it.

I made the "Sidebar Topics" page for things that are sort of not quite syntax and language features, and also sort of not really containing fully fleshed out examples and tutorials, but are instead for exactly things like this - helpful extra information on the side that a KOS script writer would need to know - like how the XYZ system is laid out, or how the Volumes and Archive work, or how long antenna range is.

[Dunbaratu]

[*]I highly suggest a round(<float>,<digits>) command.[/list

That should be on the GitHub Issues page. But I'd recommend that if you're only going to be able to get one operator of the set:

ROUND,

TRUNC OR FLOOR (same thing),

CEIL

MODULO (the "%" operator).

implemented (because let's face it, Kevin is busy), then of the set of all those, that TRUNC is in fact the most valuable one to implement first, because with it you can derive the others:

CEIL(X) is almost always the same as TRUNC(X + 0.999999999999 ). (As many '9's as you can fit before the float precision rounds it up - the problem being that how large that can be varies depending on how far away from zero X is. The precision is not constant - it gets worse the bigger the number is. That's why I had to say "almost always" rather than "always".)

ROUND(X) is almost always the same as TRUNC( X + 0.5 ). (Depending on rounding algorithm).

(To get a ROUND(X,digits) function you can multiply by powers of 10 to shift the decimal place, do the TRUNC, and then multiply by the opposite power of 10 to shift the number back.)

And MODULO(X,Y) *is* always the same as X - TRUNC(X/Y). (What's leftover after the integer portion of X/Y).

If there's only going to be one thing implemented, I'd rather it be TRUNC. It's a lot more universal.

[Bizz Keryear]

I made the "Sidebar Topics" page for things that are sort of not quite syntax and language features, and also sort of not really containing fully fleshed out examples and tutorials, but are instead for exactly things like this - helpful extra information on the side that a KOS script writer would need to know - like how the XYZ system is laid out, or how the Volumes and Archive work, or how long antenna range is.

Meh, don't ruin my chance to recruit another editor*... But thanks.

*=I was hoping to hit two birds with one stone.

[Bizz Keryear]

That should be on the GitHub Issues page. But I'd recommend that if you're only going to be able to get one operator of the set:

ROUND,

TRUNC OR FLOOR (same thing),

CEIL

MODULO (the "%" operator).

implemented (because let's face it, Kevin is busy), then of the set of all those, that TRUNC is in fact the most valuable one to implement first, because with it you can derive the others:

CEIL(X) is almost always the same as TRUNC(X + 0.999999999999 ). (As many '9's as you can fit before the float precision rounds it up - the problem being that how large that can be varies depending on how far away from zero X is. The precision is not constant - it gets worse the bigger the number is. That's why I had to say "almost always" rather than "always".)

ROUND(X) is almost always the same as TRUNC( X + 0.5 ). (Depending on rounding algorithm).

(To get a ROUND(X,digits) function you can multiply by powers of 10 to shift the decimal place, do the TRUNC, and then multiply by the opposite power of 10 to shift the number back.)

And MODULO(X,Y) *is* always the same as X - TRUNC(X/Y). (What's leftover after the integer portion of X/Y).

If there's only going to be one thing implemented, I'd rather it be TRUNC. It's a lot more universal.

Dunno, I know round as context sensitive means if the first invisible digit is bigger than 5 the last visible goes up by one. E.g: 1.33533333335 would come up with round(1.33533333335 , 10) as 1.3353333334 // and round(1.33533333335 , 5) as 1.33533 // and round(1.33533333335 , 0) as 1 // and round(1.33533333335 , 2) as 1.34

[Dunbaratu]

The formula below will give you the force of drag at velocity. You will have to do some additional computation if you want to include a deployed parachute. The cD will change then, it wont be just 0.2.

Fd= 0.5 * atmDensity * (velocity)^2 * 0.2 * (mass*.008).

I tried working out that same drag formula and balked at KOS's inability to query the coefficient of drag for the ship. It looks like you're plugging in 0.2 as the coefficient of drag. Where did you get that 0.2 figure from? You mention that it would be higher with a parachute. That's true but even before the parachute is thrown into the mix how did you know it was 0.2 in the first place?

Did you obtain that number from outside of KOS? (i.e. writing down the parts' drags as you add them to the ship, or getting it from a mod, or something like that)? Because I can't figure out how to derive it from inside of KOS.

[Dunbaratu]

Meh, don't ruin my chance to recruit another editor*... But thanks.

*=I was hoping to hit two birds with one stone.

How does that ruin the chance to get another editor? I was answering the question of where to add the information about drag. I was saying that's a good place to go add it.

[Dunbaratu]

Dunno, I know round as context sensitive means if the first invisible digit is bigger than 5 the last visible goes up by one. E.g: 1.33533333335 would come up with round(1.33533333335 , 10) as 1.3353333334 // and round(1.33533333335 , 5) as 1.33533 // and round(1.33533333335 , 0) as 1 // and round(1.33533333335 , 2) as 1.34

Yeah but so would what I hinted at. Here, I'll spell it out more explicitly without being so terse about it. I realize I wasn't clear because it was just one item in a list and I didn't mention all the steps correctly:

For example:

set x to 1.6666666.

set y to round(x, 3).

would become this instead:

set x to 1.6666666.

set y to TRUNC(X*10^3 + 0.5) / 10^3 .

That would give you 1.667 as expected.

X*10^3 is 1666.6666

1666.6666 + 0.5 is 1667.1666

TRUNC(1667.1666) is 1667.

1667 / 10^3 is 1.667

The general form is this:

ROUND(X,d) is equal to TRUNC( X*10^d + 0.5 ) / 10^d .

[HeadChef]

I tried working out that same drag formula and balked at KOS's inability to query the coefficient of drag for the ship. It looks like you're plugging in 0.2 as the coefficient of drag. Where did you get that 0.2 figure from? You mention that it would be higher with a parachute. That's true but even before the parachute is thrown into the mix how did you know it was 0.2 in the first place?

Did you obtain that number from outside of KOS? (i.e. writing down the parts' drags as you add them to the ship, or getting it from a mod, or something like that)? Because I can't figure out how to derive it from inside of KOS.

I hope you don't mind me answering this.

Most parts in KSP have a drag value ofo 0.2. As long as noch chute with its insanely high drag value comes in, the average value will thus remain close to 0.2. It's an approximation.

The KSP Wiki has a topic on this: http://wiki.kerbalspaceprogram.com/wiki/Atmosphere#Drag.

This is a great mod. Thank you Kevin and all the others who put effort into this.

I was looking for something like this since I first started off with KSP.

I too have some suggestions for improvements. These are the first that came to my mind:

More storage per CX-4184.

Don't get me wrong. I really like the Idea of having to household with memory, to use multiple units for complex missions and to copy stuff around. I however had a really hard time to fit a single advanced launch program into one CX-4184 without stripping all comments. For a scripting launguage that is aimed on users who do not have any programming knowledge, I think comments are a must-have. Maybe you could exclude comments from the program size calculations. As a quick fix however, doubling the storage size to 20kb would be OK.

Arrays.

It would be really nice if one could iterate over information. In my case, I store information on each stage of my rocket in a program file. In other programs I then often have something like this:

if curr_stage = 1 { ... }.
if curr_stage = 2 { ... }.
if curr_stage = 3 { ... }.
...

In each block I have to repeat almost the same code, only with different variable names. Especially in an environment with strictly limited memory, this becomes a real burden.

Smaller parts.

The CX-4184 is nice for most types of rockets. Small probes or rovers on the other hand become very bulky if built around this monster. An additional, OKTO-sized part would be really neat. That one may then have a reduced storage and/or a slower CPU.

Finally, the ´lock´ command seems not to update variables if they are queried from within a loop. What I tried was basically this:

lock lnc_atm_d to 1.2230948554874 * bi_atm_p0 * (e ^ ((0 - altitude) / bi_atm_sh)).
lock set lnc_vt to ((250 * bi_gm) / ((bi_r ^ 2) * vi_grav * lnc_atm_d)) ^ 0.5.

until apoapsis > p_lnc_alt {
    print "Terminal Velocity:   " + lnc_vt      at (15,25).
    print "Atmospheric Density: " + lnc_atm_d   at (15,26).
}.

The loop however keeps printing the values both variables had when the loop was entered.

But anyway: Keep up the great work.

[Bizz Keryear]

Yeah but so would what I hinted at. Here, I'll spell it out more explicitly without being so terse about it. I realize I wasn't clear because it was just one item in a list and I didn't mention all the steps correctly:

For example:

set x to 1.6666666.

set y to round(x, 3).

would become this instead:

set x to 1.6666666.

set y to TRUNC(X*10^3 + 0.5) / 10^3 .

That would give you 1.667 as expected.

X*10^3 is 1666.6666

1666.6666 + 0.5 is 1667.1666

TRUNC(1667.1666) is 1667.

1667 / 10^3 is 1.667

The general form is this:

ROUND(X,d) is equal to TRUNC( X*10^d + 0.5 ) / 10^d .

Eeeerr, can't he use a round that is build in the C he uses? I mean most languages have that build in. I am sure Python has.

I tried working out that same drag formula and balked at KOS's inability to query the coefficient of drag for the ship. It looks like you're plugging in 0.2 as the coefficient of drag. Where did you get that 0.2 figure from? You mention that it would be higher with a parachute. That's true but even before the parachute is thrown into the mix how did you know it was 0.2 in the first place?

Did you obtain that number from outside of KOS? (i.e. writing down the parts' drags as you add them to the ship, or getting it from a mod, or something like that)? Because I can't figure out how to derive it from inside of KOS.

Isn't that the drag thing that are stored in the parts?

How does that ruin the chance to get another editor? I was answering the question of where to add the information about drag. I was saying that's a good place to go add it.

If he had felt a gentle push to do it because I can't... (But the comment wasn't totally serious anyway)

Now I have done it anyway...

[Bizz Keryear]

More storage per CX-4184.

Don't get me wrong. I really like the Idea of having to household with memory, to use multiple units for complex missions and to copy stuff around. I however had a really hard time to fit a single advanced launch program into one CX-4184 without stripping all comments. For a scripting launguage that is aimed on users who do not have any programming knowledge, I think comments are a must-have. Maybe you could exclude comments from the program size calculations. As a quick fix however, doubling the storage size to 20kb would be OK.

For various reasons I am attempted to create a compiler in Python that not only strips comments, but also verifies the code. (Its a hassle to test it with crafts.) and eventually also shortens the length of variable names.

But currently I am so busy with the wiki that I barely have time to play.

Arrays.

Yeah that would be neat.

Smaller parts.

The CX-4184 is nice for most types of rockets. Small probes or rovers on the other hand become very bulky if built around this monster. An additional, OKTO-sized part would be really neat. That one may then have a reduced storage and/or a slower CPU.

Well I don't think so. I would use Module Manager instead to make all probe cores also a k-OS computer. It would be a logic choice to do so. (since it would irrational for a probe core to not have a computer like this)

Finally, the ´lock´ command seems not to update variables if they are queried from within a loop.

What I thought it propose it was.

Yeah, run into that, too. Missed to report that bug at GitHub, though.

[aNewHope]

Will there be a feature to create lists, where values can be accessed using variables? I picture it like this.

 l2(x) -> list two; line x

Also it would be very useful to be able to print at positions given by variables (gives an error right now).

This would open up a new world of possibilities.

print "testtest1212" at (x,y) 

And last but not least the feature to read out the thrust currently put out by your rocket, would solve almost all problems with asparagus staging.

(When an outer stage burns out, you thrust suddenly decreases --> your program stages).

Gotta love your mod. Keep up the good work!

Edited September 29, 2013 by aNewHope

[HeadChef]

For various reasons I am attempted to create a compiler in Python that not only strips comments, but also verifies the code. (Its a hassle to test it with crafts.) and eventually also shortens the length of variable names.

That's the route I'm currently taking too. On a long run however, I think there should be something built right into the Pluging itself. An unexperienced user may not be willing to use additional external tools just to get some common example code to work.

Well I don't think so. I would use Module Manager instead to make all probe cores also a k-OS computer. It would be a logic choice to do so. (since it would irrational for a probe core to not have a computer like this)

This would definitely be the more consequent solution. Then the existing part could also be removed.

Yeah, run into that, too. Missed to report that bug at GitHub, though.

I somehow hadn't realized yet at all that there is an issue tracker on GitHub. Maybe a more explicit anouncement in the OP would help others. Something like "If you find any bugs, please post them on the GitHub page".

Will there be a feature to create lists, where values can be accessed using variables. I picture it like this.

 l2(x) -> list two; line x

This is basically what I meant with 'arrays'. To have the ability to store multiple sets of data in a single variable and to look up a specific data set by an index. If this index could itself be read from a variable, one could (besides many other cool things) iterate over all data sets in a loop. E.g.

// Pseudocode
set 0 in a to "value1".
set 1 in a to "value2".
...

set i to 0.
until i = 5 {
    print i in a.
    set i to i + 1.
}.

This would print

value1
value2
...

Also it would be very useful to be able to print at positions given by variables (gives an error right now).

This would open up a new world of possibilities.

print "testtest1212" at (x,y) 

This was one of the first features I was missing in my very first program. It would indeed be useful.

And last but not least the feature to read out the thrust currently put out by your rocket, would solve almost all problems with asparagus staging.

(When an outer stage burns out, you thrust suddenly decreases --> your program stages).

This would indeed be nice. By now, you can implement staging for such rockets by coding the 'empty levels' of the stages into your program. Look up the fuel capacity of your rocket, then have a look at the capacity of the boosters in each stage and subtract it from the capacity of the whole rocket. The result is the amount of fuel your rocket will still have when the booster stage is spent. You can then trigger the staging command when the fuel of the current stage becomes lower than the 'empty level' of that stage. For the Kerbal-X stock rocket, the code looks like this:

set stage1_empty to 6480.
set stage2_empty to 5400.
set stage3_empty to 4320.

when stage:liquidfuel < stage1_empty then stage.
when stage:liquidfuel < stage2_empty then stage.
when stage:liquidfuel < stage3_empty then stage.

Edited September 29, 2013 by HeadChef
Fixed my code sample.