Eric S

I'll second that. I prefer KER in the VAB, but really like MJ's ability to customize the windows when I'm flying something. Lets me have the information I need but just that information, so it doesn't have to clutter up the screen.

I can only think of two things that would bother me if they lost massless status, both because they're normally placed non-symmetrically. Ladders and aircraft wheels, and maybe some of the smaller experiments.

Just to clear up the confusion, EVA reports transmitted at 50% in 0.22, changed to 100% in 0.23. Crew reports were at 100% in both.

I, as well most of my friends that I've bought KSP for, are well into the 36+ bracket, and would probably still be in the upper bracket if you split that bracket :-)

Having a preference for playing with FAR, I think you overstate it a bit (at least for rockets), though I do agree that more realistic aerodynamics is probably going to be the biggest relearning-causing improvement. My normal rockets mostly just required nosecones on radially attached stacks with FAR even with my more aggressive asparagus-staged launchers. Yes, when you get into asparagus pancakes that are wider than they are tall, there will be issues, but I don't think those are really as common as some people seem to think. When I'm balancing a large, non-aerodynamic rover on top of a rocket, yes, I have to pay a lot more attention.

Actually, I find ejection angle far more finicky than phase angle, but I really can't disagree with anything you said. When i do this, I start off making a single maneuver node to do the transfer. Then, I bump the maneuver node backwards in time, with the time I bump it back depending on whether I'll need one or two passes to get about 800 m/s delta-v. That keeps me below the Mun's orbit, and I've had too many times that the Mun has flung my craft out of Kerbin's SoI at the wrong velocity and angle to be tempted by the improved efficiency that a higher apoapsis would get me. Also note that the higher the apoapsis, the more you have to adjust your initial burn, since you're increasing the orbital period. Once I've got the first maneuver node, I just set up one or two subsequent maneuver nodes at periapsis that all sum up to the proper transfer velocity, maybe with a small amount extra due to inefficiency on the last burn (though I've never had to do a couple hundred). Other comments: If you're going to be doing a long burn on your last orbit, you might want to avoid too low a parking orbit. I usually use an 80k parking orbit for interplanetary transfers, and every once in a while if I'm not paying attention, I'll wind up with the last pass of my orbital transfer burning long enough it actually pushes the trajectory into the atmosphere, which is bad. However, trying to do the transfer with a low TWR in a single burn just makes that issue even more pronounced. Basically, except for timing the departure, any issues that the multi-pass burn has would be worse trying to do the burn in a single pass at the same TWR.

I doubt using FAR would inhibit Whackjob much. I've launched my fair share of monstrosities with FAR enabled. At the worst case, it usually involved a lower TWR and/or some extra delta-v so I could take things slow. To me, FAR feels more like it's about rewarding doing it right than punishing doing it wrong. Personally, I'm in favor of being able to turn reentry heat or life support on or off as an option, but not better aerodynamics. In the former two cases, it's strictly disabling some functionality. With aerodynamics, you're switching between functionality. Or to put it another way, reentry heat probably means you add a heat shield. Life support might mean adding storage for life support resources. Changing the way aerodynamics works means potentially undoing something in order to make it work differently. So it's the difference between learning new things and unlearning bad habits combined with learning new things.

The devs agree with you, or at least did last time they discussed difficulty settings. They weren't interested in having a single difficulty setting, but rather having certain options that could be turned on or off. Reentry heat and life support are two of the things that they discussed that, if implemented, could be disabled this way. Yes, there's a lot of if/could type words there, I wouldn't count on both making it into the stock game. In fact, the only time they discussed life support favorably, they were also talking about resource mining, so I wouldn't be surprised if no resources means no life support. As for the "hassle" of having to set a bunch of options, I don't see it that way if done well. First, at worst, you'd only have to deal with them when you create a save file or want to alter the settings. I probably create one or two save files a week at most, except for the week a new version comes out. Second, most games I play that have these kinds of settings instead of a strict difficulty setting give you two or three buttons, one for a game with default settings, one for a game with the previous settings, and one for "OK, let me specify everything." Since we don't currently have to reset key bindings, audio settings, etc. every time we create a save file, I don't see why we would assume that the difficulty settings couldn't be persistent either.

While they've changed their minds and may change it again (or may have already done so), the last time I heard a dev comment on adding stock reentry heat, they said that it would be something that could be turned off. Sadly, I can't reference it because it occurred during the lost months after the great oops.

As I understand it, the "recovered vessel from" science is specific to the control pod that landed there, and doesn't transfer. To make matters worse, you can only get one "recovered vessel from" per pod, so if you were to do a grand tour and land on every body, you'd only get points for the one most valuable landing place.

If you're throwing it in a retrograde orbit, down near Moho would be a much bigger pain than by Eloo, killing twice Moho's orbital velocity would be a much greater pain than twice Eloo's. Of course, we'd all just do a plane change far above Eloo. So then, instead of placing it near Moho's orbit, we place it IN Moho's orbit, retrograde. so you have less than 13 days to reach it before it collides with Moho. Then some mechanism so that the craft that placed the last asteroid has to be the one to make the rendezvous :-)

You're implying that they're saying something they're not. Here's what you quoted: To which you replied: Given the phrase "the use of features we're not familiar with" I really don't think that they're discussing tracking the number of mods that are available, but rather having enough familiarity with those mods to be familiar with the features of all those mods. So yes, I do think my reply targets what they seem to be saying. It's your reply referring to tracking the number of mods that seems to miss the point. We don't have to argue about whether or not they can know how many mods are out there. Either they can't, in which case it's very unlikely that they know all the features of them, or they can, which doesn't by itself gain them the ability to know enough about them all to provide support for them.

There's quite a difference between knowing that a mod exists and knowing how it impacts the game, particularly in combination with any other mods that might interact with that mod. We've seen cases where while mod A and mod B work fine individually, the game crashes if you install both of them. That takes the knowledge and testing required to meet your expectations through the roof.

I look forward to the day they replace that placeholder. But right now, they're working on things that don't even have placeholders, like budgets.

I'll second that. The number of times I'm doing multi-craft missions, converting the "human readable" times into UT to do math and then convert it all back to human readable times so that I could adjust my orbital periods so that a craft hits its mark right on the spot gets silly :-)

My first mothership-style mission originally started as an unmanned probe where I wanted to drop a probe on every moon of Jul in a single mission. Before too long, it had turned into a 300+ ton (in orbit, not on the launch pad) ship composed of four pieces docked in orbit, with eight probes, two landers, hydroponics bays, a rotating exercise ring, and room for 20 kerbals, though I only sent 8. Not the first time or the last time I got carried away, but the most memorable.

I've done aerocapture with FAR installed, so I know it's possible, I just can't remember how far down I had to go. I do remember that I had to use a lower periapsis than with stock. Part of it is that if you're coming in at higher interplanetary speeds, you'll want to aerocapture in multiple passes (I aim for the first pass to be lower than the Mun's orbit, just to avoid getting thrown out of the Kerbin system). Also, if you also have Deadly Reentry installed, you'll need a heatshield for all but the most gentle of captures.

To be honest, unless you disable all saving and loading, you still won't know for certain. They could set things up, exit the program, back up the save file, start the program again, and try it. If they fail, exit, restore the save, and try again.

You apparently missed the thread when career mode was announced where using just the tier 0 parts at least one person did a manned Duna return mission. Admittedly, this was without science parts, but it was also without decouplers. At this time, yes. If/when Ike gets biomes, things could change. I doubt Duna getting biomes would make a difference at this tech level as biome hopping in Duna's gravity well would be a pain. It could also change once reputation/budgets/contracts come into game. It may be the decision of "Do I go for easy science, or for the bigger reputation reward?" I wouldn't mind seeing Minmus get a slight nerf on its science multiplier, but I also don't have problems with Minmus being an effective place for science. Some people don't go to other planets easily, and nerfing Minmus too far could force them into doing it before they're ready.

Which trades the inefficiency on yaw/pitch for inefficency on the roll axis. Like I said, not the biggest of problems, just have to stomp the perfectionist in me. You'd think he'd already be under the desk whimpering with how far from perfect I am :-)

This is a very valid point. Anyone that can build a craft that can hit half of Minmus' biomes in a single trip can get to Duna and Ike with the same tech. When/if biomes get added to Duna and Ike, then we'll have a better idea of how well the rewards are balanced.

If the quads don't line up with the cardinal directions, you lose some efficiency and control. Not large amounts, but some. My OCD tends to war over efficiency vs not running ladders over the quads :-) Not something a sane person really needs to worry about much.

I like it :-) The centered hatch means that ladders are going to be running over RCS quads, but I'm still going to get my hands on it to play with :-)

Actually, hohmann transfers can take various amounts of time depending on the amount of delta-v allocated to getting into/out of the transfer orbit. The most efficient hohmann transfers involve one planet at the periapse, one at the apoapsis of the transfer orbit, but that's not required. By injecting the craft into an orbit where the periapse is below the lower planet, the apoapsis is above the higher planet, but both planets intersect the transfer orbit at the correct time, you can shorten transfer times at the cost of delta-v at both ends. If you go to http://alexmoon.github.io/ksp/ you'll find a calculator that tells you the correct phase angle/ejection angle/ejection delta-v/etc to get from one planet to another at almost any time. By the time you're talking about burning 15k-102k delta-v (depending on the phase angle) to go from Kerbin to Duna, you're arriving in about 30 days, as opposed to the 264+ days of the delta-v-optimal transfer. Beyond this, there are transfers that are constant thrust maneuvers, but these tend to dramatically increase the fuel required unless you're talking low-thrust craft, so you'd probably only see them in KSP if you're using far-future engines or the infinite fuel setting.

The aerodynamic model in KSP is at best a gross approximation that was never intended to handle aircraft or anything else beyond a rocket going up and a capsule coming down. It's a placeholder that was created early on in KSP just to get things working. The devs have said in the past that they intend on replacing it at some point, but they haven't commented on it recently, so it's possible that it may slip between the cracks or they may change their minds.