Eric S

That's what I use, and it's at least approximately correct. You might have to throttle down a little bit as you're burning off fuel, however, since otherwise your thrust is constant but your weight is decreasing. When you're in orbit, TWR doesn't matter much, as it all comes down to patience. I usually try to avoid going below 10 m/s accel for normal craft, and 2 m/s for big craft going a long way. For example, a transfer orbit to Duna takes about 1000 m/s of acceleration. With 10 m/s, that's 100 seconds, which is bearable. at 2 m/s, it takes 500 seconds, or a bit over 8 minutes, which can get annoying. At that rate, an Eeloo transfer orbit would take over 15 minutes. Now, something to be aware of is that if you're using a low acceleration craft, it's quite possible to find yourself spending so little time in the SoI of a celestial object that you can't achieve an orbit before leaving the SoI. Two pieces of advice on that. First is to enter the SoI as precisely as possible. Not only do you have more time within the SoI to change your velocity, but you also benefit more from the Oberth effect. Second, sometimes even with that, you need to start matching velocity with the celestial object before you enter that object's SoI. I try to maintain a 2.2 TWR from launch until I hit the apoapsis. I don't mind circularizing with a TWR of 1.0 or so, but I prefer at least a 2.0 even at that point, as it makes getting a circular orbit easier since you don't have to burn as much before and after apoapsis. Generally a good idea to keep it in that general area. MJ is pretty good on some craft, and pretty bad on others, it really depends. A very good pilot will always match or beat MJ, however. Where MJ wins is in consistency. While I might occasionally have a very good or very bad launch with a specific vehicle, MJ will almost always have very little variation, which is kind of nice if you're testing small changes in a craft. Large changes don't give as accurate a result, as you can more easily be making the ship fit MJ's launch profile. Again, it's not bad, but I find I can usually do a bit better after some practice with the specific craft in question, since they all behave a little differently.

I've landed kerbals everywhere and returned them, and Eve is the hardest place. Moho would probably be second, but that's because of the difficulty in getting there, not the landing and takeoff. Moho may actually take more delta-V for a round trip including landing, but Eve still felt harder because so much of the delta-V needs to be accompanied by a high TWR.

SAS modules have a maxTorque stat instead of a rotPower stat, and I'm pretty sure that the difference is that maxTorque only helps you stop turning, it doesn't help you turn faster. While it's not exactly what it's doing, think of SAS as providing friction to turning. If your rocket starts tumbling end over end and you turn on SAS, eventually the rocket will stop tumbling if the SAS has more force than whatever was causing you to tumble. However, just like spinning a roulette wheel, friction doesn't mean it's going to stop pointing the same direction it was when it started moving. The rotPower from capsules is actually useful for turning the craft, provided you have enough rotPower. I don't know the correct terms for all these different types of gyroscopes/flywheels, but there are actually real life spacecraft parts that behave like SAS modules, and parts that behave like capule rotPower.

An alternative is to disable all fuel tanks except those you plan on dropping next. Taking 15 seconds to turn on new tanks probably won't significantly affect hour long burns.

Correct, my numbers got inflated because I was counting the electricity drain of the probe pod as well. EDIT: I just retested with a manned pod so that it wouldn't cause any drain, and I'm still seeing a 14.55 unit/sec drain from the engine.

There's several theories as to why asparagus staging isn't used in real life. The ones that I think are real are: 1) Too many parts, and unlike the Saturn V or Falcon 9, if the wrong fuel pump were to fail (a common problem from what I've read on causes for failed launches), the mission would have to abort unless they had redundant pumps. The Saturn V was able to launch on multiple occasions despite engine failures, and the Falcon 9s have the same ability, though I don't know if any launches have had engine failures yet. 2) It wouldn't provide as much benefit. The reason asparagus staging works is because you're discarding fuel tanks and engines as soon as possible. Real engines and tanks weigh about a quarter what they do in KSP for the same thrust or tank volume, so the delta-V benefits are significantly reduced. (I haven't done the math on this, but I plan on doing the math to verify this).

It did at one time, it no longer does. I tested it top to bottom in 0.18.1, and additional SAS modules actually slowed down turning a ship even when it was off because they added to the mass that needed to be turned. Actually, I'd say that's a display bug in the VAB. If you look at the rotPower stat in the command files, you'll find that the torque values do vary. In fact, the command pods vary between each other. The Mk1-2 pod has four times the rotPower of the Mk1, and 40 times the power of the probe pods (except for the Stayputnik, which has even less rotPower).

Right. single-stack staging can't do this because they more stages they add, the more dead engine weight they're pushing, so it hits diminishing returns from staging much faster than asparagus staging does. Heck, I've got one Asparagus design that's ten stages including the center stage but not the stage on top of the center stage. Not a practical vehicle, but it was designed for a "go really fast" type of challenge. Which isn't to say that it didn't overlook something, but it's more likely that I did, and I really want to know what I did.

SAS modules are almost useless at this time. All they do is make it harder to turn the ship (intentionally or otherwise) while it is on. It does not help you turn when you want to, and other than trying to bring you to a stop, it won't try to turn the ship back in the direction it was pointed when SAS was turned on. It does this by itself. Note that this isn't magic, it uses gyroscopes/flywheels to do the work. ASAS modules do nothing by themselves. What they will do is use the other control methods available to it (capsule rotational power, RCS, vectorable engines, and aerodynamic control surfaces) to turn the ship back in the direction that it was pointed when SAS was turned on (SAS and ASAS are both turned on with the same key, and it's called SAS regardless of whether there is any SAS on the ship). ASAS loves to overcorrect if you're using RCS. Basically, it will always be using RCS to turn towards the right direction, even if you're pointed almost exactly the right direction.

I think all out an ion engine takes 15 electricity a second, and a thermoelectric generator provides 0.75, so it would take 20 generators per ion engine.

Yes. Create an action group that shuts off (or toggles) both engines at the same time. If you don't know how to do that, feel free to ask for more details.

I disagree, though I'll gladly listen to counterarguments. The angular momentum is minimal. Yes, you're causing angular acceleration of a portion of the fuel supply as fuel enters the fuel line. However, you're also causing angular deceleration of an equal amount of the fuel supply as it exits the fuel line. There will be a brief moment where there is only acceleration as the fuel line fills, and a brief moment where there is only deceleration when the tank is empty but the fuel line isn't. That doesn't sound like ever-increasing, and hardly sounds unstoppable. I think part of our disagreement is that you're basing this on it spiraling in, which it doesn't do. It moves circularly, stops (or at least makes a 90 degree turn dumping it's angular energy into whatever forced it to turn 90 degrees), then moves directly inward. I understand conservation of angular momentum, I just don't think it applies here the same way you do. I do agree with the danger of it. The engineering challenge impossible? Difficult, yes, but I don't think I'd call it impossible since that's very similar to the external tank on the space shuttle, not to mention the fact that the Falcon 9 Heavy is scheduled to test soon (later this year, if I remember correctly), and while not true asparagus staging, has many of the same technical challenges, though at a smaller fuel flow rate since each fuel line is feeding half of the center stack at most, instead of half the center stack plus two other complete stacks.

Since the first pass of the resources is all about the various rocket fuels really, and the devs have hinted that real base construction will probably be put off into an expansion, I think KSP even with resource mining won't feel like an RTS. They're maintaining focus on the spirit of the game, just adding options. So yes, if I had to chose one item, I think I'd go with resource mining. A combination of more science, career mode, and resource mining is what I really want, so that I get a stronger feel of being out there for a reason. I've got to admit that even on some of my best missions, I'll have that moment of "OK, time to take the obligatory PR screen shot, and then stand around pretending to do something meaningful." I'm sure that the game will need some optimization to make all that possible, and as long as we're talking that many options, I'll take the rest while I'm at it, they all look good. So, you want to win a race by being the only person in the race? Crafty! Kidding. I do understand that, though as you might guess by what I said above, it's not my prime motivator. Then again, there's nothing wrong with that being your motivation.

If you do that, you still have dead weight on your rocket. I've been known to put a bigger engine or SRBs on my outermost asparagus stage, but I've never noticed it making a distinct improvement on your total delta-V to orbit assuming that your early stages are around a 2.2 TWR. I'm not sure hitting 100 m/s in three seconds is that much better than doing it in 10-15 seconds. I've thought of that and even use it occasionally, but not as a launch concept. My atomic powered Duna lander sometimes takes an extra fuel tank mounted under the rover, which it of course has to ditch before it lands, just to make sure I have plenty of delta-V left over for stupidity on my part. I generally find that it doesn't gain much over traditional asparagus staging because you either keep the engines, trading delta-V for a high TWR ratio that doesn't necessarily help your efficiency, or you're dropping them about as fast as you would a properly balanced traditional asparagus staged rocket. Oh, and leaving tanks on the launch pad can be a serious problem with this design concept. No, but you can turn off vectoring on the engines so that at least they're not fighting against you. And I agree with the rest of your points as well. Back when I had KW rocketry and Nova Punch installed, I often didn't use the same engine in two consecutive asparagus stages just trying to keep my TWR in the optimal range.

Yeah, DF is one of the games in my current "do not burn out on any one game" rotation. My biggest issue with it is that just when it's getting interesting, it slows down to the point that I give up in frustration. Have you checked the graphics packs? It's still not 3d or anything, but looks a lot better than a default install. I can honestly say that I don't think better graphics would improve the game that much for me.

I hadn't thought about that, and yes, that's probably a major factor. Other factors: Fuel lines: They're just not as easy in reality as in KSP. I think the US Space Shuttle (and probably the Buran) was the first craft to do a fuel transfer during launch, and the Falcon 9 Heavy which hasn't been tested yet is the only other craft that I'm aware of that does it. Did Burran Aerodynamic drag: Nope, not talking about delta-V used to counteract drag, that's a very minor factor at most. If you've launched rockets using FAR which has more accurate aerodynamics than stock, you know that rockets with a center of drag higher than their center of mass are inherently unstable. This isn't necessarily the case with all asparagus staged vehicles, but I ran into it more than once while testing. Also, since real earth launch gravity turns tend to more closely follow the prograde, this is less of a factor in reality since the instability is easily correctable if you're close to prograde, it just becomes bad if you turn as far from prograde as you do following the informal standard of "turn to 45 degrees at 10K altitude. I've heard someone on these forums mention the rotational energy of transferring the fuel would cause a problem. I don't think so, for your normal three stages plus center stack, I'm pretty sure you'd get 70 degrees of rotation at most, and that's assuming a massless center stack. Excess mass?: Nope, from what I've seen, asparagus staging has a higher payload percentage than single stack rockets, so by definition, an asparagus staged rocket that could put X tons into orbit would have less mass than a non-asparagus one. If you're seeing different results, you may be overbuilding your asparagus rockets. More parts: This is also true. Having a fuel pump go out in the innermost asparagus stage could mean that none of the stacks on that leg would transfer fuel correctly, throwing the entire ship out of balance. While it only has this effect in game if you incorrectly attach the fuel line, more parts can still be bad for performance depending on the total parts on the craft.

Sadly, I was laughing WAY too hard to get screenshots, and you'd really need a video to really get it anyway, so you'll just have to turn on your imagination for this one. Some of you may have read this before the great forum oops. I was working on a space station. I wanted to have life pods, but I wanted them to the minimum to do the job, no wasted part count or expensive parts. Basically, a probe core, battery, two solar panels (the flat non-deploying kind), a hitchhiker pod, a few parachutes, minimal RCS jets/fuel, and a few sepratrons. Most of the single items where on the bottom so that I didn't have to mount pairs of them symmetrically. So, time for the first test. Undock from the space station, use RCS to back away from the space station so that I don't smash the station just for a test. Aim retrograde and pop the sepratrons. Check periapsis, it's far enough into the atmosphere that I don't think I'll be making it back out of the atmosphere. So far so good. Time warp to hitting the atmosphere, and watch reentry. Pop the chutes. Chutes deploy, and then fully deploy without tearing themselves off the pod. I think I'm just about done. It floats down, and my confidence builds. It hits the water... and blows up. I check the stats. Yup, the hitchhiker pod is weaker than capsules, so it will have to land more gently. Go to the VAB, add another parachute. Throw it on a rocket, don't bother docking it to the station, just put it in a matching orbit and pop the sepratrons. Everything goes fine, it hits the water, and is fine, it just floats. GREAT! Hmmm... but what if it hits land instead of water? I don't think it will be that much worse, but we should check just to be sure. Relaunch, and repeat. Manage to time the sepratrons so that I'm coming in over land. Excellent, the test will be a success, even if the life pod isn't. Parachutes deploy. Pod comes down gently. Touches down, no explosions, YAY! Oops, it fell over because all the small stuff on the bottom of the pod. No biggie... wait, it's starting to roll downhill. It'll stop when it hits a radially mounted sepratron, right? Crunch... nope. Ooh, we're rolling faster. We've basically developed the orbitally deployed wheel and forgot the breaks. OK, so they may get sick, but they're alive, right? Rolling even faster, bottom of the hill is coming up, I'm thinking it will roll half way up the next hill. And again, I'm wrong, it's going so fast that the slight bump at the bottom of the hill causes the pod to explode. And this, my friends, is why Kerbals should follow NASA's lead and have high speed cameras filming everything. Not to figure out what went wrong or why, but so that they have something to throw up on Youtube when ground control can't take screenshots because they're too busy laughing so hard it hurts.

Am I sure that multi-couplers cause fuel flow problems in the absense of docking ports? Yes. As a test when I first heard about this problem, I built a small test rocket that was "probe module/tank/bi-coupler/inverted-bi-coupler/tank/engine" and despite the total lack of docking ports, the engine could exhaust the bottom fuel tank but wouldn't touch the top one. I further simplified it to "probe/tank/bi-coupler/tank/engine" and the engine drained both tanks. "probe/tank/inverted-bi-coupler/tank/engine" again demonstrated the problem, with the top tank remaining untouched. The problem is that the single side of the bi-coupler can't draw fuel from either of the nodes on the other side of the bi-coupler. Either of the two nodes on the double side can draw fuel from the single side, however. The two nodes on the double side cannot draw from each other, however. So it appears to me that the only fuel flow allowed through a bi-coupler is from the single node to either/both of the double nodes. I also tried variations of each case where the engine could drain the tank, and the presence of docking ports did not affect the results. Am I sure that docking ports do not cause fuel flow problems in the absense of multi-couplers? No, but I've never been able to create a case where this happens, so at the very least, I feel that docking ports are at least unlikely to cause this kind of problem. I've tried replacing both bi-couplers in the non-working designs with docking ports and it has always worked fine for me at that point. If you could recreate the config you had problems with, I'd like to see it. I'm not going to claim that my scientific method is perfect (my anything, for that matter), so I'm quite open to scrutiny. Am I sure that you can get away with bypassing only one of the bi-couplers with a fuel line? I think so, but I'm not sure as I haven't tried it. Since bi-couplers let fuel flow one way but not the other, then only one bi-coupler is the problem, so bypassing the problem bi-coupler should resolve the problem.

Correct, I wasn't specific enough, thank you for clarifying. Correct. It's the multi-couplers that have the issue, it's not actually the multiport docking that causes it, so if you use fuel lines to skip over the multi-couplers, you'll be fine. In fact, you only need to skip one of the multi-coupler.

The default rescaleFactor is 1.25, so if you make a 0.5m part and don't specify a rescaleFactor, it comes out as a 0.625m part. This causes a lot of confusion, as some people use the "in game" size and some people use the size "as designed."

Yes, you understand it correctly. I'm not sure on the difference, I think it's that if you place a docking port on another docking port in the VAB, they are coupled rather than docked. If you put anything else on the docking port instead of another docking port, you can still decouple it. EDIT: the "not really connected" parts will connect as soon as physics kicks in before you have the chance to launch, so it will be effective for the launch. Also note that you might have problems getting fuel to flow through two multi-couplers facing each other. You'll be able to transfer fuel from above to below them, but engines on one side won't draw from tanks on the other. I'm not sure this happens in all cases, but I've seen it happen fairly regularly lately.

Several of them, actually. Some require an EVA'ed kerbal to initiate the hookup, some don't.

I'm not sure if you did this, but there is some vector that needs to be part of the 3d model that tells unity which way the engine exhaust goes so it knows which way the engine thrusts. I've read about it in the tutorials, but haven't actually tried it yet.

Not so much negativity as experience with large scale building in the current game engine. At this time, you can't even come close to making a 1km long craft that doesn't shake itself apart. Theoretically possible, but I'm pretty sure that it would require developer involvement as I don't think that modding can really create new sets of physics rules, just push the existing rules in possibly unnatural directions. Given that developer time is a finite resource, I can think of many other things I'd want before this, not to mention that you'd have to convince them to do it to begin with, since it's probably outside the scope of the game that they have planned out. He didn't, though he was working on one. Whether it would work or not, for what kind of an orbit, how much payload, and what kind of payloads could handle the acceleration would be a separate discussion (and one I'd be interested in, but it would be off topic in this forum).

Unlike a Mun trip, doing the separate lander/orbiter for Duna makes sense, but isn't necessary. I did this for the 40th reddit KSP challenge carrying a heatshield. Fuel margins were tight, but doable. Fuel margins are wider on my next Duna mission, but I'm using atomic engines for that mission.