Eric S

As the 5thHorseman said, sometimes it gives the best delta-v results. Basically, the engine gives twice as much total thrust from the same amount of fuel as any of the stock engines except the ion engine, so if you're using any significant amount of fuel, the extra fuel mass you'd have to bring would be more than the extra mass of the engine. Now, if you design small focused probes, you're less likely to need the fuel amounts that would make the LV-N worth it. Basically, as the mass of the craft increases, whether from payload or from fuel, the delta-v you get from an LV-N increases compared to the amount of delta-v you'd get from any other engine. This is more true in the case of the payload mass increasing than fuel mass, but it's still true in either case. Even the lightest stock pod, the OKTO2, on top of an FL-T800 fuel tank, gets more delta-V from an LV-N, despite it's extra mass, than it would from an LV-909 or a Rockomax 48-7S. Now, I'll admit that in the case of a probe that light, you'd be better off breaking it into separate stages or adding drop tanks from the delta-v point of view, but as your payload mass goes up, that gains less and less.

Actually, it's throughput isn't the best, the other two antennas are faster, they just have a throughput stat that is inversely proportional to the actual throughput. I did some tests from the launchpad to confirm this, the small dish is 20% faster, the larger dish is 40% faster, if I remember correctly (I did this back when 0.22 was first released).

Easiest way to get "flying over" is to either do the EVA report while on a ladder or jump into the air and take the EVA report before you hit the ground. For "high atmosphere" the easiest way is actually during launch. Just wait until you're coasting to your apoapsis, somewhere between 40 and 60 km, and EVA while the rocket coasts.

NM, you answered that question and I overlooked it. EDIT: To be clear, I was asking a question someone else had already asked and hadn't seen the answer, so I deleted the question.

Curious as to what your reasoning on this is. It seems to me that you'd be punishing the people that can get to orbit but can't get to the Mun/Minmus on the very early parts this way, with no upside. What benefit do you see?

What makes science too easy right now is that it's the only part of career mode that's implemented, so people can focus on it singlemindedly and without any limitations that the rest of career mode might bring. That said, I wouldn't object to a reduction in the below-Kerbin-orbit science multipliers, since they never play a significant role in the amount of science I get.

That thread was closed because part failure was on the "do not suggest" list. The devs have stated that they will not have a single difficulty control, so that tends to be treated as being on the "do not suggest" list. The devs have said that they're considering certain features being individually disableable if implemented (reentry heat and life support, as I recall), which is probably where the idea that they'll have difficulty selection comes from.

Pretty much this. The reason that they haven't done it yet is because it isn't trivial (even FAR, which is more complicated than your description is really only an approximation) and they have other things that they consider more important. When they run out of things to do that they consider more important, they'll get around to it.

When I did this, I didn't turn on SAS to begin with. Tail fins kept it going mostly straight, and a few sepratrons (thrust tweaked to burn longer) pointed sideways triggering when the second stage went off started the gravity turn. A few stages of pairs of sepratrons let me adjust my periapsis, with the only real difficulty being the fact that once the craft left the atmosphere, it didn't continue to point prograde. Other than that last issue, orbiting without pressing anything but the spacebar is actually rather easy, but as you said, not consistent.

Are you talking which way you launch into Kerbin orbit, or which way you leave Kerbin to travel to the planet? All these answers apply to the latter. For the former, you don't actually have to, that was a mistake early on on one explanitory page that never got completely cleaned up. For highest efficiency, you can still launch into a prograde orbit of Kerbin, you just do your ejection burn early on the day side of Kerbin instead of early on the night side.

Agreed. I've used the Skipper as my launch engine, I've never used a poodle to launch off of Kerbin. It's rare enough that I use one to circularize, and I'm not at all tempted to use one until I've at least got some other 2.5m engine to get it up there.

Definitely SCANSat. There's also ISA MapSat (probably the one you referred to as unsupported), but SCANSat does more and gives me fewer problems.

Yes, all velocity is relative to something (and gravity assists depend on this fact), and I don't have a precise answer to this, though I suspect it's because if nothing else, you'd need to pay attention to the energy in all the gravity wells you'd have to traverse to get from where you are to your point of reference. I never made it that far in physics in college before getting distracted by how much money my pre-graduate programming skills could earn me in the "real world." Here's the thing. If you ignore gravity and other external effects, the Oberth effect is just navel gazing. It's neat that speeding up from 20 m/s to 30 m/s gives you more energy than speeding up from 10 m/s to 20 m/s, but since it took the same amount of delta-v (the very definition of delta-v) and delta-v isn't affected by your velocity (assuming you're not in an atmosphere), that's all it is. The Oberth effect doesn't affect how far you can travel or how fast until those external forces come into play, and gravity is the most common external effect that we deal with. Atmospheric resistance is probably the only other one we deal with in this game as far as navigation is concerned. So while the Oberth effect itself doesn't require the presence of gravity, it's kind of useless without it (which isn't the same as not existing without an external force). The Oberth effect is about energy, and gravity wells are about kinetic and potential energy (at any point in an orbit, the sum of your kinetic and potential energy should be the same value). The Oberth effect is about how much delta-v it takes to increase/decrease your kinetic energy, which in turn affects your total energy. However, that's drifting back towards the "correct" explanation of the Oberth affect that I described previously. Not exactly, in both cases, the planet you're departing from is a more significant gravity well than the solar gravity well at the point you're departing from, so for purposes of escaping that gravity well, the solar gravity well isn't the important factor. In fact, because of the patched conics physics we work in, the solar gravity well doesn't even exist within Kerbin or Duna SoI (relative to the planet, that is), all that maters is the velocity vector you have relative to the Sun when you exit the planetary SoI and enter the Solar SoI. If you expend delta-v to accelerate inside the Solar SoI, then this would be a factor.

Correct, I really should have been more explicit, that's burn Mun-retrograde to give yourself a low Kerbin periapsis. If you're going to Duna, for example, you'll only need a 250 m/s or so burn to depart the Mun, then another 200-300 m/s burn at kerbin periapsis to get the desired ejection velocity (not certain of the numbers, when I do this I usually use Minmus). The only reason I'd orbit that high around the Mun is if I'm going for "High Orbit" research or SCANSat work.

Yes, ignoring all of how you got there and how you refueled, a transfer directly from the Mun's orbit is more efficient. However, you can ramp up the efficiency if you want to try for a maneuver with a tighter margin of error. If instead of burning in the direction of the Mun's prograde, if you burn retrograde, dropping your periapsis down to 70-100 km, and then burn ship-prograde at that point, the Oberth effect kicks in, saving you even more. The timing can be tricky, so don't try it if you're not willing to experiment. I strongly recommend quicksaves before the leaving-Mun burn if you try this.

Dave is correct. To give a bit more of an explanation, it basically comes down to this. Consider the baseline being how you do this. Velocity X is just enough velocity for you to coast to the edge of the SoI. If you increase this velocity slightly, say X+Y, then because of the way the energy is conserved, when you reach the SoI, you haven't lost all of your X speed this time, so you're moving faster than Y when you reach the SoI. You can imagine this "free" velocity coming from one of two places. First, the actual "correct" explanation is that the amount of kinetic energy an object has is 1/2*(mass of object)*(velocity squared). Escaping the gravity well costs a fixed amount of energy. So, if it takes x velocity to escape and we add one extra m/s, we have 1/2*mass*((x+1)squared) energy. We extract the energy of x, and this leaves us with 1/2*mass*(2x+1) energy, which as long as x is larger than 0, means that we have more velocity than the "extra" amount we put in. The larger x is (meaning the gravity well is stronger), the more "free" velocity you gained. If looking at it from a mathmatical/physics point of view is too much, then think of it this way. Think of x as escape velocity, the amount of acceleration backwards the gravity well is going to produce on the craft while the craft moves to the SoI boundary, assuming it hits zero velocity right at the SoI boundary. Now, if you move faster, gravity has less time to slow you down, so you get slowed down by a total velocity of less than x, which means that in addition to keeping the extra velocity, you get to keep some of the base x velocity as well. The implications of the Oberth effect are all over the place in this game, and knowing about it and its implications will help a lot. For example, this also explains why a higher orbit is actually less efficient for achieving a planetary transfer from, because a higher orbit will have a smaller x value.

From what I gather, progress is being made, but it's not a focus of the devs, so the progress is slow. One of the Squad devs implied that the version of Unity in 0.23 was much closer to being stable in a win-64 environment, but still not close enough. Given that one of the bugs fixed between the version of Unity used in 0.22 and 0.23 was "random crashes while raycasting (win-64 only)" and KSP does a lot of raycasting, it may be just that one bug fix that makes it seem much more stable.

Not necessarily, you're at the very least throwing more parts at new players and avoiding that was a major consideration in how they set up the tech tree. I do think that plane parts could come earlier, but not level zero, and probably not level one.

Please tell me it will allow for events, instead of just always running in a loop, preferably with a timer event that runs off of game time rather than real time :-) Oh, and a "computer reset" event for quickloads, unless you go so far as to save the program and state in the quicksave file. I'd think keep it to a single, potentially upgradeable part. Have the part limits specified in the .cfg file, possibly overridden by tweakables. Keep it simple, because as was said, I don't see where complicating the installation of the device would add much in this case. It's about being able to preprogram maneuvers, not computer maintenance. Not sure if CPU speed limitations could be easily enforced, that would probably depend on the interpreter in question. Memory limits could probably be enforced and optionally upgradeable. You'll probably want to implement some sort of loadable modules (preferably with the ability to unload a module, though that gets tricky) so that you don't need the entire program in a single file, though that would be an acceptable limitation if it isn't easy to implement. And then it occurs to me I'm giving you suggestions you didn't ask for, so I'll shut up for now :-)

I agree that this is a reason to examine your methodology more than anything else, and I don't mean to sound like I'm insulting you or anything, this game has a learning curve. I've unlocked the whole tech tree before I bothered using any engines larger than the starting engine, but I know the science fairly well. If you can't get to orbit with the starting parts, either your ship design or your piloting skills are off. If you want to try the craft I use to do this to narrow down the ship design/piloting skill question, it's pretty basic. Mk 1 capsule, parachute on top, 10 FL-T200 tanks under it, and an LV-T30 engine under those. Maybe a Communotron-16 antenna to send crew reports on the way up. You'll come down a bit fast, but the fuel tanks make for a nice crumple zone, sacrificing themselves to save the capsule. If you can get to orbit but aren't getting at least 100 science points on your first flight, then you may not know the science system as well as you think. I'm not talking the really impressive first missions where you go to multiple planets, I'm talking orbiting kerbin, never going higher than 260 km or so. I've managed over 130 points on that kind of flight without transmission spam. Just the EVA reports over 9 biomes plus one in high orbit should be 80 points, though you'll get fewer biomes if you're in an equatorial orbit instead of a polar one (6 if I remember correctly, so 24 fewer science points). An EVA report on the ladder before launch, an EVA report on the ladder while coasting to your apoapsis (but before you reach 68km altitude), an EVA report where you land, and probably one "flying over" where you landed. Then there's the crew reports. Even without an antenna, you can manage five crew reports, though that takes a trick that might be considered an exploit (I don't count this when I say you should get to 130 points). Then, points for a surface sample wherever you land and for recovering a craft that orbited kerbin. That many science points should unlock decouplers, batteries, mystery goo containers, and the materials science lab. My second mission actually a suborbital flight, just bringing along as many of those parts as I can, six of each with a 260 km apoapsis being ideal. I used to go to Minmus as my second mission, not necessarily landing, but with 0.23 bringing one shot goo/mat-sci parts, I like being a little more prepared before heading to Minmus or the Mun. As far as the tree goes, I tend to focus on getting things in the following order: T1, all of T2, beeline for solar panels (through Science Tech, not flight controls), beeline for fuel lines (through General Construction, not Advanced Rocketry). Once I've got all that, I usually focus on the science nodes that grant more science parts. To me, having the negative gravioli detector is far more important than having the 2.5 meter rocket parts, especially now that Minmus has biomes. The negative gravioli detector works on the surface, in "space near" and "high above" and respects biomes at all three of those, so that's 27 experiment results for Minmus and 45 for the Mun.

I have to disagree, for reasons that have already been stated elsewhere. In KSP, designing a successful aircraft is harder than designing a successful rocket. You'd basically be selling them a game of rocketry, but telling them that they have to go do something else before they can play with said rocketry. It's more realistic, yes, but realism doesn't equate out to good gameplay.

Actually, realistic reentry heat in the kerbin universe wouldn't be that bad, for one reason. Typical reentry speeds in KSP are about a third that of real world reentry speeds. The one time Harvester talked about it beyond "we may do it" he basically said that he wanted a system where you didn't need dedicated heatshields but reentry heat was still a consideration in how you design your craft and plan your missions, and this level of heat is actually not too far from such. I've landed craft using deadly reentry without heatshields, you just need to be careful to either come in very slowly or make sure you're leading with more heat-resistant parts and not come in stupidly fast (no direct aerobrake-to-landings at Jool transfer speed).

What promises have they not fulfilled? They really haven't made many, and they haven't broken those few that they did make. Talking about working on something isn't the same as promising. Features get dropped from games under development all the time, sometimes because they run out of time, sometimes because it's not practical, and sometimes because the devs decide that the mechanic isn't fun or doesn't fit into the game.

But resources aren't that reason. I've played with kethane extensively, and other than the first time I detected kethane and the first time a drill started filling a tank, it added no thrill to the game. It enabled me to do missions that I wouldn't have otherwise pulled off, but all my mining colonies basically got ignored as soon as I finished them. This is coming from a player that has always been focused on the economy/infrastructure of any game I played, so it should be right up my alley. Well yeah, but science and the tech tree isn't intended to be all of career mode. And as for resources lasting forever, "Yay, yet another body for me strip mine for no purpose other than to get resources that only get used for setting up more mining bases. Shoot me now, please." Resources aren't a goal, they're a means to achieve a goal, and if the game runs out of goals, then the resources are pointless. Unless there are goals that can only be achieved through resources, then resources aren't going to push back the point at which a player gets bored of the game.

As long as it's a small amount of science, I'm good with it, otherwise it would give the experienced players too much of an advantage.