Keldor

Does this mean there are now default settings for different keyboard layouts?? That's awesome! I use Dvorak, and setting 999 keybindings every time there's an update is a real headache...

I'm getting NaNs in Trajectory Planner when I'm trying to go from Kerbin to Aptur. I have a suspicion that they actually have SOIs that overlap during closest approach. This should probably be looked over and have orbits tweaked as necessary, since I don't even want to think about what bugs might happen if you have, for instance, a satellite fly through the overlapping area.

Bug report: The mod doesn't seem to properly handle NaNs, though it's doing it halfway right. The pork chop graph isn't drawn correctly. I blame the New Horizons planet pack, since I strongly suspect two particular muns of having overlapping SOIs. In any case... Fix: 1. Calculate min and max DV, but make sure to check for and disregard any NaNs. 2. Create a second buffer (you still want it to display NaN when you mouseover the appropriate spots), flushing NaNs to something like System.Single.MaxValue. This will give you a valid buffer to display the pork chop graph. Make sure to derive the color gradient from the values obtained in (1).

Wouldn't the depth map be floating point in any remotely modern GPU implementation? In that case, doing a 1/z transformation is superfluous, since floats are pseudo-logarithmic in the first place and can cover a vast range without loosing precision for small numbers. Should be 3.4E-38 to 3.4E+38 for single precision, which is enough to cover both universe scale and subatomic scale in the same coordinate system. Since floating point is essentially scientific notation for computers, you get about 6-7 digits of precision at all scales. 1/z was common historically when depth buffers were integer, for what it's worth, though the reciprocal operation is expensive, or at least was back in the days where 1 TFlops wasn't the norm for mid-range GPUs.

A SSTO from Eve is truly impressive. But we're still missing a very important step: Landing. In order to get the mass down low enough, our best engineers stripped away all non-essentials, leaving us a craft with huge heavy fuel tanks, minimal wings, and toothpick landing gear, which must almost certainly glide down for an unpowered pinpoint landing on a mountain top of a planet with nearly twice the gravity of Kerbin. Failing this, any landing, somewhere generally near to the mountain and with empty tanks, is also acceptable, if we assume the kerbals built the infrastructure to refuel the thing and tow it to the mountain top before launch. Can you do it??

One thing I've noticed is that there's a bug with wheel traction in physics warp. It seems to stay the same while the rest of the world moves faster, so it's like driving on ice. Thus, if you need to climb something, make sure to go to 1x time!

One thing you could try is tilting the back of the winglets inward. Then when you sideslip, it should tend to pull you back forward.

You could always use the torque the reaction wheels are able to produce against their power consumption to get a estimate for power conversion. This would have the advantage of being physically accurate, no matter what strange amounts of power various sources produce. Bonus points for then determining the luminosity of Kerbol from this and the size of the solar panels. Don't forget to factor in heat loss on each stage! Use heat dissipation, surface area, and the thermometer. Oh, and you should be able to figure out the halflife of the isotope used in the RTGs from their power production and mass. It would be interesting to see exactly how ridiculous the in game numbers are.

Now that New Horizons has finally reached Pluto... Are we going to see Plock finished any time soon?

I picture the kerbals going to Tylo to fake a Mun landing. They'd have a lovely shot, with Jool in the background, "oceans" crudely painted on so it looks like Kerbin.

As far as big, bulky science modules are concerned, remember that you can EVA a kerbal and have them retrieve the science from the modules and stash it in the command pod. This frees you from having to recover anything else.

It would be even better to just have physicsless parts add their mass to whatever they're attached to.

I think someone needs to audit your mission planning department, Yakky.

Looks like OSX supports BASH scripts, and will run them on ordinary double click with the extension .command. Anyone want to try this? Something like (I don't know the name of the exe off hand, but you get the idea.): cd $(dirname "$0") mono CKAN.exe

You are aware that KSP itself is a .NET program running under Mono? The Unity engine itself uses .NET...

I seem to remember Scott Manley doing a flying box (in stock). He used the rectangular wing segments instead of plates, which are bigger and thus you need fewer. You could try soomething like that.

I agree. A "kill timewarp" key is something I've missed too.

KSP seems to be a very good candidate for HDR rendering since there's such a massive difference in brightness between say a planet, the sun, and stars. I think the game would look vastly better with proper HDR tone mapping (you can see during the night, but the back side of planets are dark when you're in the sun, etc. Now, before anyone says anything, HDR is *not* about cheesy bloom effects, it's about proper contrast between light and dark.

Lovely little bug - Texture Replacer is spamming the error log with this: Hundreds of thousands of times. Probably every frame.

Quick fix for Z-fighting bug: In vertex shader: 1. Get normal. 2. If normal points toward the camera (front facing), bias the vertex toward the camera. If it points away from the camera (back facing), bias the vertex away from the camera. This should give some space between the planet surface and the cloud layer, meaning it won't be as sensitive to precision, and since you'll be moving vertices directly toward and away from the camera, the actual image should be almost completely unaffected. Bias in proportion to distance from camera - the Z-buffer is floating point! 3. Make sure shading is done using the original, unperturbed vertex. For city lights vs. clouds, bias the lights some and the clouds more. The idea is to artificially add space between the layers. Improvement for city lights: Instead of an ordinary blended crossover in the shader, use a threshold. This hopefully will make the lights look crisp and not blurry. Something along the lines of: Pixel Shader: if (detailLightMapLookup > (1-coarseLightMapLookup)) lightContribution = (detailLightMapLookup-(1-coarseLightMapLookup))/coarseLightMapLookup //remap the light brightness to [0-1] else lightContribution = 0; Make sure it doesn't spit out NaNs when coarseLightMapLoookup=0 (you can tell NaNs when the pixel renders black). It *should* take the fallthrough case where lightContribution = 0. Possibly multiply in some ordinary crossover or look at ddx and ddx to smooth things. Do you have compile instructions? I'd like to tinker with it and see if I can get this stuff working.

How about setting the initial extension/rotation of the parts, in particular, hinges? It's tricky to build folding apparatus when you're stuck with 0 and 180 degrees.

How about adding some randomization to the aerodynamic failure point? In real life, the exact point at which something breaks is unpredictable and random, so this would make disintegration look more realistic, since instead of both wings falling off at the exact same time, one would fail, the craft would turn sharply as a result, which would force the other to fail. Much more interesting looking. The current failure point could just be treated as a lower bound where things might break.

One idea would be a longish term experiment rewarding a player for putting a probe in orbit in the first place, rather than just doing a flyby. So the duration of the experiment would just be perhaps 10 orbits or so - too long to fit in a flyby, but short enough that it's only a brief timewarp.

As far as stability in FAR is concerned, you just want to keep your center of drag below/behind your center of mass. Think of the CoM as a pivot, which the rocket swings around. Then the end with more drag wants to go around to the back. Adding tail fins, as you said, adds more drag to the end of the rocket, thus pulling it around to the back as it moves through the atmosphere. Conversely, having a big fat payload at the top of the rocket adds drag up there, which will make it want to flip over so the center of drag goes behind the center of mass.

Ion engines are your friends here, since their low thrust is perfect for fine-tuning your orbit.