Zhetaan

Agreed. At Gilly, 'flat' becomes an exercise in perspective; there's no easy way to tell. Aside from that: There is another way to do this. @Vanamonde had the hint in the first reply: treat it as the reverse of a launch. When you come to a stop at 10 km over the landing site and then burn to reduce your velocity to something survivable before hitting the ground, that's the reverse of launching straight up to an apoapsis of 10 km, then turning sideways and burning for orbit. If you know what a gravity turn is and how it works, then you know that what I just described is an inefficient way to launch. For the exact same reason, it's an inefficient way to land. Your intuition is absolutely correct in that respect, so you're enough of a pilot to identify the problem--since you need to do that before you can fix it, I'd say that you're not bad at all. Anyway, here's the alternative. This is an old, old, old video, but the principles are still sound: Note that the lander in this video has extremely low thrust-to-weight. Low-TWR vehicles are inherently inefficient on airless bodies (the low thrust means you need to fight longer against gravity), but the principle of a constant-altitude landing is a sound one. The best part is that starting your burn too late won't destroy your vehicle; you can simply go back to orbit. I will caution that this is not precisely beginner-level technique. Suicide burns and what I will call 'stop-and-turn' burns have an advantage in that you figure out the right direction to point your rocket and then you burn in that direction until the burn is done; you don't need to change the direction except for corrections. Constant-altitude landings require you to understand that you can control velocity not only with the magnitude of the burn (meaning the throttle), but also with the direction of the burn (which you do with the pitch angle), and that you can control both of these things at the same time. If landing this way is not your style, then you will still enjoy better results by following @bewing's or @Snark's advice: start from a low orbit and bring your periapsis even lower. Minimise the amount that you need to drop vertically, because that's where you spend the fuel inefficiently. Good luck!

Let me clarify that: processing an experiment in the lab does use it up; you'll need to go back to get a duplicate to recover at Kerbin. You are correct, however, in that you can take two copies of the exact same experiment and get science from each one. You can also save yourself that second trip with creative vessel design. There are a few other points about this to make: Labs are nearly worthless when landed on Kerbin. The data value for processed experiments there is reduced by 90%. Labs work better when you land them on a celestial body. The data value is increased by 10% when you bring experiments to a lab that is landed (or splashed down) on a body that is not Kerbin. Labs work better yet when you bring them to the same sphere of influence as the experiments are obtained. The data value is increased by 25% when you process experiments in their own sphere of influence (for example, when you process Minmus experiments in a Minmus-orbiting lab). You can combine these effects: a Mun experiment brought to a lab landed on the Mun will give much more data. It is best to use high-level Scientists in the lab. Higher-level Scientists do not increase the amount of data or science points, but they do increase processing speed so that you get the science faster. Labs have limits on how much data and science they can contain. I do not know whether it will refuse to process experiments in excess of the limit, but either way, you will need to revisit the lab periodically to transmit built-up science and refill the data buffer. Labs process data into science faster when they are full of data. Try to provide enough experiments to keep the data buffer full. The data conversion rate is 1 data point to 5 science points. The data value depends on the original science value of the experiment and the landed or sphere of influence modifiers, but you can usually expect a return of at least five times the original science value for each experiment. Labs do not need electric charge to process experiments into data, but they do need electric charge to process data into science. Be sure to provide a power supply. Labs also need electricity and a radio (not provided) to transmit science to Kerbin. Be certain to provide an antenna capable of reaching Kerbin or a Kerbin-connected relay, and enough electric charge (in batteries) to power the transmission. That is true, but not quite the way you put the idea. There are only so many places in the Kerbal solar system, and there are only so many experiments that can be done. Thus, there is a maximum amount of science that can be obtained from each celestial body. Since each lab can process experiments only once, each lab also has a maximum amount of science that can be obtained. However, there's no limit to the number of labs you can build. Also, asteroids spawn indefinitely and they have science experiments, too--and those experiments can be processed in a lab! (Edit: Ninja'd by @Geonovast) Some people think so. Granted, some people think that asteroids are overpowered, too, because they also provide for infinite science. On the other hand, career mode contracts also provide infinite funds, reputation, and science, so maybe it's a question of how you want to play more than anything else.

How have you been manipulating MNA? Are you using radians or degrees? I am fairly certain that KSP uses radians for MNA, so you'll want to use numbers ranging from 0 to 2π (approximately equivalent to 6.2832). For a constellation of four satellites, that would mean 0, 1.5708. 3.1416, and 4.7124.

A different alternative would be to use the mod DeepFreeze Continued and take a cryopod with you. That would alleviate the need to carry years' worth of supplies on a deep-space mothership all for the sake of one Kerbal's health and sanity.

Nicely done! I'm glad that you got an answer so quickly. I hope that you can have the rest of the problem resolved soon.

That's a bug. There used to be a bug that would cause the target vessel to match your SAS rotation (which made it very frustrating to dock), but this is something else, I think. Unfortunately, It's possible that you're dealing with an interaction between two incompatible mods, in which case there may not be an obvious answer. You can probably assume that aesthetic and informational mods are not responsible, but the only way to really get into this and figure out the problem mod is to start with a clean, stock installation of the game, begin adding mods, and try to dock until you find the mod that's causing the issue. Once you find it, you can then go to that mod's thread and see whether there are any known incompatibilities--if nothing else, you can make it known to the author. Edit: I'd suggest to start with anything that changes the controls or the underlying game mechanics. I don't think kOS would be responsible unless you were running a docking script at the time. I'm disinclined to think DPAI would do it; it's informational. You should take a closer look at Easy Vessel Switch and maybe ModularFlightIntegrator--I'm not certain and there are better-informed people to ask, but those two seem to be obvious first choices.

Your intuition is correct. Remember that KSP uses metric tonnes as a base measure of mass, not kg. The density of LFO is 5 kg / unit, or .005 tonnes / unit (LF and O share the same density for some reason). A 'unit' in KSP used to be an arbitrary amount until the developers fixed it at one litre per unit and introduced density to make up the balance of the mass calculation. Thus, the complete value is 5 kg / L for LFO, and a corresponding 4 kg / L for monopropellant. In the resource definition files, this reads as the completely incongruous .005 tonnes / litre. Your stock LFO-to-EC conversion is correct; one unit of LFO produces 400 electric charge. Of course, that reduces the 'charge density' to 80 EC per kg, not 80,000. I made a spreadsheet a few years ago to compare some modded RTGs to other power sources, but I included solar panels and fuel cells in the comparison. I won't post the spreadsheet, but the essential idea that is relevant here is that in terms of actual power generated, the stock fuel cell array produces something in the rough neighbourhood of a Gigantor solar panel at Kerbin (it's actually about a third less), and the stock solitary cell produces something approximately equal to the OX-4L at Kerbin (or any of the other deployable OX-Stat solar panels; they're all equivalent in power production). The reason that this is relevant is because you'll need to balance your fuel cells against the other power producers in the game: you want something that is of clear use in specific situations (such as stock RTGs near Eeloo), but not something that is the clear winner in all situations (such as a .002 tonne RTG that produces 5,000 EC per minute indefinitely). When converted to output per unit mass, the fuel cell array produces about 4,500 EC per minute per tonne and the singlet produces 1,800 per minute per tonne. Note that this does not include fuel mass, mainly because there is no way to predict it. The solar panels produce an average of 4,500 EC per minute per tonne at Kerbin (actual values vary between approximately 4,000 and 5,000; the Gigantor is a bit under 4,900) and a bit over 1,900 EC per minute per tonne at Duna. The inclusion of fuel lowers the overall charge per tonne and imposes a time limit, but the point was to show that stock appears to envision fuel cells as primarily outer-system power supplies (solar panels at Dres average at 560 EC per minute per tonne and it only gets worse from there). That being said, the solitary fuel cell produces 90 EC per minute and uses only .225 units of LFO per minute to do so. If we were to assume a monopropellant-derived reaction to power a fuel cell that had similar production and consumption, then the stock Mk1 pod and its 10 units of monopropellant would produce 4000 EC over a period of nearly 45 minutes at maximum output. I am inclined to think that this is likely quite good enough for a Mun landing, though I can see reasons to try something else. I'd not be inclined to use such a part for Kerbin orbital operations; a single OX-STAT panel produces 21 EC per minute indefinitely, and for most operations, that's enough--even when accounting for the fact that that is a static panel and rarely produces its full output. I don't quite follow your conversions for 'energy charge density'. I see how you got 80,000 for LFO, but lower density should not result in greater power; it should only result in larger tankage. The choice of reactants would affect power output, but that is not immediately related to the density. Taking LFO as an example, the fuel cells readily convert it into EC at a rate of 400 EC / unit of LFO. Since each unit is 5 kg, that makes an energy conversion potential of 80 EC / kg. If we assume that monopropellant converts at the same rate (which is a total conceit), then that would yield 80 EC / kg * 4 kg / unit = 320 EC / unit. To achieve the same power production, we'd need to run more units of monopropellant through the cell, which implies larger tanks. Your idea of air-breathing fuel cells is intriguing. I think that in that case, you'd still want an overall energy conversion potential of 400 EC per unit, but since you only need to carry the LF, the effective conversion potential is nearly 890 EC per unit (400 for LFO / .45 for needing to carry only LF)--but with the caveat that it only works in oxygen atmospheres. There are interesting possibilities for intakes limiting the rate because of their ability to supply oxygen.

Welcome to the cozy little group! I don't have much to add to @Vanamonde's advice; I will say that the Mun and Minmus present different challenges, but they are roughly equal in overall difficulty. Both present general piloting challenges for the early game: the Mun's is one of landing, and Minmus's is one of navigation. You can prepare for the Minmus challenges by learning to rendezvous two vessels in Kerbin orbit (especially so with one in an inclined orbit), and many people do that first. Since you asked about landing in particular, yes, Minmus can be easier on that specific point, but while Minmus has perfectly flat places, it also has its share of hills and uneven terrain. You need to select your landing site with some care (and pay attention to the area around that site--some players have wrecked landers on the slopes next to the flats). On the other hand, you won't learn unless you go, so give it a try. If you like, you can take pictures and post them in Mission Reports!

There are three popular ways to orbit Moho that I know aside from taking a monstrous amount of delta-V and trying a Hohmann transfer: One: Ignore the transfer window, and instead attempt to rendezvous with Moho's orbit at its ascending or descending node with Kerbin's orbit. Once there, burn retrograde to lower your apoapsis for an encounter with Moho on your return to this point. There are varying schools of thought on whether you should transfer to Moho's ascending or descending node, because the difference in velocities when you do finally encounter Moho can be large, but this manoeuvre saves you the trouble of needing to correct your inclination and usually makes capture to orbit easier. Two: Try for an Eve assist. This does not necessarily mean a gravity assist: though a double Eve gravity assist (meaning you transfer from Kerbin to Eve, fly by Eve a second time, and then go to Moho) can save a lot of delta-V, Eve (especially with Gilly) also makes a good staging point for a vessel. If it only needs to reach Eve instead of Kerbin, then it doesn't need quite so much delta-V in the first place. I've seen a few grand tour vessels that stopped the mothership in Eve orbit and sent a lander to Moho and back again. A miner on Gilly that generates propellant for your return while you go on to Moho makes this option even more attractive. Three: It's essentially the same as @VoidSquid's answer of sending a vessel with half the delta-V and mining equipment to make the other half. This is completely compatible with either of the first two options, but it changes your mission profile enough to merit a special mention. Whether you break that into multiple vessels is up to you, though it should be obvious that the need for orbital scanners complicates the mission profile somewhat without at least a detachable scanning module. I've seen people send miners that remained on the surface; I've seen stage-able mining equipment, and I've seen people bring it back with them. If you do choose this option, then remember that solar power is not necessarily the best option for Moho; the nights are more than sixty days long. Insofar as returning to Kerbin is a problem, I'd need to know more about your specific situation. What do you mean when you say that one mission worked barely? Did it nearly run out of propellant? Did you nearly miss the transfer? Was it difficult to find a transfer in the first place? The answers to these and similar questions help, and they will inform your next mission.

You'll have to explain it, then. If oxygen is the reactant, then it makes no sense to me that air, as a mixture of one-fifth the concentration, would have equal efficiency to the pure material. If nothing else, nitrogen occupies space and ought to slow oxygen's ability to pass to and through the cathode. Also, don't real fuel cells have a problem where carbon dioxide degrades them over time? At the least, an air-breathing cell would need CO2 scrubbers.

You can have both, but they are separate functions. Allow me to clarify: Autostruts are actual stock struts, but without the graphical component. In essence, they're invisible struts that do not increase the part count (they still have connections, so too many of them can induce lag). They come in three modes: Grandparent, Heaviest, and Root. Grandparent is the most difficult to describe, but the essence is that when you attach a new part to an existing part, the new part is the child and the existing part is the parent. If you attach an even newer part to the child, then that is the grandchild and the existing part is its grandparent. Grandparent autostruts attach to the grandparent of a given part. In other words, this mode attaches a strut two parts back in the build tree. Heaviest is straightforward, but you should avoid this except perhaps for launch-stage boosters. The identity of the heaviest part can change in flight--especially when docking--and the recalculation can cause destructive glitches. Root is also straightforward, but again should be avoided for anything that docks. I prefer to use it to connect the lowest launch engine in my core stack to the pod at the tip, because it helps with rigidity of the whole rocket. There is also a separate option (in the same part action menu as autostruts) called rigid attachment. It modifies the physical properties to make the joints less elastic. I typically use rigid attachment for side-mounted boosters and nothing else.

That's true. I'll add for the record that you can process each unique science experiment exactly once in a lab, so if the lab you have in Mun orbit has processed a lot of (or all of) your Mun science, then it will be advantageous to you to move it. When you do send a new lab, it has a clean slate, so to speak, and is not aware of which experiments were processed in other labs, so you can research the same set of experiments as many times as you have labs to process them. Some people consider this an overpowered game mechanic, but it is a game mechanic, and I'd be remiss not to tell you of it.

@bootsam: Almost all 'place vessel in orbit of' contracts require the vessel to be new. Be certain to check. To answer your original question, it can be done in stock, but @Geonovast has the truth of it: your options are the claw or a mod.

Then it's probably a decoy. Keep watch for hunters. Macabre pessimism aside, the hamster wheel is an EC generator, but the hamster itself is the fuel cell; it turns pellet fuel and oxygen into mechanical work and fertiliser--also entertainment, but I don't have the exact reaction for that. @zer0Kerbal: @VoidSquid is correct; the chemistry of fuel cells really doesn't work with monopropellant, so if realism is the goal, then that is not the solution. The other solutions will work well, though of course you will want to adjust the efficiencies for the different fuel-oxidant mixtures. For example, I would expect a pure-oxygen fuel cell to have far better efficiency than an air-driven model, though not necessarily five times better considering the heat production and the fact that the technology doesn't necessarily scale that way. Pedantry notwithstanding, the point to remember about the difference between the solitary fuel cell and the array in stock is that the array produces (and consumes) twelve times the output (and input) as the single cell, but it only costs six times as much and masses 4.8 times as much. That suggests to me that a significant portion of the mass and cost is in elements such as an essential control module of which you need only one, or in efficient packing that reduces the materials needed for the outer container. The array also only has six times the battery capacity as the cell in despite of its twelvefold production, so perhaps the rule at work is that larger arrays save somewhat on the cost by reducing the included battery capacity. Any way that you examine the problem, there appears to be an economy of scale at work that is more advanced than a simple first-degree curve. All of this is information that you appear to have incorporated, but I don't quite follow your choice of scaling factor: for example, your size .625 cell has essentially identical capability and mass as the stock cell plus an on-board fuel tank that the stock cell does not have, but at half of the cost. Why? Along similar lines, the size 3.75 cell has the same output as the stock array, but it has four times the mass, a bit over three times times the battery capacity, carries the equivalent of an FL-T300 fuel tank (if such existed), and only 150% the cost. I understand that the fuel tank would add some cost and mass to the system, but as I said, I don't understand the scaling factor at work. For another example, I would not expect your size 20 fuel cell to necessarily cost double or to have double the capability as the size 10, but rather expect it to be closer to four times as much, because--assuming that the height of the cells is the same--a twofold increase in diameter means a fourfold increase in cross-sectional area and corresponding volume. This is why, for instance, the 1.25-metre battery is the Z-1k with 1,000 EC, but the corresponding 2.5-metre battery is the Z-4k with 4,000 EC. I may be going into far too much detail and overthinking this, but I think that for a balance pass, I would choose to break the cells into their constituent components, scale the sizes and costs separately, and then add everything back together for a final value in order to preserve stock-like gameplay. Doing this doesn't need to be difficult: to wit, all KSP stock batteries have the same charge density, which is to say that they all have the same battery capacity per unit mass at 20,000 EC per tonne. I therefore assume that all KSP battery technology, including that in the stock fuel cells, uses the same standard. Similarly, all stock LFO tanks have a wet-to-dry mass ratio of 9, so that calculation is similarly easy: simply calculate the size tank that you want for your on-board fuel supply and add its mass to the final product. Monopropellant tanks do not follow that standard, but that's not insurmountable. Of course, the fact of it is that I'm not the one making parts to expand the game, so there may be a lot more that goes into the determination that I simply do not know. I think adding fuel cell capability is an interesting creative direction, so please do continue, and don't let anything I tell you be discouraging.

Additionally, you can shut off the reaction wheels, though that leaves you unable to right the rover when you do flip. As @bewing does, I prefer to disconnect the wheel controls from WASD, but I assign them to the number pad: 8 is forward, 4 is left, 6 is right, 2 is reverse, and 5 is brake. I've seen 0 used as the brake, too.

Welcome to the forum! To add to what others have said, normal career mode requires that the VAB and SPH be upgraded to level three before you have the numbered action groups; level two gives the basic ones (such as lights, gear, abort, and such) but not the numbered ones. Also, the VAB and SPH track this separately, so having a level three VAB and a level one SPH, for example, will leave you with no action groups for your aeroplanes.

Isp is dependent on the engine, and it is part of the tooltip for the engine in the VAB editor window where you select it. In fact, both the Isp and thrust are available in that information window without needing to right-click. Note that Isp is also affected by the presence of an atmosphere: the values given in the VAB represent a range from sea level on Kerbin to vacuum. TWR is dependent on the rocket, the engine, and the gravity of the celestial body. Since fuel mass decreases as the rocket flies, TWR changes in flight. I do not know whether the current version of KSP has a TWR readout to go with the delta-V readout; I use Kerbal Engineer for that information. MechJeb has it, too. For a stock answer, @Aegolius13 has it right; the gee readout on the right side of the navball will tell you the thrust-to-weight ratio. That works because the readout already accounts for the mass of the rocket, and since a standard Kerbin gravity is one gee, you have to divide the gees by one to convert it to a TWR readout (i.e. it's the same). It's of limited use: it only works once you're in flight and it's only accurate when you're pointed up. It seems flippant, but you'll figure out whether your rocket has enough thrust to fly by whether it falls to the pad and explodes, so that's another way. You're contending with atmospheric drag. You get more drag with more thrust, but you also get more heating. You can alleviate that somewhat by using less thrust, but then you spend more time and fuel fighting gravity because you take a while to get to orbit. The standard advice applies: make your rocket long and pointed. Put the fins on the bottom should you need them. Taper the size changes; don't have any flat faces pointing into the wind. Put everything that's not a fuel tank or a pointed pod in a fairing. Keep the fairing as close to the original diameter of the rocket as possible. For a rover, that often means that the best thing is to make it as small as possible. If it can fit in a service bay, then it won't need a fairing. Don't feel attached to the idea of a mobile base; a metal plate on wheels with a solar panel, a battery, and a command seat will work as a rover. Begin with that and then, once you have both a payload that works and a lifter than puts it in orbit, try scaling it to larger rovers. Eventually, you'll reach a point that you need to consider skycranes and underslung rovers, but work out how to fly a normal rocket payload before you start on the exotic stuff.

Indeed, there were. The World's Firsts Society offered the altitude and other milestones as contracts prior to version 1.0.5. The system changed to a passive rewards scheme for completing these milestones when contextual contracts and a few other features were added (such as the Leadership Initiative strategy for increasing the new passive milestone rewards). If I recall the rationale correctly, then the problem was that because the original World's First contracts were only offered until the milestone was reached, and also because Mission Control at level one can only handle two contracts at once, it was entirely too easy to miss milestone rewards. Putting aside the problem of permanently missed content, it rewarded a play style where you built a rocket that was only exactly capable enough to complete the contract, and no more--which is silly, especially since contextual contracts specifically depend on having satellites in orbit that can do more. Anyway, @arb8743: Welcome to the forum, as others have said. You get the world's first rewards simply for reaching the milestones, so feel free to build a good, capable rocket. I do not recall the altitudes that count for the milestones, but when you reach one, the messages tab at the upper right corner of the screen in flight mode (the one with the radio beacon icon) will blink with colours. It will tell you what you've earned.

Indeed, that is the case. I am not quite certain why I interpreted this statement: ... as meaning that you were having problems with your nuclear engines, but I did. That being said: It was not my intention to be rude. It may not account for much, but I did not perceive my remarks as being such when I wrote them. Nevertheless, you do have my apologies for any slight. Even unintentional hostility does nothing to further my purpose in posting, which is to provide help and information to those who ask for it (though I freely admit that my apparent inability to closely read your posts is quite frustrating to that effort). Let me try this again, and please accept my advance apologies for anything that repeats what was said above. My full reply is quite long, so I put a lot of it in spoilers: Of course, when you remove engines, there's a difference in thrust and attendant burn time, as you well noted. Part of our misunderstanding, I think, is the fact that the various staging options are generally regarded as launch configurations. Technically, I understand that long, thin rockets are the best designs for any situation with an atmosphere, provided that they will do the job. You may feel free to launch pancake rockets to your heart's content on Minmus and other airless bodies where drag does not exist. But long, thin rockets are not a balm for every situation, either, because: That is exactly right. Eventually, you will reach the limit of what one engine can do. Even a Mammoth, with its 4,000 kilonewtons of thrust, won't lift a rocket that weighs 4,001 kilonewtons (until it drains that kilonewton of fuel, that is). Clustering can assist with this, but there's only so much room for that. The only true solutions are either to cut the payload to manageable pieces and assemble it in space, or to accept that the limitation of thrust is an inherent trade-off of inline staging and that to get anything larger into orbit, you'll need a different scheme. The amount of delta-V lost to drag depends on the cross-sectional profile of the rocket, its orientation into the air stream, the thrust with which it attempts to plough through the atmosphere (airspeed, essentially), and the pressure and density properties of the atmosphere itself. There are probably other elements, as well. Drag's importance is less of an issue for delta-V and more a matter of balancing the forces on your rocket. If you imagine the thrust from the engine acting as a lever that works through the rocket's centre of mass, then you'll see that it is necessary for that thrust to point directly through that centre to keep the rocket from spinning out of control. Since you've been moving asteroids about, you've experienced this first-hand. The forces involved in that do not need to be large: most engines that gimbal have a gimballing range of less than five degrees. For longer rockets, five degrees is too much. In like fashion, tiny drag forces can cause a rocket to flip out of control; this is why fins at the fore are normally a bad idea. Fins at the rear can help keep a rocket stable, but there is also such a thing as too stable, because too much stabilising drag can make the rocket difficult to turn. Under the old (pre-version 1.0) aerodynamics, drag was so much worse that it cost over a thousand more metres per second just to reach orbit (roughly 4,500 m/s versus the present roughly 3,400 m/s). Furthermore, it was practically necessary to lift off vertically for the first ten kilometres and then make a sharp turn to forty-five degrees. You cannot do that with a current-version rocket and expect not to flip out of control and crash. But this is also the reason why so many posts and threads (especially old ones) sing the praises of asparagus staging: under that aero system, a staging scheme that had high thrust and kept high mass ratio was the best way by far to plough through the atmosphere and still have enough fuel to get to orbit. Under the current system, it is not that asparagus staging is bad, but rather that it is reduced to an equal footing from its original status as the clear winner over everything else. I'm guessing that you mean fifty tonnes of payload delivered to space, not on the pad. If so, then yes, that's a lot of Skiffs! Consider looking at the Twin Boar; I think that it unlocks in the same node as the Skiff. It's expensive, but it provides a lot of rocket for the price. If it's a mission or a challenge to do it with only Skiffs, then you may consider clustering. Do Skiffs surface attach?

@Aegolius13 did a good job of explaining the rationale; I'll just give you some basic categories. As a very rough thumb rule, engines with an atmospheric (not vacuum, for once!) Isp of less than 250 seconds are usually vacuum engines. Engines with atmospheric Isp greater than 275 are usually good sea-level lifting engines, and engines with atmospheric Isp between 250 and 275 can fit either role, albeit not necessarily so well as more specialised engines. To refine that, if an engine has a vacuum (note that this time, it's vacuum, not atmospheric) Isp greater than 320, then it is probably a good choice for space. If you want to pick an engine with an eye specifically for launching, then try for one that has an atmospheric thrust of greater than 100 kilonewtons (kN). The Thud is arguably the worst choice that still follows this rule, the Rapier is a niche engine, and the Rhino is actually best in vacuum (you can tell because its atmospheric thrust is about 60% of its vacuum thrust, whereas most launching engines have between 85% and 90% of their vacuum thrust at sea level), but it has good properties on the ground, too. The others all are good choices for launch stages. SRBs don't follow the Isp rule: they have low Isp in any situation, and are best suited to the launch stage. Don't attempt to use jets in space. You can try, but you'll be disappointed. That's not to say that many of the remaining engines do not have specific niche applications that defy these rules, but the rules will probably get you to your destination with a minimum of trouble. Concerning thrust-to-weight ratios, it depends on the celestial body. More is often better, but when an atmosphere is involved, you need to consider drag (usually not a problem unless your rocket is not streamlined) and heating. For rockets launching from Kerbin, I typically design for a TWR of between 1.3 and 1.6. You can get away with anything from 1.2 to 2.0 provided you design the rocket well. TWR values under 1.2 take too long to get up to speed (and they waste too much fuel fighting gravity during that time), and values over 2.0 tend to get too hot in the lower atmosphere. For airless bodies, it's simpler: I generally try for a TWR of more than 2 for the body I'm landing on. Remember that a rocket weighs less in weaker gravity, but an engine's thrust is constant for a given throttle setting: a TWR of 1 on Kerbin can be 6 on the Mun. SRBs are terrible engines insofar as efficiency is concerned, but they are the cheapest engines available. Use them in the launch stage, either on their own or as a low-cost way to increase your rocket's TWR without resorting to a complete redesign. When you have a choice of engines, the usual method is to burn your least efficient engines first and go in order from there, and SRBs are no exception. When designing your initial launch stages, don't neglect the Twin Boar. It is also extremely cost-effective for the thrust that it delivers, and unlike SRBs, it isn't utter rubbish in the upper atmosphere.

But the rigid part of the pendulum--the steel bar--is still free to rotate about the fulcrum on the bearing. That rotational degree of freedom is the necessary part. My apologies if that was unclear; I cited flexible cables specifically because that's what real sky cranes use.

It's not a fallacy when it's an actual pendulum. The reason that the pendulum fallacy is a fallacy is because it involves the idea that a rocket essentially dangles from its tip because of gravity. Aside from having no answer for what to do once it reaches free space where gravity is effectively nil and the concept of dangling needs to be redefined, there is the problem that a rocket is a rigid body, but a pendulum is not. In order to work, a pendulum must hang freely from a fulcrum and be subject to forces external to itself--specifically, forces that are transmitted through the fulcrum one way or the other. Normally, that's gravity on the pendulum and a normal force transmitting through the fulcrum, which is to say that the fulcrum holds the pendulum up against the pull of gravity with an equal-and-opposite force. While it is true that a rocket is subject to gravity, it's also true that both the gravity and its own force of thrust work through the rocket's centre of mass (meaning that they work on the rocket in its entirety), and that it dangles from nothing. In like fashion, a fulcrum under thrust or acceleration of some kind can be the fulcrum for a pendulum provided that the force on the fulcrum is transmitted through it to the pendulum. A force that operates equally on both won't work, which is why a pendulum-driven clock won't work in free fall--the force is not being transmitted through one to the other but instead acts on both fulcrum and pendulum directly. The technical term is restoring force and it refers to the tendency of a pendulum to hang along the gravitational pull so as to minimise its potential energy--i.e., the swinging action restores it to vertical. A hanging object that generates its own force is no longer a pendulum, because the direction of the force changes orientation as the object does; it's no longer restorative. A sky crane, on the other hand, is an actual pendulum because the rover hangs by a flexible cable and the force behind the hanging is gravity or an acceleration generated somewhere not on the payload, but still transmitted to the payload through the cable. It's either from the rockets on the sky crane (which would be a pseudo-gravitational acceleration that impels the payload to hang) or it would be gravity itself if the crane is landing the payload on the surface of some other body and there is a hovering element involved in the landing. On the gripping hand, a pendulum-like rocket would work just fine if the payload hung from the force generator by a flexible attachment and the force generator kept its orientation in despite of any motion of the payload. That's the operating theory behind Medusa rockets (they're like Orion, but with the nuclear bombs going off in a sort of shroud in front of the rocket), or, for that matter, parachutes.

For your information, I never lean out the window in space. I'd get my helmet stuck on the frame! Theoretically, the limit for a rocket with infinite fuel in KSP tanks and a massless payload is 6,895.2 m/s of delta-V, to be exact. Also, I made no provisions for your choice of transfer trajectory or destination; my theoretical rocket can't lift off from Eve, either. That wasn't really the point. Neither was my point to say that staging has no value in the face of larger tankage. My point is that larger tankage, in space, solves the same problem that asparagus staging solves on (or very near to) the ground: making more propellant available to the engines. I treat the asparagus-stage need for more engines, as well, to be a specific use-case application of drop tanks in a gee field too strong to otherwise support the increased fuel load. That said, drop tanks, as I indicated, do have a use, and they work very nicely in those applications where manipulation of the dry mass portion of the mass fraction of the rocket is necessary to achieve a desired outcome--namely, the one where every element of the payload is essential across two or more stages. Being able to remove dry mass from a rocket is the only way to overcome the problem of diminishing returns: you diminish the rocket, instead. Nevertheless, the point is well taken; I will endeavour to be more precise in the future. It's more that asparagus staging isn't necessary in space. You don't need fuel lines and you definitely don't need extra engines because you're not trying to go straight up against gravity. If you were seeing bad results from the nuke engines, then there are two likely reasons for that. First is that your rocket was too light--three tonnes of engine on one tonne of payload is a lot. Three tonnes of engine on thirty tonnes of payload is a lot less of a dry mass penalty, and gives the nuke a chance for its higher efficiency to work for you. Second is that you were using rocket propellant tanks instead of liquid-fuel-only tanks. That not only gives you a reduced fuel load, but also several tonnes of dead weight in oxidiser. Even draining the oxidiser would still leave you with less than half the fuel in a too-large tank. Let me ask you this: are you asparagus-staging rockets that have only two or three stages, or are you speaking of a ten-stage monstrosity? Every staging scheme has its benefits and its costs. Traditionally, there are inline staging and side-along staging. There are some variants such as onion staging, and asparagus staging is a sort of hybrid. Inline staging (like the Saturn V) has the benefit that when each stage empties and is jettisoned, the remaining upper stage is fully-fuelled. This works well for the Saturn V because it gives the benefit of full burn time for each booster but at a cost of reduced thrust on each stage. However, the reduced thrust is okay because the upper stage engines are optimised for the region of the atmosphere in which they were meant to work; there is no benefit from burning all of the stages at once (assuming that it could be done without rapid unplanned disassembly). Side-along staging (like the Delta IV Heavy) has the benefit that all of the engines (core and two boosters), burn at the same time, which increases thrust (by about three times, assuming my arithmetic is still good). Putting aside the throttle trickery used by the actual Delta IV Heavy, the net effect is that when the boosters empty and stage away, the core is left partially empty and thus suffering from both a higher dry mass in the mass fraction and reduced burn time because of the lack of fuel. Onion staging (I don't know of any rockets that actually use this, but I don't think there's any reason they can't) is actually a variant of inline staging. Envision a rocket like the Delta IV Heavy, but instead of lighting all three engines, imagine that only the outer two are lit, and when they are empty, they stage away and the core is lit. The name comes from the idea that the outer boosters fall off and leave the inner ones to burn anew, much like peeling layers of an onion. Note that it looks the same as the side-along-staged Delta IV Heavy, but it merely appears similar to side-along staging because strapping the boosters to the sides helps with symmetric thrust. You get the same result when you attach the boosters to a bicoupler or the like and achieve a more inline look. In essence, we can even go so far as to say that inline staging is the degenerate case of onion staging when there is only one additional booster in each stage. Its benefits and costs are the same as for inline staging, except that when there are multiple outer boosters, they do have the advantage of some increased thrust (though technically the same effect can be achieved with clustering and taller or more numerous propellant tanks). Asparagus staging works by the boosters sharing their propellant with all engines inward from them. Practically, it is a series of powered supplementary propellant tanks--meaning that the tanks lift their own mass against gravity rather than your core stack needing to lift their mass in addition to the rest of the rocket. This means that, in the Delta IV Heavy example, all three engines are lit at the start, but you'd see the outer side boosters stage away much sooner. The core engine, however, would have the benefit of full burn time because until that point, it would be running on propellant flowing in from the outer boosters rather than in its own tank. In this way, it combines the advantages of high thrust and high second-stage mass fraction, but at the cost of increased drag (there's no inline form) and much-reduced stage burn time. Because the core stage burns (usually with a full propellant load) the entire time, this is a problem with efficiency in the new aerodynamics model because first-stage engines get to be quite inefficient compared to their vacuum-rated counterparts once they get over ten kilometres. The old model had an atmosphere thick enough to require high-thrust engines quite a long way, and it also calculated drag in a weird way that actually justified pancake-shaped rockets (drag was calculated per-part and paid no attention to orientation, so nosecones, for example, increased the part count and thus increased drag). It made sense in some cases to have many-stage rockets that were wider than the launchpad just to get to orbit. Now, the atmosphere is thinner (such it takes 1,000 m/s less delta-V to reach orbit), and the aerodynamics reward long, thin rockets. If you need extra thrust in the first stage, then solid rocket boosters provide that at a bargain. Asparagus staging, on the other hand, requires a wider rocket and involves extra parts that are also extra-draggy parts. It still has applications (Darts enjoy good efficiency from the surface to orbit, and high thrust, high second-stage mass-fraction rockets are a practical application for a lot of situations--Eve ascent is the crown of them all), but it is no longer the champion Über-rocket that it once was. However, in space (which was your original question) it is normally a waste to haul engines that you do not absolutely need. As with anything, there are applications, but few to none for asparagus staging once in orbit.

Not as such, no. Putting aside the question of how you get an asparagus-staged rocket to space in the first place, once you are there, the rules are a bit different from the situation that would necessitate asparagus staging on the ground. The main advantage of asparagus staging is that it was essentially a way to run the core along with the boosters while still expending only booster propellant. This does two things: it gives a lot of thrust, and it also leaves you with full propellant tanks after each staging event. In space, there is little need for high thrust. It helps in certain applications--the Rhino is a vacuum-rated engine and it has a proper niche--but it's not strictly necessary in the way that it is necessary to have high thrust to get off the pad at launch. However, having full propellant tanks after each staging event (or, more accurately, staging away empty tanks rather than carrying the tankage dead weight) is useful in space. That's already a concept; it's called drop tanks. The idea is that you have one engine (or cluster, or however you're moving your rocket) feed from a series of tanks, and as each tank empties, you stage away the empty dead weight. This works in applications that need it, but in many cases, it's just not necessary. Part of the reason for that is that it doesn't take a literally astronomical amount of propellant to get anywhere in KSP. Another part is that staging away the empty tank improves your mass fraction by the mass of an empty tank--i.e., not much if it's a large rocket. Small rockets benefit more, but in those cases, it's trivial to add significant propellant mass fraction. A small probe on an FL-T800 tank with a Spark engine can go nearly anywhere. The same probe on an S3-14400 tank can go anywhere ten times. There's no need for staged tanks when you can simply use a larger tank.

Goddard himself built the first liquid-fuelled rocket with the engine on top and the tanks on the bottom. When it comes to making mistakes with rockets, you're in good company.