Keldor

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).

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.