Zhetaan

There are certain issues with autostruts that can explain what is going on. Are you using them? Also, does it explode every time, or only some of the time?

That's the best way to do it; you want to turn gradually. The best way to fly a rocket changes with the rocket, but for most rockets, going straight up for the first thousand metres and then pitching east by three degrees is good enough to start. Continue the gradual pitchover a degree or two at a time, and so long as you aim to be at roughly forty-five degrees by 10 km and nearly horizontal anywhere between 30 and 45 km, you'll probably have no problem getting to orbit. Some rockets prefer a much more specific ascent profile, but if you begin with that one, it'll work well enough in most cases and on the few times that it fails, you'll probably be in a good position to know why and how to correct it. Eventually, you'll be able to build a rocket that requires you only to give the initial three-degree pitch at a thousand metres and it will fly itself to space--without setting SAS to prograde, without throttle work--just keep your hands off the controls until you shut down the engine, and perhaps you'll need to coast a bit before you circularise. If anything, I'd be concerned that your payload is actually too light; there isn't much that three Mainsails can't lift. Relatively quick ways to check that would be to see whether you reach orbit with a lot of extra fuel (in your lifter stage--you obviously want your transfer and lander stages to have their fuel), and to see what your thrust-to-weight ratio is. I don't think there's a TWR calculator in the latest version of KSP (I lag behind the most recent by a few versions), so know that the thrust of three Mainsail engines at sea level is 4137 kN; you'll need to take the mass of the fuelled rocket in tonnes (available in the VAB), multiply that value by 9.81 (Kerbin's gravitational acceleration at sea level), and divide 4137 by your answer. Put in an equation: TWR = Thrust / (FuelledRocketMass * 9.81) Ideally, the answer is somewhere between 1.2 and 1.5, but I suspect that it's a lot higher for your rocket. Being outside that range has drawbacks on either side. Too low of a TWR means that you either cannot get off the pad at all (if it's less than 1) or else you ascend so slowly that a minor instability while you hover six metres above the pad causes you to tip over. Too high of a TWR will get you off the pad, but it greatly reduces efficiency (which requires more rocket, which costs more), and more importantly, it makes the rocket difficult to control. Imagine the difference between trying to control a garden hose versus a fire hose; each will water your plants; but one will water everything else. Even better, imagine trying to make orbital rendezvous, or even trying to insert into a specific orbit altitude, when the most insignificant burp of your engines changes your apoapsis by ten kilometres. It may be difficult to think of a hundred-tonne column that ascends to space like 'a crazed robot made out of explosions' as a precision machine, but consider it against the scale of the cosmos in which it operates and you'll get the right perspective. Don't lower the centre of mass. If anything, you want it at the top of your rocket. It seems counter-intuitive, but that's how it works. Lowering the centre of mass is to fall victim to something called the pendulum fallacy, which is the idea that a rocket, like a pendulum, dangles from its centre of mass. This notion has led to weird designs that do things like include the engines at the top of the rocket (the idea being to drag the rocket behind) or at the centre of mass. This is wrong for two reasons. First, a rocket is a rigid body. Thrust from the engines acts on the entire rocket at once; when you light it, it all goes up at the same time. A pendulum depends on the fulcrum, and thus on the relationship between itself and its pivot (the fulcrum cannot be rigidly attached to the bob of the pendulum); it thus is not a rigid body because it has that pivot point. Second, a pendulum works because it is powered by gravity (or else some other force that acts as a 'restoring force' in physics parlance). Rockets overcome gravity; that's how they work. That's not to say that a rocket isn't affected by gravity, but simply to say that gravity does not stabilise a rocket's ascent. If it did, then a rocket would become unstable as it ventured farther out of the gravity well, which does not happen; but a pendulum does become unstable and eventually swings round in circles. The reason to put all the mass at the top of the rocket has to do with leverage. If you can concentrate the mass as far away from the engines as possible, then you get the most effect out of gimballing and other attitude-control mechanisms. This makes it so that you can respond to slight instabilities more easily, and thus it stabilises the rocket for ascent. If your rocket suffers from too much engine, then I suggest that you cut back on the thrust. You can do that with thrust limiters, but you can also do it by switching to Skippers on the outer boosters. You ought to consider the Twin Boar, as well; it's one of the most cost-effective ways to get to space because it incorporates the fuel tank and the engine into one part. It's best to put the fuel for a stage into as few tanks as possible; this isn't because it gives an advantage in physics, but rather because there are fewer parts and joints for the game to track, so it improves performance. Do you have a screenshot of your rocket? Define efficiency. The fuel requires a lot of time and an expensive infrastructure investment, but after that is free of cost. The usual convenience of fuel in orbit is that it reduces launch costs by spreading the cost over several launches (at a minimum, one for the empty vessel and one for the fuel tank). There are a lot of space stations that consist of a Jumbo tank with a docking port. That being said, there are specific, desirable use cases for a fuel operation on the moons beyond 'I want to try it out'. On the other hand, they are fewer than, say, the use cases for a fuel operation on the moons of Jool. On the gripping hand, 'I want to try it out' is the reason you do anything in this game.

@JBMCW2010: Welcome to the party! We don't have drinks, snacks, or even brightly-coloured hats, but you get to pick a profile picture, so that's something. Others have hinted, and I will write it out: In-Situ Resource Utilisation. In other words, it means on-site mining and refining. It comes from a NASA proposal. For KSP users, ISRU typically refers to the refinery parts (these are known in-game as Convert-O-Trons) or to the act of mining itself; the drills have always been regarded separately, though technically ISRU refers to the entire process chain from prospecting all the way to storage prior to final use. It is, on the balance, more efficient to harvest and convert on the surface. The small Convert-O-Tron is ten percent efficient, which for you means that you spend fuel to haul ore to orbit (even if it's only Minus orbit) only for nine units of ore out of every ten to be wasted. On the other hand, the small unit is not meant for large-scale refinery work anyway (it has a heat imbalance that makes it impossible to run continuously). The large Convert-O-Tron converts one hundred percent, but it is only lossless when you use it to make liquid fuel and oxidiser. Monopropellant manufacture results in a twenty percent mass loss anyway; this is because monopropellant has a density of 4 kg/L whereas liquid fuel and oxidiser have densities of 5 kg/L each. In this case, if you plan on making no monopropellant, then you can leave the converter in orbit. Personally, I never do, but that's only preference. As to the scale, the small Convert-O-Tron is 1.25-metre scale (the same as the Reliant and Terrier engines and the bottom of the Mk. I Command Pod), and the large one is 2.5-metre scale (the same as the Rockomax fuel tanks and the Skipper engine). If you keep going out to 250 km on launch, then I suspect that you are either not cutting your engines early enough or else flying an odd profile. Try switching to map view once you get your rocket mostly horizontal (on most ascents, this should happen around approximately 30,000 km altitude) and watching the Ap marker (if you don't want to chase it with your mouse, right-click on it and it ought to stay visible). When your apoapsis reaches 80 km, cut your engines. You may wish to watch the 'Time Until' counter on the marker, as well, and try to keep the apoapsis roughly thirty seconds to one minute ahead of your rocket, which you can control by use of the throttle. Done correctly, by the time you get to 75 km, you'll have most of the circularisation done already. You may be confusing aerobrake with airbrake. Aerobraking is using atmo to help reduce your speed; airbrakes are parts available for the later planes. Either way, why not try it and see whether you can figure out how to make it work? You can use quicksave in case you guess incorrectly. I won't tell. Seriously, though, don't worry about a tutorial. You don't need one to figure out how it works. If you can re-enter and return a rocket to the surface, then you can aerobrake: you still re-enter, but you stay high enough to miss the surface and avoid burning off any parts. How high is something for you to discover: science is driven by experimentation, and rocket science is the same way. Also, the right altitude changes with the rocket. A rocket with high drag may get a lot of braking with a shallow pass, but a needle rocket may need to dive into thicker air to get the same result. Good luck, have fun, and do please tell us how it works out. KSP is supposed to be hard, but it is also supposed to be fun, so if you should have any problems or particularly fun-destroying frustrations after trying to work it out from here, then please don't hesitate to ask about them. We're here to help.

This can be calculated, so let's do that. Objects in circular orbits orbit at a constant speed; the more elliptical the orbit, the more the speed varies between the apoapsis and periapsis. Lower orbits are also faster orbits, so to get the most from a gravitational dive to Duna, let's assume that you want the 28,000 metre limit as your periapsis, and since we want a value that will complete the contract, let's use the minimum velocity of 2,450 m/s. First, we need something called the vis-viva equation: v2 = μ [(2 / r) - (1 / a)] Where: v is the relative velocity, μ is the standard gravitational parameter (for Duna, this is 3.0136321 x 1011 m3/s2), r is the radial distance from the centre of mass (KSP measures surface altitudes, not radial altitudes, so we need to add 320,000 metres to the altitude for this value), and a is the semi-major axis of the orbit, also measured according to radial distance from the centre of mass. For our purposes, we know the radial distance we want to use (28,000 + 320,000 = 348,000 metres) and the velocity (2,450 m/s), so we can solve for the semi-major axis. With a bit of algebra, we get this: a = 1 / [(2 / r) - (v2 / μ)] a = 1 / [(2 / [348,000]) - ([2,450]2 / [3.0136321 x 1011])] a = 1 / ([5.74712643 x 10-6] - [6.0026 x 106 / (3.0136321 x 1011)]) a = 1 / ([5.74712643 x 10-6] - [1.991782607 x 10-5]) a = 1 / -1.417069964 x 10-5 a = -70568.14 m What happened? How do we get a negative semi-major axis? Put simply, we're looking at the wrong kind of orbit. Even though the semi-major axis represents a real value when dealing with elliptical orbits, there are other kinds of orbit; in this case, a negative semi-major axis means that we're dealing with a hyperbolic orbit. In other words, the contract is specifically asking you to test this heat shield on an interplanetary insertion. (Technically, the negative semi-major axis is a real value, too; it measures the distance from the periapsis to the point where the hyperbolic asymptotes cross--but since that direction is opposite the centre of the primary, the value is negative--and if you don't know what those terms mean, that's okay.) Even so, I can still help you. Hyperbolic orbits have a particular parameter called the hyperbolic excess velocity, which is a measure of how much faster than escape velocity an object on such an orbit moves. This value is often termed vinf or v∞ in the equations. It's also easy to calculate when you already have the semi-major axis: v∞ = √(-μ / a) v∞ = √[-(3.0136321 x 1011) / (-70568.14)] v∞ = √(4270527.89) v∞ = 2066.53 m/s There is an inaccuracy involved because Duna's sphere of influence begins a bit inside the effective infinite distance (just a little bit) but it isn't extremely large. The point is that if you enter Duna's sphere of influence with approximately 2067 m/s relative velocity on a trajectory that aims for a 28 km periapsis, then you should touch the minimum required velocity for your contract. Obviously, more velocity would be a good idea in this case: you have to account for error, aerobraking (not much but it's there), and the fact that I just calculated the essential minimum velocity to just barely complete the contract; you'll likely want a margin anyway. Or you could, as others have suggested, simulate such a trajectory by the use of a massive rocket pointed down. This is one problem where more boosters will actually help. Alternatively, there is nothing saying that you have to aim for a periapsis at 28 km; the contract only requires you to have the right velocity at that altitude. You could always try to ram the core of the planet and see whether you reach the required velocity in that case. KSP is versatile; whether you want to make peaceful exploration of the skies or knock those pesky planets out of the way, it has something for you.

With respect to @jost, don't set autostrut to root. That can cause problems when you undock later and the root part changes. Your best choice is to autostrut to grandparent part. Here's the basic idea behind the autostrut settings: Root: Autostruts go to the first part you placed when you built the rocket. That's usually the command pod or probe core, but not necessarily--perhaps you open in chess with your knight, too. This can give rigidity to a tall rocket's core stage if you strut from the bottommost engine to the topmost command pod, but it is not recommended for side boosters and definitely not for anything that needs to undock. The root-choosing algorithm for pieces that undock can be weird, and if you send two rockets in separate launches, then when they dock, one root part is favoured over the other. All of those autostruts changing their connections all at once can cause explosive disassembly. I'm not entirely certain of exactly how it works, but I do know that there are a lot of explosions that can be traced to root-type autostruts on complicated vessels and stations. Don't use them on anything that docks. Heaviest: Autostruts go to the heaviest part of the rocket. I do not know whether this ignores the mass of fuel in tanks; I have not tested it. If it does not, then it means that the struts can change connections in flight. I stay away from this one for the same reason that I stay away from root: the heaviest part changes when you dock, undock, potentially also when you stage, and--should it not ignore fuel mass--also while you fly the rocket. Grandparent: Autostruts skip the part to which the current part is attached (called the parent) and go to the part to which that part is attached (called the grandparent). For example, let's assume that you have a rocket with two side-mounted, detachable solid rocket boosters along with a core stack. You attach these boosters using radial decouplers, which are themselves attached to a core fuel tank. If you autostrut the boosters, then the struts go to the central fuel tank. In essence, grandparent struts always go two parts up in the build tree--and if that doesn't make any sense to you, then use my example as a guide. If you are within two parts of the root, then I don't know what the autostruts do--they'll either go to the root or turn off--but at that point, you don't need them and they won't hurt anything anyway. Autostruts only cause problems when they are unnecessarily long, bridge too many complicated assemblies, or change suddenly in flight. Actual flight advice begins here: Your idea of detachable fuel tanks is not a bad one. I think you should consider using a larger docking port, though. The Clamp-O-Tron Sr. is much more rigid in its docking connections. Another idea is to mount the docking port radially on the fuel tank (in other words, exactly like it's mounted on the main rocket) so that you keep the mass closer to the centre. That will also reduce wobble. Lastly, if you happen to enjoy doing things the difficult way, then you can double-dock, which is exactly what it says: put two docking ports on your fuel tank and central rocket and dock with them both at the same time. That will give a very rigid connection but at the cost of a lot of frustration unless you can dock on the head of a pin.

And if the claw craft has an Experiment Storage Unit, the claw also has a remotely operated robotic science hose ....

The claw is absolutely, utterly necessary for asteroid operations, but when used on other vessels, you're right; it is overpowered. On the other hand, it's also the only way to do certain things. For example, it's the only stock way to get decent docking alignment on surface bases on uneven terrain--at least without resorting to maniacal devices involving centipede-like arrays of landing legs and such. Correction: Breaking Ground may have changed that, but that's DLC and not exactly stock. Besides, with it you can have things such as the Mosquito-class refuelling tug, the Lamprey-class supplies-recovery tank, the Barnacle-class heat-shield and tracking array, and the the Digger-Wasp-class supplemental crew module. Or, if you have a penchant for science-fiction horror, you can call it all some variation of Facehugger. I once tempted fate and named them after whaling ships (for the harpoons): imagine a vessel named Pequod that hunts the sky for a white class-E magic asteroid .... Insofar as tips and tricks are concerned, I know that they fixed the worst of the bug, but I still recommend that you always control the vessel with the claw rather than the vessel being clawed when you join them together. That may be pure habit, but I'm still leery of doing otherwise. Another thing is to note that there is a way to adjust the attitude of the head. This is so you can put your rocket in line with the centre of mass of an asteroid for more symmetric thrust, but remember to lock the head again when you have it adjusted as you want it. Yet another is to remember that it is not a docking port, so the approach is different. Where the docking ports need to be mated slowly and carefully, the claw prefers to be more forceful; you'll need a higher relative speed to get a lock. Oh, and the claw will not grab the ground of any celestial body. That would be anything with a sphere of influence; if you want to mine Gilly, then you have to land on it; you cannot grab it with the claw.

Apparently, that part had a probe core attached to it at one point. I don't know how you launched everything originally, but something is obviously missing--that's a decoupler, not a separator, and it ought to be attached to something. If you detached from a part that had a probe core but then the probe core exploded because of exhaust impingement or collision, KSP won't necessarily re-brand it as debris. That only happens when you detach something that has no control points whatsoever, and in this case, it is explained by the probe core not being the root part. I don't think it a glitch so much as an uncommon, but normal, occurrence, but I'm with @Geschosskopf either way--it's best to terminate it and move on. However, to answer your question, you can rename it in the Tracking Station. Go to the tracking station and click the information button as in your first image. Click the orange banner of that window (the part that has the name of the vessel)--or double-click; I don't recall which--and it will give you a rename dialogue with the option to mark the thing as debris.

Certainly, but I would counter that tedium is a necessary part of the design process. KSP spares the player from the worst of it (mostly with revert-to-launch and the cool explosion sound effects), but I think that it's inescapable that if you want to play with experimental rockets, then you must expect to do experiments. Perhaps I am making too many assumptions, but since @Mammoth already indicated a desire to test the effect of launch altitude on delta-V, I am under the impression that @Mammoth is a more nuts-and-bolts type of player who wants to actually see the effect rather than let the calculator provide the answer. If I am wrong, then that's easy enough to do with Kerbal Engineer: switch to the atmospheric delta-V readout and there are two sliders, one for altitude and one for speed. Besides, I don't think it's that onerous. The problem is to test launches at various altitudes with minimal net forces: that implies as close to a zero-velocity launch as one can get. That's easy enough: launch straight up, kill the engines a few thousand metres short of the intended launch altitude, coast to that altitude, stage and burn when the velocity is zero, and there's the answer. It's essentially the same as the part test contracts that require one to test a part at high altitude but low velocity. It's even made repeatable by tweaking the fuel load so that the lifter burns out at the same altitude, and pilot error is at a minimum because straight up is the starting attitude of the rocket in the first place.

Quartz. Val's on her own for the V. I enjoyed this report quite a lot. You've got a good eye for screenshots--and I particularly liked the map/satellite view at the beginning. I am a bit curious to know whether you experimented with putting the Mk3-Mk2 adaptor on your cargo plane the other way round; i.e. with the cockpit high instead of low.

Perhaps I'm not understanding the question, but if you want to launch your rocket from altitude x, then why not use a first stage to lift it to altitude x and launch from there?

@Baker: I wanted to place some extra emphasis on this point. Using an action group is a quite popular way of controlling engine clusters, because they allow one to activate or deactivate, for example, the air-breathing engines versus the rocket engines on a spaceplane while under power. Doing it one at a time can cause asymmetric thrust. Another important point is that if your mothership will include any landers or transfer craft, then you absolutely will want to employ this method to control which engines fire when you want to go anywhere. Common control schemes include setting separate action groups for each vessel's engines, or a universal engine shutdown/abort command, followed by individual groups to activate a craft's engines--or however, you may want to do it, really. I agree with this sentiment; four Mammoths is an immense lifter. I'd expect that on something designed to return from Eve, perhaps. But your best option for this may well be to build cheaper. Other possibilities for weight reduction include reducing redundancy (let the payload's batteries power everything) and shipping tanks empty (set up ISRU first and bring fuel from the Mun or Minmus). Depending on how you want to do things, you may benefit from shifting the monopropellant carriage to stations rather than taking two long-form Mark-II fuselages full of it from place to place. In other words, only carry enough monopropellant on the vessel to match velocities (assuming you need that much), and instead use a docking tug or similar contrivance (or set of contrivances; you can put one on each end if you like) to bring the vessel in to dock. On the other hand, you can avoid the need for gigantic manoeuvres with three amazing words: detachable crew modules. You can transfer large numbers of crew to stations or wherever by use of a passenger module that operates as a shuttle (whether or not you use a tug). Moreover, the undocked engine/tank combination then becomes available for a tanker to refuel.

If it's a mod interaction, then good luck finding it. The best I can offer is to suggest that you get rid of BetterTimeWarp and see whether that corrects the problem. Start from the obvious places and work from there. I will add, however, that you have a directory named 'Source' in your Gamedata, which suggests that you may have installed something incorrectly. See which mod uses that 'Source' directory, delete it, and reinstall. On a minor housekeeping note, you may wish to remove all of the outdated versions of ModuleManager. The old versions are supposed to shut themselves down when they detect a newer version, but that still represents time spent starting, checking, and unloading themselves.

@leosefcik: To the above I add that you can also use the thrust limiters on the Kickbacks to slow their burn rate. If you have 4,300 m/s of delta-V, then fuel is not your problem. Your choice of engine and ascent profile are the issue. Be mindful, however, that if you do decide to change engines, then you may create a fuel problem: A fuel load that lets a Terrier run for ten minutes will supply a Vector for a lot less time.

@Geschosskopf: Your screenshot shows science taken in low space, not low flight. There is a difference: flight requires an atmosphere, and the experiment availability is not copied from one situation to the other. It's also the case that crew reports are and have always been once-per-planet in low and high space, but once-per-biome in low flight. I do not recall about high flight. EVA reports, on the other hand, are once-per-biome in low space. I will throw out the possibility that you do not have corrupt save files but rather a forgotten Module Manager patch. I patch the experiments myself (thermometer readings are numbers; why can't they be transmitted for full value? What's this nonsense about getting biome-specific science just by being outside the capsule in space? And so on), so if you did the same and installed on top of an old version, then that would explain what you're seeing.

In the stock game, there is no way to repair a solar panel in the same way that you can repack parachutes and repair rover wheels. The most you can do is replace the solar panel with a new one, either by use of a docking port or with an Advanced Grabbing Unit. If you don't mind the cheating-adjacent elements of doing so, then you can also revise the persistence file: the damaged panel will have a line saying something similar to 'STATE = BROKEN', and if you change that to say 'STATE = DEPLOYED', then the panel becomes undamaged. I know I'm rather late to the discussion, but I will add that given the appearance of the solar panels in the game, the ones that break appear to break at the hinges, not the cells. Admittedly, the break animation may not be the best gauge: if it were, then the idea of simply 'patching' the rover wheels makes a lot less sense given the visual appearance of the damage--and besides that, real rover wheels are not inflated, so patching would be pointless in the first place. The point is that a broken solar panel is not quite the same thing as a solar panel that is destroyed outright (with explosions, not flying panel parts). It may still be unacceptably unrealistic to repair a panel whose hinges are snapped, but I don't think it's fair to assume the cells themselves are shattered.

Yes, because flying a course in full N-body gravitation by hand can easily become complicated enough to require a few degrees in mathematics. Since Principia already solves those equations, why not use the same solver for flight planning? It isn't an autopilot, but it will help you plan your trip. To quote from the Principia Wiki:

Not quite. Orbital speed is a major factor because that kinetic energy inherent in your velocity has to be shed as heat--that's what re-entry heating is. You collide into the atmosphere and compress it, and that compression heats the air in the energy transfer from your moving space vehicle to moving molecules of air. The more velocity you have, the more compression, and the more heating--entry angle doesn't change that. The steepness of the re-entry profile matters because the atmosphere is not of uniform density, so by choosing the correct path of travel through the density gradient as you progress to thicker and thicker air, you can alter the distribution of the heat load to best suit the actual construction (in the sense of the mechanical and thermal properties) of the vessel: shallower angles trade high temperatures for long soak times, and steeper angles do the opposite. In a sense, it's an inversion of the gravity turn problem: as the right choice of ascent paths minimises drag and gravity losses on your rocket as you reach orbit, but that right choice still nevertheless depends on the actual construction of that rocket, so too the right choice of descent paths minimises the types of heating that your rocket is least capable of dissipating safely, but that right choice also nevertheless depends on the actual construction of that rocket. 'Actual construction' means two things: first, it refers to the design, but second, it refers to the limits of the materials. To wit, a rocket with 100 thrust-to-weight on the pad flying horizontally at 1000 metres is going to tear itself apart in the atmosphere. Theoretically, there is an ideal gravity turn for such a rocket, but it is practically useless because there's no real material that can handle that sort of stress. In the same way, there probably is an ideal minimum-heat re-entry profile for a vessel returning directly from Eeloo, but it's still useless because whatever that minimum is is still too high for a vessel with no heat shield. In other words, there is definitely a maximum survivable altitude for orbital skydiving, but it's an optimisation problem with variables that I do not fully understand. There was a challenge here a few years ago called The Goddard Problem that dealt with optimising the altitude of a provided rocket by using throttle and attitude to minimise drag losses. This, I think, is similar: we want to optimise the return altitude of a provided part (the Kerbal) by using entry angle to minimise destructive heating.

You have my apologies for this response, but ... ... It depends. Your trajectory has a lot to do with it. I assume you mean a personal parachute, not a pod with a parachute--but the case is still the same. There are two ways to approach re-entry problems: you can choose a steep re-entry or a shallow one, and each has its own trade-offs. A steep re-entry gets you close to ground level quickly, but it also has high shock heating, which is to say that the maximum temperature that you experience is higher. A shallow re-entry is slower and does not reach those high temperature spikes, but it leaves you in the heat for longer periods of time, which allows that heat to 'soak' into whatever is re-entering. For practical purposes, the preferred method relates to the thermal tolerance of the part. If the skin temperature limit is higher than the part temperature limit, then that implies that the part was designed to handle high shock heat--the assumption being that while the skin gets hotter than the main body of the part can tolerate, the re-entry will be completed and the skin can return that heat to the atmosphere before too much soaks into the part and destroys it. On the other hand, if the skin temperature limit is the same as the part temperature limit, then the part was likely designed for shallower re-entry such that the skin has time to sink heat into that part--though some parts are set to very high temperature limits for both so that you have your choice of how to re-enter. On the gripping hand, some parts have low values for both skin and part temperature limits: these are designed not to re-enter at all, so use a shield or some other method to get it to the ground intact. So far as I recall, Kerbals have temperature limits for both skin and body of 800 K. That's quite low, so there is definitely a maximum re-entry speed and angle combination for them. (Though I cannot help but point out that my body does not have a thermal limit anywhere even close to 800 K.) There is another factor involved relating to heat conduction; some parts have intimate thermal contact with their skins, which means that heat in the skin (from re-entry) is conducted into the body of the part quickly. Others have low skin conduction: in a sense, the skin conducts heat so poorly that it can almost be considered a separate part for thermal purposes. Heat shields are supposed to work this way, though they have a different method to manage the heat (ablation). I have no idea whether Kerbals are good conductors. Lastly, there are two other things to consider for purposes of trajectory calculation: drag and wind speed. Kerbals falling through air have drag, and although I don't know anything about a Kerbal body's flight characteristics, I can say that all Kerbals are treated equally by the physics. Whether that means that orientation matters or that Kerbals experience body lift is nothing I can answer, but all EVAKerbals are considered identical parts by the game, so far as I understand. Wind speed is obviously not a major concern on a planet that has no weather, but I think it important to note that the atmosphere rotates with the planet; otherwise, your rocket would be blown off the pad by 175 m/s winds before you had a chance to launch. Therefore, you may experience differences in re-entry depending on whether you re-enter with the planet's rotation or against it. I've never tested to see whether there is a significant difference, but it's something to consider.

Have you got a plan for the overall scope for this? I know that it says all the maths 'needed', but that's rather a broad view of it. Do you intend to include calculations for rocket design, orbital manoeuvring, rendezvous of objects in different orbits, and interplanetary transfer injections? You may need to break this down into chapters. Do you want to give only the calculations themselves, or do you want to include derivations?

The Principia thread would be the best place to ask your question, but in this case, I can answer it: no. The MechJeb transfer planner relies on instantaneous velocity changes in the same way that the stock manoeuvre node system does. The difference is that MechJeb is a lot better at choosing precise solutions quickly--though it certainly has its limits in that area, as well. There's a reason that Principia comes with its own flight planner; if you use MechJeb, then you probably won't get the encounter. I'm not saying that it's impossible, but the entire design of MechJeb is established with the stock game in mind (with a few notable exceptions--but Principia is not one of them). For your second question, I don't know what you mean: if you are asking whether you can crash into Tylo, then yes, you can crash into it just the same as in the stock game. If you're asking whether you can crash Tylo into something else, then no. Principia has an orbit configuration file designed to prevent that kind of thing, and my understanding is that planetary collisions resulting from unstable or otherwise badly-designed orbits cause unacceptable bugs anyway.

Respectfully, I disagree with the others; a Nerv-powered lander can work just fine, but you have to take into account its particular issues. Mass is part of it. Heat is another. The length of the engine is yet another. But you also need to load it with the correct fuel. My apologies to those who commented before if I repeat anything, but in the interest of gathering these ideas into one place: First, Isp is a measure of efficiency, as others (@bewing) have said. It is not the only way, and it is not the most intuitive way. The most intuitive way is exhaust velocity: an engine that propels its exhaust at a higher velocity imparts more momentum to that exhaust (and, because of conservation of momentum, to the rocket, too) than an engine that propels its exhaust at a lower velocity. The convenient thing about Isp and vexh is that they directly relate: in other words, if you have two engines and one has double the Isp, then it also has double the vexh. Please note that efficiency does not necessarily relate to thrust. Because of the way engines are made, there's often a trade-off between thrust and efficiency, but this is not always necessarily so. For example, the ion engine accelerates its exhaust to ludicrous speed which makes it extremely efficient, but it does so almost a molecule at a time, so its thrust is terrible. A solid rocket booster, on the other hand, comparatively vomits its propellant onto the pad nearly all at once and thus achieves high thrust, but at such low velocity that the only real advantage is that SRBs are cheap. On the gripping hand, Project Orion is both efficient and high-thrust; please never mind the fallout. Second, you are correct that at the same thrust, the higher Isp of the Nerv gives a longer burn time for the same amount of fuel. We can work that through the calculation and figure out how much fuel is involved: We can consider that thrust from an engine is essentially constant regardless of the mass of the rocket (unlike delta-V). The engine exhaust velocity is also constant, and that is directly related to Isp (thanks to @HebaruSan): For the Terrier, it is 3383.29 m/s, and for the Nerv, it is 7845.32. Thrust is a force, which traditionally is defined as mass times acceleration (that's effectively Newton's Second Law), but acceleration is velocity divided by time, which means that we can define thrust in terms of velocity and still get a valid answer. Specifically, thrust, the force, is equal to velocity times the quantity of mass divided by time--which we can call mass flow rate. In other words, thrust results from the engine exhaust velocity times the rate of fuel flow. Tabulated, these give us the following values: Thrust / vexh = Mflow Terrier: 60000 N / 3383.29 m/s = 17.734 kg/s Nerv: 60000 N / 7845.32 = 7.648 kg/s Fuel flow rate times total burn time gives the total mass of fuel consumed: Terrier: 17.734 kg/s * 113 s = 2 tonnes Nerv: 7.648 kg/s * 118 s = .9 tonnes The FL-T400 tank holds two tonnes of LFO, divided up as .9 tonnes fuel and 1.1 tonnes oxidiser. In this case, using the same tank for your Nerv engine starved it of more than half of its potential fuel load. I could use the rocket equation to see, given your delta-V values, whether you unloaded the oxidiser from the tank, but you really ought to have used Mk1 Liquid Fuel Fuselage tanks for a Nerv-powered lander. It's the exact same tank but in a liquid-fuel-only variant; if you had used that, you would have had more than double the burn time and much more delta-V. Specifically: 2 tonnes LF * 7.648 kg/s = 262 seconds, approximately 5.19 TWR / 60 kN = 11560 N weight 11560 N / 1.63 m/s2 Mun surface gravity = 7092 kg mass (You didn't drain the Oxidiser!) Assuming 2000 kg liquid fuel: ln (7092 kg / 5092 kg) * 7845.32 m/s = 2599 m/s delta-V We can call this approximately 2600 m/s of delta-V. It's only 700 more than you'd get with the Terrier, so there's an argument to be made about adding another fuel tank rather than switching to a Nerv, but there's an equally valid argument for using the Nerv and keeping the lander relatively small. Replace the FL-T400 with a Mk-1 fuel fuselage. Used in this way, your lander will be perfectly serviceable.

Fly by from outside Kerbin's sphere of influence for an interplanetary encounter; in that case, it takes zero m/s to leave. Escape velocity for any given starting altitude is the velocity of a circular orbit at that altitude multiplied by the square root of 2. Note that the surface rotational velocity is not the same as orbital velocity; also note that surface velocity is greatest at the equator, zero at the poles, and affects your orbital velocity depending on the direction that you launch. For a real answer on how to reduce your necessary delta-V, the best I can give you is to launch east from the highest equatorial mountain you can find using the most aerodynamic rocket that you can build, and make use of a Mun assist. If you have a specific destination in mind, then I defer to the others who have already responded. I will add that a Mun assist can be worthwhile if you accept that it won't do the entire job, but the value of its help is limited, oddly enough, by its total lack of inclination. Every interplanetary destination is inclined with respect to Kerbin and that makes a Mun assist potentially more a harm than a help, except for trips to Duna whose relative inclination is tiny.

I generally avoid clipping because of the separation-followed-by-exploding-parts issue, but I'll do it in specific situations where it makes sense. For example, stock ladders require clipping to work at all; look at the part (try mounting a ladder on a girder to see how much of the ladder is a storage case that clips into the vessel). Because of the way it mounts, I assume that it is purely visual and that there is no collider, but even if there is not, ladders visually clip. For a more practical example, I'll put a Place-Anywhere RCS thruster into the middle of a four-way block to make a five-way thruster if I need (or want) one, because that makes sense. I clip wing parts together to get better-looking wings, but I hesitate to clip wings to get double lift from what appears to be one wing. Before service bays, I would clip parts into the insides of structural fuselages because structural fuselages are hollow. They absolutely can work as service bays. Before I used modded fuel-bearing adapters, I would occasionally clip small fuel tanks into the Rockomax 2.5-to-1.25 adapter, though the amount of fuel I gained that way was usually not worth the trouble. Stock aerodynamics didn't reward that kind of nonsense at all, either, but in fairness, that's what FAR was for.

First, welcome to the forum! This is the right place to ask. Second, I'm going to venture to guess that you are new to landing on the Mun. That's okay; we all had to do it for the first time at some point. However, if you are tipping over on your landing because you're new at it, it may mean that fixing the problem is beyond your skill level for the moment. To answer the question you asked, there are a few ways to tip a fallen rocket back upright, so yes, there's a chance. Some use mods--but you may not want or be able to use mods (console versions can't use mods, for example). Using the cheat menu as @Jognt suggested may be unacceptable to you, though it certainly will work. @Aeroboi's rover forklift is a great idea, but it requires you to have access to the rover parts and the ability to make precision landings with delicate gear and an unbalanced payload. @mikey117's idea to use the slope is often a good way, though it risks damage to the rocket and requires both a slope and powerful reaction wheels or RCS thrusters. Maybe you tipped over because you weren't upright when you landed, rather than because you landed on too steep a slope; I don't know. To answer the question you didn't ask, unless you are lucky both with the slope and with your flying, you probably will not be able to save this rocket. However, you can still save the crew. By all means, build a rescue rocket. You can do it in a couple of ways; one is to send a probe-controlled rocket, though that may not be feasible depending on your communications settings. Another is to build a rocket with one seat more than the stranded crew and send a pilot to pick them up. Be sure that the other seats are empty; I've seen many people quit in frustration after sending a four-seat rocket to pick up three stranded crew, only to find that all four seats were occupied and they forgot to empty the extra three before launch Perhaps that behaviour has changed; I don't recall. Another idea is to learn why this rocket tipped and send a new one that is resistant to that problem in the future. There are many ways to make that happen; you can include powerful reaction wheels or RCS thrusters, if you like, but my preference in these situations is to design a rocket that is less prone to tipping in the first place. Most of my Mun landers are very short, and most incorporate three widely-spaced landing legs. Tripods don't wobble! I normally include three FL-T100 or FL-T200 fuel tanks on radial decouplers, and put the landing legs on the extra tanks; this gives the rocket such a wide footprint that it usually can handle any slope up to the point that it begins to slide along the ground--but it won't tip. The centre may be a Spark engine on another FL-T200 (or maybe an FL-T-400) tank with the science experiments and pod. If you're making a rescue, you may want to use a crew capsule rather than a science package; if you can land on the Mun with an intact (if not upright) rocket, then I will assume that you understand how to design a return-capable rocket. Flying a squat lander to orbit can be tricky, but if you have access to the 2.5-metre parts, then you can reduce the amount that the lander ruins the aerodynamic profile of the lifter. Any way that you choose to address the tipped lander, good luck, and if you have any further problems, please don't hesitate to ask.