Zhetaan

That's correct; all of the anomalies are measured under the condition that periapsis equals zero (and apoapsis is π radians (or 180 degrees); the anomalies all converge there, too). And to answer the unspoken question: if it's a circular orbit, the anomalies don't exist--though the hypothetical orbit described by the mean anomaly describes the actual orbit, so you can use that and simplify calculation immensely. In Kepler's time, orbits were assumed to be circular, so any deviation from circularity was anomalous--hence the term anomaly. I use Character Map if I need it. However, there's no special requirement to use difficult-to-type characters in these equations; I could have solved for the true anomaly as x just as easily as θ. It's simply convention to use Greek letters because of either tradition or a need to use more letters than are available in the Latin alphabet. That being said, the conventions are fairly common, so here's a cheat sheet: ε - Epsilon, used for eccentricity; e is often used instead, but since e is also a mathematical quantity and E is used for eccentric anomaly, it can get confusing, so any time that I calculate eccentric anomaly, I make certain that I use E for the anomaly and ε for the eccentricity. You'll also find ε used for planetaery axial tilt; it's not an issue in KSP but you'll want to know that if you ever try your calculations on real planets. θ - Theta, often used instead of x when the unknown variable is an angle; it's also used for true anomaly since t is almost universally used for time and T is used in astronomy for orbital period. You'll encounter it a lot in place of x in trigonometric functions, and it is used for angular measure in polar coordinates (which use the (r, θ) form instead of the (x, y) of Cartesian coordinates). ν - Nu, an alternative way to show true anomaly. It looks like Latin v in Arial but its actual form is a bit more elaborate (it has serifs and everything!); needless to say, its similarity to Latin v means that it can be mistaken for velocity, so I prefer to use θ. Incidentally, Latin f is yet another way to show true anomaly, but f can also mean frequency, and it is used to denote focal length for a lens--this isn't a concern in KSP, but in the kind of astronomy that requires telescopes, it can be confusing, so again, I prefer θ. π - Pi, and I'm sure you know this one. ω - Omega, used in physics for angular velocity; the difference between this and θ is that θ describes a static angle, whereas ω describes rotational speed (usually in terms of radians per second). It's used in orbital mechanics as the argument of periapsis (the angle between the periapsis and the ascending node). Note that capital omega (Ω) is used for the longitude of the ascending node, so there are two different omega parameters in orbital mechanics. It turns out that there aren't enough letters even with Greek. μ - Mu (pronounced myoo) (or mew, as though it were a kitten), which is used in many different contexts. It is the symbol for the SI prefix micro-, which in astronomy is likely only to arise if, for some reason, you need to describe micro-light-years. Astronomy has to scale colossally, though, generally doesn't bother with prefices, and instead uses scientific notation almost exclusively. You are more likely to encounter μ as the standard gravitational parameter, which is a measure of the gravitational influence of a large body and is actually a very important value to know when calculating orbital period and the like. This parameter first arose as the proportionality constant in the relationship T2 ∝ a3, which you may recognise as Kepler's Third Law (as an aside, the symbol ∝ means is proportional to). When taking the proportionality constant into account in order to make an equation, it becomes T2 = ka3, where T is the orbital period, a is the semi-major axis, and k is constant for all orbits about a given body (but it is different for every body). The constant k relates to μ by this relationship: k is equal to 4π2 / μ. If that seems esoteric then know that the π factor appears because you're chasing around an ellipse; the angular velocity relates to the period because the period is the amount of time it takes to travel 2π radians (one full revolution) around the ellipse. Since the period is squared in the Third Law, the period in terms of angular velocity needs must also be squared: hence, 4π2. A more intuitive way to describe the Third Law is this: (T / 2π)2 = a3 / μ, in which it is more obvious that the entire period factor refers to time per revolution. Correct. Though if you are starting from apoapsis, then it may be simpler to subtract 7000.63 seconds from six hours to get time after apoapsis rather than time before periapsis. This will work around any body, and yes, the orbital period encodes the gravitational relationship between the primary and the orbit in its calculation; that's why an orbit of a given semi-major axis around a given body has the orbital period it does. Furthermore, it's why we need further calculation to locate things on that orbit: any orbit with that SMA about that body will have that orbital period, regardless of its shape, and the need to find the differences that relate to eccentricity is the reason that the concept of orbital anomaly was invented in the first place. However, you won't need the orbital period until you are ready to include the mean orbital motion to get time from the mean anomaly; all ellipses of the same eccentricity are similar, so the angles will be the same in any case. Bear in mind that you must know the eccentricity to get that far, but orbital eccentricity is trivial to calculate, especially if you have Kerbal Engineer to do it for you. However, if not (or if you'd like to do it yourself): ε = (ra - rp) / (ra + rp), where ra and rp are the radii of the apoapsis and periapsis to the centre of mass (meaning the planet's centre if you're orbiting a planet), respectively. Bear in mind that this requires the actual apsides, but KSP displays the altitudes above the surface. You'll need to add the planetary radius to get the correct value, but that radius is available both on the wiki and in the KSP Knowledge Base. For Kerbin, it's 600,000 metres. I think that was all of your questions. In any case, good luck.

I can help you with some of the prediction. If you want to know when you'll be at 90 degrees true anomaly, then you need Kepler's laws; that's non-negotiable. I'll assume that you're starting from a true anomaly of zero; it's one element that is easy enough to see both in KSP's interface and in Kerbal Engineer. True anomaly, θ, is given by the equation: (1 - ε) tan2 (θ / 2) = (1 + ε) tan2 (E / 2) Where E is the eccentric anomaly and ε = .28, the eccentricity. In this case, we know that we want a ninety-degree (or π/2) true anomaly, so this equation is a matter of solving for E. (1 - .28) tan2 (π / 4) = (1 + .28) tan2 (E / 2) --- This is easy enough; tan of π/4 is 1 .72 = 1.28 tan2 (E / 2) .5625 = tan2 (E / 2) .75 = tan (E / 2) .643501 = (E / 2) 1.287 rad = E This is about 73.7 degrees. Once you have E, you need to solve Kepler's Equation for mean anomaly, M: M = E - ε sin E --- This is the easy way to do it; if you were solving for position instead of time, you'd have to solve the transcendental M = 1.287 - .28 sin 1.287 M = 1.287 - .28 (.96) M = 1.287 - .2688 M = 1.0182 rad This is about 58.3 degrees. Mean anomaly is the mean motion times time, and 2π radians divided by the period is the mean motion, n; you mentioned earlier that the period is twelve hours, so I'll use that. Twelve hours is 43,200 seconds, so: 2π / 43,200 = 1.45444 x 10-4 radians per second. 1.0182 rad = 1.45444 x 10-4 s-1 * t 7000.63 seconds = t Your time after periapsis passage at true anomaly of 90 degrees is 7000.63 seconds, or 1 hour, 56 minutes, and 40.63 seconds. The next question is whether you are certain that you want the true anomaly to be ninety degrees. θ of ninety degrees actually gives the location of the latus rectum, which is certainly useful for some purposes, but if you really want the location of the semi-minor axis, then you want E to be ninety degrees, not θ. Of course, that's even easier to solve; you can dispense with the true anomaly completely and can begin with Kepler's Equation. Edit: Oh, why not--let's do it: M = E - ε sin E --- sin of π/2 is 1 M = (π / 2) - .28 M = 1.2908 radians, approximately, or 74.0 degrees 1.2908 = 1.45444 x 10-4 s-1 * t 8874.87 seconds = t This gives a time after periapsis passage of 8874.87 seconds, or 2 hours, 27 minutes, and 54.86 seconds.

Welcome to the forum, @Pryor! Stock KSP doesn't have a speed limit--though in practical terms, the program will crash before you can carry enough rocket fuel to get any appreciable fraction of lightspeed. You'll have to deal with mods. To be honest, what you want is something probably best served by a combination of KSP Interstellar and an outlying-stars pack powered by Kopernicus. KSP doesn't simulate relativity (rockets never normally approach lightspeed) so you're probably out of luck with respect to time dilation. You may want to play a bit with Real Solar System (also powered by Kopernicus) if you want the authentic go-to-α Cen experience, but I don't know whether any RSS-based planet-and-star packs include it.

@Lankspace: Others have covered theory of construction well enough that I don't need to repeat them. In terms of theory of design, however, I can say that the overall goal is to get something into space such that it doesn't: cost too much, blow up on the way there, fall back down later, and fail the mission. Usually for real-life space programs, cost is the deciding factor. There are a lot of missions that don't fly because they cost too much. For KSP, the practical issue of getting something to space--and making it stay in space--intact is more important. The main difference between the two designs you gave as examples involves drag versus thrust: a rocket with boosters has more of both. Sometimes, that's needed, and the reason for that is because getting off the ground requires you to fly in what would otherwise be the most inefficient way possible. I will assume that you know about how to manoeuvre in space. If not, then please accept that you generally want to change your orbit by thrusting in the prograde/retrograde direction, with normal added if you need to change inclination. Radial burns (at right angles to both prograde and normal but meaning roughly toward or away from the planet) are the least efficient because they don't add much useful velocity to your rocket and don't add any inclination at all. There are a couple of very specific use cases for them but normally only as corrective manoeuvres. When you launch, however, your rocket begins by going straight up--which is to say, radial out. Because of both the atmosphere and the gravity, it is necessary to include a radial-out component in your launch burn. Obviously, radial-out keeps you from falling down to the surface, but it also gets you out of the atmosphere, which otherwise parasitically drains prograde velocity. Spaceplanes get this radial-out component from lift, which is what makes spaceplanes potentially so efficient, but wingless rockets cannot take advantage of that. However, with the right rocket design, you can immediately begin adding prograde velocity at launch in such a way that gravity and drag cancel the radial part at the correct rate to match the declining need for radial velocity--that is to say, you want gravity and drag to work against you so that when you don't have any radial velocity left, you don't need it anymore, either. That's the idea behind a gravity turn. Ultimately, your choice for a rocket design is tied to how well it will fly to orbit. 'Well' can be defined as a matter of cost, weight, thrust, or a combination of these and other factors. One thing to remember is that because of the way gravity works, you will only need to provide a specific value of thrust to counter it, so anything above that value is thrust that you can use for other things, such as going to orbit. Side boosters provide that extra thrust (which means, practically, that you can tip the rocket a bit more on your way to orbit), but that also has you going faster in the atmosphere which increases drag and heat and wastes fuel--there's also such a thing as too much thrust. On the other hand, a long inline rocket will fly very well through the atmosphere--provided that it is pointed in the same direction that it flies. Also, with less thrust generally available, a larger proportion of it must be used to counteract gravity. This requires a longer gravity turn and wastes fuel--there's such a thing as too little thrust, as well. You are always going to 'waste' fuel to fight gravity in any surface launch; the object is to find a design that wastes less of it.

Correct. And giving credit where it's due, that is the same thing that @GoatRider said, but with a different mathematical definition. I will caution you that because it is a polar orbit, you will have some inclination with respect to Kerbin; that's unavoidable. However, as I said before, it's probably going to be less than a degree unless you're in a really high orbit.

There is an efficient way to do it without needing to correct inclination. Mainly, you need to understand that the object of a good return is to leave the Mun in a direction that is parallel to the Mun's own retrograde vector. That's easy enough to see when everything is coplanar: burn on the prograde side to raise the apoapsis on the retrograde side so that you leave along a path that ultimately shoots out the back side of the Mun's sphere of influence. There is nuance to that in the form of ejection angles and other tricks, but that's the idea. It can be done in three dimensions as well, but there are, as these things go, fewer solutions. In other words, it will take time. The key is to wait until your polar orbit's axis points through Kerbin. Then eject when your rocket is above the prograde point of the Mun as normal. This will happen twice in any given Mun orbit (of Kerbin--not your rocket's orbit of the Mun). However, this isn't an interplanetary transfer window, either; there's a lot of room for error. Remember that your polar orbit of the Mun is from Kerbin's perspective equal to the Mun's orbit of Kerbin plus minor perturbations: everything is a matter of scale. Your polar orbit of the Mun, if you were to leave the Mun at the exact north pole of its sphere of influence, constitutes an inclination of a bit over eleven degrees with respect to Kerbin. Close polar orbit of the Mun is less than a degree. Imagine that, for example, you wanted to go from Jool to the Mun: that trajectory is essentially the same as going to Kerbin until you get very close to (or even within) Kerbin's sphere of influence. With scale in mind, you can get a satisfactory Mun return from quite a wide selection of axis angles.

Reinstall. To be honest, I have no idea how you managed to so thoroughly corrupt your game; however, I will say that while any part in Gamedata is (probably) going to be found and loaded no matter where it is, the configuration files for those parts also often have defined paths to find the meshes and models such that they need to be in specific directories to load properly. Or, alternatively, they all just expect to find a 'model.mu' in the same directory as the part configuration file, in which case you may have overwritten the model. In short, the lesson is: put the Near Future parts in the Near Future directory, and let the Squad directory be.

Your English is fine. Anyway, you could try a vessel with a cradle in the front that's made of girders, I-beams, or other structural parts (or non-structural parts--you can do it with upward-facing landing legs). These can hold the target vessel and keep it in front while the cradle-vessel takes both back to Kerbin and de-orbits. I don't know whether your vessel can take the impact forces involved in that, but if so, it would get everyone home.

This fits a sort of combination of the above, but you could perhaps try setting up a resonant orbit to ensure that both vessels are on the same side of the planet at atmospheric entry. This would also allow you the flexibility to build a sort of delay-spacing into the flight plan so that the probe doesn't fall behind the orbiter so much as it falls back to the orbiter. This would require keeping everything together for insertion and capture: you'll still want to have a low, almost atmosphere-grazing periapsis, but also to keep a high apoapsis for ease of setting up the atmospheric entry later. Release the probe (if you used decouplers or separators and didn't turn down the decoupler force, you'll have to chase it to keep your velocities matched--consider releasing the probe in a retrograde direction) and at the next periapsis, burn retrograde with the orbiter so that the orbital periods are some simple rational resonance. 7:8 requires less delta-V, but 3:4 requires less time. It's up to you. Let's assume that you decide to use 7:8. This means that the orbital period of the orbiter is one-eighth less than the orbital period of the probe, which is left in the larger orbit. In other words, for every eight orbits of the (inner, thus faster) orbiter, you get seven orbits of the probe to put them both back in the same place (at periapsis). Control the probe and wait for six and one-half orbits: this will put you at the apoapsis, where your tiny amount of delta-V will get the most effect. Assuming that you kept your periapsis low, it won't take much to drop it into the atmosphere, and the total change to orbital period is so small that the orbiter will be literally right above the probe when it interfaces with the atmosphere. Depending on how quickly the probe decelerates, that may mean that your orbiter will move too quickly anyway, thus pulling ahead and leaving communication range too early. In that case you will need to perform the deceleration burn on the five and one-half mark, which will put the orbiter back by an eighth-orbit, which will give you more time to transmit when you get to that point. Of course, if you want finer control over the timing, then you need to span it to take more time so that you can more easily divide the orbit into finer fractions. That would imply resonances of 11:12 or 14:15 or whatever you like. You may need to become very familiar with quicksave.

I can think of two ways: Timing. Follow the entry probe with the insertion-orbiter in a nearly identical track (or it can be exactly identical if you're using aerobraking or aerocapture). This would probably be best done by use of a radial burn after the orbiter burns for a near-but-not-quite-atmospheric interface. There will be drift but you should be able to keep line of sight. However, you may find that you must release the entry probe at a point well after entry to the sphere of influence. Sequence of stage separation. You may have a better time if you decide to capture to a high elliptical orbit, release the entry probe, and then complete your orbit insertion. If you release the insertion stage and make any other manoeuvre, then your orbital tracks will give better-than-half radio coverage for when your entry probe returns. This will also depend on timing and you'll lose some delta-V from keeping the probe attached, but if need be, you can take fuel from the probe--unless you mean to say that the probe is purely kinetic?

Mission Control came out with contracts (and Funds and new Career mode, while old Career mode became Science mode) in v 0.24. The Admin Building came out with strategies in 0.25.

That will cover Duna but will require periodic checking because unless your orbits are absolutely exact, you will eventually lose the network to orbital drift and Ike's hungry maw. You can't get that level of precision (and in fact, just loading the satellite will introduce rounding errors in the numbers used) so you might be better off either having a cluster of satellites closer to Duna (cool, but not realistic--in real life the gravitational interaction would make the orbit terribly unstable), or else a cluster farther out from Duna with an Ike station (or Ike network) to connect to the larger constellation and keep everything in communication.

@Just Jim: I don't know how often you get comments to this effect, but it isn't often enough, so I am going to point out that you have an amazing eye for design. Many people who play this game choose function over form--and admittedly, that's not wrong--but there's a lot to be said for craft that complete missions with style and panache. Assuming that they're not doing so already, Squad ought to put you on redesigning all of the scenario vessels, bases, and so forth to give them the same elegant, polished look that you give to everything in Emiko.

I'm familiar with it; I did read your opening post. But there are plenty of ways to move a rover over water. Or under it; it's not as though your Kerbals mind.

You could try driving. That requires no landing at all, and you did say that this mountain is 'not far' from the launchpad. It also saves you the weight of parachutes and the risk of destroying a wheel or six in either the decoupling or the landing.

@Navel lint: First, welcome to the forum! Second, the others are correct; your engines are 'way too close to the asteroid. The way the game calculates thrust and impingement and all that makes it so that if a part interferes with the engine exhaust, then all of the thrust is cancelled, so indeed you will see zero motion. There's no half-measure where it takes into account cross-section or anything like that. Normally, rocket parts have such low thermal mass that they burn up and thereby get out of the way (this is explosive decoupling if done deliberately), but asteroids have a bit more tolerance. Your design can be improved simply by keeping the drills where they are and moving the engines to the front. Obviously, you'll need to design to avoid burning your solar panels and radiators, and you may need another fuel tank as a spacer to ensure that the exhaust plumes really don't impinge on the asteroid--it's surprising just how long the exhaust plume is. Alternatively, as others have said, you can improve it by keeping the engines where they are and moving the drills and grabber to the front. In that case, you'll need to avoid bumping your solar panels. Personally, I favour puller designs over pusher designs because pullers are easier to correct if you don't aim precisely through the centre of mass of the asteroid. Pushers tend to fall into positive feedback more easily, though that can be corrected by enough RCS nozzles or reaction wheels. I do not, however, like designs that splay the engines because the cosine losses are incredible. I'd do it if it were the only way, but it's not. Straight engines on outriggers are okay if the outriggers can take the strain, but I mostly move Class E asteroids, which makes that impracticable.

Then again, you could be surprised. The first stock Eve SSTO was an entrant into a challenge to see how low in Eve's atmosphere a craft could dip and still return to orbit. It turned out, with the new aero model, that one could go all the way down. Obviously, if the pressure is 50 atm, then there's no hope of getting down to datum and living to return even with a forward glide, but that doesn't mean that there isn't something to learn from the attempt.

Welcome to the forum! The best parts of KSP are made for mathematicians who also like explosions, so you'll have no trouble finding friends here. With respect to the people before me, it depends on what you're trying to do. Since you're new, I'm going to assume that you are working just on getting orbits that you want and not yet doing anything more complex, such as rendezvous or docking. For simplicity of training, your first orbital changes are going to be one of three types. First is to raise an apsis of your orbit and go to a higher orbit (or transfer to another body such as the Mun). Note that it doesn't matter whether you want to raise your apoapsis (farthest point of the orbit from what you're orbiting) or your periapsis (closest point); if you want to raise either one, then you need to point your nose prograde (). For example, if you are starting in a low orbit and want to go to a higher orbit, then you would start by pointing prograde to raise your apoapsis to the level of the higher orbit, and when you reached that apoapsis, you would point prograde again to raise the periapsis and make the orbit circular. Second is to lower an apsis of an orbit and go to a lower orbit (or land). For similar reasons as before, it doesn't matter whether you want to lower the apoapsis or the periapsis of your orbit: if you want to lower an apsis, you will always point retrograde (). Third is to change the inclination of an orbit, meaning to tilt the plane of the orbit relative to the equator of what you're orbiting. This is something that you need to do for more precision work, such as selecting a landing point away from the equator, polar exploration (either from space or on the ground), transferring to bodies whose orbits are inclined (such as Minmus), and orbital rendezvous. For these, you will need to point your rocket in either the normal () or anti-normal () directions, but the one you want will depend both on the changes that you want to make and the timing of your burn. If you're starting from a circular equatorial orbit, then it matters less, but it's still important--the wrong answer won't cost more fuel to change the inclination, but it will change the inclination the wrong way. The reason I raise the issue is because orbital inclination changes are necessary for anything beyond single-vessel, single-body orbital operations, meaning that you need to know how to do them for transfer orbits (such as for Mun flyby missions), which will be among the next things you learn.

@A35K: The only stock engine that has any thrust at all at 15 atm is the Dart. Nothing else can force out its exhaust against that pressure. However, (and admittedly, I have not simulated it to check) the Dart's Isp at that pressure is somewhere around 80. The only way I can think of doing this--without stock propellers--would be with a multistage spaceplane. However, I do not know whether that is actually possible; the low thrust of the Dart at that altitude combined with both the thick atmosphere and the high mass of fuel needed to make it up to a 200 km orbit may make it impossible to maintain enough forward speed to lift against the gravity, no matter what wing configuration you use, because unlike Kerbin and all other atmospheric bodies, there's no surface to hold your craft at altitude until you can build up enough speed to take off. On the other hand, it may be possible to get down to that altitude and make a powered ascent from a forward glide: call such a craft an atmospheric skimmer rather than a pseudo-lander. You ought to try it, and if it doesn't work, it's certainly challenge material.

In the interests of clarity, capture means something different in KSP. What you call capture, we generally call an encounter. Normally, that wouldn't be an issue, except that capture also has a meaning: it means to go from a fly-by encounter to a stable orbit around the target body. Since the issue appears to be the encounter, I'll give the standard advice: you need to move the closest approach markers together. I'm not certain of how close you're getting to begin with, but the fact that you are seeing the markers is a good indication that you're in the right neighbourhood, at least. When you set up a manoeuvre node, the intercept markers will change to reflect your future orbit after the burn. You can play with the node controls to see what you need to do to get the encounter well in advance of the actual burn, and thus plan the encounter without wasting fuel. As far as making your orbit exactly on or exceeding Minmus's orbit, it is most efficient to have your transfer orbit be exactly tangent to Minmus's orbit at the point of encounter (well, technically, you want it to be slightly under-powered so that your encounter has a low-periapsis flyby rather than an impact that you then have to undo, but that correction is usually only one or two metres per second). It's okay to exceed a bit if you need to get an encounter, but then every extra metre per second that you spend to get to Minmus over the minimum is a metre per second that you have to cancel once you arrive. Again, this is expected in normal manoeuvring, but it's something to plan for in advance.

Is that to say that it flies well, except for the everything? It reminds me of this. If you should find yourself pressed for additional ideas, you may wish to look at challenge threads and mission reports for the phrase 'nanocrystalline diamond'. That's the cheeky name for the hardest possible career difficulty, and you may find innovations that interest you. I think there's a satisfying challenge in devising new ways to use only the first ten parts to progress the game: the venerable ScienceRoller has pride of place there. Congratulations on inventing it independently! I look forward to seeing your landing mission!

Indeed. Welcome to KSP, @jkeller098; you're officially no longer a novice player. And that's no joke: you can successfully field an interplanetary mission and both encounter and land on another planet. That isn't beginner-level. However, I will suggest that your rescue mission carry both parachutes and landing rockets. Parachutes alone aren't always enough on Duna. Also take an engineer to repack them if you want to use the parachutes again to land on Kerbin when you come back, or else take extra parachutes. In the meantime, remember that Duna is lovely; try to enjoy the place. Grab some science and go for a few hikes. If Ike's in the sky, you can advance the timewarp and watch it librate.

It may be a bug--possibly with the sudden impact with the air not registering correctly--but it may also be that something attached to the lab flexes and causes impact damage once exposed to air. I can't guarantee that it's the problem, so in lieu of a proper solution, I suggest three things to test: one, try reducing speed to under 6 m/s (the impact tolerance of the lab) before you release the payload. That means stalling the plane, so be careful that you don't crash into the lab when you let it out. Two, try increasing the crashTolerance value in LargeCrewedLab.cfg in the Gamedata\Squad\Parts directory. See whether 50 works. Three, put a probe core on the lab if you don't have one already and set it as the root part so that when you decouple, the focus stays with the lab and not with the plane. That way, the destruction--if the lab is destroyed--will appear on the F3 report. Another possibility to consider is that your lab is bathing in engine exhaust from the plane when it decouples, which overheats it to failure. Given the thermal tolerance, it's worth investigating. I don't know whether you would see temperature bars on decoupled parts--my guess is no--so that would be one for the probe core test. You may consider trading the ramp-style cargo bay for an inverted standard bay such that the doors open on the belly. I don't know what that will do to the lift characteristics when you open it but dropping the lab straight out the bottom of your plane will help avoid problems with the engine exhaust, if there are any.

Not at all. I merely said that your interactions with them are driven by a computer simulation. Consider the feelings of loss and frustration when your Jool-5 mission crashes at the pad because of bad staging, or when you lose a pod on reentry:

Kerbals don't reproduce. KSP is a simulation, and it's what we would have seen on the silver screen if Neo had taken the green pill. Yes, there is something behind the curtain, but it's all maintained by computers: