Difference between revisions of "Tutorial:How to Play"

Revision as of 04:55, 22 August 2024

Welcome to my tutorial for Kerbal Space Program. This guide is targeted at version 1.10.1, which is the latest version as of this writing. It assumes the availability of all expansions, but no mods. Obviously, those can change the game a lot.

So why do we need yet another tutorial? There is a lot of good information out there, including but not limited to elsewhere on this wiki. For one, a lot of it is outdated by now. While this guide will presumably also be outdated someday, there is always a need for new information to update the old that has become obsolete.

But there are two things that I wanted to focus on that most guides don't. First, the lengthy list of parts available to use can be rather bewildering to a new player. I go somewhat systematically through all of the major types of parts and explain what they are for.

Second, this guide has more of a focus on the underlying math and physics than most. Before you run away screaming, that does not mean lengthy algebraic derivations. I'll write down a handful of formulas, but not really do anything with them. But it does mean discussing the three great conservation laws of classical mechanics, explaining how some parts actually work in real life, and defining enough linear algebra terminology to at least give you the right way to think about what is going on.

Moving locally

One of the most basic activities in many games is moving around. Move up, down, left, right, or whatever in order to get where you're going. But as we'll see shortly, moving one direction now and then drifting in orbit could have you moving in a very different direction much later on. That's why this section is only about moving locally, with a separate section for moving globally coming later.

Law of conservation of momentum

Let's start with a few basic definitions. Your velocity is how fast you are moving. This is a three-dimensional vector, which incorporates both your speed and also which direction you are moving. Velocity is intrinsically relative to some frame of reference. If you're driving a car, for example, you might be moving pretty fast relative to the ground, but basically not moving relative to the car.

Loosely, the mass of an object is how much matter it consists of. More technically, mass is resistance to acceleration. The greater the mass of an object, the harder it is to move it very far.

When in an area with a fixed strength of gravity, mass can be interchangeable with weight. That's a good description of moving around on the surface of a planet, but a rather poor model of space travel. Weight is how much force gravity exerts on an object, which depends on the force of gravity in the area. And just to confuse you, gravity and acceleration are, in some weird sense, the same thing.

It turns out that mass in the sense of resistance to acceleration and mass in the sense of affected by gravity are actually the same thing. This conveniently means that your acceleration due to gravity doesn't depend on your mass.

Momentum is mass times velocity. In the mathematical sense, this is a scalar multiple of a vector. Momentum itself is a vector, with both a magnitude and a direction. As with velocity, your momentum depends on your frame of reference, as you could be moving very fast relative to one object and not moving at all (and thus zero momentum) relative to another.

The Law of Conservation of Momentum basically asserts that the sum of the momentum of everything in a system is constant, provided that nothing outside the system interacts with anything inside of it. Having a truly closed system that cannot interact with the rest of the universe at all isn't a common situation unless you consider the entire universe itself, and a model that must start by computing the sum of all momentum in the entire universe isn't likely to be useful.

But for a system to be isolated sometimes is a pretty good approximation on a small scale of time and space. And it's often a pretty good approximation if you allow an accelerating frame of reference where you consider everything in a system relative to what would have happened if the objects had just sat there and not interacted.

Conservation of momentum can be a problem for space travel. Sure, once you get going pretty fast, you keep going pretty fast, at least until gravity has its say. The problem is that if your rocket has to just sit there in space, it can't accelerate to speed up and get you where you want to go.

Specific impulse

The solution to this is that space rockets take stuff up into space so that they can throw it in the opposite direction of where they want to go. If you want to move to the right, then throw a piece of something to the left really hard, and that moves the entire rest of the rocket to the right. If you throw a small percentage of the rocket in one direction, though, the velocity gained in the opposite direction is much smaller in magnitude because it has much higher mass. The real solution is to do this repeatedly, or perhaps more to the point, continuously.

Rocket engines are basically giant bombs with a somewhat controlled explosion to throw burning fuel as hard as you can in the opposite of the direction that you want to go. The harder you can throw it, the more momentum it has, and the more momentum your rocket gains in the opposite direction. As you have to carry your future fuel along with you, firing your exhaust as hard as you can without losing control is very important. Hence the giant bomb approach.

The specific impulse of a rocket engine is basically a measure of its efficiency. The harder it can fire whatever it ejects as it explodes in one net direction, the harder it pushes your rocket in the opposite direction, and the more acceleration you can get from burning a given amount of fuel. Abbreviated as Isp, it is conventionally defined as the average velocity of the fuel ejected divided by 9.81 m/s^2. The latter quantity is the acceleration due to gravity at sea level on Earth, and also on Kerbin.

It should be obvious that if trying to accelerate in a vacuum, being able to eject mass harder in the opposite direction is an advantage. What may be less obvious is that breaking it into more, smaller chunks is also an advantage. Let's suppose, for example, that half of the mass of your rocket is fuel that you can burn and eject, and suppose that you can hurl it away at 3000 m/s, for a reasonably common Isp of a little over 300. If you do that all at once, then you get 1500 m/s of acceleration. Relative to where you started, the fuel will be traveling at 1500 m/s in one direction, and your rocket will be traveling at 1500 m/s in the opposite direction.

But suppose instead that you broke burning the fuel into two chunks. First, you throw back 1/4 of your mass, then you throw another 1/4, now 1/3 of what remains. The first explosion will fire the fuel at 2250 m/s relative to where you started, while accelerating the rocket by 750 m/s in the opposite direction. The second will throw the second batch of fuel at 2000 m/s relative to where the rocket was going, and the rocket another 1000 m/s in the opposite direction. On net, the rocket accelerates by 1750 m/s, which is a lot more than 1500 m/s.

Breaking this into more, smaller explosions yields further gains, though with diminishing returns. In the limiting case of a steady, continuous burn, the best possible acceleration that you can get is about 2079 m/s. The formula, in case you're wondering, is ln(start mass / end mass) * (velocity of ejected fuel), or more conventionally, ln(start mass / end mass) * Isp * 9.81 m/s^2. For those who know calculus, the logarithm naturally shows up by integrating 1/(mass) with respect to mass.

The ∆v approach

∆v

This leads to the ∆v way of thinking about what a rocket can do. That would be the Greek letter ∆ as in "change in" and v for velocity. A given rocket with a given amount of fuel to burn and a given mass of other stuff besides fuel can do up to this amount of change in its velocity by burning fuel and no more.

Crucially, it doesn't have to be all at once. If a rocket has an available ∆v of 2000 m/s, there's no reason why it can't accelerate enough to change its velocity by 1000 m/s now, then wait some days or months, then use the other 1000 m/s later. For example, some now to get on a trajectory with the moon where it wants to land, then wait until it gets close, and some then to actually slow down and land safely.

In many situations, the proper way to think about how much fuel you have left is not in tons or units of liquid fuel. Rather, it is how much ∆v you have left. That's what dictates how far you can go and whether you can get to your intended destination. And back, if you want to come back.

Main rocket engines

Most of the rocket engines in the game rely on combustion to generate the force to fire something backward. You burn rocket fuel with oxidizer to get a good explosion, and that hurls the burnt mixture out the back of the rocket, thus propelling the rocket forward.

Normally, when things burn on Earth, it takes oxygen from Earth's atmosphere to burn with something else. There isn't a bunch of ambient oxygen in the middle of space, however. Thus, if you want to burn something, you've got to bring your own oxygen. There are some engines that don't take this approach and don't require oxidizer, but they all come with severe drawbacks. We'll cover them in a later section.

The game has many different rockets, in many different shapes and sizes. Some are wider than others. Some are longer than others. Some produce more thrust than others. Some cost more than others. In all four of those features, it tends to be the same rockets that are more in all ways. Some rockets are also more efficient than others, in the specific impulse metric explained earlier.

In most practical uses, you'll need to start by considering just how big of a rocket you need, and that will eliminate most of the rockets from contention for a particular use. This is most directly dictated by radial size, as you usually want a rocket to fit nicely on whatever you're attaching it to. There are six common radial sizes for many types of parts in the game: tiny (0.625 m), small (1.25 m), medium (1.875 m), large (2.5 m), extra large (3.75 m), and huge (5 m). For things that are placed in-line--which includes most rocket engines and fuel tanks--you usually want for both components that you're attaching to have the same radial size. This isn't absolutely required, and sometimes there are good reasons not to, but it's commonly more efficient if you do.

Just how much thrust you need to lift your payload plays a huge role. A spark, with its 20 kN of thrust and 0.13 t of mass is a fine engine. So is a rhino, with its 2000 kN of thrust and 9 t mass. But a spark isn't going to do much for you if you're trying to lift 1000 tons off the ground, as you'd need several hundred of them, which would be an incredibly awkward design. Meanwhile, a rhino would be ridiculous overkill for a 2 ton payload, as the weight of the engine alone would make it highly inefficient for the task.

Lower stage liquid engines

Using rockets for liftoff (and in some cases, landings) brings two additional complications. One is that gravity is pulling hard on you, and you don't have unlimited time. If the thrust from your engines is less than the force of gravity, then you don't get off the ground. If you're lucky, you don't move; if not, you fall over and blow up. But just having thrust slightly greater than gravity isn't enough, as then you use huge amounts of fuel to barely move.

This leads to the notion of a thrust to weight ratio. If you click the delta-v icon in the game, it will offer to show you a lot of computed values, including your current thrust to weight ratio. When taking off, you want this to be considerably greater than one, such as 1.3 or 1.5 or 1.7. You don't necessarily want it to be too large, as that means you're using too many or too heavy of rockets. Moving very fast in the lower atmosphere will also mean excessive drag, and can sometimes flip you over and make you lose control.

The other complication of taking off is that rocket engines don't work as well in an atmosphere. The air gets in the way, and so they just don't function as well. Some engines are affected by this far more than others. That's why for Isp and thrust, each engine gives two values, not one: one for performance in a vacuum, and another for 1 atmosphere of pressure, at sea level on Kerbin. In an atmosphere, you burn fuel at the same rate, but it produces less thrust.

Naturally, there are a lot of other amounts of atmospheric pressure besides 1 atmosphere or a vacuum. There are intermediate values, or in some places, pressures of greater than one atmosphere. At low pressures such as 0.01 atmospheres, the numbers for a vacuum are a pretty good approximation. Rocket engines get worse as the pressure increases, and produce no thrust at all at sufficiently high pressures. You can see the exact thrust and Isp for a given rocket engine in the vehicle assembly building by choosing a planet and altitude in the option on the lower right pane.

For taking off from Kerbin, or anywhere else with a thick atmosphere (Laythe, Eve, and the lower atmosphere of Jool), you pretty much have to discard any engines that have a large gap in efficiency between atmosphere and vacuum from consideration for your first stage. Engines with a small efficiency gap between a vacuum or one atmosphere of pressure are much better suited for the lower stages of a takeoff than those with a large gap. Such engines include a cub, vector, mainsail, or mammoth, among others.

Upper stage liquid engines

When out in deep space, you might want to adjust your trajectory by a given amount velocity, which consumes that amount of delta-v. It doesn't really matter how fast you do the maneuver, as you have plenty of time. What matters is how little fuel and cost you can use to do it. Some rockets are intended for the upper stages of an engine, and only intended to be used in a vacuum, or at most in a very thin atmosphere. These commonly focus more on efficiency, in the sense of high specific impulse.

Some engines sacrifice the ability to work well at high pressures in favor of the ability to be more efficient in a vacuum. These are the upper stage liquid engines. There isn't a formal demarcation between those suitable for upper stages versus lower stages, but good examples of upper stage engines include an ant, terrier, cheetah, poodle, wolfhound, or rhino.

With upper stages, you typically have a good idea of how much mass your payload is, and how big of a rocket you want, and how it needs to fit with other parts in your rocket. That will limit you to a handful of reasonable choices, and then you can pick one that seems efficient, in the sense that it can do the job while requiring the least fuel and cost to build.

You can use lower stage engines in deep space, but it's usually significantly less efficient than an upper stage engine. Meanwhile, using an upper stage engine at high pressures will give very poor performance.

Solid fuel boosters

Solid fuel booster rockets are a special type of rocket intended for the very first stage to get you off of the ground and moving upward. They won't get you very far, but they can be a good way to get started. While most liquid fuel rockets have the fuel as a separate component from the rocket proper, for a solid fuel engine, you get an integrated package with both fuel and the engine.

Solid fuel boosters do have some serious drawbacks, however. First of all, unlike liquid fuel engines that respond to the throttle and can be scaled up or down, solid fuel rockets can't be turned off. Once you ignite them, they burn until they are out of fuel, then stop entirely. The early fuel rockets can't gimbal at all, though some that were added to the game much more recently can. Their specific impulse is also pretty bad.

So why use solid fuel boosters at all? One reason is because they're dirt cheap. A kickback can provide about 600 kN of thrust in a lower atmosphere for 62.8 seconds, at a cost of only 2700 funds. There are few ways to get that amount of thrust from liquid fuel engines at double that cost for the engines alone, and that's not counting the additional cost of the fuel.

Solid fuel rockets also provide a lot of thrust in little space. That can also be helpful at liftoff, when you need a ton of thrust to get off of the ground, but want to keep your cross-sectional area small to reduce drag.

Solid fuel rockets are really only good for the first stage to get you off of the ground on Kerbin. Because of their poor efficiency, you don't want to carry all that weight up for use in the upper atmosphere or out in space. They're good for starting on a lot of rockets, but just use them, discard them, and move on. Once you get to launching larger rockets, you can expect to start attaching a bunch of clydesdales to nearly everything.

Specialized engines

It might seem like it's inefficient to have to bring a bunch of liquid oxygen with you so that you can burn it. Isn't there some other way to let you skip the oxygen? Well yes, there is. Several, in fact. But they all have major drawbacks. The specialty engines are the focus of this section.

Nerv atomic rocket

First is the nerv atomic rocket motor. The idea is that it has a nuclear reactor in the rocket that it can use to heat hydrogen to be very hot. As atoms get hotter, they move faster. Have a hole so that there's only one direction that goes out, heat it up, and let it go out the hole. Hydrogen is used for the fuel because it has the lowest molecular weight, and the lower the molecular weight of a molecule, the higher its velocity at a given temperature.

The advantage of the nerv is its enormous specific impulse of 800. For comparison, the highest for a normal rocket in the game is a wolfhound, at 380. So that's why you'd want to use a a nerv.

There are some enormous drawbacks, however. For starters, the thrust to weight ratio is awful, with a 3 ton engine for only 60 kN of thrust. Every single normal liquid or solid rocket in the game has a thrust to weight ratio of at least five times that, and many are more than ten times that. Throw in its poor performance in an atmosphere and at sea level on Kerbin, a nerv can't even lift half of its own weight off the ground, even without any fuel or payload.

They're also expensive, as they cost 10000 funds each. That makes a nerv the seventh most expensive engine in the game, and all of the more expensive engines are much larger with at least 1000 kN of thrust. You can sometimes compensate for a weak engine by just adding more, but that gets expensive with nervs.

The fuel ecosystem for nervs is also not very good. You can use normal fuel tanks and not include the oxidizer, but then your wet to dry mass ratio for your fuel tanks is only 4.6:1 rather than 9:1, which eats up much of their efficiency advantage. Otherwise, you have a handful of pure liquid fuel tanks that you can use, and mostly not of the sizes and shapes you'll want.

The low thrust means that you'll commonly have long burn times to get the change in velocity that you want. That's fine in deep space, but it's not fine in low orbit of a planet with strong gravity. If you try to do a 20 minute burn maneuver when your current orbit has a period of 30 minutes, you're not going to like the results. They are functional for getting you out of low orbit of a planet, but kind of a pain.

Even so, for long distance flights, a nerv is commonly worth using because of its efficiency. There's no sense in using them if you're only orbiting Kerbin or traveling to one of its moons, and they're not that great for going to Eve or Duna, either. But for faraway destinations such as Jool, Moho, or Eeloo, having a stage of Nervs in the middle for the deep space portion can considerably reduce the total mass at launch required to reach your destination.

Dawn engine

Another way to make a rocket engine that fires its exhaust at much higher speeds than normal rockets is the ion engine. The idea here is that you have some xenon gas in an electric field. Normally, as a noble gas, xenon is unreactive and electrically neutral. If you ionize a tiny fraction of the xenon atoms by ripping off an electron, then your electric field can push on that handful of ions with an enormous force while having no force on the rest of the xenon. That handful of ions zip out of the engine at enormous speeds while the rest stay put.

The result is a specific impulse of 4200 in a vacuum. That's more than five times that of a nerv, and more than 11 times that of any liquid or solid fuel rocket. That makes the dawn engine the best in the game at mass efficiency in a vacuum, and by an enormous margin.

Naturally, they come with some enormous drawbacks. First of all, they offer very little thrust, at only 2 kN. That's actually massively more powerful than the real-life versions, which tend to offer about 0.01% that much thrust--naturally measured in mN, not kN. While dawn engines are very efficient for deep space travel, you're either going to need a whole lot of them or else accept that your burns take a very long time.

Second, their fuel tanks are inefficient with a full to empty mass ratio of only about 4:1, as compared to 9:1 for liquid fuel tanks, which implicitly eats up some of that mass efficiency advantage.

Third, they're expensive. A cost of 8000 funds for an engine isn't outlandish, until you realize that you're only getting 2 kN of thrust. Their fuel tanks are even more expensive, as xenon doesn't exactly grow on trees. Xenon costs more than 40000 funds per ton. For comparison, liquid rocket fuel costs less than 100 funds per ton.

Fourth, they use a lot of electricity to maintain a strong electric field. Each dawn engine consumes 8.741 electricity per second while in operation. The mass in electrical equipment that it takes to generate that much electricity that fast can easily make them seem like they're not that efficient anymore.

Fifth, that very weak thrust means very long burn times. For a single dawn engine to drain a single PB-X750 Xenon Container takes more than three hours. You can't time warp while accelerating, either, though you can do up to 4x physics warp. That still requires waiting more than 45 minutes. And remember that even that speed is because they made the engines far more powerful than their real-life counterparts. The real-life ion engines can burn for days or weeks.

Sixth, their xenon fuel cannot be refilled by mining. All other engines in the game allow you to land on some arbitrary planet or moon, use some mining equipment, and completely refill your fuel. But you can't expect to find xenon gas in arbitrary places. On many planets and moons, if they even had xenon in the first place, it would just float off into space and be gone.

Dawn engines are pretty much unusable for lower stages because of their high cost and low thrust. Where they really shine is for bringing a very small payload back to Kerbin, such as a command pod with few Kerbals, an experiment storage unit with valuable data, or some part that you were asked to bring home for a contract. They're great for coming home from Moho. They're less great for faraway planets such as Jool or Eeloo, as solar panels are far less effective there. Dawn engines are also nearly mandatory if you want to put something in low orbit about the Sun.

Jet engines

Another way to provide thrust is to not use rockets at all. Jet engines as used on airplanes are massively more efficient than rocket engines, as they have two huge advantages. First, they only need to carry fuel and not oxygen, as they can grab oxygen out of the air to burn. Second, they don't have to implicitly carry something to hurl off into space, as turbines can push against the air to provide thrust. This results in specific impulse ratings for jet engines ranging from 3200 to 12600. That's competitive with a dawn engine at the low end, and massively more efficient at the high end.

However, jet engines have some enormous drawbacks, too. Their key weakness is a need for oxygen. Thus, they only work in the lower atmosphere, and even then, only if there is oxygen present. So that limits you to Kerbin and Laythe. The problem with this is that if you're in the lower atmosphere of a planet, the first thing you want to do is to get out of the lower atmosphere--either up into space or down on the ground. For most missions, jet engines would be functional for such a short amount of time that their fuel efficiency doesn't matter.

Second, their thrust to weight ratio is awful by the standards of rocket engines, so they provide little thrust for the weight that they bring. It doesn't work to have one engine pointing its exhaust at another, as that would screw up your aerodynamics, so the number of jet engines you can use is sharply limited by your cross-sectional area. You generally need a vehicle to be longer than it is wide or else aerodynamics will try to flip you out of control, so this limits you to small vehicles at launch.

Third, take-offs and landings are a problem. In real-life, there are many airports with runways, and planes generally fly from one to another. Kerbin has only three runways, and Laythe has none at all, which makes take-offs and landings a problem. It is possible to do a vertical take off and landing so as not to need a runway, but this is difficult to construct.

Fourth, jets force you to deal intricately with finicky aerodynamics, which is just plain hard. It's hard in real-life, too, but there, aerospace engineers have much more precise tools available. You can mostly manage rockets by rotational symmetry, which prevents things being slightly off from breaking everything for you. For jets, you can use mirror symmetry for one dimension, but still have to balance things in another dimension with tools that are just too imprecise for the job.

If you look around, you can find a lot of people saying that they did this or that with jets. Most of it is very old and dates to before aerodynamics was redone in version 1.0, so that what they did then won't still work today. You can perhaps make a small jet with no meaningful payload and fly it around, but I haven't found any practical situation where that's not markedly worse than using a rocket. It's best to regard jet engines as being a toy with no practical use in the game.

Rotors

In addition to using the built-in jet engines, it's also possible to roll your own using rotors. Rotors don't use fuel, but rather, rely on electricity. A rotor has two main components, and forces one to spin relative to the other. This can be used to spin propeller blades, helicopter blades, or structural panels to provide a modest amount of thrust.

You can be creative with your use of rotors, but do keep in mind that they're tricky to use well. You can make them into propellers for planes, rather than using jet engines. You can also make helicopters. These don't rely on atmospheric oxygen, so they can also work on Eve or Jool. Indeed, helicopters are the only thing that work far into Jool's lower atmosphere.

Another alternative that lets you avoid the finicky aerodynamics is to use rotors to make a boat engine. That way, if you land in the water while out of fuel, you fire up the boat engine and slowly get back to shore, where you can switch to rover wheels or mine for more rocket fuel. So long as you move slowly enough, aerodynamics won't flip you over and blow you up.

RCS thrusters

One other specialized type of engines is RCS thrusters. These are intended for small, precise movements, especially in deep space. RCS thrusters won't get you into orbit and won't land you, but they might help you line up something just right to have two vehicles dock in space.

Personally, I don't find them useful. They work, but you can also make things precise enough for docking by other means, without needing an additional type of fuel and additional engines.

Rotating

For most purposes, it isn't enough to just provide a lot of force. You need to provide it in the right direction in order to get where you want to go. With rockets, that typically means rotating the rocket such that it is pointing away from the direction in which you want to travel. To do that, you'll need to be able to rotate your vehicle. That's what this section is about.

Law of conservation of angular momentum

Linear velocity has an angular version, too. We'll talk more about coordinate systems in a subsequent section, but your angular velocity is the rate at which your angle about something is changing. Just as there is linear momentum, there is also angular momentum. The angular momentum of an object about a point is the vector cross product of the distance from the point to the object and the momentum of the object. The cross product is algebraically messy and unintuitive, so I won't define it here.

What is important about angular momentum is that it is conserved. So long as there aren't any external torques applied, the sum of the angular momenta of a system about a fixed point is constant. No external torques is a weaker condition than there being no external forces applied to the system; I'll explain the concept of torque shortly. While conservation of momentum explains how rockets work and not much else of consequence in the game, conservation of angular momentum is an extremely important principle with broad consequences.

Conservation of angular momentum works with any object and any point. In the limit as the point that you are rotating about becomes infinitely far away, it becomes equivalent to ordinary conservation of momentum. Most combinations of an object and a point really aren't very illuminating--in part because there are external torques on the system.

There are two types of situations in the game where conservation of angular momentum is extremely consequential. The more complicated and profound one is that of your rocket orbiting some celestial body, such as a planet or moon. The object whose angular momentum we track is your rocket, and the point is the center of the planet or whatever it is that you're orbiting. We'll need more terminology before we can make sense of that, so we'll get to it a little later.

The other situation where angular momentum is important is your rocket rotating about its center of mass. The center of mass of an object is loosely the average position of mass in the object. For a collection of point masses, it is computed as the (sum of (mass times position)) / (sum of masses). For continuous, solid objects, you would technically want integrals instead of sums.

Some objects have a center of mass that is pretty simple by symmetry. For example, the center of mass of a ball is at the center of the ball. When building rockets, if you place everything with mirror symmetry in the spaceplane hangar, you're guaranteed that the center of mass will be somewhere in the plane that the mirror symmetry is symmetric about. If you place everything with rotational symmetry in the vehicle assembly building, the center of mass will be somewhere on the vertical line through the center of the rocket. Both buildings have an option to show you where your center of mass is.

One important thing to understand about the center of mass of an object is that when the object rotates while not being touched by anything else, it rotates about its center of mass. Thus, in order to rotate your rocket at all, you're usually going to rotate it about the center of mass.

Reaction wheels

Reaction wheels probably look like magic if you don't know how they work. The idea is that you're in deep space and not touching anything. You want to rotate your rocket in a particular direction. So you fire up the reaction wheels and rotate the entire rocket to exactly the direction you want. And then you stop, and stay pointing in exactly the direction you wanted. And it didn't require firing any rockets, but only using some electricity. And that is actually a real thing.

The first reaction wheels were discovered accidentally. Some space program had launched a satellite, and it was going along just as they expected. Then when it started to transmit data back to Earth, it started rotating. That was a nuisance, so they had to stop it and rotate it back to the intended direction, which wasted fuel. Then when it started transmitting data again, it started rotating again. This was rather baffling at first.

Eventually, they figured out what was happening. When the satellite transmitted data, it rotated some tapes internally as part of the tape drives where it stored data. In an appropriate reference frame, the satellite had zero net angular momentum before it started transmitting. When rotating the tape wheels, those wheels had some angular momentum in some direction. In order for the net angular momentum of the entire satellite to remain zero (as angular momentum is conserved), that caused the entire rest of the satellite to rotate slowly in the opposite direction.

Figuring that out was a huge advance for space rockets. Instead of needing a bunch of small thrusters all over the place to make it possible to rotate your rocket in arbitrary directions, all that they needed was a few internal wheels. Want to rotate the rocket in one direction? Just rotate the wheels in the opposite direction. Stop the wheels to stop the rocket from rotating.

There are three dedicated reaction wheels objects in the game, with three different radial sizes. The game simplifies this for you somewhat by allowing all reaction wheels to rotate you in arbitrary directions, and much faster than real-life reaction wheels would tend to. Furthermore, the game doesn't limit the cumulative torque that reaction wheels can provide, unlike the real-life versions that can only spin so fast. But reaction wheels are a real thing, not just magic to make the game easier for you.

In addition to the dedicated reaction wheels, most of the pods in the game have some built-in reaction wheels. These tend to be lower torque than dedicated reaction wheels, so other than for some very small vehicles, you'll typically want to add one or more dedicated reaction wheels.

Torque

Torque is basically the angular version of force. Technically, the torque on an object about a particular point is the vector cross product of (the distance from the point about which you rotate to the point where the force is applied) with the force. Thus, the torque depends not only on the force, but also on the point that you're computing the torque around.

For our purposes, there are again two useful choices for the point that you compute the torque about. One is the center of mass of your rocket. The other is the celestial body that you're orbiting. We'll come back to the latter in a later section. The torque about the center of mass of your rocket will rotate your rocket.

There are two important cases where the cross product is zero. One is that cross product of zero with any other vector is always zero. This means that zero force causes zero torque. It also means that any force applied to the center of mass of an object applies zero torque to the object.

The other, broader situation is that the cross product of two parallel vectors is zero. Thus, if the force applied is pointed right at the center of mass of an object, it causes zero net torque, and does not rotate the object.

There are five major sources of torque in the game other than reaction wheels. They can be intentional or undesirable, but they will cause the rocket to rotate, so it's important to understand them.

Asymmetric rocket placement

First is if your rockets are placed asymmetrically. A rocket engine that isn't pointed right at your center of mass will have some torque. If you have another engine on the opposite side, it will cause the opposite torque. These cancel out, for a net sum of zero torque. That's usually what you want, so that you can avoid extra torque when you don't want it.

The vehicle assembly building and spaceplane hangar will both draw this for you. You can show the sum of the forces, as well as the center of mass. If the former is pointed right at the latter, you're fine, at least for a rocket. Making everything use rotational symmetry will accomplish this for you. For a plane, you want the sum of the forces to be pointed right at the center of mass in the horizontal direction, but possibly not quite in the vertical.

There are two ways to screw up the net force here. One is if the rockets firing at a given time are placed asymmetrically. This can happen because of the way that the rocket is built, with one engine not having others to balance it. Even if the initial design is correct, it can happen if one engine is firing while the other(s) to balance it are not. It can also happen if something goes awry and blows up some but not all of your engines.

The other way to mess this up is if your center of mass is off-center. For example, if you stick one extra fuel tank off to one side without a counterpart on the other side, you can end up with a center of mass that is off to the side. Then even if you properly pair all of your engines, the net force isn't pointing at the center of mass, and so the rocket still rotates. To avoid this, you need all of your parts to be either paired with other, identical parts using the rotational symmetry tool, or else a single part actually on the center line of the rocket.

Engine gimbal

In addition to pointing their exhaust in the exact direction that they're facing, some engines can angle the nozzle off to the side. This is something that can be adjusted from moment to moment, so that you can have the nozzle pointed to the side one moment when you want to turn and centered again a second later when you want to go straight.

Each engine has a maximum amount of gimbal. Some engines can't gimbal at all, and the maximum angle for most of those that can is very small, such as two or three degrees. A few engines have a very large gimbal angle, such as 10.5 degrees for the vector or 22.5 degrees for the cub--though the cub can only angle in one axis, not two.

Large gimbal can be handy sometimes, but excessively large gimbal can mean a lot of torque. With SAS on, this can cause it to overshoot back and forth on angles until the entire ship shakes violently or even flies apart. Fortunately, you can reduce the maximum gimbal of any rocket engine. Sometimes it is handy to have a stage that mixes some engines with high gimbal with others with no gimbal at all so that you can still rotate at a decent rate.

Aerodynamics

Air resistance when in the lower atmosphere is another source of torque. For planes, this is essential to make the plane fly at all. For rockets, it's generally undesirable at take-off, but can be helpful to slow you down before landing.

While air resistance mostly slows you down in whatever direction you were going, it can also provide some torque. Because it pushes so hard, a slight angular tilt can offer considerable torque. In some cases, it can cause a rocket to flip over shortly after launch.

For a rocket of a fixed size and shape, there will be some amount of force applied to the rocket as it moves in any particular direction. The force generally varies with the direction, and often by quite a lot. A pancake moving with its wide face catching the wind will draw a lot of air resistance, for example, but the same shape will get much less if it moves in the direction of an edge.

The most stable direction for a rocket is whichever direction offers the least resistance. For a long, narrow rocket, this will usually be either retrograde or prograde. For a short, wide rocket, it can be moving on an edge. If you're near the direction of minimum wind resistance, aerodynamics will often push you toward it.

There can be multiple local minima that are stable if you're near them. Additionally, so long as the torque applied by aerodynamics is less than what you can apply with other sources (typically engine gimbal or reaction wheels), you can keep the rocket stable in the direction you want it to be facing.

Ultimately, aerodynamics is very complicated. New players commonly have to figure out why their rocket is flipping over shortly after launch, and aerodynamics is the culprit. It often helps to make your rocket have less drag when traveling in the direction you want to go, such as by using aerodynamic nose cones. Sometimes you need more torque from other sources. Occasionally, you just have to make the rocket go slower when in the lower atmosphere to keep it stable.

Collisions

If one object directly pushes on another, it can apply some torque to the other object. Actually, both objects can apply some amount of torque to each other. In one sense, this is obvious, and also the simplest example of torque. But in another sense, it's fairly rare, as you typically don't collide with other objects when deep in space.

The main issue where collisions will spin your rocket around is when landing. If the ground is uneven and one side of your rocket touches before the other, the ground will apply some torque to spin the rocket away from the side that touched first. You can reduce this force considerably by touching down at a lower velocity. It also helps a lot if you can find a level place to land, though this isn't always practical.

Rotors

The basic goal of a rotor is to apply some torque to rotate some small portion of the ship in one direction, such as helicopter blades. But as angular momentum is conserved, this rotates the entire rest of your ship in the opposite direction, albeit usually much more slowly. Even so, if you're reckless with rotors, they can easily cause you to spin out of control.

The solution to this is usually to have an even number of rotors, and spin them in opposite directions. Thus, when some of them apply torque in one direction, others apply an equal amount of torque in the opposite direction. The net effect is zero torque on the rest of your ship.

Inertia

Just mass is resistance to acceleration, so inertia is resistance to rotation. The amount of angular acceleration of an object is the amount of torque divided by the moment of inertia about the axis that the torque is trying to rotate the object. Importantly, the moment of inertia is not a single, fixed constant for a single object, but varies with the axis. The axis of rotation always goes through the center of mass of the object.

Technically, the moment of inertia is the integral over space of the mass density of the object times the square of the distance from the axis of rotation. You can think of it intuitively as the mass of the object times the square of the "average" distance of parts of the object from the axis of rotation. It would be more proper to use the root mean square (which is greater than the average) rather than the average, but using the average is probably more intuitive and usually won't lead you too far astray.

One thing that is important to understand is that an object of fixed shape gets larger in all directions, the moment of inertia grows much faster than the mass. Meanwhile, the aerodynamic forces on it grow proportionally to the cross-sectional surface area, and thus more slowly than the mass. If you increase the size of the rocket in all dimensions by a factor of n, the aerodynamic forces (including torque) increase by a factor of n^2, the mass by a factor of n^3, and the moment of inertia by a factor of n^5. That last one is n^3 for the mass times n^2 because the distance from the axis of rotation increases by a factor of n.

Thus, the angular acceleration due to aerodynamic forces decreases by a factor of n^3. For example, make the rocket twice as big in all dimensions, and the angular acceleration due to aerodynamics will only be 1/8 as big as before. This is why small rockets are prone to flipping, but a similar shape with a much larger rocket allows you to nearly ignore aerodynamics when taking off.

Another consequence of this is that big rockets are much harder to turn than small ones. Small probes that only weigh a few tons can commonly spin very fast from the minor reaction wheels inside of a pod or probe core. Giant stations with a mass of thousands of tons can take minutes to rotate to the direction you wanted, even with a number of dedicated reaction wheels.

Moving globally

Your intuition is likely that if you want to move from point A to point B, you start moving directly toward point B. Keep moving in that direction for a while, and eventually, you'll get there. For moving small distances, that works pretty well, with some fake forces that we'll discuss near the end as the only real impediments.

For moving from one celestial body to another, however, just pointing in the direction you want to go will fail spectacularly. Constantly firing rockets to counteract the force of gravity will drain your fuel in a hurry. Rather, you need to apply minimal thrust at carefully chosen places, and then rely on gravity to take you where you want to go.

This section is by far the most math-intensive in the entire guide. As before, I promise not to give you lengthy algebraic derivations. I will, however, introduce some linear algebra terminology, to at least give you the proper nomenclature for what is going on.

Coordinate systems

If you want to describe the location of a point in space, there are a variety of ways to do it. The three that will generally be introduced in a fairly introductory physics or multivariable calculus course are rectangular, cylindrical, and spherical coordinates. There are plenty of others, and we'll get to some that are useful for describing orbital mechanics shortly. Cylindrical coordinates aren't important in this game, but I'd like to explain rectangular and spherical coordinates before moving on.

Rectangular coordinates

To describe a point on a line, you can use a single number. Pick a point on the line as your zero point. You can then specify any other point by saying how far from the zero point it is, and in which direction. One side of the point is positive, and the other side is negative.

You can do about the same in two dimensions, but you'll need two numbers. For example, to specify a point on your monitor, you could have one number that describes the position in the horizontal direction, and another that describes it in the vertical direction. Each spot on the screen corresponds to a unique pair of numbers.

You can do the same in any other number of dimensions, too. As space is three-dimensional, we commonly want three dimensions. In this case, it takes three numbers, that is, three coordinates, to describe the position. The three coordinates are customarily called x, y, and z.

It's important to understand that there is not a canonical origin (zero) point. Nor are there canonical directions of which way is x, which way is y, and which way is z. Rather, you're allowed to pick whatever is most convenient. It's common to use z as "up", but out in the middle of space, there isn't a clear "up" direction.

Spherical coordinates

Another way to describe a point in space is with spherical coordinates. As with rectangular coordinates, you start by picking one particular point as your origin. Your three coordinates are the Greek letters rho, theta, and phi. I'll call them r, t, and p, respectively, simply because it's hard to type Greek letters here.

The r coordinate is your distance from the origin, regardless of the direction. The t coordinate is your angle in some particular plane through the origin that you pick. The p coordinate is your angle with that plane. The t and p coordinates together specify a direction. Physicists sometimes reverse the roles of theta and phi, but I'm going to stay with the convention I've just described.

One notable feature of spherical coordinates is that the three coordinates aren't allowed to be arbitrary numbers. As r is a distance, it must not be negative. As t and p are angles, they would repeat if allowed to become arbitrarily large. By convention, t is allowed to be in [0, 2 * pi), while p is allowed to be in [-pi/2, pi/2], where pi = 3.14159...

There's one important use of spherical coordinates built into the game that you're probably already familiar with. The zero point is the center of a planet or moon. r is essentially your altitude, though it is commonly displayed as (distance from the center of the planet) - (distance from sea level to the center of the planet). t is your longitude, that is, how far east or west you are. p is your latitude, which is how far north or south you are.

Some linear algebra

If using a rectangular coordinate system, you can choose the directions almost arbitrarily. But some choices are often better than others. To explain why, we're going to need some terminology.

When using rectangular coordinates, we said that we had x, y, and z coordinates. We commonly write a point (or a vector) by listing the three coordinates. For example, we might write (2, 5, -3) to mean that we're at the location where x = 2, y = 5, and z = -3. We can add two vectors algebraically by adding their coordinates. For example, (2, 5, -3) + (7, 1, 3) = (9, 6, 0). In the x-coordinate, we get 2 + 7 = 9, and so forth.

Geometrically, we can write a vector by drawing an arrow from the origin to the point. We can add two vectors geometrically by moving the tail point of one to the head of the other, and then drawing a vector from the other tail to the other head.

We can also take scalar multiples of vectors. Algebraically, this is just multiplying each coefficient by the same number. For example 3 * (2, 5, -3) = (6, 15, -9). Geometrically, this corresponds to making the vector longer or shorter (or pointing in the opposite direction if negative) without changing the direction that the vector is pointing.

Orthonormal bases

The span of a set of vectors is the set of all linear combinations of them. That is, pick a scalar multiple of each vector in the set, then add them all together. The span of a set of vectors is a subspace of the original vector space, that is, the space in which our vectors live.

A set of vectors spans a vector space if the span of the set of vectors is the whole space. A good coordinate system should span the whole space, so that you have a way to describe all of the points in it. For example, the set of vectors (1, 0, 0), (0, 1, 0), and (0, 0, 1) spans the whole three-dimensional space. If we want to write a point (a, b, c), we can write it as a * (1, 0, 0) + b * (0, 1, 0) + c * (0, 0, 1). The set of vectors (1, 0, 0) and (0, 1, 0) does not span the whole space, as it gives us no way to make the z-coordinate not be zero. Similarly, the set of vectors (1, 0, 0), (1, 1, 0), (2, 1, 0), and (0, 1, 0) does not span the whole space.

A set of vectors is linearly independent if the only linear combination of the vectors to give zero is the zero combination. For example, the set (1, 0, 0), (0, 1, 0), and (0, 0, 1) is linearly independent. The set (0, 1, 0) and (1, 0, 1) is also linearly independent. The set (1, 0, 0) and (2, 0, 0) is not linearly independent, as we could compute 2 * (1, 0, 0) + (-1) * (2, 0, 0) = (0, 0, 0). A good choice of a rectangular coordinate system should have its coordinate vectors be linearly independent, as otherwise, more than one set of coordinates will give the same point.

A set of vectors is a basis for a vector space if it is both linearly independent and a spanning set. This requires that every point in the space can be written as a linear combination of the basis vectors in exactly one way.

The dot product of two vectors is obtained by multiplying the components, then adding the products. For example (1, 2, 3) dot (4, 5, 6) = 1 * 4 + 2 * 5 + 3 * 6 = 32. Two vectors are orthogonal to each other if their dot product is zero. In other contexts, this is sometimes called perpendicular or normal, but I'll generally stick with orthogonal.

We usually want for the coordinate vectors in a coordinate system to be orthogonal to each other, as otherwise, we could get some peculiar effects. For example, the set of vectors (2, 1, 1), (1, 2, 1), and (1, 1, 2) forms a basis for three-dimensional space. But it's kind of an awkward basis to use, as we can get the vector (4, 4, 4) by using +1 as the coefficient for all three basis vectors. We can get the vector (2, -1, -1) by using +2 for the first coordinate and -1 for each of the other two. But this makes the vector (2, -1, -1) look "larger" than (4, 4, 4), which seems intuitively wrong.

The length of a vector is the square root of the dot product of the vector with itself. This does geometrically give the length if you measure it. An orthogonal set of vectors is called orthonormal if each of its vectors has length 1.

We typically want a good coordinate system to have its coordinate vectors form an orthonormal basis. We could use (1, 0, 0), (0, 2, 0), (0, 0, 2398) as a basis for a space. But that would make the z-coordinates tend to be much smaller than the x and y coordinates, which would seem weird.

Dimension and degrees of freedom

All bases for a vector space have exactly the same number of vectors. It isn't a coincidence that rectangular coordinates and spherical coordinates for the same space each have three coordinates. The number of vectors in such a basis is the dimension of the space.

It might be surprising that most ways of picking vectors randomly will form a basis, if you pick the right number of them. It's kind of like observing that most ways of picking three points at random won't happen to accidentally place them on the same line. Most sets of vectors will not happen to form an orthonormal basis, however.

Spherical coordinates don't technically define a basis for a space globally. They do provide a valid coordinate system for treating the space as a smooth manifold, except along the axis through the poles, but that's far beyond the scope of this guide.

When you get to non-rectangular coordinate systems, the number of degrees of freedom is basically the dimension that you're dealing with. That's the number of coordinates that you'll need.

Maneuver nodes

To help you plan your journey, maneuver nodes let you specify to specify how much thrust you want to apply in which places. They will map out your future trajectory after that thrust so that you can see if you need to thrust more or less or in a different direction or whatever. Changing maneuver nodes doesn't use any fuel, as it's only planning, not actually firing rockets.

Just as your position has three coordinates, so does your velocity. Thus, if we want to describe the direction in which you're moving, it will take three coordinates. It may be tempting to make them just the change in the three coordinates to describe your position. That works, after all. But it's usually a rather bad choice, and especially terrible if you're using spherical coordinates.

Rather, the game has a built-in orthonormal basis that it will show you that is very useful. One of the coordinates is the direction you're going. That's the "prograde" direction, and the opposite direction from it is "retrograde". For reasons that we'll get to shortly, much of the time, when you want to thrust at all, it is best to do it in either the prograde or retrograde direction.

Another coordinate is kind of away from the celestial body that you're orbiting, but not quite. This is the "radial out" coordinate, and its opposite direction is "radial in". There are two reasons why it is only "kind of". One is that you're not necessarily orbiting anything; we'll get to spheres of influence in a bit.

The larger reason is that directly toward some celestial body usually isn't orthogonal to the direction you're moving. We want the basis to be orthonormal, as otherwise, it will do weird things, so it needs to be orthogonal to the prograde direction. What they actually do is to pick the direction nearest to pointing away from the celestial body from among those directions orthogonal to the prograde direction. For those who know linear algebra, they're using the Gram-Schmidt process under the hood.

The third coordinate is the normal direction, which basically means, whatever direction is orthogonal to the first two axes. Its opposite direction is the anti-normal direction. This is the normal direction to the plane in which your trajectory lies.

When you specify how much thrust to apply at a given maneuver node, the you specify numbers in each of the prograde, radial out, and normal directions. Those directions are as you will be traveling at the node itself. This makes it fairly easy to do a purely prograde burn, or purely retrograde, or whatever.

Law of conservation of energy

The first thing to know about energy is that there is no such thing as energy. It simply isn't a real, physical thing. Rather, it's a made-up quantity that is designed to make computations easier. It can also help with your intuition about how things work.

What has happened over the centuries is that there are various situations in which scientists have noted that some computed quantity is constant, even as various components of it change. In a number of intuitively related situations, they decided to call this quantity energy. Most such situations don't matter to us, but converting between a rocket's speed and its height above an object is hugely important.

I promised that there wouldn't be any lengthy algebraic derivations, so I'll just give you the formula. If you're in orbit about some celestial body, let your speed relative to the body be v and your distance from the center of the body be r. Then there is some constant k such that v^2 - k/r is constant, even though both v and r will probably change as you move through your orbit. The constant k varies by celestial body. For those who are previously familiar with conservation of energy in a gravitational sense, I've factored out some terms and folded some constants into each other.

Furthermore, your total energy gives you information about the status of your orbit. If it is positive (i.e., v^2 > k/r), then you're on an escape trajectory and not coming back. If negative (i.e., v^2 < k/r), then you're either in orbit or else going to fall and crash.

If you are in a circular orbit, then v and r will be constant. A circular orbit implies constant distance from the planet, after all, which is what makes r constant. Furthermore, in a circular orbit, you will always have k/r = 2v^2, and your total energy will be -v^2 = -k/2r. This gives you a fairly easy way to compute k: get to a circular orbit and compute k = 2rv^2. This works regardless of the height of the circular orbit, so long as it's a stable orbit. You'll have to add the radius of the body you're orbiting to the altitude above sea level that the game displays for you to compute r. For v, you want the speed relative to orbit, not relative to the surface.

Remember that if you're in orbit and not on an escape trajectory, your energy is negative. A higher orbit (greater altitude) corresponds to higher (less negative) energy, even though you're moving slower.

Describing orbits

To describe your trajectory, we'd like an appropriate coordinate system. One could specify your current position and velocity as vectors, with three coordinates for each. But this is awfully inconvenient, as you'll have six coordinates, all of which are constantly changing in seemingly weird ways.

What we really want is a different coordinate system that is better suited to describing orbits. We'll need six coordinates, but we'd like one of those six to be your position on the orbit. Furthermore, we'd like for the other five coordinates to not be changing as you drift along in space on your orbit.

Those who don't have a strong math background may be surprised to learn that not only is it possible to devise such a coordinate system, but there are a lot of ways to do it. The game has one such coordinate system built-in that it will display for you. I'll present an alternative that is sometimes more illuminating than the one that the game gives you.

In-game coordinate system

Let's start with the game's coordinate system for describing an orbit. One coordinate is the altitude of your apoapsis, which is the highest point in your orbit. Another is the altitude of the periapsis, which is the lowest point in your orbit. The third coordinate is the argument of your periapsis, which is what would change if you rotate the orbit while leaving it in the same plane. The fourth argument is your inclination, which is the angle between the plane that contains your orbit and the equator of the body you're orbiting. THe fifth coordinate is the longitude of the ascending node, which is where along the equator of the body you're orbiting your orbit passes from below the equator to above it.

The game displays the apoapsis and periapsis prominently for you. Inclination is somewhat prominent on the map, though the numerical display shoves it off into the advanced orbital info tab. Longitude of ascending node (LAN) and argument of periapsis (LAN PE) are displayed numerically in the advanced orbital info tab. They're implicit in the drawing of your orbit on a map, but not displayed numerically there. The math is a little complicated, but those five coordinates uniquely determine your orbit.

You may find it puzzling that the game sometimes displays your apoapsis as negative. It does this when you are on an escape trajectory, rather than in orbit. There is a sound mathematical reason for it, and it is meaningful information about an escape trajectory. After all, you don't have a highest point when you're going to go off to infinity. I'll get to this in a later section.

Alternative coordinate system

The alternative coordinate system that I would propose keeps the argument of periapsis from above, but replaces the other four coordinates. The other four coordinates are your energy and your angular momentum, both divided by your mass. Your angular momentum is a vector, so it encompasses three coordinates. We'll effectively use spherical coordinates to describe your angular momentum, with one coordinate for the magnitude of it and two for the direction.

The direction of your angular momentum is basically equivalent to the inclination and longitude of ascending node as the game displays for you. Indeed, it can be explicitly written that way, with the longitude of the ascending node as the theta angle and the inclination as phi, at least up to a sign issue where the coordinates remain the same if you traverse the orbit in the opposite direction. Because you usually don't want to change the direction of your angular momentum other than to make it the same as that of your target, I find it easier to think if the two coordinates as just a direction on a sphere rather than two separate things.

Your energy and the magnitude of your angular momentum (both divided by your mass) are equivalent to your apoapsis and periapsis in the game's built-in coordinate system. You can compute either pair of coordinates from the other. If your energy is E, your angular momentum L, your apoapsis altitude A, your periapsis altitude P, and the radius of the body you're orbiting R, then you can compute L = sqrt(k(A+R)(P+R)/(A+P+2R)) and E = -k/(A+P+2R). In the other direction, A = (-sqrt(k^2+4EL^2)-k)/(2E) - R and P = (sqrt(k^2+4EL^2)-k)/(2E) - R. The exact formulas don't particularly matter, but that there are formulas to convert proves that the coordinates are equivalent.

At this point, you may be wondering why I'm pushing energy and angular momentum as coordinates rather than apoapsis and periapsis. The latter pair is graphically intuitive, after all, while the former is definitely not. The answer is that when you thrust, how it changes your apoapsis and periapsis is weird and unintuitive. How a thrust changes your energy and angular momentum is much easier to understand. I'll come back to this in a future section.

Conic sections

The shape of the path of one object as it passes by another while affected by the gravity of the latter object has some nice structure. Algebraically, it is a quadratic equation in the two variables for the plane in which the object's path lies. Geometrically, it is a conic section, that is, the intersection of a plane with a cone.

There are two main cases. If your energy is negative, so that you're in a stable orbit, the path will be an ellipse. Geometrically, an ellipse has two foci, one of which is at the center of the object you're orbiting. The ellipse itself is the collection of all points whose sum of the distances from the two foci is some fixed value. So basically, there is some point in space such that at any point on your orbit, the sum of the your distances from that point plus the center of the body you're orbiting is constant. The other point is geometrically intuitive, as the two foci are symmetric about the center of the ellipse.

If your energy is positive, so that you're on an escape trajectory, the path will be a hyperbola, or perhaps more properly, one arc of it. A hyperbola also has two foci, but the arc is the collection of points such that the difference between the distances to the two foci is constant. So basically, when you're on an escape trajectory, the distance to the object you're flying by minus that of some other point in space is constant.

The algebraic equation for a hyperbola actually gives something with two separate arcs, not just one. One arc is for points closer to one of the foci, and the other arc is for points closer to the other. When on an escape trajectory, if you regard the nearest point in the other arc to the body you're escaping as being the apoapsis, the negative of that height will be the apoapsis that the game reports for you. It also matches the formula that I gave in the previous section to compute the apoapsis from your energy and angular momentum. This probably isn't helpful, but a negative apoapsis does have actual meaning and isn't just a bug in the game.

The degenerate cases also give you a conic section. If your energy is exactly zero, your path is a parabola, which is another conic section. If you are traveling directly toward (or away from) the center of the body you're orbiting, your path is a line, or rather, half of one, as if you don't escape to infinity, you're going to go splat and stop. Geometrically, a half-line is also a conic section, obtained when the plane is tangent to the cone.

Modifying orbits

In order to get to where you want to go, it isn't enough to just know where you're going on your current trajectory. You need to know how to change your orbit so that it goes where you want. That's what this section is about.

When near a planet, thrust to go up, down, or sideways is intuitive enough. When off in space, it really isn't. Thrust in one direction at one point can have you going in a very different direction much later in the orbit. The best way to understand this is by understanding the results of thrusting in each possible direction. We'll break down what thrusting in the coordinate axes presented by the game does for you.

In order to rendezvous with some distant body, whether a moon, another rocket, or whatever, you basically need to make all of the coordinates of your orbit match those of the other object. If you use the game's built-in coordinates with the apoapsis and periapsis, how this works is simple enough if you only thrust at those two spots. Thrusting at apoapsis changes your periapsis and vice versa. Burning prograde increases the altitude of the other end and retrograde decreases it. Burning normal or anti-normal doesn't change your apoapsis or periapsis.

One problem with this is that burning inradius or outradius does weird things. Another problem is that it gives you no intuition at all about what happens if you thrust anywhere else. And sometimes, you'll want to thrust somewhere else, so that you can time where you cross paths to get there at the same time as your target. It is possible to make all prograde or retrograde thrusts off in space either from a circular orbit or else at periapsis or apoapsis, often to circularize an orbit. But that's rather limiting.

Burning prograde/retrograde

Burning prograde increases your velocity and angular momentum. Burning retrograde decreases both of them. The amount by which it changes your energy is proportional to your speed. A slight thrust when you are moving at 2000 m/s thus increases your energy by 10 times as much as if you were only moving 200 m/s. Here, it is critical to use your velocity relative to orbit, not relative to the surface. Thus, a given amount of delta V changes your energy the most when you were already moving very fast.

In order to see what this does to your angular momentum, a different coordinate system would be more natural. Earlier, we said that we wanted two coordinates for the plane in which your orbit lies to be the direction you're going and the direction away from the body you're orbiting, or more colloquially, "up". But usually, those aren't orthogonal to each other, so the outradius direction is as close to "up" as we can get while still being orthogonal to the prograde direction.

To see angular momentum, what you'd really like is for "up" to be one of the coordinate axes, and another one to be as close to it as we can get while still being orthogonal to it. This basically means taking the same basic vectors that you started with, but swapping their order before doing Gram-Schmidt. In this new coordinate system, thrusting in the modified "prograde" direction that is orthogonal to "up" increases your angular momentum by an amount proportional to your distance from the center of the object you're orbiting. Thrusting up or down does not affect your angular momentum.

Burning prograde or retrograde does not affect the direction of your angular momentum. Thus, it does not affect the equivalent coordinates of the inclination and longitude of the ascending node.

Note that the effect of burning prograde on your energy depends on your current speed but not your position, while the effect on your angular momentum depends on your position but not your speed. When you do the burn at periapsis, this makes the largest possible change to your energy, but the smallest change to your angular momentum. At apoapsis, it is the other way around.

Burning inradius/outradius

Burning inradius or outradius changes the shape of your orbit. It will typically change both your apoapsis and periapsis in peculiar ways, unless the burn is done at one of the two apses. It does not change your energy at all, however. Its effect on the magnitude of your angular momentum is as explained in the previous section. Burning inradius or outradius does not affect the direction of your angular momentum.

Burning normal/anti-normal

Burning normal or anti-normal does not affect your energy or the magnitude of your angular momentum. As such, it does not affect your apoapsis or periapsis. It likewise does not affect the argument of your periapsis.

You may have noticed that a large burn in the normal direction at a maneuver node makes your orbit end up higher than it was initially. I just said it wouldn't do that. The reason is that as you do the burn, you change which direction is your normal direction. The start of the burn could be exactly in the normal direction, but as the burn goes along, your direction is partially prograde or inradius or something else that isn't purely normal or anti-normal. You can avoid this effect by using SAS to point in the normal or anti-normal direction and turning as you go. For small burns in the normal direction, this doesn't matter much, but you may wish to compensate for it somehow if you need to change your inclination by something large like 50 degrees.

Burning normal or anti-normal modifies the direction of your angular momentum. I think it is pretty intuitive about what direction it turns your orbit in if you think of angular momentum as a direction rather than your inclination and longitude of ascending node as two completely independent coordinates. The rate at which it changes the direction of your angular momentum is inversely proportional to your speed relative to orbit.

Thus, you can make a given change in your inclination or whatever using much less delta-v when you are high above the body rather than close to it. For small adjustments, this doesn't matter much, but if you need to make large changes, or in the most extreme case, turn around to orbit in the other direction, it is more efficient to do this at a whichever of your ascending and descending nodes has greater altitude.

It can sometimes even save a lot of delta-v to first burn prograde so that your orbit reaches a very high apoapsis, then do a small burn at apoapsis to change your angular momentum, and then do a retrograde burn at periapsis to return your orbit to its previous shape. If you need to turn around to orbit in the opposite direction, this will use less than half as much delta-v as the brute force approach of a very long normal or anti-normal burn.

Hohmann transfers

Above, I said that the optimal directions to change your energy and angular momentum using as little delta-v as possible tend to be different directions. At apoapsis and periapsis, however, they coincide. Thus, it is more efficient to do your burns at these two locations when possible. You do a burn at apoapsis by however much you want to change your periapsis, and then the other way around. Or you can do them in the other order. This is called a Hohmann transfer.

It isn't always possible to do a Hohmann transfer. For one thing, if you're trying to land on a planet or dock with another rocket or whatever, it might get you there at the wrong time. If you're not already in a circular orbit, to first circularize the orbit so that you can have a second burn happen at the right time may take more delta-v than just changing your orbit in a single burn.

Another problem with Hohmann transfers is that as an ideal case, it basically assumes an instantaneous thrust, rather than one spread over a long period of time. If your angle in your orbit changes very little over the course of a burn, this is a very good approximation. It's not a good approximation to a five minute burn at periapsis when you start out orbiting on a forty minute period. That doesn't make Hohmann transfers into a bad idea so much as that it sometimes makes them impractical.

Bielliptical transfers

Pop quiz time: you're orbiting the Sun in a circular orbit with a speed of 10000 m/s. There are no planets in this system, so there isn't anything that you can use for a gravity assist. You want to crash head-on into the very center of the sun, or perhaps rather, burn up as you get close while traveling directly toward the center of the sun. How much delta-v does it take to do this?

There's an obvious answer: 10000 m/s. That's what it would take to stop so that you can go directly toward the sun. That's what it would take for the first step of a Hohmann transfer to a very low orbit. But that's not the correct answer.

Rather, you can do it in under 4200 m/s of delta-v. Instead of thrusting retrograde to stop, you thrust prograde to bring your rocket to just shy of an escape velocity. For a circular orbit of 10000 m/s, the minimum escape velocity would be 10000 * sqrt(2) ~ 14142 m/s. So you thrust by perhaps 4140 m/s, then wait a very long time until you reach apoapsis. If you reach apoapsis at, say, 1000 times your periapsis, then by conservation of angular momentum, you'll have 1/1000 times the speed. At that point, you're traveling about 14 m/s, and it only takes 14 m/s of delta-v to come to a dead stop. Then you wait a very long time and crash into the center of the Sun.

This is an extreme case, of course, but this sort of bielliptical transfer is the optimal way to make very large changes to your orbital height. The idea is that you first thrust prograde to get just shy of an escape velocity. Then you wait until apoapsis, where you're barely moving, so it costs very little to dramatically change your periapsis. Then you thrust retrograde at your new periapsis to circularize the orbit. One downside of this is that it takes a very long time to get to a very high apoapsis, however.

What is going on here is that at a very high apoapsis, it takes very little delta-v to change your angular momentum to whatever you want. If you want to change the direction of your angular momentum, this can be a relatively cheap way to do it. For example, if you're in a low equatorial orbit of a planet and want to shift to a low polar orbit, this approach is much cheaper than just burning normal for a long time.

A bielliptical transfer intrinsically costs a lot of delta-v. From a circular orbit, it takes sqrt(2)-1 times your current speed to get up to the very high apoapsis, plus sqrt(2)-1 times your final speed to get back down to your new orbit. Thus, it is a very bad choice for making small changes to your orbit. Still, it's good to understand for when you need to make very large changes to a low orbit.

Spheres of Influence

The way that gravity is believed to work is that everything in the universe has some force on everything else in the universe. One could quibble about what counts as part of "everything", but it certainly includes everything with mass. I say the way that gravity is believed to work because it really isn't well understood. The best known formulas are measurably wrong, not just the classical mechanics approach that dates to Newton, but also the adjustments suggested by relativity.

Gravity is hard to study because it is such a weak force. For example, two electrons repel each other because they have the same charge, and also attract each other due to gravity. The former effect is on the order of a tredecillion times as large as the latter. This is why after Newton wrote down his law of gravity (force = GMm/r^2, where M and m are the two masses, r is the distance between them, and G is some constant), it took about a century before Cavendish made the first effort at calculating the constant G.

One of the problems with implementing this model of gravity in a game is that the collection of all pairs of objects in the entire game is quite a lot. That's going to be computationally expensive. It also doesn't lend itself to nice simplifications such as orbits being known ellipses or hyperbolas.

Another problem with it is that it would make the game a pain to play, as there would be no such thing as a truly stable orbit. You'd put your satellite in some position and it would seem to stay there for months or years, then sometimes wander off and crash or blow up. Real-life space programs have to deal with this, but the game would be a lot easier if players didn't.

For example, you might think of Earth as being in a stable orbit about the Sun, but it's a lot less stable than you might think. That doesn't mean we're in imminent danger of crashing into the Sun. Rather, consider the length of a year. That's one orbit about the Sun, right?

But what counts as an orbit? If two observers are rotating relative to each other, they might disagree. For example, if an observer is slowly rotating at a rate of one rotation per year, he might think that the Earth is always on the same side of the Sun. The idea of a sidereal year is that we take how long it would look like it takes for the Earth to revolve about the Sun once, as viewed from very distant stars. A tropical year doesn't want to rely on some distant points, but is the time between two consecutive summer solstices. An anomalistic year tries to measure purely based on the orbit itself, and is the time between two consecutive times that the Earth is at its periapsis.

These are all reasonable definitions of a year, but they all give different year lengths. An anomalistic year is currently more than 20 minutes longer than a tropical year. And all three of these definitions of a year also have the length of a year change with time due to the effect of other objects pulling on Earth and the Sun besides each other.

The game's approach to simplifying this is to use spheres of influence. The celestial bodies (the Sun, the planets, and their moons) operate on fixed orbits. Everything else is affected by gravity of a celestial body, but does not exert any force due to gravity on anything else. For example, two rockets don't affect each other due to gravity, even though they would in real life.

Furthermore, an object is only directly affected by the gravity of one celestial body at a time. For all others, the effect of gravity on you is assumed to be the same as the effect of gravity on that one particular object. For example, your rocket could be affected by gravity properly measured from Kerbin or Minmus, but not both at once. Which one affects you depends on where you are. Loosely, the game ignores all but the strongest gravitational effect, but that isn't quite right.

More properly, each celestial body has a sphere of influence. If you are outside of its sphere of influence, then it has no effect on you. If you are inside the sphere of influence of multiple bodies, then you are directly affected only by whichever has the smallest sphere of influence, as being in that small sphere ensures that you are much closer to it than to the others. You are also implicitly affected by the bodies with a larger sphere of influence, but the effects of their gravity on you is presumed to be the same as that of the body in your sphere of influence.

For example, if you are not in the sphere of influence of any planet, then the game will compute the effect of the Sun's gravity on you, but no planets will affect you at all. If you are in the sphere of influence of Kerbin but not Mun or Minmus, then the game will compute the effect of Kerbin's gravity on you directly. It will not compute the effect of the Sun's gravity directly, but will assume that it is the same as the effect of the Sun's gravity on Kerbin. If you are in Minmus's sphere of influence, then the effect of Kerbin's gravity is assumed on you is assumed to be the same as on Minmus. The effect of the Sun's gravity on you is assumed to be the same as its effect on Minmus, which is itself assumed to be the same as its effect on Kerbin.

This is a hack that is not true at all of real life. It's the price of making a game playable. It usually isn't that far off from real-life gravity, at least on short time scales. But it does have some weird effects when you transfer from one sphere of influence to another.

One thing that you absolutely should consider when switching spheres of influence is what your velocity will be when escaping. Recall that v^2 - k/r is constant by conservation of energy. If you have just barely enough velocity to escape a sphere of influence, your speed will be basically zero when you leave. But adding a little bit of thrust long before you reach the boundary can give you a lot of speed upon leaving. If you were barely at an escape velocity before, so that v = sqrt(k/r), and then you burn prograde to increase your speed by t, then new velocity upon leaving the sphere of influence is sqrt(2vt + t^2). This will be greater than t, and for large planets like Eve, Jool, or even Kerbin, can be massively larger.

For example, if you're barely on an escape velocity from Kerbin at v = 3000 m/s, and then you add a mere 15 m/s, your speed upon leaving the sphere of influence will now be over 300 m/s. Add 60 m/s and your speed upon leaving will be over 600 m/s. That's an extremely efficient use of delta-v, and unless you're traveling to another planet with a fairly nearby orbit (e.g., from Kerbin to Eve or Duna), you nearly always want to leave the sphere of influence of a big planet with a lot of speed.

Vehicle controls

In order for a ship to go where you want, you have to have some way to control it. There are two basic approaches: manned and unmanned. In this section, we'll consider both.

Manned pods

There are a variety of pods that can hold kerbals and that you can use to control a ship. These only work to control a ship if there is a kerbal inside. Any kerbal can control the ship, but pilots can do it better than scientists or engineers.

The pods differ in a lot of ways, including size, shape, mass, and the number of kerbals that they can hold. Many pods have some degree of built-in batteries, reaction wheels, or monopropellant storage, though these tend to be pretty meager and not a viable replacement for dedicated units in any but the smallest of cases.

The cockpits are not radially symmetric, and are intended for planes, not rockets. As a consequence, they're pretty terrible as a way to control rockets.

The Mk1 Command Pod, Mk2 Command Pod, and Mk1-3 Command Pod command pods have good aerodynamic properties for launch, and are intended to go at the top of a rocket. They vary in radial size and number of kerbals. Their aerodynamics are not so great for landing, however, as they'll try to flip the rocket prograde and then you don't slow down as quickly as you might want. They're also relatively heavy for their number of kerbals.

The KV line of reentry modules have aerodynamics optimized for an atmospheric landing. So long as your lander is just a the pod on top of a stack of things with a radial size of small, you just need to get into the atmosphere at a low enough velocity as to not burn up and then aerodynamics will force you retrograde for a nice landing, at least if you have enough parachutes. Their aerodynamics are bad for launching a small rocket, however, and can easily flip you over.

The Mk1 Lander Can and Mk2 Lander Can are optimized to get kerbals into a lightweight module so as not to waste fuel. Their aerodynamics are terrible, and they're really only intended for use in a vacuum. Most planets and moons have no atmosphere, though, and the lander cans have the lowest mass of any command pods for their number of kerbals.

The PPD-12 Cupola Module is a dumb part whose only real use is contracts that require a base to have a cupola module.

The EAS-1 External Command Seat gives you a very lightweight way for a kerbal to control a ship. It's needlessly dangerous in most situations, but if you absolutely need to get your mass as low as possible for some purpose, this is a way to do it. Be warned that it cannot run crew reports.

Probe cores

In addition to the manned pods, there are unmanned pods that allow you to control a vehicle without needing to have a kerbal on board. This can be useful for a variety of purposes. They don't allow you to reset experiments like a scientist, repack parachutes or repair wheels like a parachute, gather a surface sample, or anything else that you need a kerbal for. But they can be perfectly appropriate for missions that aren't going to do any of those things, such as leaving a relay or telescope in space indefinitely. Unmanned command modules can also be useful for vehicles that will only sometimes have a kerbal present, so that you can control the vehicle without the kerbal.

By far the most important feature of an unmanned module is its SAS level. We'll get to what that means in the next section. But you'll want to get to the SAS level 3 modules as quickly as possible, and then completely ignore all of the ones with a lower SAS level, with rare exceptions. Because probe cores can offer high SAS levels, they can often make having a pilot unnecessary even on manned missions.

The probe cores that offer SAS level 3 can also store science experiment data, in addition to the normal probe core functions. Less advanced probe cores cannot do that.

SAS levels

SAS, or Stability Assist System, allows you to automatically rotate your ship in a particular direction. Rather than having to manually adjust the pitch, yaw, and roll, it can do this for you to get your ship pointing in the desired direction and keep it there. SAS can use both reaction wheels and engine gimbal to point you in the intended direction. This is very useful, and you'll want to get to SAS level 3 quickly. Higher levels of SAS give you more directional options of which way you want to point.

Your SAS level is determined by the highest SAS level of any unmanned command pod or pilot kerbal in a manned command pod on the ship. The possible SAS levels range from 0 to 3. For an unmanned probe core, the SAS level is determined by the module. For a pilot, it is his experience level, at least up to level 3. Only pilots offer SAS; engineers and scientists do not. It is also possible to have a vehicle that offers no SAS, not even level 0.

SAS level 0 offers only simple stability assist. Whatever direction you're pointing, keep you pointing in that direction. If this doesn't sound useful, its utility becomes immediately obvious when you try to fly a ship using only a scientist or engineer and no SAS. Without it, your ship will constantly rotate a little in one direction or another. When in a vacuum, you can make the ship stop rotating by briefly turning on time warp, but you can't do that in an atmosphere.

SAS level 1 adds prograde and retrograde as options. Retrograde is very, very useful for landing. Prograde is useful in a lot of situations.

SAS level 2 adds inradius, outradius, normal, and anti-normal as options. These are occasionally useful, but not very. The difference between SAS level 1 and 2 isn't important.

SAS level 3 adds pointing toward your target, away from your target, and in the direction of a maneuver node as options. The maneuver node option is extremely useful, and makes it much easier to use maneuver nodes. The target and anti-target options are only occasionally useful, but are so valuable for docking in space that I'd hold off on even attempting to dock until you have SAS level 3.

Passenger modules

Sometimes you want to take a lot of kerbals on a single mission. There could be a lot of reasons for this, such as having a lot of tourists to transport. You could load up your ship with a lot of manned command modules, and get the kerbal capacity you need that way. But that is inefficient.

A better approach is to use the passenger modules from the utility section. These don't offer any SAS, and don't give you any way to control the ship. You'll still need either a manned module or an unmanned command core, in addition to the passenger modules. But the passenger modules can carry more kerbals per ton than any command module other than the EAS-1 external command seat. They're also built to be in-line rather than designed to go on the top of a rocket, which makes it much easier to stack them and thus pack a lot of them in.

Coupling

It is possible and commonly even necessary to disconnect a ship into multiple pieces, or connect separate pieces into a larger ship. What you build on Kerbin usually isn't the shape that your rocket will keep for long.

Staging

In most cases, you'll need to stage rockets to get very far. That is, you have some big rockets that provide a ton of thrust to get you off the ground and take you well into Kerbin's atmosphere. After a while, those rockets run out of fuel, so you disconnect them, and have a smaller ship with smaller rockets that can take off from there. Depending on what you're trying to do, you may need to stage like this several times in a single journey.

As an example, suppose that we have a payload of 5 tons for command pods, science equipment, or whatever. We want to get that 5 ton payload to its destination. For simplicity, suppose that we start in a vacuum. Suppose that our last stage has a 4.5 ton fuel tank (which has 4 tons of fuel, counting both the oxidizer and liquid fuel, as well as the tank itself weighing half a ton) and a terrier engine, which ways 0.5 tons. That is good for a delta-v of 1729 m/s, with acceleration that starts at 6 m/s and increases to 10 m/s as the fuel tank empties.

Now suppose that we treat that 10 ton rocket as a payload and add another stage. The next stage will have 9 tons of fuel tanks and two terrier engines. That adds delta-v of another 1729 m/s, and also starts at 6 m/s of acceleration, increasing to 10 m/s as this stage's fuel tanks empty. I'm ignoring the mass of a decoupler for simplicity, but that wouldn't change the values much. After that, another stage that has 18 tons of fuel tanks and four terrier engines would add another 1729 m/s of delta-v with the same acceleration as before to get the 20 ton payload started. Another stage with 36 tons and eight terrier engines would do likewise. The net result of this four-stage rocket is that we have an 80 ton rocket that ends with a 5 ton payload, and has about 6915 m/s of delta-v and always has acceleration of at least 6 m/s available. That won't get you off the ground on Kerbin, but if it starts from orbit, that will get you pretty far.

One might ask, why do we need to make this several stages? Why not have the 80 ton rocket as a single stage with a ton of fuel? If we have just a single terrier engine, and have the other 74.5 tons as fuel tanks, that only gets you 5953 delta-v, which is less than before. Worse, your initial acceleration will only be 0.75 m/s, which won't even get you off the ground on the Mun. If you have eight terrier engines like in the previous example for the same initial acceleration, that reduces your delta-v to 5264 m/s. Having multiple stages works better. And that's even before we consider that later stages give you a smaller, lighter, more maneuverable rocket, which is a major advantage except when trying to take off in a dense atmosphere.

So why? Why does staging work? Without staging, when we finish a fuel tank, we have to carry that empty fuel tank around with us forever. Staging lets us discard the fuel tank and be rid of its extra mass. That allows the same remaining thrust to offer more acceleration than before. Discarding engines, too, is sometimes a drawback, but staging is still a net win if done properly. It is sometimes possible to discard empty fuel tanks without also discarding engines, but the mechanics of doing this properly and still having a decently shaped rocket are tricky. We'll come back to that in a bit.

Vertical decouplers

Perhaps the simplest method of staging is using the vertical decouplers. The TD-12 Decoupler, and about the same thing with other numbers, gives you a way to split two stages vertically. You can put the later stage on top of the earlier one, then disconnect them when you please. There are six such decouplers, and they correspond to the six radial sizes that the game offers.

The vertical decouplers all have arrows on them. When you fire a decoupler, it will disconnect the piece that the arrows point toward, but stick to the other side. You usually want the arrows to point up, as you discard the lower piece while letting the upper piece ignite its engines and take off. There are less common reasons to disconnect in a different direction, and the ability to rotate the decoupler before attaching it gives you this capability when you need it.

Usually the way that decouplers are used are as part of the game's staging sequence. Rocket engines, decouplers, and some other things can be grouped into stages. When you press the space bar (or whatever you reassign it to), it starts all of the parts on a single stage. The simplest, most common example of this is whatever decouplers are needed to discard empty fuel tanks and unwanted engines from your previous stage, while also enabling the engines that you'll fire for your next stage. You don't want to fire the engines for later stages too soon, or else they'll blow up the decoupler and whatever it is immediately attached to from the previous stage. Rather, you fire them when you decouple whatever they were attached to.

Radial decouplers

Using exclusively vertical decouplers tends to lead to some very tall, narrow rockets. That's fine for two or three stages, but once it gets too tall, this can make your rocket not be mechanically stable, so that it falls apart as you try to fly it. It's much like how if you hold a relatively short length of wire, it can seem plenty rigid, but a much longer wire of the same gauge will be bent downward by gravity.

The solution to this is radial decouplers. Rather than having all of the stages stacked vertically on top of each other, you attach some of them horizontally. This allows for a wider, shorter rocket. It also allows connecting pieces more rigidly, so that the rocket doesn't fall apart as you try to launch it.

There are three radial decouplers: the TT-38K Radial Decoupler, the TT-70 Radial Decoupler, and the Hydraulic Detachment Manifold. The TT-38K is the basic one, and the best choice for small, cheap projects. The hydraulic detachment manifold detaches the discarded portion with more force, but has such a high mass for the coupler itself that I've never seen a reasonable use for it. The TT-70 barely detaches with more force than the TT-38K, but it does stand off further, which reduces the chances of the detached piece immediately smashing into remaining parts of your rocket.

For large projects, I like the TT-70 best, as the extra force of the hydraulic detachment manifold barely matters when detaching debris weighing tens of tons, but the extra space that you start with can help. Additionally, the TT-70 makes it easiest to see exactly how things are lined up, so that if you need to separately attached multiple decouplers at almost exactly the same height, you can.

It is probable that one or more of your early attempts at using radial decouplers will fail spectacularly. Basically, you'll decouple something to toss it aside, then the next stage of your rocket will immediately accelerate into it. This causes a high-speed collision of the sort that causes parts to explode. Once you lose some of the rockets that you had counted on having, and might no longer have a symmetric center of mass, you're doomed.

The solution to this is that, if you use a radial decoupler in an atmosphere, make you're that you're accelerating prograde relative to the surface when you do it. Prograde relative to orbit or any direction that isn't particularly close to prograde is no good, as the air is likely to throw the debris that you rejected right back at you. Prograde relative to the surface means that you're acceleration is parallel to the direction in which the air will push debris, and so you don't get an unwanted collision. In a vacuum, this usually isn't a problem unless you have a really dumb design.

Stack separators

Sometimes you want to detach two sections of your ship but keep both. This can be the case if you want to take several small probes to the same area, so you make them various parts of one larger ship for simplicity to get them there. With normal decouplers, the decoupler itself will stick to one piece or another when you try to separate them.

The solution to this is stack separators. These work like vertical decouplers, except that they disconnect from the parts on both sides. As with the vertical decouplers, there is a stack separator for all of the radial sizes of rockets in the game. Stack separators cost a little more than vertical decouplers and add a little more mass, making them an inferior option if one of the pieces that you disconnect is debris that you want to be rid of, as it usually is. But anything that can be done with vertical decouplers could, in principle, be done with stack separators.

While the game has dedicated stack separators available, it is often better to build your own out of vertical decouplers. The reason for this is that while making an implicit stack separator just out of two vertical decouplers is dumb, you can put other things between the vertical decouplers. For example, you could put some batteries or reaction wheels, then attach I-beams to them. From there, you could have a lot of struts that use the "stack separator" as their base point, so that they won't be tied to either of your real vehicles when you separate them. I'll discuss this more when I get to struts later.

Engine plates

It is common for rockets to have a fuel tank with one rocket engine immediately below it. Or sometimes you have a rocket engine immediately below a stack of two or three fuel tanks. When you do that, you generally want the rocket engine centered on the fuel tank, and then vertical decouplers will disconnect the way you want.

Sometimes, though, you want to have a big fuel tank with several rocket engines attached below it. A ring of six nerv engines pushing a Mk3 Liquid Fuel Fuselage Long is my most common case of this. Sometimes you may want to have several dart or vector engines under an S3 or S4 fuel tank. I've had reasons to load up with a bunch of spark engines. The normal vertical decouplers don't work very well if you have several engines like this, as a vertical decoupler must attach to exactly one piece.

The solution is engine plates. So long you don't have an engine at the center of the piece it is attached to, you can attach an engine plate instead. This functions like a vertical decoupler, but has structure to allow you to attach the next stage to the fuel tank or whatever the engines are attached to, rather than having to pick an engine. For example, you could have a Kerbodyne S3-14400 Tank with six dart engines attached to it, then an EP-37 Engine Plate, and then another Kerbodyne S3-14400 fuel tank for the next stage. The engine plate will be attached to both fuel tanks, with the dart engines covered up under the engine plate but not required for structural strength.

If you use engine plates, make sure that you see the option to choose a length. You can adjust to any one of five lengths in the vehicle assembly building. You usually want to pick the shortest length that will fit the engines or whatever else you're hiding under there without clipping into the previous stage.

FTX-2 External Fuel Duct

When you discard previous stages, you might sometimes wish to only discard the empty fuel tanks while keeping the engines. This is possible, though sometimes it makes the rocket so awkwardly shaped as to be a bad idea. What you can do is to have several fuel tanks that are all there to feed the same engine. You use FTX-2 external fuel ducts to connect the fuel tanks to each other, so that fuel can flow from one to another. You wait until the first tank(s) are empty, then discard them by staging, while keeping the others.

An alternative version of this is to have several fuel tanks each of which have a rocket attached, and fire them all simultaneously to get enough acceleration for what you need. You route the fuel ducts such that all of the engines draw their fuel from one or a few of the fuel tanks, and then when that first round of tanks is empty, you discard them, as well as the attached engines. Meanwhile, you keep the rest of the engines firing into the next stage, then all drawing fuel from a different set of fuel tanks.

Taken to its extreme, this is called asparagus staging, as you end up with rockets that look like a handful of asparagus. This was more common before the aerodynamics model was redone in version 1.0. The problem is that a handful of asparagus is not known for its good aerodynamic properties, so you end up with rockets that would be fine in space, but struggle to get out of Kerbin's atmosphere without flipping over, falling apart, or other things that ultimately cause rockets to blow up. Rather than having a large amount of asparagus staging, it's usually better to just use bigger fuel tanks and bigger rockets for better aerodynamics and better structural stability.

That said, a modest amount of asparagus staging can sometimes be useful. Just don't get carried away with it.

It is also important to realize that if two fuel tanks are connected by a coupler or stack separator, you don't need a fuel duct to pass fuel from one to the other. While couplers disable fuel crossfeed by default (to prevent an engine from an earlier stage from consuming the fuel intended for a later one), you can enable it if you want to.

Docking

Suppose that you design your dream space station. It has some of this, some of that, and a bunch of some other things. Space for 72 kerbals. 50 tons of monopropellant. Four science labs. In all, the space station has a mass of about 1300 tons. And you want to put it into a low polar orbit of Jool.

So you design a magnificent rocket to deliver your station to Jool. With all of the staging needed, your gigantic rocket weighs over 40,000 tons. You press the launch button to take it to the launchpad. Then you see that you've got boosters hanging far off of all sides of the launchpad. So far off that the lack of structural support beneath them makes the rocket unstable. It falls apart and blows up on the launchpad before you get a chance to launch. Oops. Does this mean that your dream is dead? Hardly!

In the previous section, we talked about starting with big rockets and splitting them into smaller pieces, commonly to discard empty fuel tanks or other debris. It's also possible to do the reverse of this. You can launch multiple pieces, then connect them to create a larger ship.

There are a variety of reasons why you might want to do this. One is as a way to create larger bases or space stations than it is practical to launch all in one go. Another is to temporarily connect two ships so that you can transfer kerbals, fuel, scientific data, or whatever else you want to transfer from one to another. A vehicle may run out of fuel and become stranded, and you may want to send a rescue ship to pick it up and bring it home. You can have a base or rocket with a bunch of detachable modules, so that you can have that science lab or mining gear when you want it, and not have to carry it around with you when you don't.

Docking ports

One way to connect ships is with docking ports. There are three radial sizes of docking ports available (tiny, small, and large), with multiple form factors for the small radial size. If you want to connect two ships in the future, you give them both a docking port of the same radial size in the places where you will want to connect them. Later, you can have the two docking ports touch, and they will stick together. We'll talk about how to actually dock in a much later section, as it is tricky to do.

One advantage of docking ports is that you can pick exactly where the two ships will dock. They could be rotated a little differently from how you planned if you don't have some way to control that axis when you dock. But other than that one rotational degree of freedom, they'll end up attached exactly how you planned.

In addition to docking, you can also undock. Click on a docking port that is linked to another and you can undock to disconnect them. Thus, the connection from a docking port can be only temporary if you want it. You can dock, transfer fuel, data or whatever, and then undock and carry on.

Advanced grabbing unit

The other option for docking is the Advanced Grabbing Unit, or its recently added smaller cousin. The idea is that one component doesn't have to have any docking equipment, but the other ship can latch on using an advanced grabbing unit. This is the only option when you don't get to design one of the ships, such as if you want to grab an asteroid. It is also an option for grabbing other ships.

The advanced grabbing unit generally doesn't give you nearly as precise of an assembly as the docking ports. You get to pick the precise point on your own ship that has the advanced grabbing unit, but you don't get to pick the precise point that it will latch on to on the other vehicle. Rather, it's probably going to be off somewhat from what you had planned. In addition to being rotated wrong, the point that you latch on to can be off in two dimensions.

When using an advanced grabbing unit, the resulting, combined ship isn't likely to still be radially symmetric. Sometimes your center of mass can be significantly off from your center of thrust, which makes it very hard to control. You can adjust how you've grabbed it after making the initial grab, but realistically, you're never going to get it exactly perfect.

Connecting two ships via an advanced grabbing unit allows you to transfer scientific data and kerbals between them. It does not allow you to transfer fuel, however. When you only want to transfer data or kerbals, using an advanced grabbing unit is easier than needing to line up two docking ports perfectly.

Landing gear

You don't actually need any of the equipment in this section. When you want to land, you can burn retrograde to slow to a near stop, then touch down gently, landing on your engines or whatever the lowest point of your rocket is. So long as you positioned equipment correctly, you can have kerbals get out, plant a flag, reset science equipment, or whatever else you need, and then get back into the vehicle. All that said, a lot of the gear in this section sure does make landing a lot easier.

Lander legs

When landing, there are two basic problems. One is that you could hit the ground too hard, causing parts to explode as part of the collision. The other is that you could land in area so uneven that your ship falls over. The latter is sometimes okay if you're landing on Kerbin at the end of a mission and just going to recover the vessel anyway, but usually means that you're stuck and can't take off. Lander legs can help with both problems.

All parts in the game have some maximum velocity at which they can hit the ground without breaking. Deployed solar panels will generally shatter at the slightest direct touch, but so long as you're not landing on the solar panel itself, everything can handle touching down at 4 m/s, and just about everything can handle up to 6 m/s. Depending on how you build your rocket, you may be able to handle a little higher than that.

So what happens if you hit the ground at a little over 6 m/s? If whatever touches the ground first can't handle that speed, it explodes. If the lowest part can handle that speed, but is a rigid part connected to something above it that can't, the part above it can explode. If what touches the ground first is lander legs, then their springs can absorb a lot of the shock of landing, so that other parts further up the rocket don't explode. This won't always make it safe to touch down at 12 m/s, but it might make it safe to hit at 8 m/s. Ultimately, you'd like to land at under 6 m/s, but lander legs can bail you out if you go slightly over that.

Lander legs are springy, and they explode not by whether they touch the ground at higher than their rated speed, but whether that provides enough force to crush the leg and destroy it. For example, a LT-2 Landing Strut is officially rated at 12 m/s impact tolerance, but I've had a vehicle land at over 35 m/s on LT-2 lander legs with no damage.

The springs in lander legs don't help you if you land in water, however. They just submerge right into the water, and whatever you were try to protect by putting lander legs under it then smacks into the water, and may explode.

The other advantage of lander legs is that they stick out further from your vehicle. A given position of the rocket touching the ground is stable if the line through your center of mass and the center of the planet or moon you land on passes through the convex hull of the collection of places where your vehicle touches the ground. You may not be familiar with the mathematical concept of the convex hull of a set, but it's a pretty simple concept and easy to look up. Lander legs stick some points that hit the ground further out from your rocket, giving you a significantly larger convex hull, and allowing you to land on a steeper slope without tipping over.

Another use of lander legs is that you can adjust the spring in them after landing to raise or lower your entire vehicle slightly. I've used that to line up pieces for docking. Be warned that if you don't revert the spring strength to automatic before switching away from the base, it is likely to explode when you switch back. I'm pretty sure that that is a bug.

That said, lander legs are hardly indestructible. Too much force on them will cause them to explode themselves. This can happen because you hit the ground too hard, or because you have too few to hold up your rocket. The game says that engineers can repair broken lander legs, but I've never seen them break in a repairable manner. Rather, they explode and are gone.

There are three models of lander legs in the game. The largest, the LT-2 Landing Strut, is usually what you want to use. Only for landing very small vessels does it really make any sense to save some mass by using the others.

Rover wheels

If you want to land in a particular spot, you can aim carefully and land right there exactly. Depending on the precision needed, that can sometimes be very difficult. For scanning surface features, you need to be within 4 m, and that sort of precision can be very difficult to achieve when landing from space. One solution to this is to put your vehicle on wheels and then roll around on the ground. Get kind of close, such as within 1 km, then drive over to the surface feature and stop right next to it.

Rover wheels can also give you a lesser degree of the same benefits as lander legs. They can't support as much mass as lander legs, and they don't stick out as far, so you should prefer lander legs to wheels if you don't actually want to roll around.

Rover wheels are also prone to breaking, and will not roll after they break. A level 3 or higher engineer can fix wheels if they break. They can also explode, but the threshold that it takes for them to explode is much higher than for them to merely break.

Rover wheels vary in their size, how much weight they can support, how fast they can go, and how much torque they can apply to brake or push up hills. I generally prefer the TR-2L Ruggedized Vehicular Wheel, as it can support more weight and move faster than the smaller wheels. The RoveMax Model XL3 is the largest rover wheel by far, but it cannot steer, so a vehicle based on them cannot turn.

Ladders

Sometimes, you need a kerbal to go outside and do something. It is nice to be able to get back into the craft without needing the awkwardness of firing up the jetpack. For a simple EVA report or surface sample, you can stay holding the door. If you need to plant a flag, repack parachutes, repair wheels, or reset certain science equipment, ladders can often make it so that you just climb up or down at your leisure to get to where you need to go. On Kerbin, Eve, Tylo, and Laythe, gravity is stronger than your jetpack, so you can't go up at all unless you have something to climb.

There are three types of ladders in the game, all placed in the utility section. For the most part, the Kelus-LV Bay Mobility Enhancer is the best of them, as it is the longest, and they all have the same mass.

Ladders other than the Pegasus I Mobility Enhancer can be deployed and retracted as needed. That allows you to get them out of the way when they aren't needed, land safely, and then deploy your ladders and have them exactly where you need them.

Airplane wheels

In addition to rover wheels, there are also airplane landing gears. They are built to allow you to take off and land, which means they have to function while rolling on the ground at very high speeds. They are also built to keep the rest of your plane well off of the ground, so that you don't crash due to a slight bump.

The problem with all of this is that it assumes that you're building a plane, which you probably aren't. If you are, then yes, do look at the airplane wheels. If not, then ignore them.

Parachutes

The final type of gear intended for landing is parachutes. As with ladders, these are found in the utility section, not the ground section.

As you pass through an atmosphere, drag from the air will slow you down relative to the surface. It is important here that your speed is relative to the surface, not relative to orbit. The idea of a parachute is to have a large surface area that will catch the air to slow you down a lot more than just ordinary air resistance would. Depending on your design, this can sometimes slow you down enough that once you enter the atmosphere, you don't need any further thrust to land safely. Other times, it just slows you down most of the way, so that you only need a little bit of thrust at the very end to land.

Parachutes only work at all in an atmosphere. That means that you are restricted to Kerbin, Eve, Laythe, Duna, and Jool. Parachutes are completely useless everywhere else, and merely a waste of mass.

Furthermore, parachutes will slow you down more in a denser atmosphere. They would provide so little force in a thin, upper atmosphere that they won't even deploy. Rather, they wait until there is some substantial amount of air before they deploy. That means that parachutes aren't that effective on Duna, but are extremely effective on Eve. Parachutes are generally ineffective on Jool because they won't fully deploy until you get near sea level, by which point, the pressure is so high that rocket engines won't work at all.

Parachutes effectively harness the air to exert force to pull your ship in a retrograde direction. But they can only exert so much force without tearing off. By default, parachutes won't deploy until you're traveling slowly enough for it to be safe. In some cases, you can rely on simple drag with the air before parachutes are deployed to slow you down enough to reach this threshold.

On Eve or Jool, you can't just rely on a bunch of parachutes as the only way to slow you down. Those planets are large enough that you'll burn up in the atmosphere before you slow down enough for parachutes to deploy unless you either burn retrograde or use a heat shield. That can happen on Kerbin, Laythe, or Duna, too, if you come in too fast, but parachutes alone are enough from a low orbit.

There are two types of parachutes: drogue and main. Drogue parachutes are smaller and tougher, so they can safely deploy at higher speeds. They don't offer as much drag once deployed as main parachutes, however. Ultimately, you probably want some of each type.

Parachutes also partially deploy at one stage, then fully deploy at another, lower stage. If they fully deployed too soon, the huge amount of force to slow you from high speeds could tear your ship apart. The partial deployment is based on atmospheric pressure, while full deployment is based on altitude. Normally, the order of parachute deployment is that drogues partially deploy, then main parachutes partially deploy, then drogues fully deploy, and then your main parachutes fully deploy. Breaking this into four stages makes it easier to have progressively increasing drag without too big of a spike all at once that tears your ship apart.

That said, you do have to be smart about parachute placement. You generally want to place them high up on your craft. They'll pull you retrograde from wherever they are placed. If they are placed up high, this pulls your ship right-side up, so that you can land in the direction you want. If placed too low, they could flip you upside-down.

Still, that doesn't mean that you want to put a lot of parachutes all on the highest point. For a heavy vehicle, that much force applied to a single part can sometimes yank it off entirely. Rather, you want to spread them out quite a bit to apply their force somewhat evenly, while keeping the center of parachute force substantially above your center of mass.

If landing is the end of a mission, such as to recover a vehicle on Kerbin or leave a probe permanently located on another planet, then parachutes can be single use. If you have an engineer of level 1 or higher, you can repack parachutes to use them again. This allows you to use parachutes to land once, then repack them, then deploy them again the next time you land. The engineer has to be able to get close to a parachute to repack it, so you may need to have a lot of ladders available. This can also restrict parachute placement to places you can reach.

The game has five particular models of parachutes, but other than the extremely early game when the Mk16 Parachute is the only one available, the Mk2-R Radial-Mount Parachute and Mk12-R Radial-Mount Drogue Chute are really the only ones that are useful. In particular, the larger Mk16-XL Parachute and Mk25 Parachute are completely useless. Using two of the analogous radial parachute (and an aerodynamic nose cone where the larger parachute would have gone) instead will get you more deployed drag for less mass and less non-deployed drag.

Communications

There are two basic reasons why you'll want to have your ships be able to communicate with the home base on Kerbin. One is sending information from Kerbin to the ship to tell it what to do. If you have a pilot on board, you always have full control of the ship, as the pilot can do whatever he needs to. But probe cores don't know what to do, so they won't be fully functional unless you can contact them from Kerbin to tell them what to do.

The other reason is sending information from the ship back to Kerbin. When you run some science experiment, you can recover the data by flying the ship all the way back to Kerbin and landing. But you can also get some science immediately by transmitting the data back. The latter often gives you less science than returning the vessel, but you can also transmit the data, immediately rerun the experiment, and get the rest of the science that way. That gives you some science now and some later, rather than all of it having to wait for later.

Controlling probes

If you have a pilot on board, you'll always have full control of the vessel with whatever SAS capabilities the pilot can offer, even without any communications link back to Kerbin. But without a pilot, you'll either have only very limited controls (no SAS) from a scientist or engineer, or only what controls a probe core can give you. And if you can't contact the probe core, you can't make it do what you want.

Exactly what you can make a probe core do while you cannot contact it depends on your difficulty settings. The default is that it will not let you create maneuver nodes, and will not let you do any amount of thrust beyond maximum or nothing. You can also set it to give you no control of the ship at all. Or you can make things easier on yourself and always have full control of a probe even without a communications link.

Communications gear

There are two types of communications gear: antennas and relays. They work just as well for transmitting data, but relays can receive data, as well. Relays allow a spacecraft to act as an intermediate node when some other ship wants to transmit data, while antennas cannot do this. As such, if you're going to bring a relay, there is scarcely any point to bringing an antenna, too.

That might lead you to ask why use antennas at all. The answer is that antennas are smaller, cheaper, lighter, and can be deployed to avoid aerodynamic issues. You generally need to ask whether you need a vessel to relay communications from other vessels. If not, then make things simpler and bring an antenna instead of a relay. Ground-based relays aren't very useful, as the planet they're on blocks them at least half of the time, so you likely don't want a relay for vessels that are going to land somewhere and stay there.

There are six strengths of antennas for you to use. The weakest is built into command pods, but other than doing experiments around Kerbin (or Mun, once you upgrade the tracking station), is really only intended to let you contact some other relay. The next two are really only intended to connect to another vessel in the same planetary system, and likely the same planet or moon within the system.

If you're using an antenna, you might as well use the most powerful one you have access to, with exceptions for very small and light vessels. Even the top end Communotron 88-88 is smaller, cheaper, and lighter than the RA-2 Relay Antenna that is only 2% as powerful as it. For a relay, it can depend on just how much of a problem the bulk and awkward aerodynamics of an RA-100 are. Regardless, it is pretty much always better to use one of a larger relay than to combine multiples of a smaller one.

While weak, the Communotron 16-S can be handy for flying in an atmosphere. Unlike all other antennas, it is surface mounted, rather than deployed, so wind won't snap it off. Unlike the surface mounted relays, it is very lightweight and does not cause aerodynamic problems.

CommNet

In order to be able to communicate with a vessel out in space, you don't necessary need a direct signal from Kerbin to the ship. Indeed, sometimes that is impossible because there is some planet or moon in the way--often the one you're landed on. Rather, you can have the ship connect to one satellite, that satellite connects to another satellite, and the second satellite connects back to Kerbin. Or however many hops you want.

Your network of satellites that can act as intermediate hops to connect any spaceship to Kerbin is called CommNet. Only vessels that have a relay rather than an antenna can act as intermediate hops. Larger, more powerful relays allow connecting over longer distances. You can also put several relays on a satellite, and they will partially combine to further increase distances.

A communications link isn't necessarily just there or not there. There can be intermediate amounts of strength. For purposes of controlling a probe, any weak connection is good enough. For transmitting science, a stronger connection will get you more science. This is unrealistic, as what they would do in real life is to still get all of the data back, but just take longer to do it. For example, transmit every bit 5 times instead of 1, then do a majority vote to determine what the real bit is.

Exactly how many relays you need to send out depends on your communications needs and how reliable you need the link to be. For example, if you have one powerful relay near a planet, any other craft near that planet only needs to connect to that one relay, which can send the data back to Kerbin. And that might work fine most of the time, but occasionally, you'll be on the opposite side of the planet from that relay and lose the connection. Or if you're going to land, then "occasionally" might mean about half of the time.

That is solvable by having a bunch of relays about the planet. It is generally better for them to be in a relatively high orbit, so that the planet only infrequently blocks one relay from seeing another. You can have one satellite with a bunch of relays on it for the main jump back to Kerbin, and the rest be much weaker. That way, if your vessel can see any one of the relays, it can connect to it, which will connect to other relays to get to the big, powerful one, and from there, send the data back to Kerbin.

The transmission strength matters for both ends of the link for a connection. The strength of the link is basically the geometric mean of the strength at the two ends. You can also put a satellite with a bunch of relays in orbit about Kerbin, to have a far stronger connection to it from deep space than any of the ground-based satellites offer.

Transmitting science

Any part that is capable of storing science experiments results can ask to transmit the results back to Kerbin. It will actually use any antenna or relay to do the transmission. Transmitting data back uses electricity, and if you run out of electricity before you finish the transmission, it fails. If this happens, you still have the data on your ship, but don't get any science for it.

The amount of science that you get by transmitting data depends on the strength of your connection back to Kerbin and the particular experiment. An EVA report or crew report will give you the full science value by transmitting it. Other experiments will only give you a fraction of the science value from transmitting it, and you'll have to go land back in Kerbin to get the rest of the science value. To a scientist on Kerbin, someone telling you about a moon rock just isn't as good as actually having the moon rock in your hands.

Heat

When traveling through space, it is quite possible for a spacecraft to overheat and explode. This section is about what causes that and how to avoid it. While rocket engines put out considerable heat, I'll ignore them for the rest of this section, as they don't put out enough heat to cause any parts to overheat and fail unless you botch your design by having a rocket engine pointed right at some other part of your ship.

Atmospheric entry

The main source of overheating and burning up is moving too fast inside of an atmosphere. It is sometimes called re-entry, as the most natural place for it to occur is when a ship returns to Kerbin. It is also possible to overheat and explode before you get out of the atmosphere in the first place, though doing so on Kerbin takes a sufficiently botched design that it's unlikely that you'll ever do so by accident.

The reason why atmospheric entry causes overheating is mysterious to a lot of people. Some think it is due to friction with the air, but this is completely wrong. Traveling at 2500 m/s at a height of 40 km above Kerbin can cause serious heat issues, even though it results in far less friction with the air than traveling at 100 m/s at sea level. You can readily verify this by looking at how quickly your velocity changes due to air resistance. And traveling only 100 m/s at sea level causes no heat problems at all.

It is sometimes said that the heating of atmospheric entry is caused by compressing air, as in the ideal gas law, PV = nRT. This is kind of true, but not very helpful. It's not at all obvious what to use for the volume, and whatever you use, air is rushing in and out. Having P, V, n, and T all changing wildly makes it difficult to glean any insight. (R ~ 8.314 J/K-mol is a constant and does not change.)

A better model is that of gas molecules bouncing around randomly. The kinetic energy of a molecule is .5mv^2, where m is the mass of the molecule and v is its speed. An atmosphere may be composed of a mix of numerous gases, but a single molecule isn't going to cause your ship to overheat, so we may simplify this by assuming that all of the molecules in an atmosphere are average in some sense (but not velocity, where the average velocity vector is 0). Thus, the temperature of a molecule is proportional to the square of its speed.

The key insight here is, speed in which reference frame? Oxygen molecules on Earth typically have a speed of around 500 m/s relative to the nearby surface of the Earth. But if you're in a spaceship and moving at 2000 m/s relative to the surface, those oxygen molecules aren't moving at 500 m/s relative to you. They're probably moving at around 2000 m/s relative to you. And that means that, to you, they seem many times hotter.

If an air molecule is moving at v m/s relative to the planet it is near, and you are moving at w m/s relative to that planet, then the molecule is moving at somewhere between w-v m/s and w+v m/s relative to you. For complicated reasons (you can derive this with a double integral over a sphere if so inclined), if the direction of the molecule relative to the planet is uniformly random, then the root mean square (not average when doing kinetic energy computations) speed of the molecule relative to you is sqrt(w^2 + v^2). If you're traveling fast enough for atmospheric entry to be an overheating problem, then w is going to be much greater than v, so this will be a little greater than w.

The upshot of this is that, when you're approaching an atmosphere at high speeds, the apparent temperature of that atmosphere will be approximately proportional to the square of your speed relative to the surface of that planet. And yes, it's relative to the surface, not orbit, though in the game, that doesn't make a very big difference other than on Jool. Still, a given orbital speed will be a smaller speed relative to the surface if you're traveling east near the equator.

The rate at which the atmosphere will heat your ship is proportional to (the difference between the atmosphere's apparent temperature and your ship's temperature) times (the density of the atmosphere). The first component of temperature difference is just how thermal transfer works. The second is because heat is transferred by collisions with individual molecules, and the more of them that are there for you to hit, the more heat can be transferred.

Or at least, that's what it would be if you weren't moving. The front part of the ship will hit many more molecules as it cuts a path for the rest of your ship to follow. The exact term is complicated, but at high velocities, you roughly have to multiply by (your speed relative to the atmosphere) / (average speed of an air molecule). This means that the front part that is hitting the brunt of the atmosphere will heat up much faster than side parts, even if both see the same apparent temperature of the atmosphere.

The upshot is that the temperature to which the atmosphere will heat your ship is roughly proportional to your speed squared, and the rate at which it will push the front parts of your ship toward that temperature is roughly proportional to your speed cubed. That 100 m/s at sea level ship doesn't cause overheating because the equilibrium temperature is cool enough to not be a problem. But if you enter an atmosphere at 3000 m/s, that's likely to cause enough heating to cause your ship to explode, at least once you get to denser portions of it. Still, the very top of an atmosphere is so thin that even very high velocities are okay.

Still, it is not the case that the effective temperature of air depends only on your speed. The effective speed of individual molecules will be roughly your own speed when you are traveling fast enough, but different gases will have different root-mean-square speeds even at the same temperature. At a given temperature, all gases will have about the same kinetic energy per molecule, but that means that those with lower masses will tend to have higher speeds. While I haven't done precise measurements, it is fairly obvious that Jool's atmosphere causes much less heating than would be expected from your speed as compared to other atmospheres, while Eve's seems to cause more of it.

The Sun

The other major source of heat that can cause your ship to explode is the Sun. Basically, if you get too close to the Sun, you die. Technically, this could add to atmospheric entry heating, but no atmospheres are close enough to the Sun to be a real problem. Thus, other than when trying to get into a low orbit about the Sun, you can generally ignore the Sun's heating.

For science purposes, the boundary between a low and high orbit about the Sun is one million km, or one thousand Mm, as the game will display it when you approach that threshold from above. So long as you're either in a high orbit about the sun or barely in a low orbit, you can largely ignore such solar heating. You'll get warnings that your ship is hot while near the edge of a low orbit, but it won't actually blow things up. If you want to get much closer to the sun, you absolutely can cause your ship to explode.

Blackbody radiation

The main source of cooling in the game is blackbody radiation. All normal matter emits electromagnetic radiation unless it is already at absolute zero. That's just how the universe works.

To explain the name, an ideal blackbody is an object for which radiation reflected is negligible as compared to radiation emitted. There are basically two ways this could happen. One is that very little radiation reaches the object, so that radiation reflected will be neglible regardless of whether it is reflected or absorbed. The Sun is a good example of this. The other is an object that absorbs nearly all radiation rather than reflecting it. An object that does this for the visible light spectrum will visibly appear black, which is the source of the name. Other portions of the electromagnetic spectrum matter, too, especially infrared if dealing with objects near room temperature.

According to the Stefan-Boltzmann Law, the intensity of blackbody radiation that an object emits is proportional to the temperature to the fourth power. The temperature here has to be a distance from absolute zero, so it is customary to use Kelvins (not Celsius or Fahrenheit!). There are some complications, in that some objects will radiate more heat at a given temperature than others. In particular, those that reflect more energy (so as to absorb less) also emit less. But for a given spaceship, the rate at which you cool down via blackbody radiation is proportional to temperature to the fourth power. Which is to say, it scales up very quickly as you get hotter.

This allows you travel in an atmosphere at a high enough speed for it to have an apparent temperature of 3000 K without your ship ever exceeding 2000 K, at least so long as the atmosphere is thin enough not to heat you up too quickly. So long as the rate of heating from the atmosphere (or from the sun) is less than the rate that you'll shed that heat via blackbody radiation at a temperature just shy of what will cause you to explode, you'll be fine.

The spectrum of blackbody radiation emitted also depends on the temperature. At room temperature, it is almost entirely in the infrared range, but as an object heats up enough, it can start emitting a lot of visible light. That's what causes very hot objects to start glowing red. Or orange or yellow if they get hot enough. The game doesn't modify the color changing as objects heat up, though, other than by making things turn red.

Thermal control systems

Most of your cooling will come from blackbody radiation, but you can also use thermal control systems to transfer heat within your ship. This is mainly used to cool mining parts, but you can also use it to transfer heat from the front portion of your ship that is heating up tremendously to a radiator that isn't, and then the radiator can dissipate that heat off into space. That's typically not a great idea for handling atmospheric entry, as the good thermal control systems will break off from drag with the air. It can help if you want to go unreasonably close to the sun, however.

Part fragility

All parts have some maximum temperature for safe operation. If they go above this, they are liable to explode. Many parts have a maximum temperature of 2000 K. It is often handy to think of your entire ship as having a maximum safe temperature of 2000 K. So long as the ship stays below that, you're fine.

Some parts have a lower maximum temperature, however, most commonly 1200 K. That's true of all science equipment and rover wheels, for example. Such equipment largely needs to be protected from overheating. In some cases, this means putting them inside of a service bay, so that they won't get hot during atmospheric entry. In others, it can mean leaving them out of the mission entirely. You really don't need rover wheels to go diving into Jool's atmosphere or low orbit about the sun. If you can't protect them, such as when trying to land a large rover on Eve, you'll just need a much more robust retrograde burn than normal to protect them from atmospheric entry.

There are also some parts with a maximum temperature greater than 2000 K. Most of the time, this doesn't offer any benefit as compared to a maximum temperature of 2000 K, as if something else reaches 2000 K and blows up, your mission probably still fails. The key exception is for the front parts that take the brunt of the heating during situations where parts are likely to overheat.

Heat shields

One strategy to protect your ship from death by overheating is to put some parts that can handle very high temperatures in the front of the ship, so that the brunt of the heating is borne by parts that can handle it. While there are some parts that could be reappropriated for this use, heat shields are specifically designed for it. All heat shields have a maximum temperature of at least 3300 K. Furthermore, most of them have some ablator that can boil off to absorb heat and protect the heat shield even against heating loads that would otherwise have caused it to exceed 3300 K and explode.

Heat shields aren't really intended for getting closer to the sun. They're unnecessary if you just want to get to low orbit for science purposes. They can help if you want to get closer than necessary for science reasons, but even heat shields will overheat and explode if you get too close.

Rather, the real intended use of heat shields is for heating from atmospheric entry. That's obviously useless for bodies that don't have an atmosphere. It's also pretty easy to land on Kerbin, Laythe, or Duna without a heat shield. If you're in a low orbit just outside of the atmosphere, then slow down a little to get your periapsis into the atmosphere and wait, you'll reach the ground without overheating, at least provided that the atmospheric entry heating is mostly hitting parts that can handle 2000 K.

Rather, the real use of heat shields is if you need to hit an atmosphere at higher speeds. If you want to land on Eve or reach Jool's lower atmosphere, then expect to overheat and explode unless you either have a heat shield or use a lot of fuel to burn retrograde and slow down.

Alternatively, a heat shield can allow you to approach a planet at a higher velocity without having to burn fuel to get into a low orbit first. For example, if properly shielded, you could set your Kerbin orbit to a periapsis of about 30 km while orbiting one of Kerbin's moons, enter Kerbin's atmosphere at around 3000 m/s, have the heat shield take the brunt of the atmospheric entry heating, and survive. If you wanted to first return to a low orbit about Kerbin before entering its atmosphere, you'd need about another 1000 delta-v of fuel to burn retrograde. That sort of aerobraking can save you a lot of fuel.

Still, heat shields can only do so much for you. If you want to enter an atmosphere at 20000 m/s, your heat shields will overheat and explode, and then so will the rest of your spacecraft. So while they increase the speed at which you can enter an atmosphere, they hardly make it infinite.

Additionally, while it usually isn't that hard to use heat shields to protect a small craft that only needs to land to finish its mission, it's much harder to properly shield larger vehicles that will have additional stages and need to subsequently move around. Heat shields are unaerodynamic, which makes it easy for drag to cause your ship to flip over, have something else besides the heat shield take the brunt of the heating, and still explode. Heat shields having a lot of drag is an intentional and necessary feature of their design, as otherwise, they wouldn't slow you down to survive landing. Try leading with aerodynamic nose cones and watch your ship crash into the ground at speeds too high for the parachutes to safely deploy, which would be the alternative if heat shields were more aerodynamic.

Mining and refueling

One challenge to any mission is that you only have so much delta-v. Once you've used up your fuel, you can't thrust anymore, and you're done. Hope you've made it back to Kerbin, or at least reached your intended destination.

Except that the universe is made out of rocket fuel. All that you have to do is land somewhere, pick up some dirt, and fill up. That's not how real-life works, of course, but it is how the universe of Kerbal Space Program works.

In order to refuel, there are three things that you need: mining drills to dig up ore, tanks to hold the ore, and converters to process the ore and turn it into your needed fuel. You can't create xenon, but you can convert ore into all of the other types of fuel: liquid fuel, oxidizer, and monopropellant.

You can refuel on planets or moons. You must be landed, however; splashed down doesn't count. And you can't drill for fuel on Jool or the sun, since you can't land there. You can also refuel on asteroids or comets, though asteroids have a limited amount of ore that you can drill up. Planets and moons have unlimited ore.

Excavators

There are two excavators in the game: the 'Drill-O-Matic Junior' Mining Excavator and the 'Drill-O-Matic' Mining Excavator. As you might guess, the latter has higher cost, mass, size, and output.

The critical difference is that the full excavator can dig up ore anywhere that there is ore at all. The junior version can't get any ore at all if the concentration is too low. At default ore concentrations, the larger excavator can get ore absolutely anywhere that you're landed, while the junior one won't be able to find anything in some places. If you reduce the ore concentration of the universe, there will also be places that the larger excavator can't pick up any more, but still fewer of them than where the junior one will fail.

It can be quite a nasty surprise to land somewhere in a mission that requires you to refuel, and then learn that there is no ore to be had. Mission failed. Because of that, I don't recommend using the junior drill at all unless you absolutely have to.

Both drills are radially mounted, so if you only have one, your center of mass will be off center. As such, if you're going to use mining drills at all, you probably want two, placed in a radially symmetric manner.

Ore

The game regards ore tanks as a type of fuel tanks. There are three, in different sizes: radial, small, and large. They all helpfully give their size in their name. Unlike most fuel tanks, ore tanks can jettison their contents without needing a drain.

You have to have at least one ore tank or else mining drills won't have anywhere to place their ore. They can't pass ore directly to a converter. But even the smallest ore tank as a small buffer is plenty for most purposes. If using radial ore tanks, you might want two, so that you can make them symmetric. But if you're only ever going to run a converter while you're on the ground mining, two radial tanks or one small (whichever is easier to fit into your design) is plenty for a lot of purposes.

There are some non-obvious reasons why you might want more ore holding capacity, however. One is that in career mode, there are missions to drill up a particular amount of ore on a particular body, generally less than 3000 ore. If you have two large holding tanks, and dump their contents just before leaving a base to return to the space station, but leave the drills running, they'll fill up with 3000 ore while you're away, at least if you're away for long enough. If you later pick up a mission to mine some amount of ore on that particular planet, you can switch back to the base, instantly complete the mission (as it credits you with acquiring the ore when you switch to the base), and dump the ore again in preparation for the next mission.

Full ore tanks have a very high density, as they have far more mass than a rocket fuel container of the same volume. Most rockets will float if they splash down in the water. If you have some full ore tanks around, you can make your ship heavy enough to sink. If you sink to the bottom of an ocean, you can perform science experiments while landed in the ocean, rather than merely splashed down. That gives you separate science rewards--including some on Laythe that are otherwise unobtainable. You can also return to the surface if so inclined by jettisoning your ore tank contents.

A third reason to consider having a lot of ore tanks is that they have a better ratio of wet mass to dry mass than liquid fuel tanks (without oxidizer), as well as offering a different and often more convenient form factor than the jet fuel tanks. By packing ore instead of liquid fuel, then converting it to liquid fuel while in flight, you can get more delta-v for nerv rockets from less mass and much less space than if you had instead packed jet fuel directly. You do need at least one jet fuel container as a buffer for conversion, however. This only works for very long flights that have plenty of time to convert the ore into jet fuel, and really only lets you burn as much at a time as you have space to store jet fuel. But nerv rockets tend to be targeted at very long distances, especially interplanetary, so this fits their typical use case perfectly.

Converters

There are two converters: the Convert-O-Tron 125 and the Convert-O-Tron 250. As you would probably guess, the latter has higher cost, mass, size, and output. But while the large converter will give double the output per unit time of the small converter, it actually burns only one fifth as much ore. As such, the larger converter gives you ten times the ore efficiency of the smaller one.

The two converters use the same amount of electricity while running. Both converters and excavators use a lot of electricity, so you'll likely want some pretty robust electricity generation methods to power them. Alternatively, you could use the trick of waiting for your batteries to fill, starting both the converters and excavators, and then switching back to the space center. Your electric charge level only changes while you're watching a base, so the converters can keep running without needing more electricity while you're elsewhere.

Unlike with excavators, the smaller converter does fundamentally work, however, at least when landed on planets and moons. It just takes ten times as long to refuel as the larger one would. The smaller converter is basically unusable on asteroids, where you can only recover a finite amount of ore before the asteroid runs out. But elsewhere, it's really just a question of how long you're willing to wait.

Thermal efficiency

Excavators and converters burn a lot of electricity, and that mostly gets turned into heat. If not cooled properly they can overheat. They do need to get fairly hot, as they work better once they've heated up, but overheating reduces their efficiency.

You can make excavators and converters work by strobing them off and on. Turn them on, let them heat up, then turn them back off and let them cool down. But the faster solution to let them run continuously is to use thermal control systems. Those will automatically cool excavators and converters down to their optimal running temperature if they had been running long enough to exceed that. Thermal control systems have a finite cooling capacity, so make sure that you bring enough to handle however many converters and excavators you want to run at once.

Scanners

The ore concentration varies by biome, and is rolled randomly when you create a new game. Rather than just landing somewhere and finding out how much ore is there (possibly none, depending on your settings), you can also use a scanner to find out before you land.

There are three scanners. The M700 Survey Scanner must be used first. The idea is that you put a satellite in a polar orbit of moderate height, and then run a survey. What would happen if this were realistic is that a survey would take place over an extended period of time, as you pass over every portion of the planet over the course of many revolutions. The polar orbit allows that, while a non-polar orbit does not, as it does not take you over the poles. But that would be a pain, so instead, the game just gives you the results of the scan almost immediately.

The game uses your antennas or relays to transmit the results of the survey back to Kerbin. As with transmitting science, this takes electricity, and if you run out, the transmission can abort. For most bodies, this doesn't take very much, but it takes quite a lot for Jool, which is huge. As such, you'd better bring either a lot of batteries or some very robust electricity generation, which that far away from the sun, probably means fuel cells. You cannot do a survey of the Sun.

The other two scanners are intended to get you a higher resolution of the ore concentration in particular locations. As the ore varies by biome, you can largely figure out where to go by comparing the survey scanner results to a biome map from any device that gives you KerbNet access. As such, I don't personally find the smaller scanners useful.

Electricity

A number of pieces of equipment use electricity. As such, you need to have sufficient electricity available to power them. The game doesn't have any restrictions on voltage or current, but only on how much electrical charge you have. If you're generating electrical charge faster than you're using it, your stored electrical charge goes up until all of your batteries are at maximum capacity. In the reverse scenario, it goes down until it reaches zero, at which point, some things that are using electricity must shut down. We'll break this into three sections, to cover generating electricity, storing it, and using it.

Consuming electricity

First up is the things that consume electricity. Deciding how to handle electricity for a given ship generally starts with determining how much you need. That's driven by your mission, and what equipment you need to run. Only after you know how much you need does it make sense to choose how to store and generate it.

Probe cores

Unmanned probe cores use a very modest amount of electricity, ranging from 1.2 to 4.8 charge per minute. For many purposes, that is negligible. If you have no means of generating electricity at all, however, that is very much not negligible. Slowly drain electricity for days and eventually you run out. That forces the probe core to shut down, which leaves you with absolutely no control of the satellite. Often, this means that a satellite is dead and useless, though it can be recoverable if you have solar panels that eventually pick up some sunlight. Remember that once a probe is out of electricity, you cannot give it any commands, so forgetting to deploy solar panels before you run out of electricity can sometimes cause a mission to fail. Having a nuclear generator on board will mean that you always have far more than enough to power a probe core.

You can greatly reduce the electricity consumption of a probe core by putting it in hibernation mode. That limits your control of the probe, but that's fine if it only hibernates while doing a time warp. That can help with short missions that have no electricity generation, or for missions that have very limited power generation, such as relying on solar panels near Jool or Eeloo.

Reaction wheels

Reaction wheels also use electricity, though typically not very much. Even the largest of them only uses 0.6 charge per second, and you usually don't run reaction wheels for very long. As such the electricity usage of reaction wheels is usually negligible. The main exception is if you have a manned spacecraft with no means of generating electricity. If your mission is too long, you can run out of electricity and then be unable to turn. This can also be a problem if you were relying on solar panels and then have to operate in the dark for too long.

Rover wheels

Rover wheels also use electricity to power the rover. They range from 1 to 5 electric charge per wheel per second. The TR-2L Ruggedized Vehicular Wheels that I usually recommend use 3.5 charge per second per wheel. Multiplied by several wheels, this can easily cost you tens of charge per second.

Even so, rover wheels only use electricity when accelerating. Even moving fast while not accelerating doesn't use charge. As such, it can work to bring plenty of battery capacity and only modest electricity generation, then stop and park for a while when you need to recharge.

Rover wheels are only used when landed, and when landed, whatever you've landed on will block the sun about half of the time. Or more, if you're in a crater. As such, you may not wish to rely on solar panels to power a rover, as that will make the rover only usable in the daytime.

Antenna transmissions

Having antennas transmit science can burn electricity quickly. Antennas range from 20 to 200 charge per second, with the larger relays all using 68.6 charge per second. That's quite a lot, but the transmissions tend to be in short bursts. If you start a transmission and then run out of charge, the transmission fails. You'll still have the data, but have to start over on transmitting it. The usual solution to this is to have sufficient battery capacity to handle an entire transmission, and then let the batteries recharge over a potentially longer period of time.

Dawn engine

Each dawn engine uses 8.741 charge per second at maximum thrust. As that maximum thrust is only good for 2 kN, they're really only good for very small spacecraft, and even then, you might want several. As such, dawn engines can burn through electricity in a hurry.

Furthermore, the nature of dawn engines greatly restricts how you can reasonably power them. If you use fuel cells to generate their electricity, then the mass of rocket fuel burned to generate the electricity will be about 2.25 the mass of the xenon fuel used. If you count the fuel in addition to the xenon when computing the specific impulse, then you basically divide the specific impulse by 3.25. A specific impulse of 1293 would still be the highest in the game, but it's not that far superior to nerv engines, and with a lot more drawbacks.

Relying on nuclear generators can be a problem because of their mass. You'd need nearly a ton of generators per dawn engine, and all that added mass would greatly decrease the delta-v. If you have too few nuclear generators to power the dawn engines continuously, then you can run them at lower power. That can work, but it's something of a nuisance, as it can turn a one hour burn into a five hour burn. And you have to be there watching that spacecraft the whole time. And remember that you can't time warp while burning, though you can physics warp, but only up to x4 speed.

That really leaves solar panels as the ideal way to power a dawn engine. But that only works if you have access to plenty of solar power, which you won't if in the shadow of some planet. And even solar panels don't generate very much energy if too far away from the sun. If near Jool, they generate much less electricity per mass than a nuclear generator. Near Dres, they're close to even with a nuclear generator, and even that assumes that the angle is optimal. You probably don't need dawn engines to go to Eve or Duna, leaving trips to Moho or a low orbit about the sun as the places where they work well. But they do work really well in a low orbit about the sun.

Mining gear

The 'Drill-O-Matic' Mining Excavator uses 15 charge per second, and the Convert-O-Tron 250 uses 30. As you probably want to run multiple excavators and the converter all at once for long periods of time, this can burn quite a lot of electricity.

One approach is to effectively cheat by starting up the mining gear, then switching to a different ship. So long as you switch before you run out, the mining gear will keep running, but the stored electric charge won't change while you aren't watching the ship.

The other approach that makes it easy to run continuously is to use however many fuel cell arrays (plural!) you need, typically packing one per excavator and two for a converter. Yes, this burns fuel, and the point of mining is to replenish your fuel. But apart from an extremely low ore concentration, mining will tend to replenish your fuel much faster than the fuel cells burn it. On net, you're still gaining fuel, but only a little slower than before. That can often be worth it for the convenience.

Robotics

Robotic arms use electricity to run. For servos and cylinders that only move briefly, this can often be negligible. For rotors that are intended to run for long periods of time, this can use a lot of electricity quickly. If trying to power a helicopter, using fuel cells is nearly mandatory.

Generating electricity

There are several basic methods of generating electricity, and they all have their uses.

Solar panels

One way to generate electricity is with solar panels. Basically, if a solar panel is pointed in the right direction to pick up sunlight, then it will convert that sunlight to electric charge.

There are two basic types of solar panels: static and deployable. The OX-STAT and OX-STAT-XL Photovoltaic Panels are fixed in place and cannot be moved or rotated. The other solar panels can rotate on one axis to point in a better direction and pick up more sunlight. One drawback of deployable panels is that they're far more fragile, and will break off if traveling very quickly through an atmosphere. They also tend to shatter if you so much as touch them. Static panels are far more durable.

Deployable panels do have some advantages, in that they can pick up more sunlight by changing their angle. A static panel pointed in a random direction will on average only pick up 1/4 as much sunlight as if it were pointed right at the sun, while a deployable one will on average pick up 1/2 as much sunlight. Or at least it would if it weren't blocked by other parts of your spaceship, which tends to happen more to deployed panels than static ones. If you're smart, you place a static solar panel in a location where it won't be blocked by the rest of your ship.

The amount of sunlight that reaches a panel also varies with your distance to the sun. Sunlight intensity is proportional to distance to the negative second power. This means that when near Moho, you tend to generate five times as much power as when near Kerbin. Near Eve is a little less than double Kerbin, while Duna is less than half. Dres gets you about a tenth of the power of Kerbin, and Jool about 4%.

How far away is far enough that solar panels don't make sense anymore is a judgment call. Even near Moho, nuclear generators always work and solar panels only when not blocked by Moho. Meanwhile, solar panels can be competitive with nuclear on an electricity per mass ratio as far out as Dres if aimed properly, and on an electricity per funds basis all the way out to Eeloo.

Nuclear generators

The game only has one nuclear generator for general use, the PB-NUK Radioisotope Thermoelectric Generator. It generates 0.75 electric charge per second at all times, and without requiring fuel. The key drawback is that they cost 23300 funds each, which is quite a lot for career mode. And if you want to generate a lot of electric charge using them, that will take a lot of generators. In some cases, a ship can cost several hundred thousand funds just for the generators alone.

Still, depending on a spacecraft's electrical needs, sometimes it is very convenient to be able to just put a single nuclear generator on the ship, have all the electricity you need, and be done with it.

Rocket alternators

Some rockets have an alternator that will generate electricity while the rocket is running. This is a very inefficient way to generate electricity, but it is a free bonus if you were going to use the rocket anyway.

Fuel cells

If you want to burn fuel to generate electricity, the way to do it is fuel cells. Fuel cells burn liquid fuel and oxidizer in the usual ratio, and will generate electricity at a rate of 80000 electric charge per ton of fuel. That can be a problem if you're relying on fuel cells to generate electricity for long periods of time when in deep space. When landed and readily able to mine for replacement fuel, the fuel consumption of the cells usually isn't a problem. As such, fuel cells are largely a way to power whatever you need when on the ground, as opposed to in orbit or in deep space. Fuel cells can also readily provide the power for short missions.

Storing electricity

You can store electric charge in batteries. Adding more batteries increases the maximum electric charge that the spacecraft can store. Command pods and probe cores generally have some modest electrical storage capability. For most missions other than putting a simple relay into its intended orbit, you'll want to add some batteries for additional electrical storage capacity.

There are in-line batteries of the tiny, small, and large radial sizes that can be placed in a spacecraft in much the same way that you'd place a fuel tank. There are also radial attached batteries that can be placed anywhere on the side of something. Both conveniently have their charge storage capacity in their name. For all batteries, the mass is proportional to the storage capacity, at 20000 charge per ton.

Radial batteries are less robust than in-line batteries, with a max temperature tolerance of only 1200 K, as compared to 2000 K for the in-line batteries. Radial batteries are often intended to be placed inside of a service bay, which will protect them during atmospheric entry.

Radial batteries can be packed very densely inside of a service bay. To place them, turn off the snap to grid option, and turn on the rotational symmetry option to place however many you want--likely eight. You can place batteries partially on top of each other, and it's pretty easy to fit three rings of Z-400 batteries on the bottom of a 2.5m service bay. You can then fit three more rings on the top if so inclined, for up to 48 batteries and a total charge of 19600 in a single 2.5m service bay. Or you can have fewer batteries and leave space for other equipment such as generators or science gear.

Aerodynamics

Aerodynamics is basically for what happens when you're in an atmosphere surrounding a planet or moon. Some planets and most moons don't have an atmosphere, which makes aerodynamics irrelevant. But the atmosphere is quite important when you're in it.

Atmospheres have several effects in the game. The cause parts to blow up if you travel to fast through them, as covered in the heat section. They slow you down when trying to take off, so that it takes more fuel to escape. They also slow you down when you approach for landing, so that the act of landing can take far less fuel than it would otherwise. And they also threaten to flip you over if you do something wrong.

Atmosphere density

The amount of drag due to air resistance for a given shape moving at a given velocity is proportional to the density of the air through which you're traveling. That drops off roughly exponentially as you get higher. Because it is zero on some planets and most moons, there is zero drag there.

You can compute drag as (some constant for the shape of the vehicle) * (density of the atmosphere) * (the square of your current speed relative to the surface). The vehicle shape constant can and probably will vary as your vehicle rotates. When relying on parachutes to land, those parachutes will typically provide nearly all of your drag, so it's basically your number of parachutes, at least if weighted properly due to some parachutes being larger than others.

It's important to understand that drag is proportional to the density of the atmosphere where you are, which is not the same thing as atmospheric pressure. For those who know calculus, if we ignore the fact that gravity varies with height, the atmospheric density is basically the first derivative of atmospheric pressure as a function of height, or possibly the negative of it, depending on how you orient your axes.

For those who don't know calculus, the force that the atmosphere exerts on a given patch of ground is the total weight of the air that is above that patch of ground. On level ground, we can compute that the force is equal to the air pressure at that altitude times the area of the patch of ground. If we make an arbitrary rectangular box with axes pointed in the appropriate directions to have top and bottom sides, the amount of air above the bottom of the box is equal to the amount of air above the top of the box plus the amount of air inside the box. You can see this by examining what happens to a particular molecule: if it is above the bottom of the box, it is either also above the top, or else below the top and hence inside the box. Thus, the difference between the force on the bottom of the box and the force on the top is the weight of the air inside the box. With a bit of arithmetic, the average density of air inside the box is ((pressure at the bottom of the box) - (pressure at the top of the box)) / (height of the box). By normalizing the box height, you can get that the atmospheric density at an altitude of between k and k+1 km on a given planet or moon is roughly proportional to (pressure at altitude k) - (pressure at altitude k+1).

Drag is proportional to speed squared, so when traveling at high speeds, you'll have a lot of drag even in a relatively thin atmosphere. Even so, if you're pointed in a direction where your ship is too good aerodynamically, it is possible to crash all the way into the surface while still going too fast for parachutes to deploy. Approaching a planet at a wide angle so that you have to pass through a lot more atmosphere before you touch down can often fix that problem. For example, when coming to land on Kerbin, you might pick an orbit with a periapsis of about 30 km, then let air resistance slow you down enough to land safely.

Of the objects that have an atmosphere, Duna has the thinnest. At sea level, it is 1/15 of the pressure of that of Kerbin, and about 1/20 of the density. That's not quite thin enough to ignore it, but it won't give you that much trouble unless you have egregiously awful aerodynamics. Laythe's atmosphere has 3/5 of the pressure of Kerbin's at sea level, and about 1/3 of the density. Eve's atmosphere is five times the pressure of Kerbin's at sea level, and about three times the density. Jool's atmosphere at sea level has 50 times the pressure of Kerbin's, though once you get deep enough into Jool's lower atmosphere that rockets don't work at all, is scarcely matters exactly how thick it is.

In real life, provided that an atmosphere isn't so dense that there isn't very much space to pack in more air, each gas component of the atmosphere has its concentration drop off exponentially with height. For example, every 5 km of altitude could drop the concentration by half. But how fast it drops off with altitude depends on the temperature, the force of gravity, and the molecular weight of the particular gas. The temperature and force of gravity at a given altitude are the same for all gases, but the molecular weight is not. Heavier molecules drop off faster with altitude. For example, the concentration of carbon dioxide will decrease with altitude faster than that of water vapor, which in turn, drops off faster than helium. This is why the Earth's upper atmosphere consists almost entirely of hydrogen and helium, even though for the entire atmosphere, they are present in far smaller amounts than nitrogen, oxygen, or argon.

The game does not explicitly model having different gases in an atmosphere like this, as demonstrated by there being portions of the atmosphere of Laythe and Eve where density goes up as altitude does. For game purposes, you can just think of the density of an atmosphere as something that drops off pretty quickly with altitude.

Cross-section area

Most of the time, you'll want to reduce the effects of the atmosphere. Drag basically acts on the cross-sectional area that gets hit as you travel. If you view your rocket from far away with the camera oriented such that the rocket is traveling directly at you, what you can see is roughly the part that the atmosphere acts on. Making your rocket wider will cause more drag, but making it longer will not. Thus, to reduce drag, it is ideal for a rocket to be very long and narrow. That is, of course, the opposite of what you want it to be in order to land.

It's also important that your rocket be symmetric. If it is pressing a part of the rocket on one side to slow you down, you want it to also have an equal force on the opposite side. Otherwise, drag could provide a potentially strong net torque and flip you around in a direction that you don't want.

Aiming rockets

A rocket that is built to be rotationally symmetric only has drag provide no net torque if it is rotationally symmetric around the direction that the rocket is traveling. If it is going sideways, the portion that the atmosphere acts on is not symmetric at all, so it can provide a strong net torque, and that could flip you in a direction that you do not want.

If your rocket is rotationally symmetric and pointed directly prograde relative to the surface (since the atmosphere gets dragged along with a planet's surface), then there will be no net torque, and you don't flip over. Directly retrograde also works for the same reason. Usually you want to be prograde when taking off and retrograde when landing. Importantly, these are relative to the surface, not orbit.

Usually at launch, you want to point straight up initially. If your rocket landed on some planet and is taking off from wherever it landed, then you probably won't be directly vertical at launch, but you want to get pointed that way quickly. You have a little bit of time, as you'll initially be moving slowly enough for there to be minimal drag.

You may wish to tilt a little to one side to start your gravity turn early on. But you're going to have to point directly prograde for a while, which will allow gravity to move your prograde direction more and more horizontal as you go. If you tilt too far to the side, too soon, you don't get out of the atmosphere.

Once you pick up some speed in the lower atmosphere, you need to stay exactly prograde, or at least very close to it. Otherwise, you'll flip over. Perhaps not on Duna, but certainly on any of the other places with an atmosphere. Once you get to a high enough altitude for the air to be very thin, you can then change your direction to adjust your gravity turn without further fear of flipping over.

Nose cones

Some shapes naturally allow air to flow by them much more easily than others. Most of the functional parts in the game such as fuel tanks and rover wheels really aren't very aerodynamic. The game offers aerodynamic nose cones that are designed specifically to reduce drag. The idea is that you put them on the top of your rocket so that most of the portion of the rocket that is cutting through the air is nose cones that are designed to have minimal drag. This can greatly reduce your drag at takeoff, and thus allow you to reach orbit with less fuel.

Nose cones don't do much to prevent you from flipping over, though. If you're turned to the side, the atmosphere is acting strongly on other portions of the rocket besides the nose cones, and that's what flips you over.

Service bays

One way to prevent awkwardly shaped parts from causing a lot of drag is to hide them so that they don't hit the air at all. Service bays allow you to do this with small equipment such as batteries or science gear. They don't just protect the gear from blowing up, but also prevent it from causing undesirable drag.

Fairing

Sometimes, you need to put something that is awkwardly shaped on the top of a rocket, and it just can't be covered with nose cones. Trying to carry a rover to some distant planet is a common situation. Needing to put a large relay on your satellite is another. You can build fairing to go around whatever your awkwardly shaped object is, and reduce drag in a manner similar to nose cones.

The idea of fairing is that there are several fairings of different radial sizes, and you can place one in-line in your rocket, like a fuel tank. You can then build the fairing by having several slices at chosen radii and lengths to cover whatever comes above it. That will give you a more aerodynamic shape when taking off from Kerbin. Once you leave Kerbin's atmosphere, you can discard the fairing.

Be warned that the act of removing fairing is explosive, and discarded portions of fairing can hit other parts of your rocket and destroy them. It's really only safe to have one fairing on a rocket, and only at the very top of the rocket, above all other portions.

Science

One of the major activities in the game is acquiring science information. In both science and career modes, this is how you unlock most of the equipment in the game. Even after you've unlocked everything, getting the rest of the science available is kind of the point of the game. That said, the game is open-ended enough that if you want to make something else besides science into the point of the game, you're welcome to do so.

Each combination of a situation, a biome, and an activity can yield separate science data. Well, sometimes. Your situation depends largely on your altitude, and includes things like being landed on the ground or flying low in space. Your biome is which portion of the planet you're over, as being over an ocean will probably be a different biome than being above a mountain. The activity is the type of science measurement, such as measuring air pressure or temperature. All of these deserve further explanation.

Situations

There are four basic situations: landed, splashed, flying, or in space. Flying and in space each break up into two different situations on the basis of your altitude. Depending on your altitude, flying could count as flying low or flying high, which are two separate situations. Similarly, in space low and in space high are separate situations. As such, there are six possible situations. The boundaries between flying low or high and between in space low or high seem to be set at some arbitrary threshold for each body, and are not a simple function of the moon's size, for example, though larger ones tend to have higher thresholds.

If any portion of your ship is touching solid ground, then you're landed. If you're touching water but not solid ground, then you're splashed. In particular, being in water but having some portion of your ship touching solid ground counts as landed, not splashed. I once had a situation where my craft was splashed, but if I opened a service bay, the bay door touched the bottom of the lake I was in, which made the ship count as landed instead. The game won't directly tell you whether you're landed or splashed, but you can query it by attempting an activity that cannot be done while splashed and seeing if the game will allow it. Splashed is only possible on bodies with oceans, which is to say, Kerbin, Eve, or Laythe. You cannot have the landed situation on Jool, as it has no solid ground to touch.

Flying means inside of an atmosphere, but not landed or splashed. Flying is thus only possible where there is an atmosphere, which means Kerbin, Eve, Laythe, Duna, or Jool. The sun also had an atmosphere in early versions of the game, and might still have one, but you can't fly there, as you'll burn up long before you get there.

In space means not landed, splashed, or flying. For planets or moons with an atmosphere, you must pass through flying low and flying high to get from landed or splashed to in space or vice versa. On planets or moons without an atmosphere, you go directly from landed to in space low.

Biomes

A biome is a geographic region. Some biomes are strongly correlated with things that are readily visible from space, such as a large crater, but many are not. Even when the biome is mostly visible from space, the edges aren't quite what they look like. Being in a particular biome when flying or in space basically means that that biome is the one you're above. More precisely, if you were to draw a straight line from your current location to the center of the planet, it's the biome where that line would pass through the surface.

Some combinations of a situation and an activity give science data that varies by biome, while some will only give one result for an entire moon. For example, a temperature scan when flying low will give different results for each biome, but when in space low, will only give one result globally. Thus, you could get separate science data for each of 11 separate temperature scans when flying low on Kerbin, one for each biome. But you can only do one temperature scan when in space near Kerbin, as trying to repeat it when above another biome will give the same results and not separate science data.

You can identify the biome that you're currently in by running an activity whose results depend on the biome. That doesn't help very much if you're trying to find a particular biome that you're not currently in. Rather, you can find biomes by using KerbNet. Relatively advanced drone cores have a biome scanning mode, as does the mobile processing lab. This will show you a map of the biomes near you. Your current location is at the center of the map, and the other biomes are color-coded. You can click on a location to see the biome at that location. Up on the map is the direction that you're currently traveling relative to orbit. When landed, it will generally be east, as not moving relative to the surface is moving east relative to orbit.

Acquiring data

There are several different ways to gather science data. If you want to get all of the science data from a planet, you'll have to hit every possible combination of a situation and a biome. That means landing in every biome, and also splashing down in every biome where that is possible. You generally want to land once, do all of the experiments that can be done at once, and then leave. I recommend getting the flying low data shortly before landing, as you'll naturally hit all of the biomes that you're about to land it. For moons without an atmosphere, you may also get the in space low data that way shortly before landing.

For planets with no atmosphere, the most efficient way to get the data from all biomes while high in space is to get into a polar orbit just above the threshold to count as high in space rather than low. Stop thrusting, but just pick up data from each biome as you cross it. As the planet rotates, things that were not under your orbit initially will eventually come under it, and then you can pick them up without further thrusting.

For planets that do have an atmosphere, you can repeat this process three times to pick up high in space, low in space, and flying high separately. You can see what is coming on future orbits and time warp when you can see that you won't pick up any new biome for quite a while. For flying high, you have to be in an atmosphere, so you cannot have a stable orbit. The key here is to just barely be in the atmosphere, with both your periapsis and apoapsis just below the edge of the atmosphere. Your orbit will slowly decay, and you may have to thrust a little occasionally to prevent it from decaying very far, but this will make thermal heating inconsequential, as well as making it safe for a kerbal to go on EVA. You can use 4x physics warp pretty safely in this situation to prevent it from taking a ridiculously long time, and may wish to just barely leave the atmosphere for some long time warps.

Sensors

There are nine different pieces of equipment to gather science data for you by doing discrete experiments. All of the sensors produce data that can be transmitted back to Kerbin, but with imperfect transmission efficiency. In order to get the full science data, you have to bring the data physically back to Kerbin, not just transmit it. Furthermore, for some of the experiments, even bringing the data back and landing on Kerbin doesn't get you the full value, and repeating this subsequent times will add some additional science.

Most science sensors are relatively fragile equipment. They won't break if you touch them, but most of them will explode at 1200 K. As such, it is often advisable to place them inside of a service bay for protection, though you cannot do that with the SENTINEL Infrared Telescope or the Magnetometer Boom. The SC-9001 Science Jr. also has a crash tolerance of only 6 m/s, making it one of the most fragile items in the game. It can readily be placed at the center of a Service Bay (2.5m).

The Mystery Goo™ Containment Unit and science jr. can be used in any situation. They provide separate data by biome when splashed or landed, but do not depend on the biome in other situations. These two experiments also have the issue that once their data is removed once (whether by transmission or transferring the data to be stored elsewhere), the equipment is left in an unusable state. It can be restored to be able to run another experiment by a scientist or by a mobile processing lab. If you are going to rely on a scientist to restore the equipment, then it is highly recommended that you place it very near the door of the command pod, with perhaps a ladder for access. Relying on the scientist to use a jetpack to fly around every time you want to restore the equipment is a major pain. Another approach is to bring multiple units that can run experiments in different locations without needing to restore any particular unit.

The 2HOT Thermometer and PresMat Barometer can also be used in any situation. In particular, you can check atmospheric pressure even while in a vacuum. Both have data that varies by biome while landed or splashed. Temperature data varies by biome while flying low, but pressure does not. When flying high or in space, data does not vary by biome.

The GRAVMAX Negative Gravioli Detector can be used while landed, splashed or in space, but not while flying. Its results always vary by biome. A gravity scan is the only thing that varies by biome while high in space, so it is the one that forces you to hit every biome while high in space if you want to get all of the science data.

A Double-C Seismic Accelerometer can only be used while landed, and its results vary by biome. As such, there is no need to bring the seismic accelerometer for satellites that will never land.

The Atmospheric Fluid Spectro-Variometer can only be used while in an atmosphere. It can be used while landed, flying low, or flying high, but not while splashed or in space. It also cannot be done at all on planets that have no atmosphere, even while landed. As such, there is no need to bring it on missions that will only visit a planet or moon with no atmosphere. Its results always vary by biome, and it is the only thing that varies by biome while flying high.

The telescope and magnetometer can only be used while in space, and not while landed or in an atmosphere. Their results never vary by biome. The telescope can only be used while high in space, though the magnetometer can be used whether high or low in space. As such, the telescope and magnetometer can only return one or two experiment results per planet or moon. While the other science sensors can be radially attached just about anywhere, these need a mounting node to attach to.

Manned reports

There are five types of reports that can be made by a kerbal, without requiring any special scientific equipment. A kerbal can do a crew report from inside of a command pod. This is done by interacting with the command pod itself. A kerbal can also do an EVA report while outside. The crew report and EVA report can be done in any situation. Both vary by biome while landed, splashed, or flying low. The EVA report also varies by biome while in space low. Otherwise, they do not vary by biome.

A kerbal can also collect a surface sample if landed or splashed, but not while flying or in space. The kerbal does not actually have to be on the surface to collect a surface sample. Rather, you can land your ship, go on EVA, collect a surface sample while holding on to the door, and then go back inside. A surface sample always varies by biome.

The final two types of manned reports are the asteroid sample and the comet sample. This requires being near an asteroid or comet, but can otherwise be done in any situation. Asteroid sample data varies by biome if splashed, landed, or flying low, but not otherwise. Asteroid sample data also varies by asteroid, so you can get separate data from testing different asteroids in the same biome and situation. This makes it possible to get effectively infinite science by repeating everything on different asteroids. Actually doing this is quite repetitive and boring, however, so I actually recommend ignoring asteroids entirely.

Rover scanner arms

Every planet and moon that you can land on has some surface features. It varies from one to four types by planet. In order to find them, it is very helpful to turn off surface scatters in the game's graphical options. Once the surface scatters are gone, odd looking things laying around will tend to be be valid surface features.

Some surface features are small enough that a kerbal can pick them up and return them to the vehicle. Otherwise, you'll need a scanner arm to pick them up. There are three different scanner arms in the game, but the smaller arms can only get some of the science, while the OP-E Large Scanning Arm can get all of the science for a feature in a single scan. As such, the smaller arms are pretty useless. The small features that can be picked up by a kerbal will give you the same data if you either have the kerbal pick it up or scan it with a large scanner arm, so it is unnecessary to do both. On Ike and Pol, there is only one type of surface feature, and it can be picked up by a kerbal, making a scanner arm unnecessary for a manned expedition.

In order to use a scanner arm, you must be very close to the surface feature, with the base of the scanner arm within a few meters of the feature. It is difficult to land this close, other than perhaps on Gilly, so it is much easier to use a rover on wheels. The idea is that the rover can land kind of close to a feature, then drive to park right next to the object and scan it.

Surface feature data can be transmitted with 100% efficiency. As such, there is no need to bring it back to Kerbin. Depending on your goals, it may be sensible to drop an unmanned rover to scan surface features and transmit the data without the rover needing a way to leave the surface.

Deployed science

The final category of science equipment is deployed science. The idea is that rather than doing an experiment once, you set up equipment to run the experiment continuously over the course of months. The equipment should be placed on the ground, but can do separate science experiments for different bodies. There are several different pieces of equipment, and you generally want to set them all up together. A full deployment generally involves laying out seven pieces of equipment.

You always need a Probodobodyne Experiment Control Station near the rest of the equipment. That controls and monitors everything else. It also counts as a separate vehicle in flight that you can switch to, even while no other ship is remotely nearby.

The Go-ob ED Monitor, Ionographer PD-22, and PD-3 Weather Analyzer do the main experiments. You always want the Go-ob ED Monitor. The Weather Analyzer only works while in an atmosphere, while the Ionographer only works if not in an atmosphere, so you bring one or the other, depending on where you're going. These pieces of equipment basically just have you set them up once and then ignore them. They will generate science data faster if placed by a high level scientist.

The Grand Slam Passive Seismometer will monitor earthquakes caused by crashing vehicles into a moon. The amount of science generated is proportional to the kinetic energy when the object hits the surface, so it scales with mass times the square of your speed, at least up to the maximum amount of science that can be cumulatively gathered from it on a moon. The amount of science generated is also decreased by the distance from crash to the seismometer. It generally takes much larger crashes to get the maximum science on larger planets and moons.

The Communotron Ground HG-48 will transmit data back that the other experiments generate. It isn't strong enough to get a good connection from the outer planets all the way back to Kerbin, but it can use CommNet and go through relays. It is strong enough that for a first link, it should be able to get a good connection to any relay that it finds orbiting the same planet--or a different moon of the same planet.

Finally, you need power generators to run the rest of the equipment. There are two options here: the OX-Stat-PD Photovoltaic Panel or the Mini-NUK-PD Radioisotope Thermoelectric Generator. The only advantages to the former are that it is cheaper and available earlier in the tech tree. The advantages to the latter are that it works both day and night, and also still works on the more distant planets. Unless you want to do deployed science on or near Kerbin and don't yet have access to the nuclear generator, there is no good reason to use the former.

The amount of power generated depends on the level of the engineer that deploys it. For a level 2 or higher engineer, you will need two generators to power a full installation. For a level 0 or 1 engineer, it will take three generators. If placed by a scientist or pilot, it will take five generators. So basically, you want to bring an engineer with some experience.

Generating data for the seismometer is much easier if there is no atmosphere, as you can crash things into the surface at very high velocity. You can send an unmanned probe to the planet aimed to crash straight into it and not try to slow down to circularize an orbit, but just crash at several kilometers per second. Alternatively, you can sometimes have some vehicle that you want to keep shed a stage while aimed directly at the moon, then have the next stage slow down and circularize the orbit while the debris crashes at high velocity. In an atmosphere, it is much harder, as coming in at several kilometers per second will mean you burn up and don't cause any crash at all, and even coming in at lower speeds has you slowed down much further by air resistance.

Storing data

Any equipment that can run science experiments can store one experiment result, and only one. For example, a PresMat Barometer can store the results of exactly one atmospheric pressure scan. If you want to do another in a different situation or biome, you have to remove the first.

If you wish to rerun experiments in many different situations or biomes on a single mission, it helps to have another place to store the data. That is what the Experiment Storage Unit is for. It can store unlimited data, though it cannot have two copies of exactly the same data. For example, it cannot store two atmospheric pressure scans while landed at Mun's midlands. But it could have multiple atmospheric pressure scans in different situations or biomes, as well as all of the other types of experiments.

The Experiment Storage Unit is basically the indestructible black box for data that you've heard that airplanes use. While not truly indestructible, it is rated for a maximum temperature of 2900 K, which is higher than anything else in the game besides heat shields. It is also rated at an impact tolerance of 15 m/s, which is higher than most other equipment.

Probe cores with SAS level 3 also have the same data storage functionality as the experiment storage unit. That may make the latter superfluous, or you may still want some extra experiment storage to store several copies of the same data. You generally don't want to load up on extra probe cores as a way to store data, however, as they have more mass than the experiment storage unit, and are also more fragile.

Consuming data

For data other than generated by the deployed science, there are three basic things that you can do with it. One is to transmit the data, which uses it up, but gets you some science. Crew reports, EVA reports, and surface features can get you the full science value when transmitted, but everything else cannot. You can also run an experiment, transmit the results, and then rerun the experiment so that you have the data again and can return it to Kerbin.

The second thing to do with data is to physically return it all the way to Kerbin. You don't necessarily have to return all of the science equipment, but just the data. A small rocket intended to return an experiment storage unit loaded with data works for this.

The third thing that you can do with data is to process it in a Mobile Processing Lab MPL-LG-2. This allows you to convert data to science, then transmit the science. The science is then transmitted with perfect efficiency. A given experiment can both be converted to science in a lab and also returned to Kerbin, and you get the full science for both. It takes the mobile processing lab a long time to convert data to science, and you'll have to come back every seventy days or so to transmit the science and add more data.

Structural components

A lot of the components that you'll use have some dedicated function. You have fuel tanks, rocket engines, command pods, batteries, and so forth. If you try to build a rocket entirely out of such functional components, sometimes it just won't work. It will fall apart, or not have the shape you want. That is why there are structural components to hold your rocket together. They are commonly lighter and/or more durable than than functional components of similar sizes, but without having any function besides holding the ship together.

EAS-4 Strut Connector

The most important structural component is the EAS-4 Strut Connector, or more colloquially, struts. Large rockets inevitably need a lot of struts. If your rocket falls apart in space, it probably means that you should have added more struts.

One critical thing to understand about the game's physics model is that, apart from struts, anytime you add a new component, it is only attached to the rest of the rocket in exactly one place. If two things are laid against each other such that it looks like they have a long common surface, they are connected only by a single point and the rest of the common surface can flap freely. If you lay out four things in a square such that it looks like each of them is touching two others, the last one placed will only be connected to one of the two others, and one of the apparent connections won't actually physically hold in place.

Struts are the exception to this. You lay out your rocket however you want to, and then add a strut to force the components at its two ends to remain a fixed distance apart. Struts do add mass and drag, but they also make it possible to build rockets that are much larger and much sturdier than can be done without them.

It is also legal to strut together components that will be part of different stages. When you decouple the stages, the strut will automatically release. The mass of the strut will remain with the piece on which you placed the first end when laying out your struts. Thus, you want the first end of the strut to be the part that is discarded earlier.

Couplers and adapters

Sometimes you want to have different stages use different sizes of rockets, or otherwise connect two things of different radial sizes. Some fuel tanks are shaped appropriately for this, but sometimes, that just isn't what you want. You can just directly attach things of different sizes, but that can look ugly as well as being poor aerodynamically.

As such, the game has a variety of couplers and adapters to allow properly connecting things of different sizes. For example, if you want a small radial size on one end and a large radial size on the other, the Rockomax Brand Adapter will get the job done. Couplers can do this in a many to one manner. For example, a TVR-2160C Mk2 Stack Quad-Coupler can attach one small size object on one side and four on the other.

There are also two cubical nodes with a separate attachment point on each side. The Rockomax HubMax Multi-Point Connector does this for a small radial size (not the large that most Rockomax gear uses!), while The Not-Rockomax Micronode does this for a tiny radial size. I commonly find the former useful for attaching a bunch of relays to a large satellite that is intended to transmit data from the orbit of one planet to another.

Finally, there is the BZ-52 Radial Attachment Point. This basically allows you to create a proper node wherever you want. One end is radially attached, so it can be placed just about anywhere, and then you can attach whatever you want that cannot otherwise be attached radially.

Girders, I-beams, structural panels, and tubes

Sometimes the basic problem with your rocket layout is that you want this item here and that item there to be far apart, with nothing in between. That's what girders and I-beams are for. They are quite sturdy with relatively little mass and drag. There is no fuel crossfeed across an I-beam, but there is across a girder.

The game also has a variety of structural panels and tubes. Often, these are targeted more at airplane wings. But if you want a sheet of metal of a particular size in a particular place, you may be able to find it. Or you may have to attach several to each other to make what you want. I personally don't find them very useful.

Robotics

Most types of parts in the game have some canonical use. Rocket engines provide thrust, batteries store electric charge, science equipment runs experiments, and so forth. Robotics parts really don't have a canonical use. There are a lot of things that they can be used for, none of which you really need to do in order to play the game. But they do have a lot of creative uses.

My personal favorite use is for docking on the ground. Have a base with mining equipment on the ground, and a lander that explores the planet. Park the lander near the base, then use robotics to have the base move a docking port around to connect to the lander. That makes it possible to dock them together to transfer fuel without needing to make precise movements with either the entire base or the entire lander. And that makes it possible for the lander to refuel without needing to carry around mining equipment.

But more generally, you can use robotics for anything that needs to make small, precise movements that don't require that much force. The rotors and blades can also be used as an alternate propulsion system that doesn't burn rockets.

Hydraulic cylinders

The idea of a hydraulic cylinder is that it can extend and contract in one direction. Thus, the distance between two fixed parts can become shorter or longer when you need it to be. The telescoping cylinders can extend further than non-telescoping cylinders, but this comes at the expense of additional cost and mass.

Cylinders can provide only a limited amount of force, so you can't expect a single cylinder to lift your thousand ton rocket. But they can reposition smaller craft just fine, or even provide a way to jump without thrusting.

Hinges and servos

Hinges and servos provide a way to rotate. Hinges can rotate up to 180 degrees around a particular axis, while servos can go up to 360 degrees. They do not provide a way to rotate perpetually like a fan, but only to move from one angle to another. You could think of a these as adjusting an angle of the location of the end object for one of the angular coordinates in a cylindrical or spherical coordinate system.

Rotors and blades

Rotors exist to spin in one direction and keep spinning. This is very different from servos that might go 30 degrees in one direction, then decide to come back by 10 degrees. Rotors can't make such precise movements, but they can say, I'm going to rotate at three revolutions per second and keep doing that perpetually.

Rotors generally exist to make fan blades spin, and thus push against the air to provide some thrust. The blades can be helicopter blades or propeller blades. They can also be the newer fan blades which don't need as much space. It is also possible but not recommended to use arbitrary structural components as the blades.

Because rotors spin pretty hard in one direction, they provide a considerable torque. If not accounted for, this can make your entire vehicle spin out of control. One common way to handle this is to have paired rotors that spin in opposite directions.

If mounted vertically, rotors can lift your entire vehicle upward, as a helicopter. In the opposite direction, they can push you down toward the ground. Usually, this would be a design failure, but it could also submerge you if you want to land on the bottom of the ocean.

Rotors can also be mounted horizontally, as propellers to make a propeller plane. This will mean you have to struggle with all of the finicky aerodynamics of a jet plane, so I don't recommend it, but you could.

Rotors can also be mounted horizontally to provide some forward thrust to a vehicle that isn't meant to leave the ground. Staying on the ground will mean that the ground provides considerable torque to offset the rotors' attempt at flipping you over, at least if they don't provide all that much net torque. This can be useful to allow a rover to ascend steeper hills on Kerbin, Laythe, and Eve. It can also be useful to allow a boat to travel across the water. For such uses, you don't have to have the center of thrust exactly right, but it should be close to the center of mass in order to avoid flipping over.

Rovers

When landing from space, it isn't that hard to land within about 1 km of where you want to land, at least in a vacuum. But sometimes, you need to reach a much more precise location than that. To scan a surface feature, for example, the base of the arm must be within 4 m of the feature for the largest arm, or closer yet for smaller arms. It's not that hard to land with that sort of precision on Gilly, but good luck doing so on Tylo or Laythe. If you want to dock with a base, landing 1 km away, or even 100 m away, doesn't get it done.

Rather, when you need to reach a precise location, it's much easier to only need to land within 1 km or so, then drive the rest of the way to your location. That commonly makes it not particularly difficult to get to within a few meters of where you wanted to go. Extending a rover arm or robotics can then cover the rest of the gap. I refer to any vehicle that can drive around like that as a rover, and that's what this section is about.

While there are four types of rover wheels in the game, that doesn't mean they're all useful. The TR-2L Ruggedized Vehicular Wheel is the one you want for just about any purpose. Do yourself a favor and ignore the others.

Ascending slopes

As with vehicles based on lander legs, if you try to build a tall, narrow rover and then land it on a steep slope, you'll fall over. Rover wheels don't stick out as far as lander legs, so a rover is more prone to this than other vehicles. But that's easily fixed by making your rover short and wide.

The situation with rovers is considerably worse, however. If you land on a slope on lander legs, then unless the slope is steep enough to make you slide, you probably just sit there. If you land on wheels, you could easily start rolling down the slope. Brakes can supply some force to slow you down, and trying to roll in the opposite direction can provide more. But if you can't provide enough force to counteract gravity pulling you down the slope, you start rolling, and often gain speed as you go. Depending on the weight (not mass; the strength of gravity matters) of your vehicle and how many wheels you have, it could be easy to stick on a 40 degree slope, or you might be unable to stop yourself from rolling down a ten degree slope.

One way to stop yourself on a slope is to turn sideways. Wheels can only go forward or backward and not skid sideways, or at least not without a tremendous amount of force. You might be unable to stop yourself from going forward or backward due to a slope if you're pointed straight down it, but if you're pointed orthogonal to the slope so that forward or backward doesn't change your elevation, you can probably stop.

Often, however, you don't merely want to stay put. You could stay put on lander legs. You want to go somewhere, and sometimes, that somewhere is up a hill from where you are. The ratio of the weight of your vehicle to the amount of force that your wheels can provide (which is proportional to the number of wheels) determines the steepest slope for which your wheels can provide enough force to ascend. That commonly pushes rover designs toward having a lot of wheels but not very much mass, so that it is possible to roll uphill when you need to.

Or at least that's the case if all of your wheels are touching the ground. Wheels that are hovering in the air don't provide you with any thrust. It is very important when designing a rover to make sure that all of the wheels are at exactly the same height. Symmetry tools can sometimes help with this somewhat, but ultimately, you're going to have to eyeball it and get the wheels as precisely the same height as you can.

The steepest slope that a given rover can ascend on a given planet or moon is determined by the design of the rover, and can't be changed once you've landed, at least unless you have a way to drop additional weight. If you discover that you need to ascend a steeper slope than your rover can handle, you can often make it work by approaching the slope at an angle. For example, suppose that you want to ascend a 30 degree slope, but your rover doesn't provide enough force to handle more than 20 degrees. Instead of going straight up the slope, you could approach at a 60 degree angle away from the direction you actually want to go. That will reduce the slope to a 15 degree slope upward, with the slope mostly trying to tilt you sideways instead. Go off to one side for a while, then turn to to at a 60 degree angle away from the direction you wanted to go on the other side. That's kind of a pain, but it does work.

Managing electricity

Rover wheels use several electric charge per second per wheel. If you need to drive very far, that can easily run you out of electricity very quickly. That means that you'll need a considerable source of electricity generation. I find nuclear power preferable to solar panels, as solar panels only work during the day. When you're landed, the sun is going to be blocked half of the time, unlike how you can mostly see it while in space. You can frequently park and wait to recharge. I find it more convenient to have several PB-NUK Radioisotope Thermoelectric Generators and a large battery so that you don't have to stop and wait to recharge as often.

If you are going to have to stop and wait to recharge, then make sure you get to a stable place to stop, where the brakes alone can prevent you from moving. That can sometimes mean turning sideways on a hill so that gravity can't pull you down the hill.

Flipping over

It's very easy to make a rover flip over, then have parts break off when they hit the ground. Even if parts don't break, if your wheels are up in the air, you're not going to keep moving. You don't just have to be able to land on wheels without immediately tipping over. You'll likely end up driving to a steeper slope than the first place you land. Furthermore, the act of accelerating can also cause you to tip over even when you would have been stable if you stayed where you were.

The classic example of how this happens comes from people riding a bicycle. If you're going too fast and slam on the brakes, the force applied by the brakes can't be pointed directly at your center of mass. Rather, it's along the ground, where the wheels actually touch the ground. That's far below your center of mass, so it provides a considerable torque to try to flip you over the point where the front wheel touches the ground. Gravity provides a torque in the opposite direction, but if you're going fast enough and hit the brakes hard enough, the torque of braking can be larger than that of gravity, in which case, you go flying over the front of the bike and take quite a spill.

The classic fix for this is to have no brakes on the front wheel. Instead, only the rear wheel has brakes. If the braking torque starts to flip you over, then the rear wheel comes off the ground and applies no more braking force. That prevents the bicycle from flipping over. It also prevents the bike from stopping, so you could easily crash into whatever you were trying to avoid by hitting the brakes in the first place. And it doesn't necessarily work on a rover that, unlike a bicycle, sometimes needs to go backwards.

About the same effect can easily cause rovers to flip over. The reduced braking fix doesn't entirely work, though, as sometimes you hit the brakes because you really need to stop. Sometimes the implicit braking is caused by turning sideways so that the wheels can't continue rolling in the direction you're traveling, which is why turning at high speeds can often cause a rover to flip over.

Rover wheels have advanced tweakables to reduce your acceleration and help avoid flipping over. The effect of the brakes slider is pretty obvious. The traction control slider allows you to reduce the acceleration from your motor in low gravity. A higher numerical setting means weaker motors.

What is really going on here is that there are two main forces on you. Gravity pulls you down toward the center of the body you're driving on. Accelerating in one direction is equivalent to an additional gravitational force in the opposite direction. If you add the implicit force of gravity from your acceleration to the actual force of gravity, you get the direction of the net pull that may try to flip you over.

The next key is to determine the convex hull of where your wheels touch the ground. The convex hull of a set of points is the smallest convex set containing all of the points. That might seem abstract, but it's a very simple concept that you'll immediately understand if you see a picture, so look it up if you need to. If you start at the center of mass of your vehicle and go in the net direction that braking, driving, and gravity are pulling you, the key question is whether that line will go through the convex hull of where your wheels touch the ground. If it does, then you're stable. If not, then you have a net torque that will flip you over the edge of the convex hull nearest to that line.

There is also a third implicit force on you: the centripetal force of being on a rotating body. Centripetal forces are fake forces, but it's easier to think of it as a fixed force than to do all of the adjustments for proper orbital mechanics. This centripetal force is very weak, however, at about 1.3% of gravity at the equator of Eeloo or Gilly and much weaker yet everywhere else that you can land. I'll come back to this in a later section.

There are several points to be made here, to help you avoid flipping over. First is that gravity alone always makes you stable or else you wouldn't have been able to hold still. For that matter, gravity pulling you down a hill can easily make you stable even if you'd fall over by stopping, as accelerate going down the hill. It's trying to slow down that threatens to flip you over. Even so, the stronger gravity is, the higher the acceleration you can handle without flipping over. If you double the force of gravity, you can double your acceleration while keeping the net direction of the pull constant. Thus, flipping over is a far larger risk in light gravity environments such as Minmus, Bop, Pol, and especially Gilly.

Second is the fairly obvious point that steeper slopes tend to make you more likely to flip over. Slopes rotate the points where your wheels touch the ground, moving the force of gravity closer to the edge that you risk flipping over. You're also likely to be inclined to try to stop rolling downhill, thus accelerating in the opposite direction, which also helps you to flip over. Furthermore, slopes increase the vertical distance between your center of mass and the lowest wheels, which also makes you more likely to flip.

A third critical point is that it helps tremendously for a rover to have a low center of mass and a large convex hull of the wheel base. If your center of mass is only 1 m off the ground, but 5 m away from all of your wheels, then it's pretty easy to remain stable while maneuvering on a 30 degree slope. If your center of mass is 5 m off the ground, and your wheels are all within 1 m of each other, it's not going to take much to send you tumbling. As with landers, the ideal rover is shaped roughly like a pancake with wheels attached.

Finally, even if you would flip over if a net torque stayed constant, it takes some time to flip over. Sometimes you can see that you're starting to flip and let go of the brakes to avert it. Small rovers flip much faster than large ones. Recall that if you scale a vehicle in all dimensions by a factor of n, the moment of inertia scales by a factor of n^5. Simply making a rover larger in all dimensions while keeping the same basic shape gives you more time to adjust if it starts to flip.

It's also important to consider the effects of reaction wheels. By default, the controls to rotate are the same as the controls to drive. That can mean that when you try to drive forward, your reaction wheels also start spinning, and reaction wheels alone can try to flip you over. This can mostly be avoided by setting your reaction wheels to SAS only. You may also want to turn SAS off entirely to avoid wasting electricity. This can also be fixed by changing the controls such that rotating reaction wheels uses different keys from driving a rover.

Rover size classes

As I see it, there are four basic size classes of rovers.

Small

When first building a rover, some people see that the Probodobodyne RoveMate is intended as the body of a rover and try to use it as the base. Attach some wheels, some electrical equipment, and whatever else you want, and away you go. That gives you a small rover that is easy to transport. You can cover it with fairings or whatever you need, and don't need a ton of struts.

The problem is that while it's easy to transfer a small rover to its destination, it's hard to do much with it. A small rover with a narrow wheel base is easy to flip over. It can be made to work, but it's more work than it is worth, which is why I recommend against small rovers.

Medium

The next step up is the medium rover, which has plenty of electrical equipment, several wheels, a wide wheel base, and likely a command pod. It may also have scientific equipment, beyond the standard rover arm. A medium rover is likely to have I-beams or girders to push the wheels further apart. It may also be large enough to need struts to hold together. To me, the defining step that makes a rover count as medium rather than small is that it's large enough that you can't try to hide it inside of a fairing. What the medium rover does not have, however, is rockets.

A medium rover is generally the best class for the large planets and moons: Kerbin, Laythe, Tylo, and Eve. The medium rover will need to be delivered somehow, but you likely have some rockets attached to deliver them, then stage to drop the rockets after you land. In an atmosphere, you'd also discard any parachutes that were used to help you land.

The idea of a medium rover is that it is large enough that it is easy to have a wide wheel base, a low center of mass, and plenty of wheels. Many wheels with light weight allows you to ascend slopes as necessary in heavier gravity. It's not particularly hard to build something that is basically unflippable at moderate gravity such as on Moho or Vall, and easy to avoid flipping even on the lighter moons such as Minmus and Pol.

A medium rover specifically avoids adding rocket engines and fuel for them so that it doesn't have to carry all that extra weight around. That makes it easier to keep a low center of mass and a high wheel force to weight ratio. The downside of this is that if you need to travel very far, it's going to take a very long time.

Lander on wheels

The next step up from a medium rover is to add rocket engines and fuel. At this point, you still don't want to add too much. In order to keep your center of mass low, it helps to use very short engines such as a terrier or spark. Radially attached engines such as a cub or twitch can also allow you to have your fuel tanks very near to the ground.

This class of rover is often constructed similarly to how you would build a lander, except that you use wheels instead of lander legs. For that matter, you might use the rover as a lander and have it jump from one biome to another picking up scientific data. The advantage to using wheels is that when you need to roll around to reach a particular spot, you can. A standard lander on legs can't do that. This can allow you to pick up surface features, or to dock with a base on the ground.

The lander on wheels is most useful in relatively light gravity. It's not very hard to make such a rover that won't flip. The added weight of rockets and fuel tanks makes it very difficult to ascend steep slopes in high gravity, but isn't such a problem in lighter gravity.

Base on wheels

The largest class of rover is basically a mobile base. In addition to rockets, you also add mining equipment so that you can refuel. You may also add a science lab, docking ports, or whatever else you might want in a base. You probably need a lot of struts to hold the base together.

The advantage of having a base on wheels is that you can refuel yourself and don't need a bunch of separate vehicles for different purposes. The disadvantage is that the high weight can make the rover awkward to position precisely. In heavy gravity, you may be unable to ascend even modest slopes. For that matter, strong enough gravity could cause your base to crush and destroy your wheels. Even in lighter gravity, it can be annoying to start rolling downhill and have to work to stop nearly every time that you land.

That said, the base on wheels approach is most viable for moderately light gravity such as on Ike, Dres, Mun, and Eeloo. Heavier gravity makes constantly rolling downhill awkward, while lighter gravity makes frequent refueling unnecessary.

A different use of the base on wheels approach is to have a base that stays roughly in the same spot, while moving to refuel nearby landers. Rather than putting a small lander on wheels, you can put the larger base on wheels so that the small lander can land more easily. While this may seem counterintuitive because the small lander can more easily maneuver regardless, the point of it is that the larger base doesn't need to move very far. Rather, you can pick a particularly flat place to land the base, and then when you want the lander to dock to the base, the lander only has to land near the base, and then the base can roll the last few hundred meters or whatever to dock. The idea is that the lander has to fly around and land far more often than the base, and likely also on much steeper slopes, so you optimize the lander to make it easier to handle, at the expense of the larger, lumbering base having to roll around, but only on relatively flat terrain.

Portions of a mission

Other than for missions that take place around Kerbin, many of the things that you'll want to launch a rocket for have three main stages. First, you get off the ground and into orbit around Kerbin. Then you transfer from orbit around Kerbin to orbit around somewhere else. And finally, you land on whatever other body is your target. The third stage of landing is optional, and for space stations or relays, you likely won't want to. Some missions involve taking off again after landing on some other body or docking with another vehicle, so we'll cover those, too.

When designing your ship, you generally construct it in the reverse order. You start by assembling whatever you want to have in low orbit about your destination. After that, you add one or more stages to get it from low orbit about Kerbin to low orbit about your destination. And then you add additional stages to get it from the launch pad into low orbit about Kerbin. How much fuel and rockets and so forth are needed in the early stages is largely driven by how large the payload is that you need to deliver.

Getting to orbit

Let's start by discussing getting your initial rocket into orbit. There are a lot of important considerations, and a lot of ways that this can go wrong.

Thrust to weight ratio

One important place to start is by looking at the thrust to weight ratio at each stage. If it's not above 1 for the first stage, you're not getting off the ground. Even if it is slightly above 1, you'll burn enormous amounts of fuel to barely move, which is inefficient. Thus, you need a thrust to weight ratio well above one, at least early on.

You don't want a thrust to weight ratio that is too high, however. If you get going too fast too soon, you can burn up before you even get out of Kerbin's atmosphere. While that takes a lot of work to do, it's a lot more common for moving too fast too soon to cause too much air resistance and flip your rocket over. You can reduce the thrust of liquid fuel engines, but then you're carrying weight for those engines that you're not using. It's fine to reduce your thrust somewhat for part of your ascent, but extreme cutbacks generally mean that you should have used lighter or fewer rockets.

Your thrust to weight ratio also changes as you ascend. Burning fuel reduces your weight, without changing your thrust, so your thrust to weight ratio increases as a stage burns. Different stages can have independent thrust to weight ratios, of course.

I typically like to have a first stage consist of a mix of solid fuel boosters and liquid fuel rockets. For huge spaceships, that would mean clydesdales and mammoths, respectively, though it will tend to mean smaller rockets for smaller ships. At the launch pad, I want a thrust to weight of somewhat under two, and then as the first stage burns, I can lower the throttle on the liquid fuel rockets to keep the thrust to weight ratio around two. Once the atmosphere is thin enough to not be much of a concern, open up the throttle to go as fast as you can.

Technically, your thrust to weight ratio ought to increase as you ascend because gravity gets weaker. For example, at an altitude of 100 km, Kerbin's gravity only applies about 73% of the that it does at sea level, so your weight should be about 73% of what it would be for the same craft at sea level. The in-game computations do not compensate for this, but compute a thrust to weight ratio that assumes that you are at sea level.

For the upper stages of your ascent, it can be acceptable to have a lower thrust to weight ratio, sometimes even of less than one. Once you're already ascending pretty fast, you don't need to continue ascending ever faster. Rather, you want to increase your horizontal velocity enough to reach orbit, and before you stop ascending. Sometimes you'll have a few minutes from the time that your apoapsis is about where you want it until the time that you fall back into the atmosphere, and then a thrust to weight ratio of somewhat less than one may still be enough to stabilize your orbit.

Staging

You'll likely have to stage two or three times during your ascent. Especially if your first stage has a mix of liquid and solid fuel rockets, they generally won't run out of fuel at the same time, and you want to drop whichever one is done to reduce weight while the other continues to burn. While it is possible to reach orbit without staging, this is generally indicative of inefficient design unless you're specifically trying to avoid staging, such as for a rocket that needs to land on Kerbin, refuel, and take off again.

When you drop a stage, its throttle remains in whatever position it was when you ejected it. Recall that you can't turn off solid fuel boosters once they are ignited. Usually, this is handled by waiting until rockets are completely out of fuel to drop them. If you need to discard liquid fuel rockets early for some reason, it is typically best to turn them off, then stage, then turn rockets back on. Otherwise, the ejected rockets will continue to burn, and without being attached to your remaining vehicle to weigh them down, will likely shoot right past the rest of your ship. That risks a collision that blows up your ship.

Discarded rockets continuing to burn is hardly the only thing that risks post-staging collisions. Another is that you can discard rockets and fuel tanks, then collide with them, causing an explosion. For stages that basically drop off the bottom of your rocket, this isn't much of a concern. For stages that are attached radially, they can easily bump into the rest of your rocket rather than dropping off smoothly. This is mainly caused by drag, which will mostly push your rocket in the direction retrograde relative to the surface. If you're thrusting directly prograde, then this is parallel to your rocket, so there is usually no problem. If you're thrusting in some other direction that isn't terribly close to prograde (or retrograde, but that's dumb during ascent), that can easily make the discarded rockets slam into your rocket pretty hard.

It's critical to realize here that the key direction that you want to travel is prograde relative to the surface, not relative to orbit. The atmosphere gets dragged along with the surface, and your direction relative to orbit is irrelevant while you're in an atmosphere. The game will automatically switch your coordinates from being relative to the surface to relative to orbit at about 36 km of altitude above Kerbin. If you're using SAS to thrust prograde, that switch can easily cause you to no longer be going prograde relative to the surface, and then you slam into discarded rockets and blow up. The solution to this is to manually switch the coordinates to be relative to the surface, and don't discard any radial stages while just before the transition unless you switch SAS to stabilization mode. That's true of every planet with an atmosphere, not just Kerbin, though the exact altitude for the automatic reference frame change differs in other places.

Drag

We've already covered drag pretty in previous sections, but this is one of the main places that you have to deal with it. So long as you're pointed directly prograde, the drag largely balances out to provide minimal net torque, but it can be a much bigger problem if you try to point in some other direction. It's okay to point in another direction while moving slowly, and it's also okay once you reach the upper atmosphere where drag is minimal, but you may want to point directly prograde in between. If your rocket is flipping over during ascent, you may need to go slower so that there is less drag to flip you over. Alternatively, you may need more gimbal on your rockets to be able to provide enough torque to offset whatever drag is doing. You usually want rockets with significant gimbal in the early stages. It can work fine to have a mix of some rockets with gimbal and some without, but traveling through a lower atmosphere with no gimbal whatsoever puts you at considerable risk of flipping over.

Engine efficiency

All rocket engines lose efficiency at higher pressures. The game implements this as reduced thrust with the same fuel burn rate. But some lose a lot more thrust than others at a given pressure. You generally need your early stages to only use rockets that work well at high pressures. That includes most of the rockets in the game, but it pointedly excludes the ant, terrier, poodle, wolfhound, cheetah, and rhino engines that are really intended for upper stages. It also excludes the dawn and nerv engines that are really intended for deep space use.

That said, you hardly have to get out of the atmosphere before upper stage engines become appropriate. All rockets work well at sea level on Duna, for example, which has about the same pressure as 15 km of altitude on Kerbin. Dawn and nerv engines are usually a bad idea during ascent because of their low thrust to weight ratio, but the liquid fuel engines that are intended for upper stages will be fine to use by the time you reach 20 km of altitude, which likely makes them acceptable for any stages that aren't firing directly from the launch pad.

Engine efficiency concerns are also important when taking off from Eve and Laythe, though you can largely ignore them on Duna. You can even use purely nerv rockets as your only stage from Duna and it's fine. Eve has such high atmospheric pressure that near sea level, darts and vectors are pretty much the only engines that are reasonable to use.

There is also the issue of engine efficiency in terms of spatial efficiency. By spacial efficiency, I mean thrust per cross-sectional area. The problem is that you cannot stack rockets vertically and fire them all at the same time, as a higher one will be ejecting mass right at the lower one, likely causing it to explode. Very long rockets will tend to have a very high weight per cross-sectional area, which means that you need a lot of thrust per area. You can't always just make the first stage wider without falling off of the launch pad. When you really need an enormous amount of thrust per cross-sectional area, clydesdales are the best at it. Earlier in the tech tree, other solid fuel boosters such as kickbacks can be useful for the same reason, though you probably aren't trying to get a six thousand ton behemoth off the ground when still early in the tech tree.

If doing career mode, there is also the question of cost efficiency. This will often push you to use solid fuel boosters in your first stage. Solid fuel boosters offer far more thrust per dollar than any of the liquid fuel rockets. If not playing in career mode so that you don't have to buy parts, this isn't a consideration.

Gravity turn

It does work to thrust straight up into space, then once you're in space, turn horizontal to circularize your orbit. The problem is that it is inefficient. If you're thrusting upward at a 45 degree angle, that gets you the same effects as thrusting upward at a little over 70% of the force and also horizontally at over 70% of the force, and at the same time. It is similar in principle to how cutting across a corner allows you to get where you're going in less distance traveled.

That doesn't mean that you want to aim at a 45 degree angle at launch, however. That would get you going very fast through Kerbin's lower atmosphere, and the drag would waste copious amounts of fuel and likely flip you over. There is also the concern that you want to be pointing in a direction close to prograde much of the time, and if you try to just stay at a fixed angle, gravity will pull your prograde direction far away from that fixed angle. That is also likely to flip you over.

Rather, the efficient approach is called a gravity turn. You point directly up at launch, then soon afterwards, tilt a little off to the side. If you try to stay pointed in some fixed direction, gravity will pull your prograde direction below your chosen direction, so you just follow where gravity tries to take you. Often, you can spend much of your ascent with SAS holding your angle directly prograde. If you need to make adjustments, it is usually fine to move your angle a little off of prograde.

How soon to start your gravity turn and at how large of an angle depends tremendously on your thrust to weight ratio. It takes some practice to get the hang of it, but you don't have to get it perfect every time. Being off by a ways might mean that you wasted 50 or 100 m/s as compared to a perfect gravity turn, but that's not a big deal unless you're perilously tight on fuel.

Maneuvering in space

The next phase of most missions is to go from a low orbit of Kerbin to a low orbit of somewhere else. Let's talk about how to get there.

Rocket choices

The key difference that maneuvering in space makes is that you don't have to worry very much about how long it takes to burn. Thus, for the stages intended for deep space, you can have a very low thrust to weight ratio that only gives you something like 1 m/s of thrust, and that's often fine. That can often push you to use nerv atomic rockets due to their very high specific impulse. If nervs are not viable for some reason, then wolfhounds, rhinos, cheetahs, and poodles are the next most efficient liquid fuel rockets at very low thrust to weight ratios. Terriers can also fill in well if you need something smaller.

Because nerv rockets have a very poor thrust to weight ratio, they become inefficient if you need higher thrust to weight ratios, even in deep space. There is no reason to use them if you need over 7 m/s^2 of acceleration, and they become dubious somewhat before that. But they far outshine any other liquid fuel rockets if something below 3 m/s^2 of acceleration is acceptable.

Even so, you might not want to rely on a single nerv rocket to push your 1000 ton load. Real-life burns in deep space can easily take days or weeks, but you don't want to sit and wait that long. Remember that you can't do a normal time warp while accelerating, and physics warp can't go above 4x speed. An hour-long burn that takes 15 minutes at 4x physics warp isn't terribly exciting. I commonly pack enough rockets to keep my acceleration around 1 m/s in deep space.

When trying to do a gravity assist near some large planet, you don't necessarily have a lot of time near periapsis. This includes leaving Kerbin when you need to head off into deep space at high velocities. If you try to do a half-hour burn while you have an orbital period of 45 minutes, it's not going to work well. In some cases, that could cause you to dip into the atmosphere and burn up. You may need to get into a higher orbit with a longer period before your burn, and that means a less efficient gravity assist. Trying to avoid that can push you toward a higher thrust to weight ratio even in space.

Maneuver nodes

When taking off or landing, you don't have a lot of time to plan, but have to just go. When maneuvering in space, you do have a lot of time. Furthermore, without drag from an atmosphere, orbits are far more predictable. As such, you should use that time to plan exactly where you're going to go. Maneuver nodes are designed to help you with that.

Maneuver nodes allow you to plan that at a particular point, you will apply some particular amount of thrust in some particular direction, and then plot out where your path will go from there. You can change the conic patch limit in the game's settings to extend how far it will project your trajectory further out if you want. You can also place multiple maneuver nodes, and have the game plot what will happen if you use the first maneuver node exactly as planned, and then add a second one.

I generally recommend that you plot one maneuver node from orbit of Kerbin to reach the sphere of influence of Mun or Minmus if that is your destination. For any other destination, have one maneuver node to leave Kerbin orbit, and then a second and possibly third while orbiting the sun to reach the sphere of influence of your intended planet. That way, you make sure that you can get where you're going in a reasonable amount of fuel before you start your burn. Don't plan out exactly what you'll do after reaching some other planet's sphere of influence, even if your ultimate target is a particular moon, as your first burn just won't be precise enough for your plans near another planet to matter.

Even if you plan out two or three maneuver nodes ahead of time, after your first burn, you should delete the other nodes and recreate them. Your first burn won't be quite what you planned, and you'll need to adjust the later ones anyway if you want to get to where you're going. At the last maneuver node to put you on a trajectory to reach the sphere of influence of some particular planet, you likely want to fine-tune your trajectory such that you get very close to the planet, as this will save you quite a bit of delta-v when you reach the planet and try to get into your intended orbit. A few m/s of delta-v when in orbit about the sun can sometimes be the difference between a low periapsis about a planet and a high one when you reach its sphere of influence, and that can save you several hundred delta-v when trying to get into your intended orbit.

One coordinate at a time

When maneuvering in space, it is often best to adjust only one coordinate at a time, with a separate burn for each coordinate. This is almost never optimal in terms of minimizing the delta-v required to get where you're going, but it is much easier to understand, especially when you're new to the game.

For example, in order to rendezvous with an object in the same sphere of influence as you, you might first have a burn at either the ascending node or descending node to get your orbit into the same plane as your target. This actually fixes two coordinates, not one, as it makes the direction of your angular momentum match your target. Equivalently, it makes your inclination and longitude of ascending node match the target. Sometimes it can take two burns, as the first ends up off a little so that you're still off by 0.2 degrees, and then a second burn at the new ascending or descending node gets you much more precisely into the same plane. But once you're in the right plane, you only have to worry about four coordinates, not six.

When trying to travel from one planet to another, it is common to have one burn done at the starting planet to change your apoapsis or periapsis to be about right in order to hit the other planet. Then partway through, you have another burn at your ascending or descending node in order to change to be in the right plane. After that, you may need another small burn to fine-tune your velocity to make the intended encounter actually happen. But adjusting one coordinate at a time makes it easier to understand what is happening.

Encounters

An encounter is when you enter a sphere of influence. It is basically the reverse of leaving a sphere of influence. The game switches your velocity relative to the center of the previous sphere of influence to the new one. There are basically two stages of handling an encounter. First is the burn to cause the encounter. Second is that, upon entering a new sphere of influence, it is good to adjust your trajectory a little so that you end up going more precisely where you want to go.

The easy way to cause an encounter is to previously adjust coordinates so that you are on a roughly circular orbit, and your own orbit is in the same plane as that of the planet or moon that you wish to encounter. After that, you create a maneuver node with just enough prograde burn (if in a smaller orbit than the other body) or retrograde burn (if in a larger orbit) to make your new orbit tangent to the orbit of your target. Move the node around until you find the right time to make the burn such that your target will be at the place where the two orbits are tangent at the same time that you are. Then make the burn at the node you set up and you're on your way.

Larger targets and those in higher orbits tend to have larger spheres of influence, which makes it easier to set up an encounter. There aren't any that are genuinely hard to encounter, however. You just have to be more precise when trying to create an encounter with Moho or Gilly than some others. Jool and Tylo are easy enough to encounter that you're likely to do so by accident at various points.

Maximizing your delta-v

One reason why I like the energy and angular momentum based coordinate system is that it makes it more intuitively clear where you ought to thrust in order to minimize your use of delta-v. When changing your plane, you are changing the direction of your angular momentum without changing its magnitude, and without changing your kinetic energy. The amount of change in angular momentum to make is the same regardless of where you make it, but the amount of delta-v it takes to make that change is not.

Meanwhile, when you are trying to change your energy, you get the largest energy changes per unit of delta-v when you are traveling as fast as possible. That means doing your thrusts near a large planet or moon when possible. That this is more efficient is sometimes called the Oberth effect.

One of the most important things in order to be efficient is that when you approach another planet or moon in order to land on it or get into orbit, your own orbit is nearly tangent to that of the other body, and going in the same direction. For example, you might be traveling at about 19 km/s relative to the Sun as you approach Moho, while Moho itself is traveling at about 16 km/s. If you're going in nearly the same direction, you'll come in traveling at about 3000 m/s relative to orbit when you enter Moho's sphere of influence, and you'll need a retrograde burn of more than 2000 m/s to get into a stable orbit. That's quite a bit, but it is manageable.

If instead, you come in the direction opposite of that which Moho orbits the Sun, you'll enter its sphere of influence at about 35000 m/s relative to Moho. If you come in that fast, you're not going to be able to get into a stable orbit. For that matter, you'll zip right through its entire sphere of influence in under six minutes.

But while it is likely obvious that coming in the wrong direction won't work, coming at even a modest angle can also be a problem. If you come in at a 45 degree angle from Moho's orbit, you'll be traveling at about 13700 m/s relative to Moho. A 20 degree angle would mean you're at about 6800 m/s relative to Moho. 10 degrees would be about 4300 m/s. You don't need your angle to be exactly right, but you do need it to be close.

While trickier to set up, it is sometimes possible to combine burns. For an analogy, if you need to walk 4 miles to the east and 3 miles to the north, you could move in one direction at a time and walk seven miles in total. Or you could walk directly to your destination and walk 5 miles in total. Similarly, if you need to thrust 400 m/s prograde and 300 m/s normal, you could use 700 m/s of delta-v in total, or you could combine them into a single 500 m/s thrust at a direction between the two.

Or at least that's how it works if the two thrusts can happen at the same time. Often, they can't. For example, you might need to thrust prograde at periapsis and normal at the descending node, and those may be nowhere near each other. But sometimes, you can manipulate things such that the periapsis and descending node are almost exactly the same spot. Or sometimes they happen to be close enough that you can get away with, say, a 520 m/s burn at prograde that does the full prograde portion, and enough of the normal portion to only require a 50 m/s burn at the modified descending node later.

Sometimes it's not just what you do after launch that matters, but also the time that you choose to launch. For example, the ideal trip from Kerbin to Duna would be to have a thrust from low orbit at Kerbin that puts you into an elliptical orbit about the Sun with your periapsis at the Kerbin's orbital distance and the apoapsis at Duna's. And you'd like for Duna to just happen to be there when you arrive at your apoapsis. That's unlikely to happen by random chance if you just pick a random time to launch. However, you can largely make it happen by choosing the right time to launch. There are tools such as Alexmoon's launch window planner to help you find the right time to make coincidences like that happen.

Gravity assists

One particular approach to squeezing more acceleration out of your rocket is called a gravity assist. The idea is that if a particular planet or moon is not your target, but you fly by it on your way to your target, its gravity pulls on you for a while. So long as its gravity is pulling you in the direction that you wanted to go anyway, it provides some free acceleration without using up any fuel.

The idea is that you use a gravity assist to pull you into a higher or lower orbit without changing your plane very much. If you want to get to a higher orbit, you pass by an object going behind it so that it pulls you forward and speeds you up. If you want to get to a lower orbit, you pass by the object going in front of it so that it slows you down.

The easiest way to demonstrate this in-game is to do a gravity assist using Mun. Get into a low, circular orbit about Kerbin with an inclination near zero. Create a maneuver node that would put your apoapsis somewhat higher than Mun's orbit, but much lower than that of Minmus. Try moving the node around. If you line it up so that you pass behind Mun, you can probably get a gravity assist that would take you out of Kerbin's sphere of influence entirely. Pass in front of Mun, and you can get into a lower orbit around Kerbin.

Gravity assists are a tremendously important way to save cost in real life. For example, the Parker Solar Probe is scheduled to do seven separate gravity assists off of Venus to bring its periapsis closer to the Sun. Getting the benefit of a few hundred delta-v here and there can add up to many millions of dollars in savings.

But they're a lot less useful in Kerbal Space Program. One problem is that they're very finicky and hard to set up properly. Being off by a small amount when you do one fly-by can mean that you're way off for the next. You can try to correct with additional burns, but that can eat up much of the benefit that you hoped for.

Another problem is that the bodies that you hope to use for a gravity assist usually won't be where you need them when you need them. If you're on Moho and want to use Eve for a gravity assist to get you to Jool, it can work great if you time it exactly right. But there will be various launch windows of how to reach Eve optimally, as well as various launch windows of how to reach Jool optimally, and they won't match. You could end up having to wait many years for them to line up properly to get a good gravity assist.

A third problem is that trying to line up a gravity assist later can often conflict with having a large thrust from a low orbit of Kerbin. Being unable to do that can easily waste more efficiency than you were hoping to gain from the gravity assist.

The easiest place in the game to get a gravity assist that both works properly and is useful is by using Jool's moons Laythe and Tylo. When you enter Jool's sphere of influence, a modest thrust of something like 100 m/s can often line up a gravity assist using either Laythe or Tylo that changes your orbit from a simple fly-by of Jool that will leave the sphere of influence at 2000 m/s to a stable orbit that is lower than Bop's. You can also have a gravity assist to go in the opposite direction when you leave the Jool system. Gravity assists are possible elsewhere in the game, but far more difficult to get any real benefit from them.

Landing

Landing on a planet or moon can be very different depending on whether the planet has an atmosphere or not. As such, we'll consider the cases of landing in an atmosphere and landing in a vacuum independently.

Atmospheric landing

Landing in an atmosphere brings concerns that drag from the air could flip you over, or that it could cause you to overheat and explode. The former can mostly be managed by pointing retrograde relative to the surface, at least assuming that you have enough reaction wheels to keep your vehicle pointed in the intended direction. But those concerns have been dealt with in previous sections.

Once you've slowed down enough that you're not going to explode, the main effect of an atmosphere is that drag slows you down. That can be troublesome if trying to land in a very specific spot, but for the most part, it's helpful, as it means that you don't need an extended rocket burn to slow down. Using drag to slow you down and lower your orbit or take you out of orbit entirely is called aerobraking. For the last stages of landing, you can use parachutes to slow you down far enough to actually touch the ground and live.

Aerobraking

When approaching an atmosphere at high velocities from a high orbit or even a fly-by of the planet, you usually don't want to point straight at the planet. That won't give you enough time for drag with the air to slow you down. Entering a thicker portion of the atmosphere while still traveling at very high velocities can cause you to overheat and explode. Even if you're traveling slowly enough to not explode, having less time to slow down can mean that you're traveling so fast that your parachutes can't safely open before you crash into the ground.

Rather, it's usually better to set your trajectory such that your periapsis is well within the atmosphere, but also well above the ground. On Kerbin, a periapsis of around 30 km often works well. That way, you'll travel a very long distance at an altitude of about 30 km, which gives the relatively thin air a lot of time to slow you down. If you set your periapsis too high, you won't slow down very much before you zip back off into space. When done properly, aerobraking will slow you down enough for your apoapsis to enter the planet's atmosphere, and from there, it's just a matter of time before you touch the ground.

It is also possible but usually inadvisable to use aerobraking to drop from a higher orbit to a lower one without actually landing on the planet. To do this, you set your target periapsis higher, such that you'll have enough drag to slow you down a lot, but not actually enough to bring your apoapsis into the atmosphere. This gets you all of the risks of overheating or flipping over, but without actually stopping and landing. Other than on Duna, it tends to be done from high enough velocities for burning up to be a major concern. And even if it works, it doesn't leave you in a stable orbit, but rather, will require another burn to get your periapsis out of the atmosphere.

Parachutes

When using parachutes, the first question to ask is, what is the goal of your use of parachutes? Are you trying to slow down enough that you can activate the parachute stage, step away, and have the landing finish on its own? Or are you only trying to slow down quite a bit, perhaps to something like 20 m/s, and then fire rockets at the very end to slow down enough to land safely? The former will commonly require a lot more parachutes than the latter. Slowing down to a given velocity will also require a lot more parachutes on Duna than on the other planets with an atmosphere, and fewer on Eve.

If you're relying on rocket thrusts to finish a landing after parachutes slow you to perhaps 20 m/s, then you'd better have rockets available that can provide that thrust. Discarding your final rockets as part of staging your parachutes obviously won't allow this. If all you have left is upper stage rockets intended for flying in deep space, they may not produce enough thrust to slow you down very much near sea level on Kerbin or especially Eve.

How many parachutes you need also depends on where on a given planet you need to be able to land safely. The atmosphere is far thinner at the top of a high mountain than it is at sea level. If you're relying on parachutes only to slow you to something like 20 m/s, and the thin atmosphere means that you're still going 30 m/s instead, you merely have to fire your rockets a little longer. But if you're relying on not needing to fire rockets at landing, you'll need to either have enough parachutes to slow down adequately atop a high mountain or else be able to aim your craft well enough to be guaranteed that you're not going to hit a high mountain. On Kerbin, Eve, and Laythe, this is easy to do provided that you don't care which biome you land in: aim for the middle of the ocean, and if you miss by 50 km, you still land in the ocean, which has the advantages of being at sea level and completely flat.

How slow you need to be going in order to land safely depends considerably on the design of your vehicle, and also where you land. The limiting factor is commonly the 6 m/s impact tolerance of fuel tanks. But fuel tanks usually don't directly touch the ground. That said, if sturdy but rigid rocket engines directly touch the ground, they can transmit that force straight through and blow up the fuel tanks to which they're attached. If lander legs or rover wheels are the only thing that touches the ground, that gives you a lot more impact tolerance and can often make it safe to touch down at 12 m/s--and least on flat ground. On a steep slope, if only a small fraction of your lander legs or wheels touch the ground at first, having to cushion the blow of your entire rocket can cause them to blow up, which then allows whatever they were trying to keep off of the ground to hit hard and also blow up. Furthermore, in a water landing, legs or wheels can't keep the rest of your ship off of the water, so they just sink into the water and then other parts higher up also hit the water, and may explode. Under 6 m/s is pretty much always safe unless you have a creatively awful design or land on an extremely steep slope.

If you're trying to land in a particular biome, it gets trickier. Parachute landings are also far more difficult to fine-tune than vacuum landings, as it's difficult to predict exactly how much drag will slow you down, which moves your trajectory away from what the game displays. When landing from orbit, you can sometimes fine-tune a parachute landing by saving then trying repeatedly. Try to use highly repeatable steps such as varying only the starting time of a retrograde burn, then have the retrograde burn use a fixed amount of delta-v every time and open your parachutes at exactly the same altitude every time. That way, it's easy to see if you started your burn too soon or too late from whether you went too far or not far enough and adjust accordingly.

Whether parachutes slow you down adequately really only depends on how fast you're going when you touch the ground, which depends on your vehicle, your parachutes, the planet's gravity, and how dense the atmosphere is there. Eve's atmosphere is very thick near the ground and tapers off slowly, so that at sea level, it has about three times the atmospheric density of Kerbin at sea level, and even at an altitude of 13 km, it is still denser than Kerbin's at sea level. Kerbin's atmosphere tapers off much more quickly, and at an altitude of 5 km, has only about half of the atmospheric density of sea level. While Laythe's atmosphere has 3/5 of the surface pressure of Kerbin's, because its atmosphere tapers off much more slowly, it's atmospheric density at sea level is only about 38% of Kerbin's, which makes parachutes less effective than you might guess. Laythe's atmosphere is actually slightly less dense at sea level than it is a kilometer or two above it, which is unrealistic. Duna's atmosphere also diminishes relatively slowly, but its atmospheric density at sea level is only about 5% of that of Kerbin, which makes parachutes less effective than the other planets with an atmosphere.

Vacuum landing

When landing in a vacuum, there is no aerobraking and parachutes will not open. As such, you have to burn retrograde in order to slow down and land. It is critical that you burn retrograde relative to the surface, not relative to orbit. The game will automatically switch your coordinates to be relative to the surface when you are near it, but if you need to start burning retrograde higher up, you may need to switch it manually. On some very slow rotating places like Moho or Pol, the difference barely matters. At the equator of Eeloo, it's a difference of about 68 m/s.

The ideal vacuum landing is to be on the proper trajectory to go where you want, then start burning retrograde at just the right time such that continuing to burn until you touch down slows you down enough to land gently, then kill the throttle as you touch the ground. It's nearly impossible to time that exactly right, however, as starting a second too soon can mean that you stop several hundred meters above the ground, while starting a second too late can slam you into the ground at 40 m/s and then you explode.

Realistically, what you do is to start your retrograde burn a little too early, then keep burning until it's clear that you started way too early. Kill the throttle for a while and wait until you're closer to the ground before starting again. Each round if this should result in you being much closer to the ground the next time you start a burn and moving at much slower speeds, so eventually, you're near the ground and moving slowly. The closer you can come to the ideal time to start the burn, the less delta-v you'll need, but if you start one burn a little too late, you crash and explode.

How slow you need to be going in order to touch down properly depends on where you're landing. The same rules of parts exploding if you land too hard apply to vacuum and atmospheric landings, and under 6 m/s is generally safe from that. But vacuum landings in light gravity have another complication: you could bounce rather than sticking. Lighter gravity makes this effect far worse than it would otherwise be. It's generally safe to land on Tylo at 10 m/s if you've got enough lander legs. Doing that on Gilly will bounce you high enough into space that it could easily be several minutes before you touch the ground again.

The way that you generally want to finish a vaccum landing is that you end up traveling almost exactly vertically relative to the surface while close to the ground and at about the speed that you want to touch down. You adjust your throttle to remain at that speed rather than accelerating up or down, then wait until you touch the ground. Turn off the throttle as you touch the ground. For example, if you're trying to land on Mun and touch down at 4 m/s, and you have about 6 m/s^2 of acceleration available at full throttle as compared to Mun's surface gravity of about 1.6 m/s^2, you set your throttle to about 27% in order to stay going about 4 m/s as you descend the final tens of meters. It often helps to use SAS to point directly retrograde, which will naturally turn you toward a directly vertical landing.

Slopes and vehicle stability

One major issue with landing is that you could land on a steep slope, then fall over. In some cases, falling over merely means that you can't take off again, but that's fine if you've landed on Kerbin and only need to recover the vessel. For larger vehicles, falling over can cause a secondary impact of the top of your rocket slamming into the ground hard enough to blow up. Depending on how well you roll, it can sometimes mean rolling down a hill until you gain enough velocity to blow up.

There are two ways to deal with this: don't land on slopes, or have a vehicle that can handle landing on slopes. Having a perfectly flat place to land is really only practical if you're either splashing down on Kerbin, Eve, or Laythe, landing on the polar ice shelves of Kerbin or Laythe, or landing on the flats on Minmus. Anywhere else, it's all about how steep of a slope your vehicle can handle. A very tall, thin rocket could fail catastrophically on a five degree slope, which can make landing it very difficult. A short, wide lander vehicle may be able to handle landing on a forty degree slope easily.

If your vehicle is on wheels and you land on a slope, it may try to roll down the slope. For a slope that is long enough and steep enough, this can accumulate enough velocity to risk blowing up if you hit a bump. To stop the vehicle, it helps to turn on the breaks and accelerate in the direction opposite what the slope will push you in. In some cases, you may need to turn, so that going either forward or backward isn't really up or down a hill, and instead, the slope is trying to push you to the side, in a direction that wheels cannot roll.

Still, no matter how short and wide you make your lander, it can still fail if it tries to land on a sufficiently steep cliff. Some cliffs in Kerbin's mountains biome are slopes of something like 80 degrees. Dres's canyons biome has comparably steep cliffs. Usually you'll want to avoid those biomes entirely unless you're specifically trying to land on them, and then be careful, with plenty of fuel available in case you need to do a considerable thrust to avoid hitting the side of a cliff.

Taking off again

Some missions don't end when you land. In some cases, you need to take off again, whether to return to Kerbin, to land somewhere else, or whatever else you might fancy. The second takeoff is substantially different from your original launch on Kerbin, for a variety of reasons. For one, you likely start on a slope, and possibly a steep one, in contrast to Kerbin's very level launch sites. Unless you're taking off from Kerbin, the gravity is very different from Kerbin. So is the atmospheric pressure and density, and you'll likely be in a vacuum. All of that changes the procedures for launching.

When launching in a vacuum, there is no concern for quickly getting up out of the lower atmosphere. If you're trying to hop a very short distance, it is optimal to thrust at about 45 degrees above the ground. For longer distances, the optimal thrust angle gets lower, and if you're trying to reach orbit, you'll sometimes want to almost immediately have an angle less than 20 degrees above the ground. It is obviously important to have a high enough angle that you don't almost immediately smack into a hill, so do look around before taking off. You also need some net upward force, so the product of your thrust to weight ratio with the sine of your angle with the ground needs to exceed 1.

When taking off from in an atmosphere, you also have to worry about drag both slowing you down and flipping you over. On Eve, you'd better get to directly vertical very quickly after launch or else you're going to flip over. As discussed elsewhere, you probably want to stay directly vertical on Eve until you reach about 40-45 km of altitude. On Kerbin or Laythe, you don't necessarily need to start out going straight up, but you likely want something more like an 80 or 85 degree angle even for a short hop where you only hope to land 100 km away. You also need to get pointed in the right direction and then thrust very close to prograde quickly or else you'll flip over. Since you're probably not starting on level ground unless splashed down, having either high gimbal engines on the first stage or else a lot of reaction wheels is very helpful. To leave Eve, it is nearly mandatory to have a vector engine on your first stage. Duna is somewhat more forgiving due to its much thinner atmosphere. But even there, you want to get out of the lower atmosphere quickly other than for extremely short hops, so you might want to take off at an angle of 60 or 70 degrees.

Another, much less obvious issue is the direction of which way to go when you finally do launch, as it's not what you might expect from looking at a flat map. The Kerbal Space Center is right at the equator, which effectively makes this issue moot. When you land elsewhere, however, it usually won't be right at the equator. And from any location not at the equator, a circular orbit that starts there will slant toward the equator. To take an extreme example, if you start at the north pole, whichever direction you try to travel, you're going to end up going south very quickly.

The way to handle this is to switch to map mode, then rotate the map such that your vehicle icon is directly over the small sphere for the center of the planet or moon you're on. The angle that you want to travel relative to the surface is the angle that it looks like you need to travel from that particular map view. Or at least it would be if the planet or moon weren't rotating, which it is. Still, that will give you a pretty good approximation in most places, off by only however much the planet or moon orbits while you're in your flight.

Docking

Sometimes, you don't want to land in a particular place, but instead, want to dock with a vehicle that is in space. This can commonly be to transfer kerbals, data, or fuel. In order to dock, you first get into the same sphere of influence as your target. You then try to rendezvous with your target in about the same way as you would cause an encounter with a moon: get into the same orbital plane, then make your orbit tangent to that of your target such that both vehicles arrive there at the same time.

Where docking diverges from creating an encounter is what happens when you get close. Your target will be massively smaller than Gilly. Rather than trying to hit your target exactly, you just try to get close at first. As you approach the rendezvous point, you aim your vehicle retrograde relative to the target. You watch as the other vehicle approaches, then burn retrograde until you are completely stopped relative to your target. Then you turn protarget and burn toward the target. Repeat as many times as necessary until you are close enough to be at risk of crashing into the other vehicle. For the protarget burns, you generally only want to go a few m/s. It helps to get over 1 m/s so that the game will allow SAS to point you retrograde automatically, but you don't want to go fast enough to cause an explosion in case of a collision.

Once you are close enough to dock, you want each vehicle to set the other as its target, and have SAS point protarget. Well, usually; I've occasionally put a docking port on the bottom of a vehicle, in which case, SAS had to point anti-target. Alternatively, you can select a docking port and choose control from here, which will definitely make it protarget. If using docking ports, you can also have each vehicle target specifically the other vehicle's docking port, not just the other vehicle.

Once you are close with both vehicles pointed protarget and effectively not moving relative to each other, you have one apply a modest thrust of something like 0.3 m/s, then wait for the collision. Assuming that they have ample reaction wheels, both vehicles will rotate as needed to line up perfectly and then they'll stick together when they hit. If they hit too hard, they might bounce off and not stick. Or if way too hard, they could explode on contact. It helps tremendously if you can thrust while pointed protarget, which requires the docking port to be on the top of at least one of your vehicles.

This assumes that both vehicles have SAS level 3 available, which allows automatically pointing protarget. If you don't, then you can try to point protarget yourself, but there will be some slight errors. If only one vehicle has SAS level 3, then you want to have that one automatically point protarget while you manually adjust the other. If neither does, then good luck. It's still very possible, but just harder. So long as you're moving slowly enough, you can handle the vehicles bouncing off each other a few times until you get it right.

Stageless colonization architectures

Even if you want to collect the science from all twelve of Moho's biomes, for example, you don't necessarily want to have to send twelve separate vehicles to do it. Rather, it's far more efficient to send one vehicle that can fly around from biome to biome and collect all of the science. However, from being landed on Moho in one biome, to take off and then land in another could easily cost you 2000 delta-v. To go from a low orbit of Moho to landing in each of the biomes and then getting back to a low orbit of Moho could easily cost you over 20000 delta-v. Doing that without refueling would take an enormous vehicle and be very awkward.

Rather, what's far preferable is to be able to send a single vehicle to a planet, and then have that vehicle be able to refuel so that it can land in all of the biomes and return to orbit without any further staging. The question is how to design your ships to make that possible. There are a number of possible architectures.

All-in-one rocket base with mining capabilities

Let's start the obvious architecture: build a huge base that has everything you want in it. Have all of the mining equipment, all of the science equipment, and whatever else you want to use all in a single base. This allows you to refuel after every single time that you move from one biome to another.

The problem with this approach is that it means that you're stuck having to move around a big, bulky base every step of the way. If you want to do deployed science, you may also have to put the whole thing on wheels so that you can roll over to a deployed science location. And then you also need to make sure that the wheels have enough force to go up whatever hills you need to ascend, which is awkward when you're carrying around a bunch of mining equipment and many tons of fuel.

That's not to say that this approach doesn't work. It works, but it's awkward. On Kerbin, Laythe, and Tylo, it's pretty much what you have to do if you want to hop around indefinitely. But on the smaller planets and moons, there are other options.

Ground base with a detachable lander

One alternative is to build a mining base that lands in one place, sets out its mining gear, and stays there. Meanwhile, you have a smaller lander that doesn't need to carry around mining equipment that goes to the various biomes to pick up the science. In order to refuel, the lander returns to the base to dock.

One advantage to this approach is that your lander can be much smaller and more agile if you don't have to carry around a bunch of mining equipment. If you want to put your lander on wheels, not needing mining equipment makes it much easier to keep your center of mass very low to the ground so that you don't flip over. This also allows the base to mine while the lander is away, so that you can dock, quickly refuel with accumulated fuel, and leave, rather than having to wait to mine ore.

One key requirement in order for this approach to work at all is that the lander has to be able to fly from the base to an arbitrary other point on the planet, land, and fly back to the base, and land at the base to dock again, all on a single load of fuel. Depending on the size and gravity of various planets on moons, this can range from trivial to impossible. This can be done on Moho, Duna, or Vall, but needing two hops for each biome and still barely having enough fuel is hard enough that it's probably a bad idea to try. It can readily be done on Mun or Eeloo, and is easy on any of the lighter moons.

The other key requirement is that you have to be able to dock. This requires not just having the proper docking ports, but also being able to line them up exactly right. In order to make this work, I generally put a docking port on top of the lander, and have another one dangling from a cylinder attached to the base. The combination of a servo and two cylinders makes it possible to have the base move its docking port to an arbitrary position. Put it directly above the lander's docking port, then lower it by extending a cylinder to make the connection. This still requires the lander to be on wheels so that it can roll up to the base, but having a docking port attached to robotics makes it good enough for the lander to get kind of close rather than needing to be in exactly the right spot.

One warning if you use a detachable lander is that you should always save your game immediately before docking and undocking. It's rather buggy, and occasionally docking or undocking causes vehicles to blow up. Additionally, never return to the space station while leaving the lander docked to the base. If you do, switching back to them will occasionally cause one or both of them to explode.

Orbital space station and detachable lander

Another alternative is to have a mining base and detachable lander, but put the base in orbit. That allows the lander to dock with the station while in space, without bumpy ground potentially causing trouble. Docking in space is commonly easier than on land.

One drawback of this approach is that a space station in orbit can't sit there mining all of the time. Rather, it has to have enough fuel to land, mine to refill, and then use some of that fuel to get back to orbit. Another drawback is that, in order to dock, the lander doesn't just need to land in a particular spot, but has to match a particular orbit, which can take a lot of fuel to adjust inclination from a bad starting point. These issues aren't a very big deal on lighter moons like Minmus, but they can be a serious problem for heavier places like Duna or Moho. You can mostly avoid the inclination adjustment by waiting to launch until you're under the station's orbit, though that could mean waiting a very long time on bodies that rotate very slowly such as Moho or Pol.

Mining rocket base with orbital refueling station

Another alternative is to have a full mining rocket base that is nearly capable of being self-sufficient, but also having an orbital refueling station. This really only makes sense for the heavier planets and moons that are hard to land on, but there are several reasons why it could be useful.

One is that in some cases, it can be difficult to go from landed to in orbit and back to landing somewhere else on a single tank of fuel. This is especially the case on Tylo, and it's much easier if you can refuel while in orbit. Another is that while a vehicle can get from Kerbin or Laythe to orbit without staging, it isn't going to have very much fuel left, and if you want the vehicle to go elsewhere, you'll probably need to refuel. A third is that at the end of some long journeys, especially to Moho, you may have enough fuel left to get into a stable orbit rather than zipping by, but not enough to land. Refueling allows you to land without having to abort the mission.

The orbital refueling station doesn't have to mine the body it orbits to collect fuel. If doing this on Moho, you would, but in most other places, you would pick a different moon as the place to go refuel. Depending on which planetary system you're in, you would probably go to Gilly, Minmus, Ike, or Pol. That allows the refueling station to operate with a very low thrust to weight ratio, and thus have more fuel and more delta-v to get from the other moon to orbit, give away some fuel, and still be able to land back on the other moon. You probably want to use Nerv atomic rockets and liquid fuel for the refueling station, even if it is delivering something else to the vehicles that it exists to refuel.

Interplanetary travel

In addition to wanting to travel between biomes and situations on a single planet, sometimes you want to travel between planets. Many missions are to basically travel from Kerbin to some particular planet or moon and then stay there. In some cases, you may want a single mission to travel between several planets or moons. This is much easier if once you get into space, you don't need to do any more staging, but can refuel at each planet or moon where you stop.

In order to do this, you want for the last stage to rely on nerv atomic rockets and a lot of fuel, as well as having mining equipment to refuel. You can readily get to about 7000 m/s of delta-v with about 3 m/s of acceleration when full on fuel. The larger the payload you want to carry, the more fuel and rockets you'll need in order to reach those thresholds. That's enough to let you get into orbit from Moho or Vall when starting full on fuel. It won't let you get off the ground on Duna with full fuel, but you can leave Duna with half fuel, then land on Ike to refuel before leaving the Duna system. Such a vehicle will not be able to depart Kerbin, Eve, Laythe, or Tylo, but it can land anywhere else that you can land and then get from there to any other planet or moon. It can also get to an orbit about the places that you can't land and rendezvous with another lander.

For the structure of such a vehicle, my preferred approach is to have girders connecting a central section to mk 3 liquid fuel fuselages of some length, and use BZ-52 Radial Attachment Points to attach the nerv rockets to the girders. That's not a very aerodynamic design, but it does work to get the rockets up into the air so that they don't touch the ground, and without having something under them that they blast and blow up. As Duna is the only place with an atmosphere that the vehicle can land at all, it doesn't need to be very aerodynamic.

Locations to visit

There are many locations in the game to visit and acquire science. We list them in this section, though the smaller, easier ones are grouped together.

If you want to acquire all of the science in the game, at least apart from the infinitely replenishable asteroids and comets, the game has three ultimate challenges that I'll focus on more extensively:

1) Eve's surface 2) Jool's lower atmosphere 3) Landed (not splashed) at Laythe's water-only biomes

Just how hard the three challenges are depends on exactly what you want to do. Just getting a probe there isn't too hard. Doing so with a kerbal on board is harder, but necessary if you want a crew report, EVA report, or surface sample. But the real, full challenge is to send the kerbal, pick up the science, and then bring that it all home to Kerbin.

One measure of a moon's "size" is how much delta-v you need there. Let's suppose that you want to go from a low orbit to landing in every biome, and then return to a low orbit to dock with something. If used reasonably efficiently, the amount of delta-v needed is approximately:
Gilly: 100 m/s
Pol: 600 m/s
Bop: 1200 m/s
Minmus: 2000 m/s
Dres: 3000 m/s
Ike: 4000 m/s
Eeloo: 7000 m/s
Vall: 8000 m/s
Duna: 10000 m/s
Mun: 14000 m/s
Moho: 14000 m/s
Tylo: 20000 m/s

Obviously, some of those are far more doable without refueling (or without staging) than others. If used inefficiently, it could take you massively more delta-v than listed, however. I exclude Eve, Kerbin, and Laythe, as the oceans make it much less clear where all the places you want to land are, the heavy gravity makes jumping from one biome to another awkward, and you're probably going to use so many different vehicles that the cumulative delta-v isn't particularly meaningful.

Tiny: Minmus, Bop, Pol, and Gilly

The distinguishing feature of the tiny moons is that you don't need to refuel on them at all. It's pretty easy to go from orbit to landing on every biome and then get back to orbit without refueling at all. You can do that in about 2000 m/s of delta-v on Minmus, and much less than that on the others. Pretty much any of the architectures in the previous section can work fine, which makes it generally preferable to use a small, easily maneuverable lander. If you want to have a refueling capability at all, that can be a separate base.

On Bop, Pol, and Gilly, you can pick up all of the biomes except poles in a relatively small area just by picking a high point, a low point, and traveling from one to the other while stopping at every biome along the way. That doesn't work on Minmus because there are several flats biomes and the slopes biome is irregular.

The tiny moons all have irregular topology with some steep slopes. The steepest that I've directly measured while landed is 47 degrees on Minmus. That can be quite a nasty surprise if you brought a tall, narrow lander and then struggle to find a place where you can land without falling over. But it's easily handled by bringing a short, wide lander, and then touching down softly enough that the torque from one side hitting the ground before the other doesn't flip you over.

You may also wish to use Minmus, Gilly, and Pol as places to mine ore and refuel elsewhere in the same planetary system as other places that are harder to land. This allows you to approach Kerbin, Eve, and Jool's other moons (especially Laythe and Tylo) with nearly full fuel, or to refuel before leaving the system.

Gilly has much lighter gravity than the other tiny moons, at only about 1/10 as strong as Pol. This is so light that it is easy to fall off rather than sticking on Gilly. It is also sometimes preferable to just ignore Gilly's gravity and rely on the docking in space approach to reach locations rather than orbital mechanics.

Small: Mun, Ike, Dres, and Eeloo

The common feature of the small moons and planets is that, while it's easy to land and take off again a few times between refueling, if you want to get all of the science, you're probably going to need to refuel. On Ike and Dres, it is possible to go from orbit to landing on every biome and then back to orbit on a single tank of fuel. But it's difficult enough that it's not a good idea to assume that you'll be able to. Even so, because you can readily do three or four hops before needing to refuel, the fixed land base with a small lander can work well.

The only non-trivial biome on Dres is the canyons. This is a series of east-west gashes visible from space near the planet's equator. The canyons are very deep with very steep side slopes, so you have to be careful to land on the bottom and not on the sides.

Eeloo has two complications. One is obvious: its extreme isolation. Solar panels barely do anything, so you'll want to rely on nuclear power and/or fuel cells instead. You also can't rely much on happening to connect to relays orbiting other bodies such as when you connect to a relay around one of Jool's moons while orbiting another, or connect all the way back to Kerbin while orbiting Moho. You'll probably want to handle this by having several relays orbiting Eeloo, at least one of which is powerful enough to connect directly back to Kerbin.

The other complication is Eeloo's very high rotational speed. Of all of the places that you can land, Eeloo has the shortest rotational period, and the second highest ground velocity behind Kerbin. The other places with a relatively high rotational speed tend to be larger planets or moons that have an atmosphere, so you're moving very fast relative to the planet until you open your parachutes and then aren't moving very fast relative to the surface, which reduces the error of using your orbit to project where you'll land. Eeloo's rotational speed is nearly three times that of Dres, which is the second fastest to not have an atmosphere. This means you commonly have to aim well to the east of where you actually want to land, much more so than on other planets or moons.

Medium: Moho, Duna, and Vall

The medium planets and moons are large enough that it's easy to fly from one arbitrary place on the planet to another on a single tank of fuel, but much more difficult to do two such arbitrary hops. That makes the model of having a small, light lander that returns to a fixed base to refuel awkward to use. Rather, it is better to have a larger base with everything you need that can refuel itself. You don't necessarily need to refuel at every stop, especially for short hops across the border between two nearby biomes. But it is important to have the capability to refuel when you need to.

Alternatively, the medium planets are large enough that you may wish not to rely on refueling at all, but bring several landers with multiple stages and discard one when it runs out of fuel. That can also work.

All three of the medium bodies make their biomes mostly visible from space. This makes it easy to find exactly where you are on a biomes map. The midlands and highlands biomes are backwards on Vall, but it's still very visible that the higher altitude "midlands" and mountains are white and the lower altitude everything else is blue, at least outside of the polar areas.

Duna has a thin atmosphere, while the others have no atmosphere at all. This makes it much harder to take off from Duna, as apart from very short hops, you'll want to get much higher than you would without an atmosphere, and possibly outside of Duna's 50 km atmosphere entirely. It does make landing use much less fuel, however, as you can rely on parachutes and aerobraking. The atmosphere is so thin that you may not want to rely purely on parachutes to land you, but even having parachutes slow you to 20 m/s before firing up rockets to finish the landing can save several hundred m/s of thrust. The other caution about using parachutes on Duna is that if you're going fast enough, the parachutes may not open at all before you crash into the planet. When trying to land from orbit, you'll probably need to burn retrograde quite a bit to get under about 480 m/s. I recommend that you tweak parachute settings to partially open at the lowest pressure available (which on Duna, is about 13 km) and fully open at higher altitude than you would on the other planets with an atmosphere.

With Moho, the big difficulty is getting there at all, or getting back to some other body when leaving. One problem is that Moho is so close to the sun that, even when you enter its sphere of influence, you're likely to be moving at several thousand m/s relative to Moho, and it requires a lot of delta-v to get into a proper orbit. And then you still need to have about 1000 m/s left to land from a low orbit. Another issue is that, at seven degrees, Moho has the largest inclination of any planet. The closer you are to the sun when you make that adjustment, the more delta-v it will take, and it can take a few thousand m/s just for the plane change if you're about as close to the sun as Moho. My preferred way to approach Moho is to wait until Kerbin is roughly at the ascending node (or descending node) to take off, and take off in a northeast or southeast direction from Kerbin, rather than directly east. From a relatively low orbit of Kerbin, do a single burn to leave Kerbin's sphere of influence at a few thousand m/s in such a manner as to put your orbit in Moho's plane with your periapsis on Moho's orbit. It's not practical to get it exactly right, but if you're off by 0.2 degrees on the inclination, fixing that with a later burn is massively cheaper than trying to fix being off by seven degrees.

Kerbin

Among the planets that you can land on Kerbin has the second highest surface gravity, tied for the second largest size, and the second densest atmosphere. So Kerbin could easily be the second hardest place to maneuver. Of course, the easiest way to get somewhere is to start there, and you start on Kerbin. That makes recovering science from Kerbin very different from anywhere else in the game.

You can recover the science from Kerbin by launching a small rocket to land there, pick up science, and recover the vessel. It takes a lot of them to land in every biome, of course. Kerbin has oceans, so you can also recover science for splashed separately from landed. It is possible to splash down in six different biomes. For the water and shores biomes, this is obvious. You can also splash down in grasslands, badlands, deserts, and tundra by landing in a lake small enough that the game doesn't register it as shores. You can also be landed (not splashed) in the water biome. One way to do this is to make a craft that is dense enough to sink to the bottom of the ocean, which counts as landed. Another is to land at the very edge of one of the ice shelves, which counts as water, as the biome boundary doesn't quite match the physical ice boundary.

Kerbin also has a number of small, special biomes for which it is only possible to be landed. If you are just off the ground, it will count as flying above one of the normal biomes, not the special ones. At the Kerbal Space Center, there are biomes for Administration, Astronaut Complex, Crawlerway, LaunchPad, Mission Control, R&D, Runway, SPH, Tracking Station, and VAB. You can find the boundaries of each by seeing what lights up if you mouse over it from the menu, except that the Crawlerway is between the VAB and LaunchPad. There is also a KSC biome between some of the other mini-biomes. There are other biomes for Desert Launch Site, Dessert Airfield, Woomerang, and Island Airfield, and the easiest way to recover science from these is to enable alternate launch sites so that you can start there. And yes, the game seems conflicted as to whether the sites in the desert are "Desert" or "Dessert". The easiest way to pick up the science from surface features is to have a rover start at Woomerang and drive to them, as both of Kerbin's surface features are nearby. This wiki lists a number of other special biomes on Kerbin, but as far as I can tell, they don't exist anymore.

It is possible on Kerbin to build a base that can refuel, do all of the science, and still get to orbit without staging. Basically, you'll need some vector and/or dart engines and a whole lot of fuel. This can be handy if you want to get the Kerbin science into space for whatever reason. Processing science in a mobile processing lab that is landed on Kerbin reduces the value of the data by 90% as compared to being in orbit.

Laythe

Laythe is the moon that is by far the most similar to Kerbin. Laythe is mostly covered in water, though there is a lot of land scattered about the planet. It is 5/6 of the radius of Kerbin and has 4/5 of the surface gravity, so it is easier to move around on Laythe than on Kerbin. Laythe's atmospheric pressure at sea level is only 3/5 that of Kerbin, but its atmosphere tapers off with altitude much less quickly than Kerbin's, leaving Laythe's atmosphere with a higher pressure than Kerbin's at an altitude of 11-46 km, and several times as dense for much of that stretch. This also makes it more difficult to pick up the science in flight high above Laythe, as its atmosphere gets dense much quicker as you enter the edge than other places with an atmosphere. Laythe's atmosphere only 100 m inside of its boundary has density comparable to Kerbin's atmosphere 13 km in or Eve's 20 km in. That said, your orbital velocity on Laythe will be lower, so burning up isn't a real concern at the edge of its atmosphere.

Laythe is the planet or moon with the most science available in the entire game. While it has only ten biomes, it has an atmosphere, so you can get flying low and flying high in each biome. It also allows you to splash down in nearly all of them. The science from being splashed down means that Laythe has more activity/biome/situation combinations than Mun with its 17 biomes, and only slightly fewer than Kerbin and Duna with 11 and 14, respectively, at least if you restrict the count to normal biomes rather than Kerbin's special ones like KSC. While it has somewhat fewer combinations than Eve, it has much higher science multipliers than any of those other planets or moons. And it has far more combinations than the atmosphereless Tylo and Eeloo with their high multipliers.

Laythe's ten biomes break down as four that are predominantly land, five that are predominantly water, and the shores biome that covers most of the boundary between land and water. Peaks and dunes are the only biomes where you can't splash down, and those are the two biomes for the interior of the land on Laythe. While the poles biome is mostly land (or ice) and the sagen sea biome is mostly water, the boundary between them doesn't quite match the boundary of the ice, so you can use that to splash down at poles or land at the sagen sea. The crater island biome is larger than the island itself, which allows you to splash down at it.

Thus, of Laythe's ten biomes, there are seven where it is easy to land (the four land biomes, shores, shallows and the Sagen Sea) and eight where it is easy to splash down (the five water biomes, shores, crater island, and poles). It is also possible to land at the other three water biomes, but that requires sinking to the bottom of the ocean, which is much more difficult to do.

There are two ways to sink: you can make a ship that is denser than water, or you can thrust downward into the water. The latter can readily be done by a helicopter-like structure that thrusts you downward. Relying on rockets to thrust downward works poorly, as the high pressure prevents rockets from functioning once you get very far below the surface. In order to sink under the water, you need your thrust to exceed the weight of the water that your vehicle displaces minus the actual weight of your vehicle.

The problem with trying to make a ship that is denser than water is that your ship is mostly made out of components that are much less dense. Command pods, probe cores, reaction wheels, service bays, and mining equipment are all much less dense than water and will tend to make you float. Full fuel tanks are slightly less dense than water, but the mass drops as the tank empties while the volume does not, so empty fuel tanks provide tremendous force to help you float. Engines are commonly denser than water. The easiest thing to add if you're just trying to add weight is full ore tanks, as those have about double the density of water. Adding a bunch of I-beams can work, too.

It's quite possible to make a reusable lander on Laythe that jumps around from one biome to another to pick up the science from all of the biomes that you can splash down in, as well as the ones where it is easy to land. You can't refuel while splashed down, but all of the biomes except Degrasse Sea are very near to land, so you can refuel on nearby land, have a short hop into the water to pick up the science while splashed down, and another short hop to return to land and refuel. If you do this, you'll want lots of parachutes so that you don't need to burn a large amount of fuel to touch down. You can also pick up the Degrasse Sea science by splashing down with nearly full fuel as the first place you visit when reaching Laythe from space, thus relying on previous stages to get you there.

Alternatively, you may want to consider making a separate vehicle for each biome where you want to splash down or land. You can use parachutes to land without using very much delta-v, but it's much easier to get back to orbit if you can stage. Still, it's easier to jump around on Laythe than on Tylo, at least if you're willing to revert to a save if you were aiming for land and accidentally end up in the water where you can't refuel. It's easy on Laythe to refuel on land, get to a stable orbit about Laythe, and then land on Laythe again without staging.

If you want that stageless lander to be able to sink to the bottom of Laythe's oceans for the remaining science, that is much, much harder to do. Even if you plan on picking up most of Laythe's science with a lander that jumps around, if you want to sink to the bottom of the oceans, it is much easier to do that with a separate, dedicated lander for each of the three biomes where it is necessary. And if you're going to build a vehicle to land at the bottom of an ocean, you might as well have it also pick up the science for being splashed down in that biome while you are sinking.

You may also want a separate rover to be able to pick up the surface features science, as it is difficult to land precisely in such heavy gravity. If you do build such a rover, beware that rover wheels have a much lower temperature threhold of 1200 K than many other parts, so you'll need to burn retrograde or completely shield them from the atmosphere as you descent to prevent the wheels from burning up. Furthermore, in Laythe's environment of heavy gravity and steep hills, many rover designs will be unable to go where you want to go. My solution to this is to make the rover itself the final stage of a vehicle that can shed all other engines and fuel tanks to drop weight after landing.

Reaching Laythe doesn't necessarily take very much delta-v. You'll first need to get into an encounter with Jool, which takes about 2000 delta-v from a low orbit of Kerbin. Once you're just inside of Jool's sphere of influence, do a relatively modest burn so that your projected orbit about Jool is roughly tangent to Laythe's and timed such that Laythe will be there at the same time that you are and going in the same direction. Laythe travels at a little over 3200 m/s relative to Jool, so if done properly, you can enter Laythe's sphere of influence while going somewhat over 5000 m/s relative to Jool, but only about 2000 m/s relative to Laythe. With a low periapsis, that will be about 3000 m/s relative to Laythe at periapsis. From there, you can burn several hundred delta-v to get into a suitable orbit, or even use aerobraking to land without a further burn, at least if you have a suitable heat shield.

Tylo

Of all of the places that you can land, Tylo just might be the most difficult. Its surface gravity of 7.85 m/s^2 is nearly three times that of Moho, the next strongest to lack an atmosphere. Its surface gravity is essentially the same as Jool and Laythe and less than Kerbin or Eve, but with no atmosphere, you can't rely on parachutes or even some modest aerobraking to save fuel on the landing. You're probably going to hit the ground pretty hard at some point, so it can help a lot to have enough lander legs for your vehicle to hit at 12 m/s or so without anything blowing up.

Tylo has nine biomes, and is one of the few places to have no polar biome. It has four large, named craters as biomes, with the other biomes scattered all over the planet. The mara biome is the large, black spots that are visible from space. The minor craters are also mostly visible from space, though without consulting KerbNet, it isn't always clear which craters are officially minor craters and which are just spots on the planet but not the minor craters biome.

It is probably possible to have a vehicle refuel on the ground, get to a stable orbit around Tylo, and then land without docking to refuel in space. But it's difficult to do so, and I haven't done it. If you want a reusable vehicle that jumps from one biome to another to pick up all of the science, it is much easier to do this with a vehicle only capable of making much shorter hops, such as 100 km at a time, as this requires far less fuel. A vehicle with high enough delta-v on a single stage to get to orbit and then land without refueling is going to have a low enough thrust to weight ratio to increase the amount of delta-v needed to get to orbit as compared to what you could do with a lighter vehicle. Expect to need something over 2400 m/s of delta-v to get to orbit with such a heavy vehicle, and then more than that to land safely from orbit.

Tylo's biomes are bunched together such that the four large craters come as two pairs that are near each other, and all other biomes are available near at least one of the large craters. As such, most of your hops going from one biome to another can be short. You can, of course, do a very long jump from one biome to another by splitting it into several shorter hops and refueling after each.

It is doable to have a reusable vehicle that jumps around on Tylo to pick up all of the science, then gets back to space. You'll need mining equipment to be able to refuel yourself after every stop, of course. Picking up the surface features with the same vehicle could be very difficult, however, as it is quite difficult to land precisely in Tylo's high gravity. If you rely on wheels to drive to surface features, adding massive amounts of weight for the wheels and batteries will make flying around much harder, or having few wheels will mean that you can't ascend even modest slopes with such a heavy vehicle. The Tylo light stones can be picked up by a kerbal, and you can easily find the other two surface features very near each other to pick them both up with a single rover that doesn't need to fly.

If you look only at thrust to weight ratio and specific impulse, then rhino engines are by far the best choice for a vehicle to hop around on Tylo. The problem is that they are huge, which is an issue for several reasons. First is discreteness: at 2000 kN per engine, just one rhino engine means you're going to need quite a large vehicle. Adding more than one makes your vehicle even larger. Second is landing difficulties. A rhino engine blows up if it hits the ground at above 7 m/s, which will probably happen on Tylo if you don't touch down exclusively on lander legs. The problem is that those lander legs are much, much shorter than the rhino engine. Third is if you want a Kerbal to get out and go anywhere, he's going to need ladders to return to his pod, as Tylo's gravity is much stronger than a jetpack thrust. These factors make designing a Tylo lander (or any other lander) around rhino engines awkward.

If you want to use engines that lander legs can reach past, then your best options are vectors, darts, and poodles. Darts would be the best of the three except for their lack of gimbal, which can be awkward when you're going to need a huge vehicle and trying to cut weight. Vectors are physically compact, but at 1000 kN per engine, do give you something of a discreteness issue in design. You can also use a mix of a single vector for its gimbal plus however many darts you want.

Because of the difficulty of jumping around on Tylo, it is reasonable to consider having smaller, single use vehicles, with one to aim for each biome. Or perhaps you want one vehicle to land in two or three nearby biomes before returning to orbit, which would allow you to get away with fewer landers. Staging allows you to have a much smaller vehicle get back to orbit with your science. There are reasonable choices to be made here, and Tylo is large enough that refueling and jumping around is much more difficult than on the smaller moons and planets.

It doesn't really take that much delta-v to reach orbit around Tylo if you do it properly. You'll first need to get into an encounter with Jool, which takes about 2000 delta-v from a low orbit of Kerbin. Once you're just inside of Jool's sphere of influence, do a relatively modest burn so that your projected orbit about Jool is roughly tangent to Tylo's and timed such that Tylo will be there at the same time that you are and going in the same direction. Tylo travels at a little over 2000 m/s relative to Jool, so if done properly, you can enter Tylo's sphere of influence while going over 3000 m/s relative to Jool, but only a little over 1000 m/s relative to Tylo. With a good approach angle, a burn of several hundred delta-v at periapsis can get you into a stable orbit that isn't unduly high. You'll still want to have about 3000 m/s of delta-v remaining to land on Tylo from a low orbit, however.

Eve

As the hardest place to land, Eve is one of the game's ultimate challenges. As compared to Kerbin, it has 4/3 the radius, 1.7 times the surface gravity, and 5 times the air pressure at sea level. It is readily possible to get to orbit in a single stage from anywhere else that you can land except for Eve, where it will necessarily take several stages, if you can do it at all. There are several ways that this makes Eve unique, some of which might not be obvious.

First, if you've ever turned on 4x physics warp while on the ground, you may have seen your vehicle spontaneously explode when it was previously stable, or at least careen around worryingly. The problem is that the game's physics computations aren't continuous, but done at discrete times, and if something is accelerating too fast, it can push parts too far into each other and then things explode. The implicit acceleration of Eve's surface gravity can do that even at 1x physics warp. You can partially correct for it by reducing the maximum physics time step in the main menu options (not available once in the game proper) from the default of 0.04 seconds to 0.03, but physics on Eve is still going to be wonky. And, of course, actually using physics warp when on or near Eve is just asking for your ship to spontaneously explode.

You might expect that helicopters would work well near Eve's surface due to its dense atmosphere. And while they should work well in theory, having a lot of small parts moving at high speeds near each other is a pretty good way to get Eve's wonky physics to cause things to explode. So while a helicopter might work how you hoped, it also might just explode the moment you touch the ground, if not sooner.

Second, Eve's high air pressure greatly restricts which engines will work near its surface. Most rocket engines normally have a specific impulse of around 300. At sea level on Eve, the highest specific impulse in the game is a dart engine at 230. Next highest is a vector or mammoth at 193. The only other engines in the game that can offer half the thrust that they do in a vacuum are the kodiak and mastodon, and even they barely offer half. As such, if you're trying to take off from Eve, there is no point in using any rocket engines other than a dart or vector while in its lower atmosphere. You can still use other engines once you get into Eve's upper atmosphere, with normal lower stage engines becoming sensible by an altitude of 15 km and all upper stage engines being fine to use by about 30 km. Remember that you still need a high thrust to weight ratio to get to orbit on Eve, so nerv engines are still not going to be useful, though small engines such as a twitch, cub, spark, or terrier could be useful for your final stages to get to orbit.

Third, parachutes work extremely well on Eve. On Duna and Laythe, there is some question as to how much you want to rely on parachutes as opposed to burning retrograde. On Eve, there is no question. You want to use parachutes. Furthermore, you want to use normal parachutes, not drogues. Drogue parachutes are normally used elsewhere to ensure that you slow down enough for normal parachutes to open before you hit the ground. Eve's atmosphere will take care of that for you on its own. Even at the highest peak on Eve, it has about 1.5 times the air pressure of Kerbin at sea level. So bring however many Mk2-R Radial-Mount Parachutes you think you need, but skip the drogue parachutes.

That said, you might want to open your parachutes later on Eve than you normally would. It can take a long time to fall through Eve's lower atmosphere, and parachutes make it take longer still. Furthermore, if you open parachutes too high when safe, falling further into Eve's thickening atmosphere can tear the parachutes off. If you wait until you are several km above the ground to open parachutes, you'll be going slowly enough to prevent that.

Fourth, burning up in Eve's atmosphere is a major concern. You can readily burn up in other atmospheres, though on Duna, hitting the ground before your parachutes open is a bigger concern than burning up. On Kerbin or Laythe, so long as you don't have any fragile parts with a temperature tolerance below 2000 K exposed, from a low orbit, you can burn retrograde just enough to get your periapsis into the mid-atmosphere, and then rely on aerobraking to put you on the ground without any real risk of burning up. If you try that on Eve, you'll go hurtling into the mid atmosphere at over 3000 m/s. If you're still even going 1500 m/s once you reach the thicker part of the atmosphere, that will cause parts with a 2000 K temperature threshold to burn up.

Realistically, to get from a low orbit around Eve to on the ground without heat shields, you're going to need about 2000 m/s of delta-v worth of retrograde burns. As you can readily get from a low orbit about Kerbin to a low orbit about Eve in only about 3000 m/s of delta-v, the retrograde burn approach is viable. While harder to design, if you can use heat shields to cover your entire lander vehicle without flipping over, that can save you about half of your launch weight, and thus a lot of funds in career mode.

Landing on Eve by using a retrograde burn to slow down without heat shields isn't one of the deep space burns where you can take a long time. You start at about 3200 m/s from orbit, and Eve's gravity will try to speed you up as you drop, so you need enough thrust to provide considerable acceleration, such as 15 m/s^2. In order to keep your rocket engines from blowing up as you descend, you need to get your velocity relative to the surface below about 1500 m/s before you reach 50 km of altitude. Eve's atmosphere becomes denser very quickly as you descend between 50 km and 40 km, so that's probably where you'll explode if you're going to do so. Eve's atmosphere actually has a hole of sorts, in that at 36 km of altitude, it has only about half of the density of an altitude of 42 km. If you want to land with something more fragile exposed, such as rover wheels, you'll need to bring the velocity down considerably further yet via longer and stronger retrograde burns.

Fifth, the goal of a rocket taking off from Eve is only to get to a stable orbit around Eve. Trying to have that rocket get back to Kerbin is a huge waste. It is far better to get your small payload into a low, stable orbit, then have another vehicle that didn't need to burn all of that fuel to take off from Eve's surface pick up your kerbals and data.

Sixth, it is critically important to drop all possible weight before taking off. On Laythe or Duna, you may want to repack parachutes and to reuse them. If you try that on Eve, you're not getting to orbit. You want to stage something to disconnect any parachutes that were used to land before taking off. Do the same for your lander legs, too. Any science equipment other than a place to store the results should also be dropped. As usual, struts connecting different stages should always go from the earlier stage to the later one so that the entire strut is discarded when you stage the earlier one. Even equipment to generate and store electricity should mostly be dropped, as if you run out of electricity while in a stable orbit around Eve, that is a success. The payload for your final stage should consist only of parts to store data and/or carry kerbals.

Eve has thirteen biomes. Mining the game's files shows that there should be fifteen biomes, but two of them do not exist. There is a lake that counts as foothills, which is presumed to be intended as Akatsuki Lake. There are also several craters that count as impact ejecta, which are assumed to be intended as the craters biome. There is a mod to change these to what people think are their intended biomes. In the unmodded game, however, the Craters and Akatsuki Lake biomes do not exist, which leaves thirteen.

Of the thirteen biomes, seven are largely intended as land biomes and four as water. The shallows biome is largely for the boundary between them, and the poles biome is about latitude and does not care about elevation. The four water biomes include three large, named bodies of water: Crater Lake, Western Sea, and Eastern Sea. All other bodies of water are Explodium Sea. The shallows biome is largely the boundary between Explodium Sea and land. There are five elevation-based land biomes: lowlands, midlands, highlands, foothills, and peaks. The impact ejecta biome is for the perimeter of various craters, and in some cases, the entire craters themselves. The Olympus biome is by far the hardest to find, and consists only of two particularly tall mountain peaks that are right next to each other.

Because the boundaries of biomes are imprecise, it is possible to land in any of the water biomes, and without having to sink to the bottom of an ocean. It is likewise possible to splash down at lowlands and impact ejecta. It is even possible to splash down at foothills in the lake that is probably intended to be Akatsuki Lake.

Unlike every other planet in the game where you can land, it isn't really practical to have a reusable vehicle that jumps from biome to biome on Eve. In order to recover the science from being landed or splashed down at a particular biome, you're going to either land in that biome from space or else land nearby and drive a rover there. If you want to recover data back on Kerbin, a rover has no hope of getting back to space, so you'll need to transfer that data to another vehicle that can.

If you want to recover all of the science data from Eve, that likely means that you need to land in some very precise locations. Getting the data for splashed at lowlands or landed (not splashed) in the various lakes requires landing in one of various small, narrow strips. Trying to get that in a single attempt by eyeballing it doesn't have much hope of working. What can work is to get on the right line, so that if you start your retrograde burn from space at the right time, you'll land exactly where you need to. Make a maneuver node of a decent guess of where you should start the retrograde burn, then save your game. Start your retrograde burn at the node and see if you went too far or not far enough. Then reload your saved game and try starting your retrograde burn several seconds before or after the node. Don't move the node, as you can't do that precisely enough.

Don't actually burn in the direction of the node. You want to burn retrograde relative to the surface all the way down. The node is just to mark a particular spot in space, and you can cancel the node as soon as you start your burn. This allows you to say, oops, I started my burn too late. Let's start 5 seconds earlier and try again. Nope, that was too soon. Let's try starting the burn 3 seconds before the node and try again. And keep going until you find just the right time to land where you need to. This trick works elsewhere in the game, too, but everywhere else besides Eve, it's easier to just get kind of close, then do another short burn to get to the right spot.

If you want take off from Eve and reach space, you're going to need a long, narrow rocket to cut through Eve's very thick lower atmosphere. Long, narrow rockets are precisely the sort that tend to fall over when you try to land. You can build out wider scaffolding to help you land, then stage it as you take off. That scaffolding can include everything from lander legs to science equipment to parachutes. Basically, anything that you want to have around in order to help you land but want gone when you take off goes on the outside scaffolding. Remember to put your parachutes well above your center of mass or else they'll flip you over.

Long, narrow rockets are also prone to falling over when they splash down in the water. Lander legs can't help you stay upright in the water. What can is if you put floatation devices in your scaffolding, right at the water level. The idea is that when an item is underwater, the downward force due to gravity is essentially the weight of the object minus the weight of the water that it has displaced. For rocket parts that have large volume but low mass, that means a strong upward force. The game doesn't have dedicated floatation devices, but service bays and large reaction wheels can fill this role nicely. Empty tanks of rocket fuel can do so, as well.

The idea is that if your rocket starts to tilt one way, then your floatation devices on that side get submerged and those on the other get pulled out of the water. That means that you have a strong upward force on the side that you're tilting toward, and a much weaker one on the opposite side. That gives a strong net torque to force you back upright. Most reasonable designs on Kerbin or Laythe will have partially empty fuel tanks do this for you automatically. On Eve, you want to be able to stay upright even after you've discarded all empty fuel tanks, as you want all fuel tanks on your vehicle to be completely full when you take off.

If you were landed on Eve, then as soon as you take off, you need to get pointed directly up immediately. If you don't, then you're about to flip over. This shouldn't be a concern if you had splashed down in the water, as that should keep you pointed directly up. As you ascend, you have to be careful not to go too fast, lest your rocket become unstable and flip over. A long, narrow rocket with many parts chained together and no struts is very vulnerable to wobbling back and forth so that the rocket at the bottom isn't pointed directly at the center of mass. But you don't want to go too slow, as that would mean burning a lot of fuel to not get very far. Keeping your thrust to weight ratio between about 1.3 and 1.4 seems to work well.

I don't recommend even starting your gravity turn until you reach around 40-45 km of altitude. Until then, trying to turn by several degrees away from prograde will threaten to flip you over. You could start your gravity turn sooner if going slower, but that would mean that you wasted a lot of fuel by staying in Eve's lower atmosphere much longer than necessary, and that is worse than starting your gravity turn later. Eve's atmosphere tapers off rapidly between 40 and 50 km of altitude, so that by 50 km, you can point any which direction without any fear of flipping over. By the time you do reach 50 km, you'd like to have enough upward velocity to get you out of Eve's atmosphere entirely, and just need to add enough horizontal velocity to stay out before you come tumbling down.

If done efficiently, a rocket that would have under 8000 m/s of delta-v in a vacuum can go from splashed down at Eve to a stable orbit. It's nice to have a little more than that so that you don't cut it too close and barely fail. If used inefficiently, you might need a lot more delta-v than that. If you almost escape but come up a few hundred m/s short, you may be able to salvage a manned mission by having your kerbal get out of his pod, take the data from wherever it is stored, and use his EVA jetpack to provide that last few hundred m/s of delta-v.

If you want to land a rover on Eve to get the surface features, there are some complications. One is that rover wheels explode at 1200 K rather than 2000 K, which means you'll need a stronger retrograde burn to get them down to the surface. Another is that Eve's strong gravity means you'll need a very high wheel to mass ratio to do much. My own Eve rover with just over 0.5 tons per TR-2L wheel is able to go straight up slopes of up to 22 degrees, which is ample mobility for a planet as flat as Eve. While Eve does have some slopes in excess of 30 degrees near its mountain peaks proper (a small subset of the peaks biome), most of the planet is close to level, with a slope under 10 degrees.

But the real complication is trying to hold still in order to measure the surface feature. Eve's strong gravity will try very hard to make you slide around, and it doesn't take much of a twitch for the game to decide to cancel a scan because the vehicle moved. You can try tinkering with the advanced tweakables to try to get them to hold your vehicle still. But ultimately, you're probably going to have to move around a lot to find just the right location where the game won't decide to cancel a scan on account of movement.

Jool

Jool is by far the largest planet, but its surface gravity isn't outlandish, as it is no more than Laythe or Tylo. As it is a gas giant, you cannot land there, and will die if you try to do so. Jool has no biomes and no landed or splashed situation, so you can recover all science available from it from four points for the four situations: high in space, low in space, high flight, and low flight. Without biomes, picking up the science data in space above Jool is trivial.

The problem on Jool is that it is so large that its gravity from a given distance is quite strong, which means that as you get close, you'll be going very fast. If you head straight to Jool from where you enter its sphere of influence, you'll probably be going about 10000 m/s when you enter the top of its atmosphere at an altitude of 200 km. Even a stable orbit can have a speed at periapsis of about 9500 m/s. A perfectly executed gravity assist at Laythe, the moon nearest to Jool, can only take about 1000 m/s off of the speed at which you enter Jool's atmosphere. Even a lengthy, retrograde burn in space to bring you into a low, circular orbit just outside of Jool's atmosphere will still leave you traveling at about 6750 m/s.

The problem is that entering an atmosphere at that kind of velocity is a quick way to explode. Recall that thermal heating from atmospheric entry is roughly proportional to the square of your speed relative to the surface. If you come in at 10000 m/s, normal parts will reach 2000 K and explode about 5 km into the top of the atmosphere, where it is still very thin. A kerbal going on EVA will explode less than 2 km in. That does make it possible to pick up the science from high flight while just barely grazing the atmosphere--and still having enough energy to leave Jool's sphere of influence and head back to Kerbin. So while picking up the science from in flight high above Jool isn't that hard, it is harder than anywhere else in the game.

The real challenge of Jool is in getting the science data from its lower atmosphere. That means you're going to have to go deep into Jool's atmosphere and survive. And that, of course, means massively slowing down. It will help some that Jool rotates very quickly, with a surface velocity relative to orbit of about 1047 m/s at its equator. That means that a low, stable orbit can be going under 5700 m/s relative to Jool's surface. That's still very fast, but it's a lot less daunting than 10000 m/s.

In order to slow down enough to actually be safe, you're going to need either a very large retrograde burn or else some very good heat shielding. To get back to 6750 m/s for a low orbit, it's going to take a rather large vehicle to have enough delta-v to get out, which can make using heat shields awkward. Being able to slow down by several thousand m/s quickly will add several thousand delta-v to your requirement to safely descend, which is also awkward. And that's why getting to Jool's lower atmosphere and back is hard.

Even if you do try to use heat shields and aerobraking to slow down, they don't really slow you down that much. Even at an altitude of 100 km, a full 20 km into Jool's lower atmosphere, its atmospheric density is only about 1/5 that of Kerbin at sea level. That means that even with heat shields, you're going to need a very large retrograde burn just to stop before you start going up again.

To make your ascent easier, it's critical to bring a minimal payload back out. There is no reason to bring more than one kerbal. If you do bring a kerbal that you want to get out, make sure it's a pilot so that you don't also need a probe core. You may even wish to bring an EAS-1 external command seat in order to reduce the mass of housing the kerbal whom you wish to extract. You cannot do a crew report from the external command seat, but you can bring a different crew module, do the crew report, transfer to the external command seat, and then drop the larger crew module to start your ascent. Obviously, any science equipment should also be dropped before you start to ascend.

Jool's upper atmosphere isn't very dense, like the other upper atmospheres in the game. As you aren't trying to land, but only to get the science from Jool's lower atmosphere, you need not descend very far into the lower atmosphere. The boundary is at an altitude of 120 km, and at that height, Jool's atmosphere only has about 1/4 of the pressure of Kerbin's at sea level. Parachutes also won't fully deploy until much lower, which makes them fairly useless.

As with Eve, when trying to escape Jool's lower atmosphere, the goal is only to get to a low, stable orbit about Jool. Don't try to bring enough thrust to actually get back to Kerbin. Rather, have another vehicle that can meet the one that escaped Jool, pick up the science and perhaps kerbal, and have that other vehicle take it back to Kerbin.

The Sun

You can't land on the Sun, and you can't even get particularly close to it without burning up. You can, however, recover the science from space high above it and near it. Getting to space high above the sun is quite easy: just get out of Kerbin's sphere of influence and you're there. Getting near the sun is harder, as you have to be within a million km. This isn't particularly hard to do: just zip out of Kerbin's sphere of influence in the opposite direction from what Kerbin is traveling at a high enough speed to get your periapsis just below the threshold. Wait until you're at periapsis and pick up the science. Wait until you're back at apoapsis and thrust to get back to Kerbin.

Contracts

If you play in career mode, you'll need to earn funds in order to build your rockets. That mostly means doing contracts to earn money. While there are many types of contracts, some are far more lucrative than others. I'd like to highlight the most lucrative types of contracts, as those are the ones you'll probably want to focus on.

Even so, there is the question of how long you actually want to do contracts, even in career mode. At the Administration Building, you can enable "aggressive negotiation" from the list of strategies, which will give you a discount on rockets that you build. If you build a very expensive rocket, then immediately recover it on the launch price, you get refunded the full, non-discounted price tag. That allows you to pocket the difference, that is, the size of your discount. Once you build up enough reputation and funds to get started on this, you can just do this repeatedly for effectively infinite funds.

Part testing

In the very early game, part testing is the most useful type of contract. The idea is that you haul a particular part to some particular situation, such as an altitude and speed in particular ranges. Then you stage to enable the part, which completes the contract. This can be lucrative when all you need to do is launch a small rocket to an altitude of 20 km, stage, and return to the space center.

It doesn't take that long before part testing contracts want you to take parts much further away. Once they ask you to go to Kerbin's moons, or worse, other planets, the contracts become far less interesting, and other types of contracts become relatively more lucrative.

Tourists

Early on, your main source of revenue is tourist contracts. Tourists will pay to go to various places, then return to Kerbin. Tourists don't have any kerbonaut skills, but you can efficiently pack them into Mk1 Crew Cabins or a Mk3 Passenger Module. You'll generally want to take several tourists on a single trip, often from different contracts, even. You don't have to finish all of a tourist's desired destinations in a single trip, and can have the tourist land on Kerbin, then take off in another vehicle. A tourist contract is completed when all tourists have gone to all desired locations and returned to Kerbin.

Tourists will only ask to be flown to places that you've previously gone. At the very start, that means only around Kerbin. Soon after that, once you reach Kerbin's moons, tourists will want to go there, too. Taking tourists to Kerbin's moons or into orbit about the Sun (just outside of Kerbin's sphere of influence) isn't difficult and can be quite lucrative. Once you've reached the sphere of influence of other planets, tourists will want to go there, too, and that takes much longer for little gain, so you'll probably want to stop doing tourist contracts. Especially once tourists start demanding to land on Eve and then return to Kerbin, you don't want to take a contract that requires that.

Rescue kerbals

Some contracts will say that a kerbal has been stranded and ask you to go rescue him and return him to Kerbin. The kerbal will generally be in just a command pod with no resources at all. Some contracts only ask that you return the kerbal back to Kerbin, while others want you to return his command pod as well. For the latter, you'll need an Advanced Grabbing Unit.

The value of a kerbal rescue contract is not just the funds that you receive, but also that you get to keep the kerbal. Once you've hired a lot of kerbals for your program, each additional one can cost several hundred thousand funds, or even millions of funds. Being able to get a kerbal as a contract reward can thus be quite valuable.

As with tourists, kerbals will only get lost in places that you've been. You may want to avoid entering the sphere of influence of other planets until you've accumulated however many kerbals you want. Having kerbals get stranded in faraway places doesn't kill off kerbal rescue missions completely the way that it does with tourist missions, however. A single kerbal is stranded in one particular place, while the several tourists on a contract might collectively ask to go to ten different places. That one place might by random chance happen to be nearby, while tourist contracts are far more likely to have at least one place be somewhere that makes the whole contract a waste of money.

Transmit science

Some contracts ask you to transmit science from a particular planet or moon or from space around it. These are generally quick and easy contracts to finish. You have various probes or stations or whatever have equipment on board that can do some experiment, and put those landed on and in orbit around all available planets and moons. When you get the contract, you switch to the probe, run an experiment, transmit the data, and complete the contract.

Mine ore

Some contracts ask you to mine ore from a particular body. In some cases, they ask you to then transport the ore to somewhere else. The amount of ore is generally under 3000 units. The contracts to mine ore are readily handled by landing a base on every available planet and moon, then switching to it to mine ore when you draw such a contract. Bases intended for this should generally have at least 3000 units of ore storage (likely as two Large Holding Tanks for simplicity.

If the contract asks you to transport the ore, the game doesn't actually check whether it is the same ore at the ultimate destination that you mined. For example, if a contract asks you to mine ore from Minmus and put it in orbit around Kerbin, it works to mine ore on Minmus, then switch to a station orbiting Kerbin with ore onboard. You can thus plan ahead by putting space stations everywhere with 3000 ore on board to complete such contracts.

Fake forces

There are some situations in physics where it can simplify matters to use an accelerating reference frame and treat the way in which the acceleration is happening as a force on everything else. There are several such situations that can be useful ways to think about particular situations in the game. That probably doesn't make very much sense in the abstract, so let's get on with the examples.

Tidal forces

You're probably aware that the Earth's tides are mostly caused by the Moon. Have you ever stopped to think about why there are slightly less than two high tides and two low tides per day, even though there is only one Moon?

Suppose that there are three bodies: A, B, and C. B and C are much closer to each other than either of them are to A. A is very large, such as a planet, so it exerts a considerable gravitational pull. We could compute the exact effect of gravity of A on B and C separately. But we could also think of A as exerting a tidal force on C relative to B, with the force consisting of the difference between the effects of gravity of A on B and C.

That might not make much sense in the abstract, so let's give an example. If A is the Moon, B is Earth, and C is water on the surface of Earth, then the tidal force caused by the Moon can push the water closer to Earth or pull it away from Earth. For water between Earth and the Moon, the Moon pulls harder on the water than it does on Earth, so it effectively pulls the water away from Earth. That's how you get one high tide. For water on the opposite side of Earth, the Moon pulls on Earth harder than it pulls on the water, so it effectively pulls the Earth away from the water. That's how you get a high tide on the side opposite the Moon. For water along the edge so that it is about as far from the Moon as the center of Earth is, the Moon pulls both the water and Earth about as hard. But it doesn't quite pull them in the same direction, and tends to pull them toward each other. That's how you get a low tide--and two of them, on opposite sides.

In situations where both A and B are celestial bodies, the game's spheres of influence system wipes out any tidal forces. However, if B and C are two vehicles that you wish to dock in space, it can be useful to think of the planet or moon that they are orbiting as being A and exerting a tidal force on them. If you design a rectangular coordinate system such that B is at the origin and the z-axis is directly away from the center of A, then the tidal force pulls C toward B along the x- and y-axes, and away from B on the z-axis. The former typically won't cause a collision, as it's really just curving their orbits and doesn't systematically move them closer to each other. But that tidal forces pull the two objects toward each other in two axes and away in the third can explain why it looks like it's moving your target off to the side in some weird direction.

The magnitude of the tidal force matters a lot, though, as acceleration of 0.1 m/s^2 relative to your target can make it hard to dock, but acceleration of 0.0001 m/s^2 can readily be ignored. The magnitude of a tidal force is proportional to (distance between B and C) / (distance between A and B)^3. You could replace the distance between A and B by the distance between A and C, as the distances are assumed to be similar. It only makes sense to think of this as a tidal force when B and C are much closer to each other than either of them are to A.

One key thing to notice is that the magnitude of tidal forces is proportional to the distance between your two objects. If you're trying to have one vehicle dock with another and they're very close to each other, tidal forces can be very small. But if they start out very far away, tidal forces can be large enough to make the usual docking approach of burning target retrograde and then burning protarget not work very well.

It's also very important to notice that the magnitude of a tidal force is inversely proportional to the cube of the distance from the object causing it. This is the distance to the center of the object, but still, that power of 3 factor makes a huge difference. Getting twice as far away from the object reduces the tidal forces by a factor of 8. That means that you don't have to get nearly as close before you can start burning target retrograde and then burning protarget and have it actually work. When in low orbit about a celestial body--any celestial body, really--tidal forces mean that you have to get pretty close. When in a much higher orbit, docking is far more forgiving. For example, if you're trying to dock in a low orbit around Minmus only 10 km above sea level, and you start out 20 km away from your target, the strong tidal forces will make it not work very well, and might even crash you into Minmus. If you're at 640 km above the surface of Minmus, then you're ten times as far away from the moon's center, making the tidal forces only 0.1% as strong as before. From there, you could just get within 100 km and start to target retrograde then protarget burns and it would work fine.

The upshot is that docking high in space is considerably easier than docking while in a very low orbit, as the tidal forces that throw you off are much weaker there. If you're having trouble docking, try doing it in a very high orbit at first. That doesn't mean that you can't dock in a low orbit. You absolutely can. It's just harder.

Centripetal forces

A centripetal force, sometimes mistakenly called a centrifugal force, is a force that keeps a rotating object moving on a circle. For example, if you tie a weight to one end of a rope, hold the other end yourself, and spin around in a circle, the weight will rotate in a circle around you. If you let go of the rope, the weight would fly away from you. The rope is always pulling the weight toward you, but the centripetal force due to spinning balances that to keep the weight at a fixed distance from you as it moves in a circle.

The acceleration due to a centripetal force can be computed as a = rw^2, where a is acceleration, r is the radius of the circle, and w is the angular velocity. One can also substitute v = rw, where v is your speed, to get the form that I think is more helpful: a = v^2/r. Thus, the acceleration due to a centripetal force is proportional to the square of your speed.

There are two situations in the game where I find it helpful to think of something as being a centripetal force. The first is a fairly obvious one: gravity when you're in a circular orbit. In a stable circular orbit, if g is the acceleration due to gravity, then we have g = v^2/r as above. The reason I find this useful is when considering what happens when you change v, such as to slow down so that you can land.

Suppose that you reduce your velocity by 10%. In order to stay on a circular orbit, the centripetal force to keep you stable would be (.9v)^2/r, or .81 times what it was before. Burning retrograde doesn't actually change the force of gravity, of course, at least until you actually get meaningfully close to the planet you're orbiting. But if a force of .81 times actual gravity would be enough to keep you in a stable, circular orbit, then you actually accelerate vertically at .19 times the acceleration due to gravity. More generally, if you change your speed from v to kv for some constant k, your downward vertical acceleration due to gravity will be (1-k^2)g. This also works to give your upward acceleration if k > 1. Your speed here when not on a circular orbit is only the horizontal component, not the vertical component. Even so, it can give you some intuition about how fast you should expect to descend as you try to land.

The other situation where centripetal forces are useful is much less obvious: staging radially attached objects. You've probably run into a situation where you staged radially attached fuel tanks, only for them to immediately crash back into your rocket and blow it up. I mentioned earlier that the main fix for that is to be accelerating directly prograde when you stage them. If in an atmosphere, it must be prograde relative to the surface, not relative to orbit.

But while that mostly fixes the problem, it doesn't completely fix it. For one thing, the force applied by the radial coupler might not be aimed directly at the center of mass of the component to stage. The ejection force thus causes a net torque on the debris, causing it to spin. One end rotates away from your rocket, but the other rotates into your rocket, causing the collision. This can also happen if you have insufficient struts so that the debris was rotating some (as part of wobbling back and forth) before it was staged.

Another problem is that when your rocket is moving fast, it forces air out of the way, creating a partial vacuum behind it. Staged parts are sucked into the vacuum as they fall relative to your rocket. That pulls the bottom of the debris toward the space below your rocket, which can cause the top of the debris to crash into your rocket itself. This is especially a problem on Eve, where you may be going at relatively high speeds through a dense portion of the atmosphere during your ascent.

Often, the real fix for this is better rocket design, especially if the problem is a lack of struts. But you may have a vehicle that has reached its destination, and is unable to complete its mission because it keeps blowing up when taking off from Eve or Laythe or whatever. In that case, you can sometimes fix the problem by rotating your rocket before staying the parts. Make the rocket rotate in the roll direction (Q or E for the default controls) so that there is some centripetal force trying to pull outer components away, but balanced by the rocket's structure holding the debris in place as the rocket rotates. When you stage, the rocket's structure holding the debris in place is removed, so that the centripetal force of rotation can pull it away from your remaining rocket. Sometimes that will give you enough of an extra cushion to avoid the collision and complete a mission that otherwise seemed doomed.

Coriolis forces

If you throw a ball straight up on a windless day, where will it land? The obvious answer is, right where you threw it from. And given the strength of your arm, that will probably be correct to within measurement error. But suppose that you could fire a projectile straight up at a much higher velocity, though still below escape velocity, from a moon that has no atmosphere. Where will it land?

One good objection that I hope you raise is, is that "straight up" relative to the surface or relative to orbit? If it's relative to orbit, then the answer is pretty obvious: it will land to the west of where you threw it from. You throw the ball up, the moon rotates eastward while the ball is off the ground, and then it lands to the west because the moon moved.

But what if it is relative to the surface? In that case, I think it is helpful to imagine throwing the ball up very, very high. Imagine that it takes several days to land. It does sort of orbit, going nearly halfway around the moon, which is the most possible for such an orbit. But if the moon does more than half of a rotation, then it probably isn't going to land exactly where it was thrown from. It will again land to the west of there.

One way to think of this westward drift is as being the product of Coriolis forces. Traveling in any direction relative to the surface implicitly causes a force relative to the surface, with the direction of the force rotated 90 degrees from the direction of travel. Traveling up implicitly causes a force to the west, while traveling down causes a force to the east. These cancel off by the time you land, so that you're again going directly vertical, but not before you traveled to the west for a while while in the air.

Coriolis forces apply to horizontal travel, as well. Traveling east causes an upward force, while traveling west causes a downward force. This makes it easier to take off and achieve orbit while traveling east. The other way of thinking of that effect is that while on the surface, you're already traveling east relative to orbit, so it takes less additional delta-v to reach a stable orbit by going east.

It is sometimes said that Coriolis forces cause water to swirl in a particular direction when you flush a toilet. That is wildly false. The Coriolis forces are present, but on such a small scale, are far too weak to matter. Coriolis forces need much larger scales to be meaningful, such as orbiting an entire planet. On Earth, they also cause hurricanes to spin in a particular direction.