tavert

Welcome back lump. This challenge is scored on vacuum dV according to MechJeb on the launchpad, not remaining once in orbit (practically speaking the latter is probably more useful though). You posted two on-orbit pictures, did you mean for the first one to be on the pad?

Mesklin's "Dedal" did just that. He undocked the nuke engine, a little bit of fuel, and a seat to bring a Kerbal down to Tylo, then brought it back up to re-dock with the rest of the plane and return to Kerbin. Pretty impressive, and good to know it's possible, but not quite as extreme a feat as bringing the whole thing down to Tylo's surface (don't think the round trip is possible there).

Shameless plug, I put together some code to optimize this: http://forum.kerbalspaceprogram.com/threads/61659-Wolfram-Web-App-Optimal-Single-stage-Lander-Design-Tool A big disadvantage of high TWR is the increased engine mass. Delta-V cost for landing approaches an asymptote as TWR increases so you get into diminishing returns.

Hey folks, as a follow-on to my sets of optimal landing and optimal engine charts, I put together an interactive analysis tool to combine the two. How many engines and how much fuel do you need on that airless-body lander to maximize your payload fraction? Have a look at my KSP Single Stage Lander Design Tool and find out! You need to install the Wolfram CDF Player Plugin for this to work. There are some explanations/instructions at the bottom of the page, let me know if you have any feedback. If you're on Linux, it appears there's no browser plugin version of the CDF Player, but you can download the standalone cdf file and use that in the player application (and look at the Mathematica code if you're so inclined).

Yes, but not by as much as you think. See http://forum.kerbalspaceprogram.com/threads/39812-Landing-and-Takeoff-Delta-V-vs-TWR-and-specific-impulse for numbers. You quickly get into diminishing returns past local TWR of around 2. And engines are heavy, so you actually start getting worse in payload fraction for higher TWR as more of your craft mass is engines. The gravity losses in the video are basically negligible. If your velocity vector is perpendicular to gravity (moving horizontally), gravity losses are zero. The losses in the constant-altitude landing method are in the form of steering losses, since you have to thrust higher than retrograde to maintain altitude. Still, for the same initial TWR, it is more efficient than performing a retrograde suicide burn.

http://forum.kerbalspaceprogram.com/threads/11214-The-K-Prize-100-reusable-spaceplane-to-orbit-and-back?p=697351&viewfull=1#post697351

Yep, check the version he took to Moho, tighter margins on that one. Dropping from two jets to one is marginal though, tough to get off the ground and into orbit with much more than 10-15 tons on only one jet.

Max theoretical dV for LV-N is over 17 km/s, which is plenty for an Eeloo round trip. It's difficult, but definitely possible. What would be immensely difficult and only marginally possible with some extreme gravity assists would be a rocket-only SSTO Eeloo round trip (no jets, no ions). The record for rocket-only SSTO delta V remaining on-orbit is around 4 km/s. Probably not enough.

Don't think I can beat that at 200 parts, at least not with anything that doesn't fall apart during flight. Orange tanks make my large rockets fail for no good reason, despite quite a bit of strutting. I have some designs built at 35 and 36 km/s that should eventually work at higher part counts, given enough time tweaking and probably replacing all orange tanks with 32's. I'm frustrated enough at the structural failures that I give up for now. Using skippers is an interesting approach, letting the mainsails run out of fuel first to improve Isp - it's not much of an improvement though, I'm surprised it's worth their lower TWR.

Looking at the design he took to Eeloo (he also had a later improved version he took to Moho), it has an initial wet mass of 24-25 tons, gets to orbit using less than 2 tons of fuel, and has a dry mass of under 10 tons. Almost 7 km/s dV remaining from LKO. You needs lots of intakes to get to orbit almost entirely on a pair of jets, enough wings to get off the ground, 1 LV-N, and the rest fuel. You'd probably have to double the design if you want to use a proper pod instead of a jumpseat.

Stochasty did this in stock a few months back: http://forum.kerbalspaceprogram.com/showthread.php/11214-The-K-Prize-100-reusable-spaceplane-to-orbit-and-back?p=585643&viewfull=1#post585643

Wasn't using any construction mods, just stock cubic octagonal struts. Looks like it was 3 horizontal, 1 vertical.

The difference is higher payload at the same dV and TWR. My optimization algorithm begs to differ, at least based on part-count constraints up to 200 (just counting fuel tanks and engines). If the extra stage of LV-N fuel were valuable enough to offset the decreased payload fraction of a single-stage lifter, the solver would've returned that as optimal.

I constrained it on part count, not mass, so it looks like an even larger version of my previous design, but with one more huge LV-N drop-tank stage instead of the 48-7S final stage. I fixed a bug with the fuel flow in the optimization and it's now 38 km/s on paper: stage 1: 1 LV-N, 12 tons of fuel, 11.2 km/s stage 2: drop tank, 96 tons of fuel (3 jumbo), 11.7 km/s stage 3: drop tank, 608 tons of fuel (19 jumbo), 11.0 km/s stage 4: 16 mainsails, 1088 tons of fuel (34 jumbo), 2.32 km/s stage 5: 35 mainsails, 2528 tons of fuel (79 jumbo), 2.17 km/s Total mass over 5000 tons. Theoretically only 200 parts, before adding struts and splitting parts up for symmetry/structural reasons. Realistically probably more like 4 or 5 hundred parts, at least.

Cool thing to note: you can now get Mathematica for free on a Raspberry Pi: http://www.wolfram.com/raspberry-pi/ Not the fastest processor in the world, but costs a lot less than a proper Mathematica license if you don't have access to one through your school / employer. P.S: I like your taste in music.

Ditto. You [Arrowstar] picked up mod-making pretty quickly, nice work.

"and no additional parts" ... you can move the solar panel and battery to a lower stage and it should work the same way, maybe even a tiny bit more dV if you put them on stage 3 or 4. Nice numbers though, I'll have to decide whether or not to build another monster at a higher part count than my last one. I've got some on-paper designs at over 37 km/s, but won't know if they're realistically buildable or flyable unless I try. I've also been thinking about making a "classic staging" version, but not sure whether drop tanks would be acceptable for that.

Jets don't use the rocket equation in quite the same way, since they don't have to carry their own oxidizer. I think you can effectively multiply the Isp by the ratio of intake air to fuel mass (or is it intake air plus fuel mass, divided by fuel mass? I forget which). numerobis knows for sure and hopefully correct me here.

Max theoretical dV is just the limit of infinite fuel tanks at the best mass ratio your component choices allow. Max practical dV is a function of TWR. Flip through my charts and you'll see that for high TWR, there's an upper limit of dV on the right side of the chart, that just isn't possible at a given TWR with the engines and fuel tanks we have. Play around with the spreadsheet version and you can see that as dV gets close to the max possible for a given TWR, the craft mass increases very quickly relative to the payload.

I've been curious about the same thing. The initial stats sort of made sense since it was imported directly as-is from KSPX. In KSPX it was 10 kg heavier but 50 seconds better Isp than its existing radial version. When I saw in pre-release streams that it was on its way to stock I was hoping it would be corrected to have the same stats as the 24-77 for better balance, but that didn't happen. We'll probably get a few balance passes, after or along with physics fixes, in future patches. Part costs are going to be an interesting balancing exercise too, once those start mattering.

Here's Mathematica's opinion, NDSolve uses a fancy adaptive method with very tight default tolerances (probably more accurate than KSP's own integration): https://dl.dropboxusercontent.com/u/8244638/Vertical%20ascent.pdf (pardon the lack of plot labels) Couple hundred meters off where you said burnout should happen, but matches apoapsis to within 25 meters. I'd put that small discrepancy down to the launchpad not being exactly on the equator.

Perhaps let another mod handle the C# and plugin integration for you? Could Telemachus be used to create a node via an HTTP API?

Here's an absolute entry, 32587 m/s with 145 parts, 1219 tons (possibly the heaviest thing I've built in KSP to date): This was giving me such a hard time, needing so many struts and constantly falling apart until I replaced most of the orange tanks with pairs of 32's. So numerobis, how many km/s does your design get with 20 times as many engines?

@NeilC nice, a new absolute leader. You should delete the #0 at the end of your imgur link, it'll embed nicer. At least a new leader until whatever numerobis is working on stops glitching, damn that's a lot of fuel tanks. Explosions that scatter massive numbers of parts like that are always entertaining.

The losses due to atmospheric Isp are pretty minor with only one LV-N, even at the 1.2 takeoff TWR our SSTO's are using. Take initial vacuum dV minus final vacuum dV minus dV expended from ascent stats, and the difference is under 200 m/s. Try with a pure-aerospike rocket and you'll see that difference should be nearly zero. Overall payload fraction is a slightly different story, since the low TWR increases the delta-V cost of ascent. What I've been doing here is imposing a minimum TWR constraint at each staging (or pseudo-staging, engine burnout for the SSTO) event, using a function of cumulative dV in lower stages. For my staged design I used TWR >= 1.5 - dv^2 / 1.35e7, and for the SSTO I used TWR >= 1.2*erf(4 - dv/1125), lower starting value but stays higher a little longer. This is a heuristic, but quite a bit easier than putting the full flight physics into the optimization problem along with the integer design variables, and doing simultaneous optimization of both the design and the ascent trajectory.