antiquark

Also known as "The Infiniglide Bug."

More realistic aerodynamics!

Try watching some 0.22 vids on youtube, all the latest features are explained.

I wish there was some way to avoid all the waits in the game. There are situations where you just have to sit there and watch for minute after agonizing minute, basically doing nothing, but you have to sit there so you don't miss an important action at the end of your wait. For example: - Warping. If you want to warp to your encounter with Jool, you just have to sit there watching the timer count down. You can't go do something else in the meantime, because you might miss your encounter and go flying off into a useless orbit. - Burning. If you want to run a nuclear engine burn, some of those take 15 minutes! Like with warping, you can't go do something else in the meantime, you just have to sit there and watch, to make sure you don't miss the end of the burn. - Flying. Say you want to fly halfway around Kerbin. That means, sitting there and watching for 30 minutes! You can't activate an autopilot and go sleep for a while (like pilots do in the real world). You have to periodically adjust your pitch. - Rovering. Similar to flying, say you want to rove over a wide plain. Same problem, you're mostly just sitting and watching. The physics warp "sort of" helps, but it seems to cause unstability and other problems. Also you still have to wait, because physics warp only goes up to 4x. I formed these opinions after playing .22 with no MechJeb. I could do it, I got through the science tree twice, but man, the waiting... the waiting...

Which wheels work best for Mun rovers? Due to the pain of getting there, I haven't done much testing on the actual Mun itself. The "balloon tires" seem OK, they aren't as grippy, but this has the advantage of not flipping over so much. The "curiosity rover" wheels seem really grippy, but they bite into the ground a lot, and if you brake too sharply or turn too fast you'll flip over. Do the "curiosity rover" wheels work better when climbing steep hills? So many questions...

Are there more science points if you repeatedly transmit by radio, or if you "save them" (no transmitting) and return to Kerbin?

Forgot the ladders!

You might be looking for something like this: http://en.wikipedia.org/wiki/Mars_cycler http://en.wikipedia.org/wiki/Lunar_cycler "A Mars cycler (or Earth-Mars cycler) is a special kind of spacecraft trajectory that encounters Earth and Mars on a regular basis. " "Cyclers are potentially useful for transporting people or materials using little propellant. Instead, they rely on gravity assist manoeuvres to keep them going[1] with occasional powered corrections to maintain the trajectory.[2]"

MechJeb has an info display in the VAB for all sorts of parameters, weight, delta-V per stage, etc.

Are you sure you didn't accidentally leave "cheat mode" on? It's happened to me...

Repped. Would be interesting to experiment to see what part has the greatest "shock absorber" value.

To reply to myself, maybe not. I took a one of my strutless planes (82 parts), parked several of them along the runway, and kept track of the frame rate. * 1 plane = 45 fps * 2 planes = 30 fps * 3 planes = 5 fps (!!!) Now the fact that it went from 30 fps to 5 fps with the addition of one plane, indicates that there's something erroneous about the performance optimizations. You would expect it to have a smooth transition as more planes are added, not a precipitous drop in performance all of a sudden! My question is, what's happening in the code itself when you go from 2 to 3 planes? Dear Devs: time to activate that profiler in the source code!

Actually I get the impression that struts slow things down a lot. If you run tests with strut-free designs, they seem to have a pretty good frame rate.

I doubt it! The way in which performance degrades shows that they're not optimizing things at the higher levels. I.e. four spaceplanes parked alongside the runway, shouldn't result in a lagfest.

I would agree with the OP, and add that the lagginess seems more due to some high-order optimization that needs to be fixed. As in-- no I don't think that we have to get into the assembly code of the Unity engine, but rather, something is being done in a crude manner that could be streamlined. Here's an experiment you can run yourself. Put a plane on the runway, and look at the frame rate. Then park that plane off to the side, and launch another plane. Keep parking them off to the side and keep track of the framerates. Here's what I saw: - 1 plane = 30 fps (yay!) - 4 planes = 3 fps (I want my money back!) My guess is that the collision box of every part in every plane is being checked with the collision box of every part in every other plane. So you'd get an "N-squared" effect in performance. That could be streamlined for sure. Also I would like to mention that multicore is no panacea! Only certain forms of algorithms are suitable for multicore. The idea of simply recompiling code to play nice with multicore is a pipe dream.

This, to the power of infinity!

Yes, MechJeb lets you bypass the parts of the game that simply aren't fun. Such as, warping to the next node, or keeping aimed while burning at the node.

The terrain has changed in the latest version, it seems like there are no "landing strips" anymore.

Someone will create a "Zombie Mod" so that deceased astronauts, can continue flying!

Has anyone mapped the 0.21 version of Duna yet? The page at http://wiki.kerbalspaceprogram.com/wiki/Duna is a little out of date. I'm trying to find a low-lying area is, so I can land a glider.

I don't know about realistic, the old Duna was quite Mars-like. For example take a look at this actual Mars picture:

Has anyone tried to land an aircraft on the new Duna? The dried lakebeds were convenient landing strips in the earlier version.

Realistic aerodynamics!

Also, regarding the two vs three J2x engines, I've heard that they're still studying the alternatives, and haven't decided on the number yet.