Plusck

I haven't checked this recently, but I'm pretty sure the "mass" of the strut attaches to the first part you click. It isn't a huge difference, but if you're trying to get rid of excess mass by ditching boosters, you really want to ditch the strut mass too. Therefore struts should always be attached, first,0 to the bit you're jettisoning. Right?!? Of course, there is the added complication that struts don't want to snap properly for the second click, but I've found that the offset tool (with snap on) does work fine on them. You just need to get a "good grip" when you first place them, so be careful to have a good line-of-sight between the two strutted parts.

No, no, the Mun's orbit is perfectly equatorial, with respect to Kerbin. In that it is quite different from the Earth's moon. However, it is very easy to end up capturing at the Mun on a highly inclined orbit due to a very small deviation from the equator on leaving Kerbin. The answer is simply to plot a correction burn about halfway out to the Mun. Even a very big inclination can be fixed with only a few dozen m/s. In addition, if you play about with the radial and prograde sliders, you can easily make it so that your insertion happens exactly where your orbiting station will be, so you can rendezvous with it as soon as you arrive.

I think it's an essential lesson, that is relevant to what we puny humans do as we try to emulate the Kerbals. If you're going up high, you do NOT want to go vertically up, since that means coming vertically back down. Going up, your vertical speed is limited by gravity pulling you back. Coming back down, the only limit is drag; if there is hardly any atmosphere, there is hardly any drag; it is easy to go supersonic just by falling; parachutes aren't very good at dealing with supersonic airflow. So don't fall vertically, ever. You need time and/or distance in the lower atmosphere to slow down, and the only way to get that is to go sideways. It is said that it isn't the fall that kills you, it's the sudden stop at the end. When it comes to the very highest skydiving records, however, when you end up tumbling wildly at supersonic speeds with no way of stabilising yourself or slowing yourself down, it can easily be both. And if you're in a heavy pointy metal box, rather than a light and floppy pressure suit, that uncontrolled tumbling will invariably become a dart-like bunker-busting trajectory as you zip though just a few seconds-worth of heavier atmosphere.

You need about 600 m/s dV to circularise at Duna. Since getting back from any other planet or moon orbit always needs exactly the same dV as it took you to get there to start with (assuming you're inserting efficiently, then burning back home efficiently), that means you need about 600 m/s to get home. Assuming you have a single pod, parachute and heatshield (which you can easily reduce to about 20% ablator for a return from Duna), plus the usual antenna, science, battery and solar panels, that means you need (1) a Terrier or Spark engine, and (2) either exactly an FL-T100 or only slightly more fuel, to get home. With an FL-T200, you have about 1500 m/s: enough to circularise and return with a very decent safety margin. That means that whatever else you do while at Duna, on leaving Kerbin you want to have a full "return stage" consisting of the above Mk1 pod, FL-T200 fuel tank and Terrier engine, ready to take you back. Or if you are using the 3-man pod, you want the smallest 2.5m tank plus a Poodle. You say that you're getting there easily enough. Therefore the obvious answer is droptanks. A Mk1 pod (plus parachute, batteries, solar panels, battery and 20% heatshield), with an FL-T200 and Terrier underneath, flanked by a pair of jettisonable T200 tanks (with nosecones front and back), will give you a massive 3100 m/s dV. If you can get that to orbit, you can orbit Duna, land on Ike and return to Kerbin, easily. I'm sure you've sent heavier ships to the Mun. As always, the thing is to shed as much mass as possible. If you can throw empty fuel tanks away, do it. If you use boosters, place fuel tanks on them and make sure they drain fully through your main engines at as close to exactly the same time as you have to drop the boosters. I'm sure you've already been to Minmus and back with a lot of fuel to spare. Going to Duna shouldn't be a problem, as long as you keep the mass down. One easily understandable tendancy is to try to do a lot more than what you've done for Minmus, just because it's so much further away. Don"t. It's not a huge leap from Minmus to Duna, it just looks like it

I've only ever used KER, which does a fine job of telling you exactly how off-axis your thrust is. There are other options, but I haven't used them. I'm assuming that your base will land horizontally (otherwise you wouldn't be having these problems). This probably also means building the lander/base in the SPH. 1) The first tip to make sure your base/lander/whatever is balanced and stays balanced is to use a fuel tank as your core. Then you hang your engine(s) to the core using symmetry with snap ON, and then offset them (with snap still on). They will snap to the exact centre of your tank. To hang the engines, you can radially attach smaller fuel tanks and rotate them down, or use the cubic struts (I tend to go for tanks, or octagonal struts). Then you start attaching everything else to your lander/base and try to balance it as best you can. If you enable the CoM and CoT indicators, you can guesstimate the balance fairly well. Just don't ever move the engines off that central snapped line. Once you"ve got everything more-or-less sorted, you can easily test it on the runway at Kerbin. Simply swap out the engines for more powerful Kerbin-atmosphere-capable versions, turn off gimbal and try to see if you can fly it around. If it works like that, it'll work elsewhere with the less powerful engines (and gimbal, if you have it). 2) Next up, you need to balance it for going up to orbit. If you're using KER or similar tools, simply attach a fake earlier stage to the back, and check the thrust offset numbers. If you're not, then you need to repeat the balancing process in the VAB. Attach an atmo-capable engine and fuel, and then using the CoT and CoM indicators, move things around carefully. The easiest thing to move here is your engines (+symmetrical radial fuel tanks). This time, turn snap off and don't ever touch the slider that might move the engines off that centre line. I've made quite a few belly-landing craft like that. I even did quite a few before installing KER, so it definitely works to get a reasonable system just using the built-in CoT and CoM indicators. (edit: just remembered another couple of things...:) 3) Knowing which items can shift the mass around and which will simply add mass to the part they attach to is also a help. For example, all of the surface mounted batteries and most science instruments (but NOT the goo and NOT the ore analyzer) add mass only to the parent part. Move them from part to part to alter balance, by all means, but on any given part their location is irrelevant. 4) If you have an external command seat, you need to balance it somehow. The mass of your Kerbal will be taken into account when using the seat. The solution I use is to add an Oscar fuel tank on the opposite side to the seat, and fill it to about 1/2 with locked-off fuel when there is a Kerbal on board, and empty it when there isn't. A very scientific process... 5) Belly-mounted Vernor engines can save you if you're imbalanced. If I use them, I assign two action groups to (1) toggling monoprop RCS thrusters on/off and (2) toggling the Vernors on/off. The monoprop thrusters are for docking, the Vernors for landing/surface movement.

Definitely this one. But first: I find reaching orbit in a plane on Laythe far, far easier than on Kerbin, much easier than the dV maps seem to suggest. The annoying thing on Laythe is how much you need to spend to get free of its SOI afterwards. However, that annoyingly high escape velocity also implies a high Oberth benefit from your low Laythe orbit burn. As with Kerbin, burning hard out from low Laythe orbit will reap great dividends for escaping the Jool system. I can't remember the exact figures but it is much less than the dV map suggests. Land and re-orbit as efficiently as possible, and you might well still make it home without any gravity assist. Next: gravity assists: You only need one, which is Tylo. Passing close by Tylo (tangentially, passing in front) on entering the Jool system can get you (for free!) into orbit around Jool with Pe near to Laythe and Ap a bit higher than Tylo. There is therefore no reason not to do the reverse: leave Laythe so that you catch Tylo when it is approaching the point where it would eclipse the sun, pass (very close) behind it, and you'll be thrown out of the Jool system retrograde. For minimal expenditure (perhaps a small burn in low (≈100km) Tylo orbit), you are guaranteed a Kerbin intercept. Travel time from Jool to Kerbin is so long that you can leave at any time; minimal corrections to your path can easily change your Kerbin intercept time by months. The only possible concern is if you have poor heatshielding, since minor corrections can make a significant difference to the speed at which you hit the atmosphere on arrival.

Yup, definitely as swjr-swis says, which also applies to any other multi-node engine plate or stack splitter: they really aren't a good idea if you plan to add anything below them, since each node is necessarily weaker and only one node will ever connect to any item placed below them. Bearing in mind that craft have a tree (parent/child) structure. Therefore each node on that engine plate will connect to one engine. Only one engine can then connect to the decoupler below it, which then connects to the tank below that. So it's a 1.25m node connecting to the 3.75m node on the decoupler, far too weak to resist bending.

That is a massive amount of bend there. First off, I do get the impression you're trying to do too much, too soon here (/me plays The Specials "Done Too Much..." in the background). I feel you're trying to put too much rocket into space, all at the same time, which tends to produce disaster. The next thing is that your SAS is trying to stick to "radial out" while you're still in surface mode on the NavBall. In itself that's not a problem as such... but the SAS takes its current heading from the "control from here" part, which is certainly at the top of the rocket. With all of the bend down lower in the rocket, the bottom is going to be significantly behind the times; therefore the top says it's going one direction, the bottom tries to correct, overcompensates, and then when the top realises it's going in a different direction the bottom is still in mid-swing; the top tells the bottom to reverse direction and it takes a second or so to do so. The end result is mad swings at the bottom until it ruptures. The only solution is to create an aerodynamic rocket and leave SAS off: aerodynamic forces keep the rocket facing the right way until you get rid of the bottom stage and have proper control. With such a massive amount of bend, I also wonder what is actually connecting those tanks in the core section. I can't see much from the pic, but I suspect there may be something between the big tanks there. One thing that people often try to do is to put a big torque wheel in between two large tanks. The reasoning is clearly that the torque should be centrally located to turn the craft. That is fallacious since it doesn't matter where the torque wheel is (if you have nothing solid to push against, torque wheels have exactly the same effect wherever they are located on the craft) and often disastrous because you're adding two separate connection nodes in the middle of what needs to be the strongest joint, thereby tripling the amount that the joint can bend. So if that is actually the case, get rid of it. Keep the minimum number of joints in the core stack. Join one huge tank to another huge tank and do not ever put anything else in the middle. And finally, to sort your problem, disactivate gimbal. In the VAB, go to the action menu, choose a number (I always use key 7 for this, on every craft, but you choose your own system) and then click on every single engine and choose the "toggle gimbal" option. As long as your craft is going in the right direction, gimbal is unnecessary and should be toggled off. When you need it, toggle it on. If the craft starts oscillating, toggle it off again. Gimbal is indeed a Good Thing on rigid craft, but it is a killer on any wobbly one.

The problem - as I see it - is that your question is essentially unanswerable. There is no possible "efficient" solution if the starting position includes both (1) a 9:11 LFO mix, and (2) Nukes (any number). Each engine has a "peak efficiency" curve. Or rather, several such curves depending on the variables that you are measuring efficiency by. The variables you can use are firstly payload, TWR, dV. Then secondly cost, fuel mass, playing time, required additional equipment (i.e. part count), elegance. From the first three (payload, TWR, dV) pick one as a fixed variable, and then you can relatively easily plot the other two as a curve. And good example of this is here: https://meithan.net/KSP/engines/ It's a bit old now, and some engines might be wrong, but the principle is sound. This is the graph for a 40 tonne payload: Each "step" in the graph represents an additional engine. So you can see that for this 40t payload, if you want more than 0.5g thrust, nukes are only the best option if you have 7 or 8 of them. And you intend to run them for a dv of about 1800 - 2500 m/s. So the trouble with nukes is that they are so heavy that they need to keep burning for quite a while before their efficiency makes up for their own mass. Or the payload has to be so big that the mass of the engine becomes less relevant. And in all cases, if you start looking at the other "efficiency" variables, such as cost, manouverability, low part count and so on, there will always be a better option, and that option is often the Poodle... And if you have to start calculating how much extra liquid fuel you need to carry to balance the LFO mix burnt by one of the chemical rocket engines, you lose that last possible efficiency benefit: your playing time. The pic above doesn't show you the next best option, but you can see that if you follow the link and use Meithan's tool. In most of the usual scenarios, that second-best option is either the Aerospike or the Poodle. One of those two has a distinct advantange for cost and manoeuverability (and therefore part-count); no guesses which... So, no, there is no real answer to your question. If you want to move a big orange tank somewhere, you definitely don't want to use a nuke to do it. If you have nukes onboard already, you'd be best ramming them into something and destroying them so you can lighten the load. However, creating a nuke tug is definitely a good idea. Create a re-usable, drag-and-drop nuke-based interplanetary booster, with radiators, drop tanks, torque wheels and suchlike, and you will definitely end up with a very efficient system, certainly better than any LFO alternative (at least until the Rhino becomes a reasonable option, for huge ships). But don't try to mix it with any LFO engine, you'll waste either the benefits, or your time, or both.

The only time I managed to land "properly" on Duna was with a very light plane with lots of wing, in KSP version 1.1.3. Definitely not able to SSTO from Kerbin. I can't find any screenshots of the plane on the ground but the number, and names of, the savegames I made at the time are telling: 131 Duna glider 3rd attempt.sfs 131 Duna new glider landing.sfs 131 Duna planes arrival.sfs 132 Duna glider crashed.sfs 132 Duna planes better arrival.sfs 132 Duna planes final arrival.sfs 132 Duna planes post burn.sfs 133 Duna glider better crashed.sfs 133 Duna plane landed upright.sfs ...

Learn to suicide burn. : D I'm sure everybody has their preferred method. The latest versions of KER even give you a big red target and the exact countdown and dV requirements to do it. Still, I find it much more satisfactory to do it all manually. So here goes: First, get into a low-ish orbit. Look at your orbital speed. That speed will rise the lower your orbit is, so just add a bit and you have essentially the dV requirement to come to a stop down on the surface. From that, your requirement to come to a dead stop on the surface of Minmus should be obvious: somewhere in the 170 to 190m/s range. Next, start a quarter orbit ahead of your landing zone. Plot a node to hit the surface. Plot another node where you hit the surface and drag the retrograde vector until the resulting Ap starts to move back up your trajectory. Then burn that first node at full power. Don't try to get it exact, just watch the map and cut off the engines when it's more or less right. Delete the node. Look at the node on the surface and make sure it's just above the surface. You should now have a time to that surface node, plus a number which should be in the ballpark figure of 170-190 m/s, plus a burn time. If you did the last burn at full power, that burn time will be exact (if you have the latest version of KSP, that burn time should be exact even if you didn't burn at full power, but I prefer to be safe than sorry). When you are about 2/3 of that time away from the node, point retrograde (with retrograde hold) and burn at full power. When under 10m/s, stop and let the craft swing towards the vertical - the ground should be just a few dozens of metres below. Ramp up power slowly until you fall at 3-5 m/s constant. Why 2/3? Well, that comes from the basic relationship between distance and acceleration. Under constant acceleration from 0 to x m/s, you will travel exactly half the distance that you would travel if you were going at x m/s to start with. S = ut + 1/2 at2 and all that. On deceleration it's exactly the same thing, you'll travel half the distance that you would have travelled if you stayed at the same speed. So basically you could wait to exactly half the time to your surface-striking node and burn, but the problem is that as you slow down, you start heading towards the ground as gravity kicks in. Therefore you need to add a bit of time to avoid hitting the ground. But any additional time will be time that you need to hover and waste fuel. Therefore 2/3 is roughly the right amount: if gravity is strong, you survive with minimal gravity losses; if gravity is weak, you hover for longer but you don't need to care so much about it since gravity losses will be small. With that technique, your total dV requirements to land from low orbit will be just a few percent more than the classic "dV map" figures. My hardest landing was on Moho when I had no other refuelling options and about 950 m/s left on my mining ship. It took a few tries but I made it...

I wouldn't bother with that. Radiators are good for dealing with heat that builds up gradually and can be dissipated over a long time. I haven't tried any spaceplanes with the latest couple of versions of KSP. In earlier versions radiators could be useful to stop Mk 2 cockpits from blowing up, since they slowed the heat spike just enough to survive reentry heating. However, for your case I'm not sure it would do any good, certainly a lot less good than a functioning heatshield and good reentry. And while we're at it, you definitely don't need to weigh yourself down with all of the ablative on the default heatshield. 20% is perfectly enough to survive reentry from anywhere within the Kerbin system. However, if you reduce the ablative you reduce weight, so again think carefully about weight distribution and CoM while you have a science module attached to your craft. As @Rocket In My Pocket clearly said, going on EVA, taking the science and then just dumping the science module is by far the easiest solution. Which again shows how varied the possible solutions to your issue are! No need for thanks, I suspect most of the people who respond to such questions live for this

I'm a bit confused by the pic, because I can't see a decoupler between the Flea and the science module. I've tried recreating your craft and the only way I can get it to look like the pic is by NOT having a decoupler, removing the Shroud from the heatshield, enabling staging for heatshield jettison, and offsetting the Flea upwards. If that is actually what you've done, that stage 1 is actually you getting rid of the heatshield altogether. You'll find it very hard to maintain a retrograde approach on re-entry because (1) if the flea is still attached, it's very light and will act perfectly as draggy feathers to your pointed pod, and (2) once you jettison the HS, your science module is very light and will do exactly the same thing. Plus your science module will probably blow up from excess heat. It is quite possible to return from orbit with a heatshield, science module and pod, but it's tricky without retrograde hold. The slightest deviation from retrograde once drag kicks in (and remember this is surface retrograde, not orbit retrograde, so click on the navball to get it in the right mode) will be almost impossible to recover from. Frankly, the simpler solution is to get your pilots to do one full orbit each, so they gain the skill to use retrograde hold, before attaching the science module to your craft.

You should do a search for "Gate Orbits". Basically, for any given interplanetary transfer you need to escape Kerbin's SOI with a given excess volocity (V∞). For any given V∞ there is a given altitude at which you need the least amount of dV to attain that excess velocity. For Eve and Duna, that altitude is around the altitude of the Mun, so it is definitely useful to start from there with full tanks. From memory, the altitude for Jool is somewhere in the 200-300km range. And for Moho or Eeloo it is at or lower than the top of Kerbin's atmosphere. Therefore, starting at the Mun for those destinations is no benefit, other than the obvious benefit of having full tanks before you leave. For example, for Duna you need to burn for about 1100 m/s from LKO, but only under 700 m/s from a 12,000 km circular orbit. Of course, from Mun orbit you need to escape the Mun's gravity, which will increase that figure a bit, but you also benefit from the Mun's contribution to the Oberth effect. So you should still save roughly 400 m/s or so going directly from the Mun. For all of the above, I'm talking about making the escape/interplanetary burn directly from Mun orbit, so you leave the Mun's SOI going very fast and prograde. Good for Eve/Duna, not so good for anywhere else (especially Moho, since you really need to align with the inclination of Moho's orbit, making it doubly expensive). On the other hand, diving down from the Mun to a low pass at Kerbin to make your ejection burn will always save you about 550-600 m/s (assuming full tanks). The 250m/s burn to escape the Mun and return to Kerbin is "wasted", but once you're at Kerbin you'll already have the equivalent of a 850m/s burn under the belt, as it were. So it's definitely worth doing this for Jool (and for Moho, Dres or Eeloo if you can be bothered getting the inclined orbit right), while for Eve or Duna you just need to decide whether the additional planning time is worth the ≈150 m/s difference compared to just burning straight out from the Mun.

If you can't aerobrake, the capture on return from Moho should cost you exactly as much as it cost to make the burn on the way out. From memory, that's about 2400-2600 m/s. If it's much more than that, your approach is wrong. Also don't forget you can reduce some of that capture burn by using the Mun to give a gravity assist. The very easy (and second most efficient) way of getting to and from Moho is on AN/DN with respect to Kerbin. You want to arrive at (and leave from) Moho when it is at its AN/DN that is closest to the sun.* Obviously, also, you want to start the burn as close to the planet as possible to maximise the Oberth effect. You also want to include the plane change with that initial burn (unless you're aerobraking on arrival, in which case you don't really care about the plane). (* this is because Moho is going faster, therefore the difference in speed between your transfer orbit and Moho's orbit is at its lowest. When Moho is nearer its Ap, it's going a lot slower and you need a whole lot more dV to make the transition between Moho's orbit and your transfer orbit) It doesn't much matter where your destination planet is when you start, because it is pretty much guaranteed not to be where you want it. You simply can't make a direct transfer, so instead you need to go round the sun for a whole extra orbit and use that second pass at Ap or Pe to time your arrival perfectly. Going from Kerbin to Moho is easy: match the plane almost perfectly, with your Pe just touching Moho's orbit, then when you get to Pe plot a retrograde burn that perfects the plane and makes you hit Moho at Pe the next time around. Going from Moho to Kerbin is trickier. Either you plot the exact reverse (which is finicky, since you need to plot that second burn in sun orbit at Pe while you're still in Moho's SOI, at virtually the same location) or you have two other options: (1) plot the burn to touch Kerbin's orbit but only do about 1/2 to 3/4 of the resulting burn, then wait until you're in sun orbit to plot the two burns that will get you up to Kerbin's orbit at exactly the right time one orbit later, or (2) plot the same burn and do it all, then at Ap add a prograde burn to catch Kerbin the next orbit around. The second option adds a lot of time to the return trip. The harder (and most efficient) way of getting to and from Moho is via Eve. It's tricky, because AN/DN between Moho and Eve is not anywhere near AN/DN between Eve and Kerbin, so the plane change that you can get from passing by Eve is only part of the plane change that you'll need to make to get an intercept trajectory. Still, if you get it right it does give significant savings and a much lower capture burn at Kerbin if you can't aerobrake.

I've developed a habit of taking every single LKO rescue contract, and trying very hard to minimise cost and time to get them done. The rescue orbits are probably a bit lower than where your station is, but it won't change much. If anything it's easier to correct if you wait too late to start, since you can use a lower orbit to catch up. Still, the method is: on the launchpad, select the station as target and right click on it so that you can see the "distance" to you clearly. warp ahead until the target is between 250 and 280km from KSC. If your target in a higher orbit, add a bit (so for a 150km orbit, I'd add about 50km to those numbers). Seen from above, the target should be a bit more than halfway across the sea separating KSC's landmass from the desert landmass. If your rocket is a bit underpowered in the latter stages (so the final burn to get to orbital speed takes a long time) you should start a little earlier. If it's overpowered you can wait until the target is 220km away or so. go ahead and start the launch using a normal efficient gravity turn. However, your need to make the turn a touch gentler than the absolute most efficient one. What you want is some coasting time to finesse the intercept, so that you can nail it exactly with what is going to be your circularising + target orbit matching burn. at the start of the launch, whenever you have enough time to switch to map view, do so and try to make sure AN/DN to target is minimal, and one of either AN or DN is near your Ap. It costs less the earlier (and slower) you do this. beware that at some point, the navball will probably switch to target mode. You do NOT want to be on SAS prograde follow when that happens! So, by about 30km altitude you ideally want to be able to go to stability assist. Keep burning and staging until your Ap is at the altitude of your target. At this stage (about 40km up) you want to go to map view and stay there if you can. If you need to stage, switch back only briefly to press the spacebar then return to map. switch the NavBall to target mode; ideally, your intercept chevron will show your target to be at or slightly behind you when you cross orbits. If slightly behind, raise your Ap a touch more to get the double sets of chevrons and get the second set better aligned. if you're behind the target at Ap, you need to sort this quickly. Aim slightly below the horizon and burn until they close up. Time to "push the marble". Right-click on the target chevron to keep the intercept distance visible. In NavBall target mode, you need to push the retrograde marker over the anti-target marker: i.e. you point your rocket on the other side of the retrograde marker and burn. The marker should move away from where you're pointing. Watch as the intercept distance falls to 0.0km (or thereabouts). Remember that gravity will be changing your trajectory more than the target (since you're still suborbital at this stage). Therefore the retrograde marker will not be exactly aligned vertically (radial in/out) when you're far away even if the intercept is perfect. Therefore, start by making sure it's aligned with anti-target on the normal/antinormal axis first, then watch the chevrons and keep pushing on the radial in/out axis only if the intercept distance decreases. And finally, the scary bit. You have MechJeb and/or KER, so you can get (and absolutely need to know) your ship's acceleration. Then check the velocity difference at the intercept chevron. Divide that velocity by your acceleration. Then divide by two. The result is the absolute minimum time to intercept that you need to burn. aim squarely at the retrograde-to-target marker (which should now be right on top of the anti-target marker). start burning a few seconds before that "velocity/accleration/2" time you worked out earlier. keep an eye on the intercept chevron. Time to intercept should be counting down very slowly. If it starts increasing, throttle down. keep "pushing the marble" if you can, to bring the intercept distance down even more. if you did all that right, when you get down to 0m/s speed to target, your target should be about 100m or so away.... If you can't see your ship's acceleration, you just need to guess when to start that final burn. If time-to-intercept increases when you burn, just stop and wait for a while longer. If it keeps counting down quickly as you burn, aim away from the anti-target marker because you're too late and about to crash - hard - into your station.

As others have said, Swivels won't work very well. With Eve's thick atmosphere, you can use the smallest ailerons as fins and they should give you all the control authority you need so you can simply deactivate gimbal once you've got some speed up. This also avoids one of the main drawbacks of the Vector: without tweaking it, it is far too fast and excessive in its gimbal movements and can easily shake a ship apart. It also looks like it's wasting fuel by firing off prograde, though I don't have the slightest clue about how much energy it's really wasting. My successful ascents from Eve have paired 2x Vector with 2x Aerospike + an Aerospike core. For my design, that was the sweet spot for thrust vs engine weight. I think I ended up dropping the outer Aerospikes first, but I may be misremembering. For your design, with a Vector core and lots of fuel, it might work better the other way around: put Aerospikes on one pair of radial stages and throw away the outer Vectors first. However, if your upper, singly aerospike stage is lacking power, I'd say that you're just being too ambitious about what you're trying to get back to orbit. After leaving the lower atmosphere soup, a single aerospike will happily propel a Mk1 command pod, final stage with terrier and the necessary fuel for both, but I wouldn't bet on much more than that. If you have more, the Aerospike won't cut it so you need a Vector, and then you need to multiply each stage before that to get that Vector (and its fuel) up to where you need it. 4x the engine mass and 5x the thrust means what it means when it comes to the size and fuel content of your core...

8k vacuum dV is just the simplest way of expressing it. The two times I did it, I didn't really use the KER atmospheric delta V option, except to check what I was getting out of my first stage. Eve's atmosphere is so thick, only a couple of engines are actually capable of providing decent thrust at sea level, but you need to drop them as soon as you get out of the really thick atmosphere (some 10-20km up) so that you can start actually picking up speed. The KER atmo stats will give you virtually zero dV for your upper stages, and maybe 3k-5k dV altogether for your craft. It therefore isn't very useful to give an "atmo dV budget". I suppose you could break that figure down into lower and upper atmosphere: you need about 3k atmo dV to get out of the lower atmosphere, and about 3k vacuum dV to get up to orbital speed.

If you are already in a low Ike orbit, it is cheaper to burn straight back to Kerbin from there than to return to Duna orbit first. The interplanetary transfer calculators can't show this because they'd need to add another stage in the calculations (escape velocity from Ike translating into an escape velocity from Duna) to work it out. I don't think it matters much whether it's equatorial or not: if it's inclined, the main effect will to make your Kerbin intercept inclined and therefore a bit trickier to hit without needing a correction burn on the way. And if it's eccentric, that's fine (and is in fact an advantage) as long as you need to burn at Pe. And that last point is where you may have a problem. Your Pe is entirely on the wrong side of Ike to burn back to Kerbin at this point in Duna's orbit. It's quite possible that you're perfectly set up to go to Dres with a minimal burn, now, if that interests you, but you'll only barely be able to capture once you got there, with no way of going home... However, when Duna is on the other side of the sun, that Pe would be in the right place. If you have a transfer window at that time (approx. 400 days), then you can burn home straight from Ike Pe. This is a distinct possibility, so you're probably best doing nothing at all until you have a better idea about that. So as others have said: you'll probably need to return to Duna orbit before burning for Kerbin, unless your transfer window is in 400 days or so; your next transfer window to Kerbin is a long way in the future, anyway, so make the most of your low passes around Ike to get EVA and gravioli science from multiple biomes if possible (and you may want to lower Pe to about 15km for this purpose); when you are ready to burn back to Kerbin, you have two conflicting things you want to do: raise your Ike orbit to send you into a dive down to Duna so that your Duna Pe is as low as possible on the prograde (with respect to the sun) side of Duna, to minimize your Duna-Kerbin transfer burn; and raise your Ike orbit to send you into a Duna orbit that has its AN/DN roughly aligned with prograde/retrograde, so that the burn back to Kerbin needs little or no correction. Frankly, I doubt you can do both of those last two things at the same time. To get the lowest Duna Pe, then you should escape Ike when it is between Duna and the sun, and you'll end up in an inclined eccentric orbit with Pe on the dark side of Duna (as we see it now) which is maybe the right way to be facing when the next transfer window comes up, but only if that is in about 600 days. Therefore the simplest option would be to minimize the inclination of your resulting Duna orbit, which means escaping Ike with minimal excess velocity when your Ike Ap (as you see it now) is as far away from Duna as possible (and which is currently prograde with respect to the sun). The burn back to Kerbin is going to be expensive, but doable if you're very careful not to waste fuel setting it up.

Ore tanks are weak, however you attach them. However, radial attachments are progressively weaker the further out they are from the thing they're attached to. This was a test I tried in version 1.2 (I think): With the tanks surface-attached with the default positioning, they break off relatively easily: However, if you offset them a bit into whatever you're attaching them to, the connection is significantly stronger: Edit: Sorry, I only just took a good look at the pics. So you're talking about node attachment and not surface. Hmm. Still, whatever you do you have to be careful with ore tanks, they are the weak point in any design. However, I've never seen a case like yours where it just beaks off at the attachment node while driving along. On a heavy landing, however, yes it can easily break off. Sorry I can't suggest much to solve your issue. However I can say that it doesn't entirely surprise me.

And I too apologise. Obviously I did intend to make you wonder, for a short while, whether there was a thinly veiled insult in there. However with your track record on the site and clear expertise in the game, I assumed you'd realise very quickly that no insult would make sense. So yes, I expected you to start by dismissing the fake 1st choice (obvious joke), then wonder whether you were reading it right (that manipulative fourth line), then realise that there was no way it could be serious (the second, sneakier joke). So again, sorry, it really was in jest. I don't think there is anything obvious at all about your issue, and had absolutely no clue how it could occur. I should have remembered how easily I can get paranoid about what other people say, rather than encouraging the sentiment. And, by the laws of unintended consequences, I'm pretty sure that tiriss's first post here was coloured by my own inept jesting, so I bear some responsiblity for that too.

A definite +1 to the voices saying career is easier. I actually started with KSP because I didn't want to buy the game. Not that I had any problem with paying for it, but because I just knew that I'd be hooked if I did. So I played the free demo, for a long, long time. And I played each new demo that came out. And eventually, I decided to say goodbye to my spare time and bought the game So naturally, I was used to a very limited set of parts, and making the most of them. And that made everything after that so much simpler. So yes, playing career really forces you to understand the benefits of each part. Therefore each additional part is a benefit, not a confusion. It's just easier to apply your mind to problems if you have a strict framework to work in. Give too much freedom to your designs, and you'll find it harder to think about a solution. The bigger the possibilities, the less thought you'll actually give to the solution, and the poorer your constructions will be. So yeah, imho, play career.

I came to much the same conclusion as Snark, but from a slightly different approach: Getting to the Mun requires at burn of "almost 900 m/s". Capturing at the Mun needs "about 250 m/s". Getting to Minmus needs "almost 1000 m/s". Capturing at Minmus needs "a bit more than 150 m/s". Therefore 1150 m/s will get you to to a circular orbit anywhere from the Mun to Minmus and beyond. Since you benefit a bit from the Oberth effect because of the size of the Mun, you'd need a bit more to circularise in an orbit sans Mun. And closer in to Kerbin, it'll cost a bit more to change orbit. But grosso modo it looks like it comes to about 1150-1200 m/s whatever you do. Next step: what if you need to change inclination? Assuming you start off going the right direction, the biggest possible plane change burn is going to be the square root of two multiplied by your current orbital velocity (since you're doing a right-angle vector change with each vector being identical, so the hypotenuse is the square root of 2x each vector). However, we know that we can go out to the SOI edge, change plane almost for free, then come back. Going to the SOI edge costs about 1000 m/s, so double that to get back and we have an absolute maximum of about 2000 m/s to change inclination. SO... If there is no change in inclination, you'll need about 1200m/s to get to any orbit. If you need to change inclination and have time, you'll need about 2000 m/s to get to any orbit (out to SOI edge, plane change, return and circularise, 2x approx 1000 m/s). If you need to get there quickly, the absolute maximum DV requirements of a ship in orbit around Kerbin is going to be 1.4 x 2300 m/s (LKO velocity) + whatever you need to raise your orbit. Since you can combine raising orbit with a plane change, that means (applying pythagoras again) that the absolute maximum is going to be the square root of (2300^2 + (2300+1000)^2)) (to get to SOI edge with correct inclination) + 1000 m/s (to return to low orbit). Now that is actually quite neat because (2300+1000)/2300 (to get back to units for the first burn) is almost equal to the square root of two. Therefore our pythagoras equation is the square root of (1^2 + (root 2)^2) = sqr.root (3) = 1.7. Therefore total expenditure is 2300 m/s x 1.7 = 4000 m/s. SO.... No change in inclination: 1200 m/s Change in inclination but no time constraint: 2000 m/s Absolute maximum if in a rush: 4000 m/s.

As Rizzo said, basically: in the final seconds you need to make sure it's a slow, perfectly vertical landing on flat ground. If you look at that first pic again, the ship appears to be resting on its engine. The landing legs are a bit weak for that size of ship, so they won't provide much protection for a heavy landing and won't be able to right the ship if it starts to lean. So I'd guess that (a) it was landed quite delicately, to avoid damage to the engine, and (b) SAS is still engaged to keep it upright, but (c) gimbal is probably turned off for that engine, so that SAS is only using reaction wheels and not moving the bell of the engine around. Incidentally, turning engine gimbal off for landing is often a good idea since you want a smooth transition from horizontal to vertical motion in those final seconds before landing, irrespective of how much you're throttling the engine. Engine gimbal is fine if your throttle position is constant, but it's easy to spin out of control if you need to throttle up just as you touch down... and if you do end up facing upside down (like Rizzo mentions), you definitely can't use the engine gimbal to right yourself without accelerating right into the ground. Engine gimbal can therefore put you quickly in a position that you can't get out of quickly without using the engine... but where using the engine would be suicidal.

Actually, for these contracts I generally end up doing what you are having to do by error! Basically, 5000 ore tank capacity is pretty much overkill. I would definitely want to send up the tanks empty, but it would be a pain trying to design a useful craft around them. Therefore I'd probably send a second tank-only craft up to latch on purely for the contract and use one of my standard mining rigs to create the base.