Dunbaratu

I made an issue for it on the dev github site. I don't know if it's easy to fix or not or if there's a good reason for it working the way it does now, but we'll see what @erendrake has to say about it.

Wow bad timing. Answered my own question almost right after I asked it. The answer is this: assuming b = a CelestialBody and parent = that CelestialBody's parent body. surfaceVelocity = b.orbit.GetVel() - parent.getRFrmVel( b.position ); getRFrmVel() is the conversion I was looking for. You pass in a position in Unity world 3D coords, and it returns the velocity vector representing the offset difference between orbital and surface velocities at that location. You have to tell it the position, of course, because the closer to the equator plane the object is, the bigger the difference between the two is. An object above the north pole would show zero difference between the two.

You can get the surface velocity of a vessel using Vessel.srf_velocity. But looking all through here: https://github.com/Anatid/XML-Documentation-for-the-KSP-API I can't find the way to get the same information about a celestial body orbiting its primary celestial body. If a vessel was in orbit around Kerbin in a circular orbit at 11,400,000 altitude, it could report both its orbital velocity and its surface velocity relative to Kerbin. But when the Mun is in orbit around Kerbin at that distance, it can't. It only gives its orbital velocity. Is there a way to get its surface velocity too? I tried calling CelestialBody.GetSrfVelocity() but as far as I can tell it always returns (0,0,0) - making me think it's the velocity relative to the body itself rather than the velocity relative to its parent it's orbiting. It would make sense if CelestialBody had a frame of reference transformation function that took any orbital velocity and returned the surface velocity version of it, but I can't seem to find it.

Can you show the KSP_Data/output_log.txt that occurs just after this happens (If you've played since then then you'll have to regenerate it, as it gets wiped each time you play the game)? I've seen this ages ago but the cause for me was running into the 3.8GB 32-bit program memory cap. What's happening if you see the black-screen launchpad is that KSP itself was unable to finish loading the terrain data for the planet Kerbin (which it didn't need while you were in the VAB). Going to launchpad causes a jump in memory usage so it's often the place where bugs due to the memory cap manifest. In my case it happened with the ages-old bug in kOS that caused the program to loop slower and slower over time, which was also causing it to use more and more memory each update tick, and the memory it was wasting wasn't being wiped when reverting to launch. But that bug has been gone for a long time now, so if you're still getting the black-launchpad then I'd guess there's a different memory issue (maybe caused by kOS, maybe not?)

That's pretty good! I'm impressed. I've done a lot with space maneuvering but nothing with flying in atmo yet (other than calculating terminal velocity for rocket throttle purposes.) As to your comment about the inability to control the ship while the autopilot is doing things, I too think it would be great if that could be dealt with but I don't know how hard that would be. In the real world most autopilots are there to supplement pilot's inputs rather than override them utterly. (As least they were until Airbus changed all that ... grumble). So, for example, you can tell the autopilot things like "please adjust my throttles as needed to maintain my speed at a constant while I make this turning maneuver..." Many autopilots also have an emergency dis-engage where they "let go" if the pilot moves the controls manually. (I'm not sure we necessarily want *that*). Does kOS actually *need* to lock out user input on WASDQE/Shift/Ctrl? Can that lockout be disabled? And if it is, and the autopilot is trying to, say, pitch down while the player is trying to pitch up, who will win? A solution in which flybywire releases control of a particular control axis (one axis at a time, rather than all controls globally) when it notices the user pressing the appropriate control for that axis, and then grabs it back again after that control hasn't been pushed for a second or so, would be great.

How did you exit the game the first time the error happened? Because I've seen this ages ago back in the old 0.9 version, and once it happens it will permanently STORE the vessel in the campaign save file with the parts gone from it unless you hurry up and force-quit KOS without letting it checkpoint the save file. Once it happens the first time, then subsequent reloads won't bring the missing parts back again, even if the actual bug that caused it is no longer there, because the bug deleted the parts from the saved game the first time. I have never seen this problem happen in versions higher than 0.10 anymore, and you're the first to report it with any new versions. Can you try it with a *new* vessel, save and restore the game, and the very first moment a part of the vessel is missing upon loading, ALT-TAB out of the game while it's still running and save a copy of the file KSP_Data/output_log.txt somewhere and then go back into the game and quit out of it? (You have to save the output.txt file to a new name because it overwrites the file each time you run KSP so the evidence will be gone if you run again after the bug happened.) The bug happens when something throws an error during the process of reloading the vessel from on-rails into full-blown-physics. It goes through each of the vessel's parts one by one and puts them on the ship. If any part along the way generates an error, the act of loading the parts quits and the rest of the vessel's parts don't get loaded. (Then if it saves the game at that point it saves this new missing-parts version of the vessel and you'll never get the parts back again after that.) Seeing the output_log.txt file will let us see what the actual error was that was generated, and let us see which mod was responsible. More than one mod has had this effect before because pretty much any error during the loading process will do it. KSP is designed to quit loading and not continue with the rest of the parts of the ship once any single error happens. [EDIT: your second post ninja'd in while I was writing this]

In trying to write some mod code for kOS to help with intercepts and rendezvous, I noticed that what I was calculating for the closest approach chevrons was way off from what KSP reports in the map view for the closest approach chevrons, but that when I looked carefully and checked out what I was doing, it seems that this wasn't a bug in my code like I thought it was - the approach I'd found *was* actually closer than the one KSP picked. By a lot. But it wasn't necessarily a *practical* approach for intercepting because it's one that was 300 km in altitude "above" the target (while the approach KSP picked was about 550 km away, but it was 550 km away down at similar altitude to the target. This sort of makes sense to me because it's easier to intercept an object from a position 550 km behind it at the same altitude than when you're closer but but directly above it. But this raises the question of what KSP actually uses for the definition of "closest" approach. It's not *really* the closest, as in finding the time T where the length of the line segment between your position at T and the target's position at T is at its minimum. That's what I solved for and I found that approach that's closer than KSP uses, but isn't practical because it's well *above* the target rather than behind or ahead of it. So does anyone have any idea what it's using? Is it weighting the altitude difference as if it was a bigger magnitude than it really is for the sake of measuring distance? That would sort of make sense. Or is it taking the relative velocities into account too and trying to minimize some sort of score composed of both velocity difference and position difference? I just don't know, and I was wondering if anyone with lots of gameplay experience had noticed this before and found a pattern to it?

Don't be sorry. You're using it to do something cool, and that's always good - the more people do that the better the advertising for it is. And yes, I understand why it drives you mad. It drove me mad to the point where back in 2013 I worked it out from experiments and pencil and paper without even being able to read the C# code under the hood yet. (What I did was I put an object into orbit and had a program just printing out data to the screen so I could compare longitude/latitude and the UP rotation tuple to my XYZ coordinates to try to work out by inductive reasoning what the actual system was.) There is a way to work out what the current offset is between longitude and the actual Z axis by reading the rotations inside the UP rotation tuple and working out from that what the relationship between the original axias and the rotation that was needed to turn it into an upward direction. (i.e. if Up:yaw is 30, then that means the Z axis (if you moved the origin to the center of the planet) would be poking out of the surface 30 degrees longitude away from where you are right now, or something like that. It's been a while since I worked it out. Here's the page I wrote about it back then, but it's getting a bit dated and I don't make any promises that it's still true: http://kos.wikia.com/wiki/XYZ_system_of_KSP ) It's not entirely right, I now realize (for example it assumed the world grid was right-handed but it's actually left-handed.) Also because of the constantly rotating frame of reference, you'll need to make sure you keep re-updating your vector calculations otherwise sometimes they become off over time as the universe's coordinate grid rotated the axes and thus altered the meaning of your vector's x, y, and z components. We all do want this messy reference frame problem dealt with, but it's not a quick fix. It affects a lot of things and has to be thought through carefully.

To a certain extent this isn't kOS's fault because its just exposing what's really wacky about KSP's own internal coordinate system, which is truly messy to work with. Here's the stuff that is always true about KSP's coordinate system, and whether or not kOS does anything to try to "fix" it or not: - The origin is always *near* the active vessel but not exactly at it. (After coming out of a timewarp it starts off being right on the vessel, but as the physics engine operates on the ship the ship drifts away from the origin.) kOS tries to fix this for you by offsetting all coordinates to give you a frame of reference relative to the ship's actual center of mass, as if the origin was there. I discovered a place where it didn't do that but I think it's fixed now in the latest release. - The Y axis is fixed. Draw an imaginary arrow from the center of the primary body through its north pole. This is always the direction of the Y axis. The origin isn't AT the center of the body, but it's Y axis is oriented to be in line with the body's north pole axis direction. Note this is NOT the same as the "north" direction, because of curvature of the surface. i.e. if you were at latitude 45 degrees, then the Y axis would be pointing toward the north but pitched up 45 degrees above the horizon. If you were at the north pole, the Y axis would be pointing straight up. - The X and Z axes are always perpendicular to the body's equator plane, 90 degrees apart from each other (obviously). BUT they are not fixed. This is the messy part, due to some really wacky stuff KSP does with the rotation of the planet (sometimes the planet rotates and the universe's coordinate grid stays still, while other times the universe's coordinate grid rotates and the planet stays still - it depends on what altitude you're at which method the game uses. As you get lower and closer to the terrain it becomes better to keep the planet fixed so the terrain doesn't get recalculated all the time, or so I've heard that's the explanation.) Anyway, the result of this is that it's impossible to say what the direction of the X and Z axes is because it all depends on how long you spent at low altitude and how long you spent at high altitude - how much of the time was the planet fixed and how much of the time was it rotating? I'm trying to come up with some good tools to hide a lot of this mess from the user, but I'm waiting on feedback from the others for approval or disapproval of my proposal before I embark upon trying to implement any of it (hint, hint).

I suspect that's going to be susceptible to large floating point error because you're multiplying two things one of which is rather small compared to the other (the vessel mass being many orders of magnitude smaller than the body mass), and then in the end dividing the end result by the small thing again (the vessel mass) to get the quantity you want, the acceleration from gravity. Multiplying the scale of a number up to a huge magnitude and then trying to cancel it back out again by dividing it back down tends to be more error prone than using calculations that keep everything in the same general magnitude. For example, if you want to calculate what is 99.99999999% of 5000, this way of doing it: set x to 5000 * (9999999999/10000000000). ends up being more accurate than this way: set x to (5000 * 9999999999) / 10000000000. even though in principle they should be mathematically identical. (assuming I typed the correct number of zeros there.) So you're going to be better off cancelling out the mass of the vessel in paper algebra first before calculating anything on the computer. (It does cancel out - left as an exercise for the reader, if the only thing you're interested in calculating in the end is vesselGPull).

There is a different mod that takes the approach of just being a sever that makes a RPC bridge between KSP's API and other processes you run externally to KSP. It might give you something a bit like what you're asking for. http://forum.kerbalspaceprogram.com/threads/69313-WIP-kRPC-A-language-agnostic-Remote-Procedure-Call-server-for-KSP I haven't used it so I can't give any advice on whether it gives you what you want, but I'm just guessing it might be closer to what you want.

Two problems: 1 - The acceleration at sea level from gravity in KSP is not 9.81 m/s^2. It's very very close to that, but not exactly. If you see 9.81 in the readout from the Gravioli device, remember that it's rounding to the hundredths place. 2 - You're better off using the actual Newtonian gravitation formula anyway if you're going to try something as precise as a hover script, as it's sensitive enough to need that level of precision - the reduction in weight due to altitude is enough to throw it off. I use this: lock heregrav to gConst*bodyMass/((altitude+bodyRadius)^2). (gConst is newton's gravitational constant, bodyMass is the planet/moon's mass, and bodyRadius is the planet/moon's radius from center to "sea level". You'll have to substitute those values in). From there on use heregrav in your calculations and you'll get the actual acceleration from gravity at your current location, dynamically updated as you go.

Those are descriptions of built-in TYPES rather than of built-in variable names. For example, it mentions "Vessel", but "Vessel" isn't a variable. It's the common type shared by both SHIP and TARGET. Come to think of it, that is a bit sloppy in the docs - perhaps there needs to be a section for built-in variable names, both to document how they work and as just a list of variable names to avoid if you're making up a name for your own homemade variable.

Can you show the parts where you SET THRUST to something, or SET ENGINE to something? I don't see that part in the screenshot. (Or are you operating under the assumption that these are built-in variables? Because they're not.).

Sigh. As it turns out, the Unity TextArea widget doesn't understand the concept of tabs, so when you indent your source code with tabs, the in-game editor won't even show one single space for them. Instead the widget assumes that hitting "TAB" means "go to next field", and as there is no next field, nothing happens. I'm not sure it's fixable. But serious editing should be done outside the game anyway, so I guess it's workable for quick-and-dirty looking at files.

The other thing people don't take into account is that a feature in the stock game requires that it works with every other feature in the stock game. This is as opposed to mods, which don't have to work with other mods because the mod's author can just say "well if you don't feel like running my mod then don't. If you like the other mod better then use it instead." That sort of approach doesn't work in the stock game. Also, mod writers don't have to find a good balance that makes everyone happy. If a mod changes the gameplay in such a way that only a minority of the players will like it, that's fine in a mod. It's not fine in the stock game to do that. My only worry is that they might have reached market saturation already during early release. By the time they are ready to sell the final product at full price instead of the early access discount, there might not be anyone left who'd be interested in buying it who hasn't bought it already.

The reason it's not surprising that men don't die the instant they hit middle age is because evolution doesn't have precise individual control over specific one-at-a-time traits in just one gender in its "toolbox" of settings it can tweak. Genes are spaghetti code awful programming. (More evidence against intelligent design there, and in favor of a 'design' in which there is no foresight - only the ability to make gradual small modifications that seek local maxima rather than global maxima because they can't 'see into the future' to pick the better long-term solution.) The spaghetti code mess of genetics means that often to get effect X, you get a lot more other effects along for the ride with it that are utterly unrelated. (i.e. trying to breed through artificial selection a tamer arctic fox resulted in a fox where the same gene that selected for tamer instincts also resulted in different fur color and a shorter snout shape more like a domestic dog. Again, genetic code is spaghetti code and none of it was set up for the benefit of logical sense.). So if there's a species where evolution is selecting in favor genes that allow the mothers to live long enough to rear their children to maturity, the same genetic settings that allow that to occur can have the side effect of letting the fathers live longer than they otherwise would have too, even though evolution might not "care" about them, so to speak. Evolutionary pressures that may be "trying" (so to speak) to kill off the fathers at 40 while letting the mothers live to 55 might not have a good set of "switches" available that isolates the effects on the two sexes that sharply. And on another unrelated point, the difference in lifespan between males and females is most pronounced in species where the males tend not to rear the offspring, but instead just leave the mothers after getting them pregnant. Species that mate and remain a couple together and share in the rearing of the offspring tend to have males living closer to the same age as females. Too high a ratio of deadbeat dads tends to be a detriment to male longevity.

As I understand it the big hurdle to RemoteTech integration is that its impossible to raise issues with the development on the RemoteTech side of things, as there is currently nobody managing the RemoteTech github codebase. Therefore when something RemoteTech is doing is interfering with kOS, and is impossible to work around, but is easily fixed with a few tiny changes to the RT code, and these changes are even implemented and submitted entirely by kOS developers, it still can't be dealt with because there's nobody on the RT side of things currently paying attention to the requested changes to put them into the main RT code. The only workaround would be if kOS developers Forked remoteTech, and offered their OWN variant of it to download with kOS. And that would mean taking on a lot of additional responsibilities.

One word of warning: Make sure the location of the archive folder is an easy config option to change in your code. It may be changing soon. Also, read this github entry: https://github.com/KSP-KOS/KOS/issues/110 if you plan to work on this area, to make sure you know what devs have been saying about it.

I tried to recreate this problem and I couldn't get it to happen. After the plane got to an altitude of about 10000 I figured it wasn't going to happen and I quit. You're not the only one to report 'out of sync', and I've seen it too once in a while but I just can't get it to happen when I'm looking for it.

I think this thread is using the word "believable" incorrectly from the start. It sounds like what it's describing is not believability but rather internal consistency. That what it's advocating is that theres' nothing wrong with making things that behave in ways you don't believe could really happen *IN OUR WORLD* (which is what "believable" actually means) so long as they look like they could work that way in *some alternate setting* because they are operating on consistent rules that at least agree with themselves. Good sci-fi invents alternate rules for its universe and makes them consistent and sticks by them. Bad Sci-fi just makes up whatever the author felt like on the spot for that one plot to work and then moves on ignoring that this was said by the next episode, making up completely contradictory things for the next episode. A lot of TV shows suffer from this problem because different episodes are written by different scriptwriters who didn't all get together in a meeting and share notes.

"Surface speed" in KSP doesn't mean what you're thinking it means. It's not your speed relative to the ground at altitude zero AGL underneath you. - it's your speed relative to whatever "part" of the planet is at your altitude right now. If you're not on the ground, then it's your speed relative to the "airy" part of the planet (i.e. atmosphere) that surrounds you, which is "glued" to the ground, so to speak. If your radius to the center of the planet is bigger because you're at a higher altitude, and therefore the circumference you travel in one Kerbin day is bigger, and thus the planetary speed due to rotation is bigger, then all this *IS* taken into account in calculating what is reported a "surface speed". What the game calls "surface" speed is really your speed in the planetary rotating frame of reference as opposed to your speed in a frame of reference glued to the space around the planet (the orbit speed).

The mod *tries* to use the actual resource name from the game's database, rather than hardcoding it. (So for example, if you say "print ship:solidfuel.", the word "solidfuel" isn't hardcoded inside kOS. It's just saying "I don't have any special meaning set aside for the term 'solidfuel', so fallback on asking Kerbal Space Program if there's a resource by that name on the ship. Oh look there is. Okay I'll return that then.") So if RealFuels works by adding the resource to the actual KSP data itself, then in principle kOS should be able to read it when you say "ship:SOMENAME" where "SOMENAME" is whatever the resource is called. Click on the resources popup in the upper-right corner of the screen in KSP and see if the fuel from RealFuels shows up there along with electriccharge, monoprop, and so on. If it does, then use the name as it appears on that popup window as the word you use in your kOS code.

Others have had this happen too. I've got a ship design that when I use LOCK STEERING it see-saws madly on the roll-axis (the axis you rotate around when using the "Q" and "E" keys), to the point where it's swinging back and forth on an arc of about 270 degrees. As I understand it, and I haven't looked at it so this is word-of-mouth from erendrake, it's happening because the steering controller logic isn't using a good dampening algorithm. (i.e. nothing like a PID controller), and is instead completely reliant on the fast speed of execution to allow it to steer entirely by looking at the current position and ignoring the current rotational velocity. That can set up oscillations in craft that have a lag between control input and ship reaction. If there's a lot of parts that can twist when rotated, and the ship has a lot of powerful torque, the oscillations can get bad. My only advice for now is build ships as ridigly as possible. Making the steering algorithm better is on the list of future things to do, but there were bigger bugs to hit first.

If I saw evidence that there were plans to add more interesting details to the existing worlds I'd consider this argument a good one. But update after update they keep the worlds very generic and empty (in fact if anything there's been a trend toward making the worlds MORE empty lately as former easter eggs get removed or hidden underneath the terrain). So if we can't get more interesting worlds by improving the ones we have, can we at least get a variety of configurations for how the worlds interreact with each other - by putting them in new and unique positons and orbits and the like.