Dunbaratu

If you use VIM, this is the syntax def file I use for it: https://drive.google.com/folderview?id=0Bxkeai7oN35fV2xCa0Y1RThSYkU&usp=sharing But I haven't updated it since 0.9. I need to go back to add all the new built-in variables and suffixes so they highlight properly.

There's absolutely no reason you can't have rotational inertia when "on rails", and I have no idea why KSP doesn't do it. It's far simpler to calculate math than anything used for the current linear XYZ movement that's tracked by plugging in Time = T into parameterized equations for an ellipse. All it is is a simple line function with a modulo operator thrown on the end of it: Rotational position around axis FOO is equal to: (IR + RV*t) mod U Where: IR = initial rotational position at the moment it first went on rails. RV = rotational velocity around this axis. t = time (the only part that changes, that you plug in for the on-rails equation) U = The size of a single unit circle, in whatever angle measuring system you're using (either 2*pi or 360, depending on if it's radians or degrees). Do that for each axis of rotation of the craft. There's nothing to even track "live" unless the ship happens to be in view when time-warping. As long as it's not in view, then just don't bother tracking the rotation until the craft gets reloaded, at which point you plug back in the time=t parameter to see where it's gotten rotated to while you weren't looking at it.

The claim that what I was talking about has anything to do with command-line usage versus GUI usage is false. The rest of what you said is based on your decision to adhere to this strawman.

You're really not seeing what I'm referring to. If it's packaged well, then when you install it into somewhere, no matter where you install it to, the only thing you get IN the location you installed it is a directory. Everything else is under that.

That seems to assume you're landing on a smooth sphere with no terrain features, where it's safe to travel at something like 500 m/s sideways a few meters off the ground, such that when you finish killing your horizontal speed, you've got no distance left to fall at that point. If you're landing in a more real situation, where your orbit has to start above the terrain features, then wouldn't you end up coming to a stop not AT the ground, but several kilometers above it, and then you have to add in the fuel spent on that vertical descent straight down against gravity?

Thanks. Hopefully that will take care of the problems.

All velocities are given relative to the current body you're orbiting. That's why body:velocity always returns V(0,0,0). But POSITIONS on the other hand, are given relative to your ship, which is a bit of a confusing contradiction.

No. I'd like there to be. Maybe it can be an upcoming feature. At the moment all you can do is react to action groups 0-9 (basically the user hitting ALT-0 through ALT-9 can be used as triggers to things in your kos script code because your code can react to the triggered action group, but that's got the big problem that people might be using those action groups for important parts of their rocket design.

This isn't a request about my thread but about another thread who's original author has abandoned it and the mod it's talking about utterly. The mod in question is kOS- Kerbal Operating System, and the thread describing it originally was this one: http://forum.kerbalspaceprogram.com/threads/47399-kOS-Scriptable-Autopilot-System-0-9 The problem is that the user KevinLaity who started the thread has since left the forum and abandoned the mod (eventually after a very long struggle trying to get in contact with him people finally verified that he had left). That was many months ago. But the mod was licensed under an opensource license which allowed others to take up the mantle and continue it (specifically it was GPL3). They started their own thread for the new version of it. The new thread is at this URL: http://forum.kerbalspaceprogram.com/threads/68089-0-23-kOS-Scriptable-Autopilot-System-v0-11-2-13 The problem is that because the old thread was around for so long and had a large number of posts on it, it keeps appearing as the topmost hit on google searches for "kos and ksp", and on searches in the forum's own search feature. Occasionally people go to the old thread asking questions about why it doesn't work (the mod broke with the 0.23 update back in November and the author wasn't around to fix it, which was a large part of the motivation for someone else taking it over), and asking questions about how to use it, and so on. The front page of the old thread makes no mention of any of this, as it was last updated by the old user before he decided to abandon it, and before the 0.23 update broke the mod. Because the front page is only editable by the (now absent) user KevinLaity, people are powerless to stop this mistake from happening over and over. This request is not to delete the thread (it has useful historical information to look up), but to edit the front page message of the thread with a big message on top of it warning people about the situation and directing them to the newer thread. I'm picturing something along the lines of this: Warning: This thread refers to an old, now abandoned, version of this mod. For the newer version that is still receiving updates, please visit /this thread/(URL link given above) instead.

Incedentally, this is a known bug in the new version still not being dealt with yet, partly because it requires that RT2 change what it's doing. (RT2 assumes that if the craft is out of range that only RT2 is allowed to move its controls, not the user or (unfortunately) any other mod. The control of the craft is locked out and RT2 won't give it up. RT2 fights with kOS over who gets to control the craft, and kOS loses the fight. (RT2 keeps setting the controls back to neutral when kOS tries moving them.) )

The reason that hasn't been done is for the same reason that a new version of the mod had to be forked - because the person with permission to do that isn't here anymore. The owner of the thread is gone. UPDATE: I got a forum administrator to add a warning message to the top of the front page.

I still think it's something to worry about because I've seen raw (unmodded) KSP give me screwy weird numbers for longitude that aren't normalized into the range of -180 to +180. I've had it tell me, for example, that my landed craft was at a longitude of "581 degrees west", when if you think about it, that's really just a really screwed up way to say 221 degrees west, which is really 139 degrees east" If it returns numbers like that in the user interface, I'm fearful that it does the same thing in the underlying API and therefore normalizing the result may be needed.

Almost. Technically it's shorthand for "<variable> is not false " which you might think is the same thing as "<variable> is true" but it's *slightly* different. I won't go into why it's slightly different here.) This may look weird to you but it's actually *very* common in programming languages to allow you to store a boolean check result in a variable and then use that variable later in place of performing the check again. Hmm.. How to explain.... When you do this: set x to y + z. The computer runs a math operation, "+", which is defined to take the following 3 terms: itself, the value to the left of itself, the value to the right of itself, and replace all three with a single value: the sum of what had been the left value and what had been the right value. Similarly, when you do this: set x to y < z. The computer is doing basically the same thing, but now the math operation is the '<', defined to do this: take the following 3 terms: itself, the value to the left of itself, the value to the right of itself, and replace all three with a single value: if the left value was smaller than the right, then the value to replace them with is 1 (true). otherwise the value to replace them with is 0 (false). In boolean algebra, operators like "<", ">", and so on are just another sort of math operator that consumes operand values and spits out a new value based on some rule. They have orders of operations, rules of precedence, and so on just like any other sort of math. As far as the computer "thinks", this expression: 3*x + 4*y isn't really all that different from this expression: 2*x < 4*y So, yes you can store the result of a test like "is a < b?" in a variable. When you say something like this: if _stuff_ { .... }. The _stuff_ part of it is just another expression like any other math expression. If the expression results in a value that means boolean "true", then it does the stuff in the brackets, regardless of whether that expression is written out right here or whether it was already run earlier and the result put into a variable and just that variable is mentioned here. This: set var to 4*x < 3*y. if var { ... }. Gives the same result as this: if 4*x < 3*y { ... }. For the exact same reason that this: set var to 4*x + 3*y. print "value is " + var. Gives the same result as this: print "value is " + (4*x + 3*y). They're both doing the same thing. Storing the result of an expression in a variable. The result of an expression could be a boolean true/false value, because in a sense those are just a special type of number - a number that's only allowed to have 2 values: 0 or 1.

I'm confused. Are you reporting a bug, or are you describing how you're saying you would expect it to work? (Because if "wait until false" and wait until true" are giving the same result, that's definitely a bug. They shouldn't be the same.)

Just do anything that keeps it from ending the program. It doesn't matter what. For example you could do this: SET done to False. ON AG1 SET done to True. wait until done. To cause it to wait forever until action group 1 (alt-1) is pressed. You can use anything from AG0 to AG9 for the action groups. (Note: for action groups to work, you have to have the terminal window NOT being focused, otherwise the ALT-number keypress doesn't pass through to the piloting code in KSP and instead KOS has it trapped.)

Yes. Exactly. This is the problem. Transmitting is less than optimal unless you don't plan to come back home, like it's a remote probe. But if it's a remote probe that's not manned, then the lab can't be used. So it's only useful when sending kerbals on a suicide mission. Otherwise the extra science points you get from a full return and just carrying more than one goo container and more than one materials bay to handle the different biomes is more efficient.

"You can't leave a vessel that is under acceleration." "Gee, thanks, game, but my vessel isn't under acceleration right now (unless you count gravity) so why can't I leave it!????" That's my biggest pet peeve. Various excuses why I can't leave my vessel that are based upon false claims about my vessel - claiming it's moving when it's not, claiming it's under acceleration when it's not.

Immediate mode: typing commands one at a time in the terminal window, and they take effect immediately. As opposed to program mode: running a program file.

Okay thanks. No rush, I just was reluctant to do anything more until I have a better idea of how those parts will be merged in. Can't we just take the logic of the transformation matrix operation used on this page: http://kos.wikia.com/wiki/Tutorial_with_example_-_Conversion_from_Directions_to_XYZs And make that a built-in function? It should be possible to make any rotation direction into a unit vector even if it didn't start out that way in the code. In order for rotations to make any sense at all they have to start from some presumed default. iIn order to know what it means to yaw or pitch 45 degrees you have to know what direction it started from before applying the 45 degree change. You have to know what direction R(0,0,0) is first before you can tell what R(45,0,0) is. Experimentally, it seems that locking steering to R(0,0,0) and locking steering to V(0,0,1) always point the same way, making me suspect that the Euler rotations are starting from the unit vector (0,0,1) and rotating it, which is what the code on that wiki page presumes is happening. Buried somewhere in the Unity docs I saw reference to something saying that the Euler rotation type in Unity presumes a default starting point for the 'zero' rotation if you don't provide one for it, and the presumed starting point is the camera looking "down the Z axis" with the camera's "up" pointing up the Y axis. It looks like this frame of reference is what's used by KSP as far as I can tell experimentally. On second thought, instead of doing the matrix math in kos's mod code, I think Unity even has a built-in function to retrieve the unit vector of a Euler Rotation, provided you give it the original starting point (the 0,0,0) that the rotation was a rotation from. (if you don't provide it, it presumes it rotated from a starting vector described as stated above).

velocity:orbit is a vector. ship:body:position is a vector, and when you think about it, ship:body:position is effectively a vector in the "down" direction. And if you need to transform a rotation into a unit vector, there's a way I worked out ages ago but it's ugly. Also, directions like Up now have a ":vector" suffix to get their unit vector. marianoapp claims it only works on some of them, but I haven't found one yet where it doesn't.

Is development stalled? I've got pull requests rooted from versions on April 7 and I'm a bit reluctant to add anything more while they're still pending.

I dislike the mod doing things for you that are quickly derivable. Normal and anti normal are derivable using vector cross product. If you take the cross product of any two vectors you get a new vector that is perpendicular to the plane containing both of the two input vectors. The ordering matters, such that given two vectors A and B, A cross B gives you the opposite direction from B cross A. Which one is which depends on if your world consists of a right-handed or left-handed coordinate system in its XYZ axes. I can't remember which way around KSP's world is off the top of my head. But anyway, to get the normal vector (and anti-normal) just cross-product two vectors that are in your orbit plane together. One such vector is your orbital velocity. Another such vector is your position relative to the SOI body (or it's position relative to you). So find the cross-product (using recent built-in function VCRS(A, - it used to have to be done by hand which was slow to execute) of the orbit velocity vector and the body position vector. That cross product will be in either the normal or anti normal direction depending on what order you did it in, and multiplying it by (-1) (scalar) will give you the opposite vector. I don't remember off the top of my head which way around is which, but you should be able to get it from experimentation.

Are you trying to do this using a vessel that contains any of the new engines that were added with the KSP 0.23.5 release? The engine attributes of the new engines doesn't work yet. Do you get the same problem on a vessel only containing parts from pre-0.23.5 KSP? The new engines don't use the same part type ID as old engines, which means the kOS code doesn't handle them right yet, I think.

Is that handled with an "and", and is the MCE code written to just treat it as a linear number ignoring the cyclical nature of angle measurements? That would make it impossible. Try to think of a number that is both larger than 170 and also smaller than -170. There isn't one. If your current position was 175, then it would be > 170 but not < -170. If your current position was -175, then it would be < -170 but not > 170. If the check is treating longitude like a raw number, then it doesn't realize that +179 and -179 are actually only 2 degrees apart from each other. The fact that the crater sits right on the boundary between positive and negative longitudes makes the check messier. While it's tempting to just say "remove the longitude goal again" I think this actually highlights a bug in the check that should be dealt with so that other future longitude goals can work properly. We're just lucky that the first real longitude goal happened to be one that triggers the bug right away. The difficult part about fixing it is that if you take into account the cyclical nature of longitude, then that flips the problem to one in which technically ALL positions match a "greater than" and "less than" check. If that was fixed then the new problem would be this: "Is 60 degrees longitude less than 50 degrees longitude? Yes. If you start from 50 degrees longitude and go 350 degrees east, you get to 60 degrees longitude, so 60 degrees is 350 degrees less that 50 degrees." And the problem is that that's technically not wrong. It's mathematically correct, but not what we want as it would make all checks return true. Therefore because of the cyclical nature of degrees longitude, I think all longitude checks will have to be implemented as error bars instead: "You must be at this longitude, plus or minus this much." Then you could have a goal of "180 degrees, plus or minus 10 degrees" which can be made to work, instead of ">170 and <-170", which cannot be made to work. If you did that, and then also made the check aware of the cyclical nature of degrees, (such that it realizes that -179 is +2 degrees from +179, for example) I think that's the only fix that's practical. An algorithm for finding the shortest angle difference between two arbitrary angles, taking into account the cyclical nature of degrees: Start with A and B being the two angles (longitudes). Get C, the difference between A and B, rotating B into a frame of reference using A as the origin angle, so we can work entirely with C, the relative difference, from now on. (i.e. if A = 45 and B = 70, then B is at angle 35 relative to A. Or if A= 45 and B = -150, then B is -195 relative to A): C = B - A. Normalize C's magnitude into the 0..360 range (i.e. if C = 365, turn it into 5, or if it's -365, turn it into -5.): C = C mod 360. Turn negative C into positive C (i.e. -90 becomes +270): if C < 0 then C = 360 + C. You now have C in the range 0..360. change C's range to -180 to +180: IF C > 180 THEN C = -(360 - C) Now you have C, which is how far off B is from A, preserving the sign so you know if it was off to the east or west (if that matters). I had to do this myself for a different reason: I was making a script for kOS and discovered that the longitudes returned by the KSP API are all over the place with no consistency. Sometimes 160 degrees east gets reported as 200 degrees west (technically true) or 520 degrees east (also technically true). The normalizing for the cyclical nature of longitude was not just a petty exercise - it was absolutely necessary because the API didn't guarantee it would normalize the values for you.

That's easy on the surface to use but harder under the hood to implement. Although, on an unrelated note, for any sort of input, converters will be necessary to be able to turn "123" into a numerical variable. Right now you can only go the other way around from number to string (by concatenating numbers to strings with "+") but you can't go from string to number, which is vital for being able to take user input and do stuff with it.