Dunbaratu

You can get the following 3 positions in space: Kerbin:Position Sun:Position Duna:Position Now you've got 3 points in space you can use to form the angle, and calculate it.

But that's waay too specific of a term that only applies to one use of it. I'm just referring to the very generic test of "is X within plus or minus Y of Z?", which can be done with ANDed conditions but it gets wordy and ugly after a bit and it's such a commonly needed operation that it makes sense to make it a function. It's a bit like MIN or MAX. It's trivially easy to write code that does the same thing with an if condition, but it gets wordy and makes the visual flow more clunky than just having a shorthand function for it.

IMO, for working with numbers within an epsilon tolerance it occurs to me that it would be a very useful shorthand for kOS to supply people with a function that works like so: if WITHIN( x, 5.0, 0.1) { stuff }. Which means "is x nearly 5.0, within a tolerance of plus or minus 0.1?", and would be the same as this: if x >= (5.0-0.1) and x <= (5.0+0.1) { stuff }.

AND and OR work exactly as you expect. You can chain together any long number of conditions like that. The only thing to remember is that when there's a chain of AND and OR conditions, the default is to assume all the ANDs happen before all the ORs. (AND is analagous to multiplication and OR is analagous to addition, in the sense that 1+4*5 means "do 4*5 first, then do +1 to that", just like A OR B AND C means "do B and C first, then 'OR' that with A".) You can always override this with explicit parentheses, like so: (A OR AND C The reason for this nomenclature comes from the original concept of Boolean algebra, which preceeds the invention of computers by quite a bit. (Boolean algebra was published in 1847 as just a quirky way to mathematically express the language of logic. It was mostly ignored as just an interesting mathematical footnote until the invention of computers revived it to being quite useful.) In Boolean algebra, you express the concept of "true" with "any number that isn't zero" (usually '1' but it doesn't have to be) and you express the concept of "false" with zero. Then the rules of logic end up mapping exactly one-to-one with rules of algebra in a nice clean way when you do this, which is why the idea got a big boost when computers arrived, as it provided a way to map statements of logic into mathematical operations a computer can do.

The general case solution is start by thinking this way: "The amount by which I choose to push the controls to move toward my target number should depend on how far off I am from my target number." If you are near the desired number, push less. If you are far away from it, push more. That, is basically a P controller - positional only. In your case it would mean "push more the farther from the programmed altitude I am". Then if that's not good enough then you add current velocity to the calculation. "The amount by which I choose to push the controls to move toward my target number should depend on BOTH how far off I am AND my current velocity toward the desired number." (my current climb rate). It depends on both current altitude AND the difference between current altitude and previous altitude (vertical speed). Then if THAT's not good enough, then you take the derivative of THAT and keep trying again, now take into account Position (altitude), AND Velocity (vertical velocity), AND Accelleration (change to vertical velocity), and so on. It's how you keep dampening the oscillations more and more given that your computer isn't capable of doing its work with perfect instantaneous response. And that, in a nutshell, is what a PID controller is trying to do, although the fact that this is what it's trying to do is a bit hidden behind some confusing math terminology, but in a nutshell, it's what I described above. To control phenomenon X, remember the previous few measurements of X and you can get a crude approximation of the deltas of that phenomenon over the previous timestep, and therefore a crude approximation of the current derivatives of the phenomenon. For example the derivative, the approximate change in X over the last timestep is ((Current X minus previous X) / delta time ). You can get the change in the change in X (second derivative) by remembering the previously calculated first derivative and compare how IT changed in that delta time. Of course, the accuracy of these goes up the shorter the delta time is. By using all this information together you can help make a much smoother control of your ship that wobbles and oscillates less.

While that can be a problem, in this case even if that wasn't happening it's STILL a bad idea for @GabeTeuton to be checking for exactly zero. Because even without the artificial artifact of computer floating point precision problems, in the *real* world you're not going to get the system that accurate. Gabe, imagine this: you work as a general errand runner and gopher in a chemistry lab where your boss has said, "I'm cooling this down until it's 30 degrees, then we can start. Your instructions are to look at this digital thermometer and tell me when it says the temperature is exactly 30 degrees." You say "okay, will do!" Then you look at it and it says 35.21301.. then 34.2411... then 32.21623.. then 31.01835, then 30.51821, then 30.201262, then 30.013011, then 30.003151, then 30.000045, then 30.00010, then 29.99912, then 29.999941. then 30.00004, then 29.999910. then 30.00004, then 30.000012, then 29.99919.... etc. At what point should you say "okay that's close enough to 30 degrees that it counts? It's clearly unable to hold it at exactly 30 to more than about 0.001 accuracy."? This is the problem with what you're doing. Even in the real world an autopilot cannot possibly get the climb rate as accurate as you're looking for here. It will inevitibly waver a bit above and below the desired number. Your job is to ensure that it wavers around that point by as small a margin as possible, not to do the impossible and make it stick to it so precisely that it's accurate up to 12 significant digits. That's utterly impossible.

Okay well I'll watch this space in the future then. I haven't officially released my mod yet, but I want to make sure it gets AVC support all squared away correctly before I do.

Action Groups Extended uses a different API than stock action groups use. kOS does not currently support it, but as I understand it, Erendrake and Diazo are working on adding support. I'd expect action groups extended support to come to kOS a lot sooner than proper input support. Supporting Action Groups Extended doesn't require that all of the terminal system be altered. Input support sort of does.

That is correct, unfortunately. Fixing it is all tied up with the remote-ablity of the terminal, however, since KSP is inherently using gui event-driven styles of input and the terminal through which input should come should be using a stream-based style of input. Fixing it involves writing a bridge between the gui event-driven input and an input stream for the terminal to read. This is all pie-in-the-sky stuff at the moment.

Stop. Using. The. Wiki. http://ksp-kos.github.io/KOS_DOC/command/math/index.html

Is there good documentation on the relationship between the github and not-guthub fields of the version file? If i tell it my github info does that mean i don't tell it my download url, and version and let it draw that from github? if i populate both and screw up and they disagree which overrules the other?

Thank you! (i can make it work manually, just adjust the pitch by a very small amount until the VS and VA is 0 (this i'll do when trim is released)... but i would like it to be automated, as an autopilot, if possible) Why haven't you tried just putting all the conditions in the same loop in one large if/else ladder? until false { if altitude < 5000 { if verticalspeed < 10 { // do stuff here. } } else if altitude > 5000 { if verticalspeed > 10 { // do stuff here. } } else { // it's exactly 5000, which seems unlikely as it will always be something like 5000.0001 or 4999.9999 // do stuff here. } }. But in general, I think your algorithm is too dependent on boolean conditions and should depend on mathematical continuous sliding scales. For example, instead of using "if below 5000" and "if above 5000", just calculate this: SET desiredAlt to 5000. LOCK altitudeDiff TO (ship:altitude - desiredAlt). Now if your altitude is above 5000, altitudeDiff is positive, else it's negative, AND the size of altitudeDiff tells you just how far off you are from 5000. Which you can then use to decide how strong to set your vertical climb to. The farther off you are from 5000, the steeper your ascent or descend should be. Since you have this in a number, you can set it by math, again, like so: // Lock neededVSpeed to a bigger number the farther off the altitude is, up to a maximum of 20 m/s LOCK neededVSpeed TO ( - MAX(altitudeDiff/500,20) ). Now you've got a neededVSpeed that is telling you how much vertical speed you need, and its sign tells you in which direction you need it. Etc, etc…

The reason why an IFNDEF is useful is that for many data types, there is no such thing as an impossible value that doesn't actually ever happen in normal operations. You need to be able to tell the difference between "this number is zero because it was never defined" from "this number is zero because it was SET to zero." IMO, an IFNDEF would be a useful thing to add to kOS.

In lots of languages, "++" means "increment this by one". foo++ is shorthand for foo = foo + 1, as is ++foo (putting it on either side of the variable name). There is a slight difference between putting it on the left or on the right, but that detail isn't worth getting into right now. It first appeared in K&R C and lots of other languages have borrowed it since then. BUT..... Kerboscript isn't one of them. I'm pretty sure that doesn't work in kerboscript.

Try this: set x to 3. print x > 5. print x < 5. When you say PRINT X > 5, it says "False". When you say PRINT X < 5, it says "True". That's because False and True are actual values an expression can "hold", if it's a boolean check expression. You can bypass the actual checking and just SAY FALSE or TRUE, meaning "act as if there is a boolean check here that was TRUE" or "act as if there is a boolean check here that was false".

But your complaint was that it never gets to the IF statement after the loop. If you intended the loop to last forever, then of course it won't get to the "IF". By the way you can just do this: UNTIL FALSE { stuff }.

It doesn't exist but maybe could be made. One thing I'd love to do some day is to have kOS spit out a config file that describes the keywords, begin/end pairings, and predefined suffixes and variables, in some sort of format that it would be easy for people to have code read it and spit out whatever syntax def format their preferred editor uses. What has made it impossible up until now has been that the majority of that information is built on the fly at runtime. Some edits we did for 0.15 do push things in a direction that might make this posisble some day. But in the meantime the only way to get syntax highlighting in editors is to write the syntax highlight rules manually.

Uhm... how on earth can that EVER be true? For it to be true, your ship would have to be underground.

Is there some reason you can't use your own flag value for this?

Try verticalspeed? If periapsis is behind you and apoapsis is ahead of you, then you are ascending. If apoapsis is behind you and periapsis is ahead of you, then you are descending. Or, alternatively, compare eta:apoapsis to eta:periapsis. Whichever is smaller is the one that's in front of you. Whichever is larger is the one that's behind you.

I have NEVER been happy with the fact that WHEN is a weird exception case that doesn't work with the same syntax as the rest of them. It's an artifact left over from Nivekk's original design, where originally WHEN didn't allow curly braces and only allowed one statement. At that time it needed the THEN to be the keyword separating the boolean check from the code to run, like so: WHEN x > 2 THEN print "x bigger than 2". The problem is that if we remove it now, we'd have to make the curly braces *mandatory* rather than optional to do so, because the following cannot be parsed by a LL(1) parser: WHEN x > 2 print "x bigger than 2". It has to lookahead more than 1 step to see if there's more coming to the boolean check or if it's seeing the start of the statement. Potentially, it would be possible to change the syntax so all of the following are legal: WHEN x > 2 { print "x bigger than 2". } WHEN x > 2 THEN { print "x bigger than 2". } WHEN x > 2 THEN print "x bigger than 2". But the following would not be legal: WHEN x > 2 print "x bigger than 2". That's still a bit inconsistent, but maybe not so bad as what it does now?

When you think of it, just like pitch can be obtained by the angle between UP and forward, roll can be obtained by the angle between UP and "my starboard". The starboard can be obtained by rotating SHIP:FACING by 90 degrees first: Set rightDir to ( SHIP:FACING*R(0,90,0) ). Set rightVec to rightDir:Vector. Now take VANG(rightVec,SHIP:UP:VECTOR). I may have the rotation wrong. It might be R(90,0,0) or R(0,90,0) or R(0,0,90) - I don't remember which axis it's supposed to be. But it's one of those. If possible, I'd like to see that wiki die. It was from a bygone era when Nivek, the original author, didn't document and the documentation was maintained by the user community trying to guess how things worked. Some of what it says is wrong because it's out of date and some of it is wrong because it was wrong to begin with because people (me included) were trying to work it out from trial and error.

The "ON AG8 { dosomething }" construct does this every update tick: Query the current boolean value of AG8. Set a "do it " flag to true if the previous boolean value of AG8 differs from this new value. Store the new boolean value in the previous value variable for next time. If the "do it" flag was true, then execute the body of the code, else skip it. Each Update tick it re-queries the current state of the action group boolean value and compares it to what it was on the previous update tick. During the update tick in which the value had just changed, from false to true or from true to false, either way, it triggers the body to execute. But none of the above work happens UNLESS the script actually mentions an ON AG8 command in it. Only those action groups for which there is an "ON AG#" command in the script get this query. It does not query all 10 groups just in case one of them is used. It only queries the action groups that were actually set up to have hooks on them, and furthermore it only starts querying for the group activation AFTER the point where the trigger is first mentioned. If you have a kOS script like this: ON AG7 { print "AG7 activated". }. WAIT 60. ON AG8 { print "AG8 activated". }. WAIT 999999. Then if action group 8 is activated by the user during the first minute of execution and never again (before the WAIT 60 is done), then the message "AG8 activated" will in fact NEVER get printed. Until the "ON AG8" is executed, the checking hasn't started yet, and it's only if the sate is toggled AFTER the checking is turned on that it does anything. In the case where AG8 was activated prior to the ON AG8 command being run, then when ON AG8 is first run, it's "previous value" STARTS off as already being "TRUE", and then it will activate if it becomes false.

It's nice that there's no reason for any rivalry at all, actually. In fact, as both kOS and Flight Computer are using the same GPL3 license, we can even share things later on down the road if there's good reasons to copy solutions between the two mods. For example, I noticed in this thread people asking for ways to affect what's on the RMB menus for parts, which just so happens to be the primary focus of the next kOS release. If pixelart wants to have a look at how it was implemented, the code's in the open on github in our develop branch.

That is the goal. I had a working system in place before we started adding the new method suffix system for 0.15. I'll need to go back and re-test it to make sure it still works after all the changes. It does make the program the same size regardless of whitespace and comments, but it still does take up more space with long variable names than short ones because the actual "machine language" used under the hood is a sort of object-aware computer that knows the names of variables and looks them up by name (so the variable name does have to be stored in the machine language). I managed to reduce the expense of it a bit by only storing the long variable name once in a packed argument section, and then referring to it by numerical index into the section after that. (So the difference in storage space between saying MyLongVariableName versus saying mLVN only exists the first time it's used. After that all subsequent uses take up the same space in the ML file.) Madlemur was taking this task on. But it's going to take time because madlemur is new to kOS and has to get a grasp of the existing terminal code first.