tavert

They provide a nice TWR boost early on, and they weigh very little when empty. Though with the current performance of the 48-7S there are not as many situations where SRB's give better performance per unit mass as there used to be. Might help on part count though.

Nice. I got a rocket-only SSTM&B to work many months ago, but I can't remember having seen anyone else pull it off since then. Without an LV-N or jet or ion engine I don't think it's possible, as the most dV you can get while still having TWR = 1 is 6746 m/s vacuum with a 48-7S, or 6405 m/s atmospheric with an aerospike.

Closest thing to what you're asking is http://forum.kerbalspaceprogram.com/threads/36476-WIN-KSP-Trajectory-Optimization-Tool-v0-11-Now-with-Mission-Control-Center%21 - it has some capabilities for gravity assists, up to what's feasible in a reasonable amount of computation without professional research tools.

Looks like it's using the structural tail connector part with 8x symmetry. He may have needed to turn on part clipping in the debug menu to build that.

A 2-Kerbal design with more stages (still no asparagus, only fuel lines are between tanks within the same stage) does the job in 21.278 tons. (1+log_2(2))*2*100/21.278 = 18.8

I absolutely disagree with this. Once you're in orbit, this is the case. However for takeoff and landing, the delta-V cost is a function of TWR. For airless bodies I've done the exact calculations here: http://forum.kerbalspaceprogram.com/threads/39812-Landing-and-Takeoff-Delta-V-vs-TWR-and-specific-impulse Although dV cost of landing or takeoff on airless bodies strictly decreases as TWR increases, engines are pretty heavy in KSP so there's actually an optimal TWR for best payload fraction of a single-stage lander (for a given size lander, this translates to an optimal number of engines - more is not always better). I put together a tool here http://forum.kerbalspaceprogram.com/threads/61659-Wolfram-Web-App-Optimal-Single-stage-Lander-Design-Tool to do this analysis. When there's an atmosphere, drag makes the calculation more complicated, and the optimal gravity turn trajectory to get out of the atmosphere is also TWR-dependent. In a purely vertical ascent it's well-established that you don't want to exceed terminal velocity, and anecdotally I've seen with some designs you can actually reduce the delta-V cost of Kerbin ascent by imposing an acceleration limit of 22 m/s^2 through the entire gravity turn. TWR influences the design tradeoffs of which engine is most efficient for any combination of delta-V and payload. See my charts here http://forum.kerbalspaceprogram.com/threads/45155-Mass-optimal-engine-type-vs-delta-V-payload-and-min-TWR for more detail on that. You can see how clusters of 48-7S engines outperform almost everything else right now, a sign of poor part balance in 0.22 and 0.23. Check the interactive spreadsheet version I linked to in that thread if you want a few more numbers. Personally what I do when optimizing a design for ascent from a planet with an atmosphere is run experiments using MechJeb's ascent autopilot. Running the same ascent settings with slight changes to the design tells me whether the delta-V left once in orbit improves or not. It's the only repeatable way to make scientific conclusions for small design tweaks - with manual piloting, there's always uncertainty in how much of your performance was due to any changes you make to a design, versus flight-to-flight differences in your trajectory.

Some people occasionally call that onion staging, but it's basically the same as asparagus just in symmetry groups of 4 instead of symmetry groups of 2. If you're burning the engines of multiple stages simultaneously, and you have fuel lines from an early stage feeding a later stage such that the later stage is full of fuel when the early stage is dropped, and the dropped stage includes both fuel tanks and engines, then I'd call that some form of asparagus. Edit out the #0 from your imgur link and the embedding will look nicer. Oh, and when you don't need the monopropellant in the capsule, you can get rid of it with tweakables for some extra delta-V!

Optimize my designs subject to different constraints? The strut just provides free connection points that can often be obtained in other ways if need be. The small engine is overpowered, definitely. As long as it's allowed and as long as its statistics make it the optimal choice, I'll continue to use it whenever it is the best choice to do so. The small decoupler makes a pretty minor difference overall, but if you care about function over form then there's no reason not to use it. And this design didn't use the landing gear for once. Glitchy physics and part balance should be fixed, I agree there. But complain to Squad, not me if you don't like the way optimized designs turn out.

Here's a direct-ascent 1-Kerbal Soyuz-staged vehicle at 12.6 tons. Really doesn't take much to get to the Mun and back. I think the score here should be (1+log_2(1))*2*100/12.6 = 15.873. It's probably possible to play with the staging on a multi-Kerbal version of this for slightly better payload fraction. Or add docking ports and launch twice for the 19% bonus.

I slightly misread what you meant with the 4th-root bonus then. I thought instead of 2x the mass for a second identical launch, it would only cost 1.2x. Instead you're saying it costs 2x, but you apply the 1.2x bonus separately. So if n is the number of Kerbals and we assume mass depends linearly on n, the overall score goes as (1 + log_2 n) * n^0.25 / n? This would give 1.19 for n=2, but lower for all other integer n.

Encouraging non-asparagus designs with a score bonus could lead to some designs that are a little different than you usually see, so it's an interesting feature. But how would you classify Soyuz-style staging, with multiple stages starting to burn from the start but with central stages having more fuel than the boosters? Your scoring also seems to encourage repeating the same mission multiple times, or at least to LKO just for the purpose of increasing number of Kerbals...

MechJeb isn't absolutely perfect, but it's repeatable and saves me time - I didn't need any quickloads on that trip thanks to MechJeb (once I worked out the launch timing anyway), but if I was flying manually I would've. Word of warning on the powered landing, it can be fairly tricky to maintain a retrograde heading during re-entry since the Kerbal and the chair have lower drag coefficients than the rest of the craft. The dV discrepancy you were seeing was probably due to not accounting for the Kerbal's mass. On EVA and when in seats, they mass 0.09375 tons, which costs a decent amount of dV on these tiny landers.

There have been a few of these, but I guess not that recently. Does it have to be a horizontal-launch spaceplane, or is vertical launch and/or parachute return ok?

This time without abnormally glitchy physics, 360 fuel in 2:45:03. Parachutes cost you lots of dV on craft this small. Better to just save a couple hundred m/s for a powered landing on the return. The last drop tank stages off the front, you have to cut the throttle and turn off-prograde briefly to ditch it partway through the Munar injection burn. In case you guys haven't watched this before, you should check out this quite-a-few-versions-old video from Abyssal Lurker where he lands on the Mun in just over half an hour: (uses SRB's so not in line with the rules here, but damn impressive!)

Only if the atmospheric density is constant, then a constant TWR of 2 will lead your velocity to asymptotically approach terminal velocity. In reality atmospheric density decreases as you ascend. To maintain terminal velocity you need a TWR slightly higher than 2 to provide the net acceleration to keep up with terminal velocity as it increases. Also keep in mind that TWR increases as you burn fuel.

It's called the "Goddard problem." Gravity losses per unit altitude are inversely proportional to vertical speed. Drag losses are proportional to speed squared. For vertical ascent through a constant-density atmosphere, the optimal tradeoff between the two is at terminal velocity. For exponential density vs altitude, and neglecting surface rotation and the variation of gravity with altitude, you can get a variational calculus derivation that keeping up with terminal velocity as it varies with altitude is optimal in these conditions too.

Actual constant. It's a unit conversion. There's no physical reason for specific impulse to be a time (effective exhaust velocity is the physically meaningful quantity here), it's that way by convention as an accident of imperial units. In KSP, it's oddly 9.82 m/s^2. Yes, Isp in KSP is essentially the same as "specific impulse measured in seconds," except for the slight difference in g0 value. Yes, fuel and oxidizer both count as propellant mass for the rocket equation.

Typically asparagus does mean you drop both engines and fuel tanks, feeding the remaining engines from that same tank before you drop it. If you're just dropping fuel tanks without any engines on them, that would be called a "drop tank," and isn't the same thing as asparagus staging.

As blizzy78 said, fuel lines and struts are treated differently than other parts by the physics engine. Happy to help, glad my critiques are coming across as constructive (my posts tend to have a more negative tone than I intend them to...) and my charts were a source of inspiration. It would be cool if there were a similar general-purpose visual way of showing multi-stage solutions, but I haven't been able to find one yet. Just say the word if you want me to start rambling about the math and open-source C++ code behind the more sophisticated optimization algorithms I've been using for multi-stage design optimization.

They were able to do that on the Cassiope launch because it was a very light satellite, way under the F9's payload capacity. Thaicom and the previous SES launch are to GTO, so don't leave as much fuel margin in the first stage to do those propulsive-descent tests. The next one of those tests may happen on the next ISS resupply launch, we'll see.

Well I was plugged in at the time, but anyway... Well you may have had the 9.82 number in your head for good reason, the conversion factor to get fuel flow from specific impulse (EARTH_GRAVITY in your code) is actually 9.82 in KSP! Also note that the fuel lines are massless. Awesome, thanks! Tremendous improvement! Looks like you aren't currently allowing drop-tank stages without any engines on them? I'm finding some stages getting LV-1 engines added to them when the TWR constraint would still be satisfied without them. Some future enhancement ideas: 1. Allow optimizing for total part count as an option 2. TWR constraint on a stage-by-stage basis, or (more complicated) min TWR as a function of cumulative delta-V 3. Optional constraints on max mass and/or max total part count 4. I'll have more later, I'm sure Again, nice work!

Yes. Check the thread I linked to earlier. At low TWR it costs a lot more dV. Did I say anything about how high your periapsis is? No. Just whether you perform your braking burn by pointing retrograde the whole time, vs changing direction to maintain constant altitude. Otherwise a like-for-like comparison would have the same incoming orbit.

Sorry! Let's try a few more interpretations of this (Kasuha's is also a new way of thinking about it, I like - though I wouldn't describe the losses as "minimal," they're quite significant at lower TWR). Right. Not quite, sorry if it came across that way. You are counteracting gravity to avoid falling, with the off-retrograde component of your thrust. But since your velocity vector is perpendicular to the force of gravity (moving horizontally, 0 vertical speed), gravity does not change the magnitude of your velocity, only its direction. It's as if you're orbiting a lighter planet at a slower speed, simulating the difference in planet mass with your vertical thrust component counteracting some of the gravity. In a retrograde burn on the other hand, as you drop in altitude, your velocity vector is no longer perpendicular to the force of gravity. The non-zero component of gravity that is parallel to your velocity causes the magnitude of your velocity to increase, and the perpendicular component changes the direction. That change in speed due to nonzero vertical speed is known as "gravity losses." It slows you down on ascent, and speeds you up during landing, if you allow your altitude to change. This is true. For higher and higher TWR, the differences between retrograde and constant-altitude landing method approach 0.

Yikes, this managed to overheat my laptop. And it's not producing correct results, just comparing a few single-stage reference points to my data here: http://forum.kerbalspaceprogram.com/threads/45155-Mass-optimal-engine-type-vs-delta-V-payload-and-min-TWR Say for example I want a 40 kg payload (just the smallest probe, nothing else), 4000 m/s dV, min TWR 1.2 relative to Kerbin (surface gravity on Kerbin is 9.81, it's the Isp-to-exhaust-velocity conversion factor that is 9.82). The mass-optimal design here is one 48-7S and one FL-T100, whether or not you include the decoupler before the payload (would be nice to turn that off, otherwise I'll always be subtracting 15 kg from my payload since that decoupler's not needed) - the mass there is 0.7175 tons (for KSP use tons is much more commonly used than kg, a lot of people won't realize they need a factor of 1000 in there) with a decoupler, or 0.7025 without. With all stock parts, your tool is telling me an RT-10 SRB is best. That's 3.803 tons. If I disable SRB's, then it's telling me to use a Skipper and 12.5 tons of fuel, 18.118 tons total mass. Disabling the Skipper I get 4x Mark 55 (which are never mass-optimal!) and total mass 19.405 tons. Then it tells me I should use a mainsail, then nothing. So I suspect something's up with your fuel consumption or delta-V calculations for small engines. I applaud the effort, and I've been thinking for a while about making a tool like this for multi-stage design optimization. I have something that works quite well for my own use, but it's using a combination of Matlab and C++ libraries and has no user interface that anyone else could easily understand. While JavaScript is great for running in a browser and providing an easy-to-use interface without any installation, it's a really terrible language for computationally intensive numerical calculations like this one. There are considerably more effective algorithms for approaching this kind of optimization problem that I've been using successfully, but they're not the kind of thing you would ever write in JavaScript.

The counterintuitive part about landing is the tradeoff between gravity losses and steering losses. If you point retrograde the whole time you don't have any steering losses, but since your altitude drops during the burn, gravity speeds you up and that costs extra fuel to counteract. If instead you come in very low and horizontally and adjust your direction of thrust to maintain constant altitude as you slow down, you do suffer steering losses from not pointing retrograde, but since your altitude doesn't change you don't get accelerated by gravity. Integrated over an entire landing burn, the constant-altitude method is more efficient than a retrograde suicide burn. See http://forum.kerbalspaceprogram.com/threads/39812-Landing-and-Takeoff-Delta-V-vs-TWR-and-specific-impulse for some math and numbers, at least for the constant altitude method. Simulations in game or with mathematical predictions will verify the comparison between constant-altitude and retrograde.