Dunbaratu

This does: // For prograde. The system insists on only // understanding steering by R()'s and not by V()'s. // So you turn a V() into an R() by just multiplying // it by the no-rotation rotation operator R(0,0,0) // to force the system to cast it to an R(). set mySteer to R(0,0,0) * velocity:surface. lock steering to mySteer. //for retrograde, multiply vector by -1 : set vs to velocity:surface. set vsx to 0 - vs:x. set vsy to 0 - vs:y. vst vsz to 0 - vs:z. set mySteer to R(0,0,0) * V(vsx, vsy, vsz). lock steering to mySteer. Using R(0,0,0) * V(x,y,z) allows me to live entirely in the sensible world of vectors and 3D space and not use Euler rotations. The only hard part is finding the zero point of the "universe" when I don't have access to the positional numbers, only the velocity. I've been asking mod makers in the development forum how the game's coordinate system is laid out and it's messy. I've got it worked out that the zero point of the universe is the center of your SOI planetary body, and that the universe's coordinates rotate with your SOI body, but only if you're lower than N (N changes depending on body), but when you're higher up than that, then the frame of reference changes such that the universe stays put and the planet starts rotating. All of that I can get, but then it turns out that for whatever strange reason SQUAD decided to make the axes of the system NOT extend through the prime meridian but at some oddball canted angle at about 100 degrees longitude or so... no idea why or how to query for "where is the x axis on this planet?".

So I've almost got it but now I need a way to find at which longitudes the X and Z axes come out from the globe, which ISN'T the zero point of the latitude/longitude of the planet it seems. On Kerbin it appears to be that the X axis exits the globe at about Longitude -170 or so, and the Z axis comes out of the globe at about Longitude 100 or so. Getting those numbers more precisely is needed to make a conversion from the XYZ numbers into a vector expressed in terms of north/east/up. I can do the trig to make the conversion but only if I know which longitude to call "zero". Is there somewhere to look that up for each body in the game?

No it isn't. It's not aligned with those directions at all, which was the whole point that made me start the thread.

My problem is the other way around. The KOS plugin gives me the surface velocity in the form of a vector, and I'm trying to use that for landing purposes, but if I want to aim the craft by saying "a bit more north than" or "a bit more east than" the surface velocity vector then I needed to know in what coordinate space that vector was expressed so I can get the "upward" vector. The plugin does provide an upward directional ray, but it's expressed as Euler angles (complete with the gimbal lock problem and all that) instead of as something sane I can actually work with like all-axis matrix roations or quaternions or vectors.

So am I to understand that below 100km the surface velocity is "native" and the orbital one is derived, whereas above 100 km they swap and the orbital velocity is native and the surface one is calculated? I can work with the system if I know what it actually IS. It was trying to decipher what it is from only being able to see velocity vectors and having to guess that was the problem.

Well, I can't read your mind. That's true of what you *meant*, when clarified, but not what you *said*, which was that the coordinate system was universal space. It's not if it's centered on the SOI body. Anyway, the one sticking point though is that if the coordinate space moves relative to kerbin, how can the surface-based velocity differ from the orbital one?

The Kerbal Space Center is at 76 degrees West longitude. Which is exactly 14 degrees off from 90 degrees. The amount by which the coordinates were angled from straight-up was exactly 14 degrees. The coordinate system IS a grid and not polar, but it DOES rotate as your main body rotates For some reason I couldn't picture that. I kept tying together "it rotates with Kerbin" with "It is therefore polar coordinates" in my head. Thanks for people helping by being a sounding board to bounce ideas off of. Finally solved. The Grid looks like this: X = Draw a ray from the center of the SOI body out through its 90 degree west longitude line on the equator. That's the X axis. Y = Draw a ray from the center of the SOI body along its axis through its north pole. That's the Y axis. Z = Draw a ray from the center of the SOI body out through its prime meridian (0 degree longitude) line on the equator. That's the Z axis. I think. And this grid rotates as the planet rotates.... but... wait... no...darn it. If that was the case then the orbital and the surface vectors would be the same. Darn I thought I had it. I was "this" close to figuring it out.

But that would require that the numbers CHANGE depending on the time of day. And They Don't. For what you're saying to be the reason it would have to mean that as I rotate around the surface in a kerbin day, I'd be in all those different positions, and ''I already tested that before I posted here'', as I mentioned in my first post description. What you describe does not happen. My velocity is always <-46,0,168> no matter whether I take the sample at high noon (on the sunward-facing side of Kerbin) or at dusk (on the retrograde side of Kerbin's orbit of the sun or at midnight (on the side of Kerbin farthest from the sun) or at dawn (on the side of Kerbin facing Kerbin's prograde direction around the sun). Whatever the frame of reference happens to be, it is definitely moving with me as I rotate through a Kerbin day. That shoots down the universal space coordinate explanation. Besides, I'm certain the devs have said that they use a coordinate system centered on the body you are in the SOI of. [Edit: Wait.. there is ONE way it would work now that I think of it and it's not exactly what you described, though. You describe a universal space coordinate system, and that can't be true given what I saw. Given what I'm seeing it does have to be centered on Kerbin... BUT.... just because it's centered on Kerbin doesn't have to mean it's polar. It could still be an orthogonal grid centered on Kerbin. that might be it... let me try some math to see if that's it.]

If it was calculated by taking two sample positions over a delta time and looking at how far it moved during that time then such a larger error is in principle poissible... BUT.... to be 14 degrees off requires it to be a VERY slow sampling rate, because it's going to take 14 minutes to move that far off. (The fact that it's 14 minutes to move 14 degrees is purely a coincidental effect of the fact that a Kerbin day is 6 hours long. and 6 * 60 = 360, making it move one degree per minute.)

Nope. It's because the XYZ system is tilted at a funny angle. Neither X, nor Y, nor Z is pointing straight up. X points up-ish, about 14 degrees off from up. What I'm trying to figure out is... why? And how do I convert from the coordinates I can see to this weird system?

The mod author didn't write the wiki. It's user-made If it became the only source of documentation then we'd all be guessing all the time.

It's more like calling a subroutine. If program 1 runs program 2, then when program 2 finishes, program 1 continues from the point right after it said "run program2". You're right that it won't run the programs simultaneously, but that's not the same thing as saying it will kill the first program. It doesn't kill it. It just suspends it until the second one is done and then it resumes.

Rotation makes no difference. Also, I don't understand your phrase "-46 for the motion down as Kerbin's rotation pulls you down". How does rotation pull you down? Did you mean gravity? If so, then that would make sense if this was a force vector but it's not. It's a velocity vector. A ship that's TRYING to move downward but is failing to because there's ground in the way is still moving zero downward just as much as a ship with no gravity acting on it.

I guess if the KOS plugin allowed me to obtain the position in the same coordinate system as the velocity, then I'd be able to see where the origin is relative to the vessel and then I'd know what's going on. But all I can get is the velocity.

Neither. They remain fixed. At exactly 174.52 m/s magnitude, no matter when in the Kerbin day I look (no matter where I've rotated to on the Kerbin surface - on the side facing the sun, on the side facing away from the sun, it's the same), which proves it HAS to be a relative coord system relative to Kerbin somehow and not one global to the solar system. And yet... if it's relative to Kerbin, why isn't it relative to the CENTER of Kerbin? The direction of the X axis isn't straight up away from planet center. It's about 14 degrees off from that. And this remains consistent no matter the time of day. It's behaving for all the world like it is a polar coordinate system, but one that instead of having an origin at the center of Kerbin it has one at a point that is inside Kerbin, but is about 14,000 miles away from Kerbin's center. That can't possibly be right. There'd be no reason to design the game that way, so I don't get what's going on.

The fact that I DON'T have center of planet as origin but ALMOST do is why it makes no sense. If it was a system with the center at the planet, then sitting still at the equator should be giving an answer with two of the numbers always zero or very close to zero with a bit of floating point wobble. THIS would make sense: (0,0,174) or this (174,0,0) or this (0,174,0) But what I get is this: (-46,0,168) Now, the thing is, that MIGHT make sense if it was a cartesian coordinate system with a grid of cubes, but only if it was a number that keeps changing as I rotate around the surface. If it was not polar coordinates, but rectangular, then I might get numbers that move over time as I rotate around the surface, like say, (-46,0,168) now, and then (-70,0,150) a little while later, and then (-126,0,120) a little later, and so on as I move around the circle. BUT that is not what I get. I consistently get a number that is floating-point-close to (-46,0,168) no matter what time of day it is on Kerbin (no matter where I've rotated to on the surface relative to the rest of the solar system). So it's neither centered at the planet center, NOR is it centered at the solar system.... so.... what is it? That's what I can't figure out.

You really didn't get what I was asking. The magnitude is FINE. It's correct. THAT isn't the problem. The problem is that I don't understand the DIRECTION of the vector. The fact that the direction is NOT due east but is in fact east plus 14 degrees of downward pitch is what's confusing me. That seems to indicate that the coordinate system in use isn't the one I thought it was and has a frame of reference in which the origin is NOT the center of the planet. I'm trying to steer by these vectors and the fact that they're off from what I'd expect is really screwing me up.

KOS 0.61 is in a sort of inbetween state between being installed in GameData and being installed the old way. The DLL's and parts go in GameData, but the scripts YOU write still have to be outside of GameData in the global location mentioned above.

I started using the KOS scriptable autopilot mod and it sometimes exposes bits of the underlying API to people who've never written mods and some of those bits are really confusing. Right now I'm trying to wrack my brain over why velocity vectors always seem to be quite a bit off from what the navball says. I looked at the GitHub code and I think I might be able to get some help from other people who've coded mods before because I think the issue I'm having is with the entire coordinate system itself - I can't find documentation on how it's set up. First here's everything I *DO* think I understand: When you ask the mod to tell you the current orbital velocity, from reading through the mod's code on GitHub I get the impression that it just maps to returning this in underlying KSP mod API: Vessel.obt_velocity And this appears to be in a coordinate system in which its polar rather than rectangular, with the current main body at the center, in which X = upward (away from origin), Y = northward, and Z = eastward. That all makes sense to me. I verified that it is in a polar coordinate system by simply time warping around Kerbin's daily rotation to see what the values were at different positions around the sphere and velocity is the same at all positions. The ground speed due to Kerbin's daily rotation is 174.53 m/s so I'd expect to see a vector of 174.53 or close to it in magnitude if I sample my velocity while I'm just sitting on the ground not moving, and I do. I get this: (-46.4125, 0.000258, 168.2678 ) Which with the Pythagorean theorem is VERY close to 174.53 in magnitude, so that's all sensible to me. Now the part that I just don't get: Yes the magnitude is about 174 m/s, BUT... why isn't it directly along one of the axes? Why isn't it something closer to this: (0,0,174) rather than (-46,0,168) What is the coordinate system the game uses here? On the one hand it behaves like a polar coordinate system centered on the planetary body, but then it doesn't because the direction of "up" doesn't seem to actually be straight up from the planet but is a bit canted off from Up. Can someone help me understand why this is? Is there an "introduction to the coordinate system of KSP" somewhere? I googled a lot trying to find it but came up empty.

There is a wiki with a few contributors trying to fill the gap left by Kevin Laity's thin README file. Perhaps The Great KOS Archive could live there? http://kos.wikia.com/wiki/KOS_Wiki I had a good hover and skycrane deployment script I'd contribute but it's currently doing a lot of work it shouldn't have to anymore after the 0.61 update and I'm still trying to simplify it. Also, there should be a discussion about conventions and how to make things interoperable and usable. For example, I'd like to see a generic bodystats file everyone can use that does nothing more than lookup a body name (which will usually be your current body but doesn't have to be) and fill a bunch of stat variables about the body (radius, gravity, mass, atmosphere properties, etc.)

Probes also try to save on transmitter power requirements by using directional antennae, which don't try to pick up signals in all directions like a car radio or a mobile phone does, but only pick up signals and only transmit signals from a specific narrow direction. A vitally important part of the various mars rovers is the software that autonomously works out the rover's position in the solar system in order to know which way to point the antenna to aim it at Earth. If that goes wrong nothing else can work.

I had a look at the code on GitHub and it appears to be getting the range by running some loops that amount to the following formula, as far as I can tell: let longAntCount = number of long antennas deployed and active on craft. let dishCount = number of dish antennas deployed and active on craft. range = ( 75000m * ( 1 + longAntCount ) ) * ( 10 ^ dishCount ) So with no antennae you get 75,000m : (75000*(1))*1 With 3 long antennae and no dish antennae you'd get 300,000m : (75000*(4))*(1) With no long antennae and 3 dish antennae you'd get 75 million meters: (75000*(1))*(10^3) With 3 long antennae and 4 dish antennae you'd get 3 billion (*) meters: (75000*(1)*(10^4) (*) - I used the word "billion" in American English meaning. If you're British, pretend I said "thousand million". Again, what antennae do to your range is another thing it would be good to have documented if this is meant to be accessible to the everyman. Having to read the source code to get basic documentation sort of runs contrary to the goal of making it easy for people who aren't normally programmers. And if you want to send a probe out to Jool, you NEED to know this sort of information.

In general whenever you have a lockup of the entire KSP game from running your KOS code the first culprit to look for is paired open/close syntax markers in which there is a mismatch of opens to closes. (more opens than closes). That locks it up every time I've done it, reliably, repeatedly. e.g.: // no close quote: print "blah . // no close parenthesis: set x to ( y + z . // no close braces: if x = 1 { print "x is one". if x = 0 { print "x is zero". Any of those will make it hang forever.

I could believe that in physics warp but even in on-rails warp? How?

Okay I *think* I've worked out that in the velocity vector, X is Up, Y is North, and Z is East. I worked out that Z is east by comparing the surface to the orbital velocity vectors when sitting on the ground. The fact that X is up is the weird part I'd have never expected that. But I just made a program to print out the velocity again and again in a loop while I launched straight up and watched the numbers change. I worked out north the same way.