Gravitas Shortfall

Hey, just downloaded this and I can tell that I'm going to love it. Considered writing something similar awhile back, but my background on the maths side of things was more than a bit lacking. A couple quick questions on the multi-flyby tool. I'm assuming this tries to optimize for dV within the given time constraints. Is there a way to specify (or is it already assumed) that I wish to enter orbit at the destination, or will it just get me to the destination without considering dV needed for capture? Or is the intent to just use the multi-flyby output as initial input for the mission architect tool, and then enter constraints there? Also, it looks like you aren't allowed to have the same body set for consecutive waypoints. Is there are particular reason for this? Perhaps there's no good use for it in the Kerbal system, but I know in real life, NASA will sometimes set up trajectories that perform multiple gravity assists around the same body - Cassini, for instance, had two consecutive Venus flybys, as I recall. Again, great looking tool - can't wait to play around with it more once I can find some free time.

When I remember, I'll put some retrograde separatrons on my final launch stage to push it back into the atmosphere after I make orbit, but I'm not horribly bothered by the occasional piece of debris. My parking orbits are generally low enough that in real life it probably wouldn't take that long for them to decay, so every once and awhile I just go to the tracking station and terminate anything that might get in the way of future missions.

We'll have to match speed with the asteroid regardless, so whether you intercept in Kerbin's SOI or the sun's, you'll be spending the dV to reach interplanetary velocities, so where would you actually save by doing the intercept around Kerbin?

When a rocket launches, the upward force is being applied to the bottom of said rocket by the engines of the first stage, and that first stage has to be able to support everything above it whilst under a force of >1 g. Thus any rocket capable of making it off the ground should, at least in theory, also be able to be supported by launch clamps attached only beneath the first stage engines. The vehicle in the screenshot isn't too much smaller than my largest launcher, which I support on the launch pad by means of 3 launch clamps placed below a fuel tank placed below a decoupler placed below each of the 19 first stage mainsails.

Computers and and lots of clever math: http://www.esa.int/gsp/ACT/inf/projects/gtop/gtop.html I've looked briefly at using PaGMO to calculate trajectories in KSP, but ran into trouble getting things to compile and run on Windows. I'll probably give it another try at some point, but I wouldn't complain if someone with either a Linux machine or more experience with Visual Studio decided to beat me to it.

Hmm, Top Gear... "Some say that he lives on the surface of Jool, and that his blood can be used to fuel LV-Ns. All we know is, he's called the Jeb."

I feel your pain - currently working on a 288T launcher myself (had one already, but let's just say it's reliability left something to be desired). You can always add more fuel and more engines, so the tricky part is making sure it won't fall part. As SRV Ron suggested, build in stages. That is, attach the very last stage to the payload first, launch it, and make sure it holds together across through the duration of the stage. Once that's working, add the second to last stage and make sure that holds together, and so on. Install mechjeb or some equivalent to get info on dV and TWR for each stage, and if you have a general idea of what sort of rocket you want, that info can guide your design. For instance, if you're doing serial staging and have the same engine type (mainsails, say) for every stage, then the optimal design will divide dV evenly between all stages. If some of your engines are more efficient than others, you'll probably want to give slightly more dV to those stages. I don't know off the top of my head what the optimal strategy is for dividing dV in asparagus rockets, but I've no doubt the answer is on this forum somewhere. Ideal TWR is apparently around 2 on the launch pad - personally I tend to end up quite a bit lower than that because I'm concerned about part counts, and so would rather use a slightly larger fuel tank than deal with cluster engines, but it's something else to keep in mind. And use lots struts, but use them smartly - you don't want to get your part count too high, and a little bit of flex is going to hold together better than something that's completely rigid.

I tried and failed numerous times to get this into orbit.

If you're aren't opposed to mods, MechJeb will give you helpful stats in the vehicle assembly building, including the thrust/weight ratio for each stage. Very helpful for designing launchers.

edit: weird delayed dup post - disregard.

Hmm, is the 3353 from Eve assuming you're starting from Eve orbit? If this is just an Eve flyby, then the ship should actually already be on a trajectory to more or less intercept Kerbin's orbit without any burn near Eve. Any burn just needs to adjust that trajectory enough to account for the fact that you aren't actually in an Eve -> Kerbin launch window. Also, this method is assuming an optimal transfer from Kerbin to Eve, but another thing someone could try is forcing an early or late transfer using the date constraints, and then seeing if you make up that DV with a more favorable return.

Here you go: http://alexmoon.github.io/ksp/ You can put restrictions on departure date and travel time. What you have to do is find a transfer from Kerbin to Eve, note the arrival date, and then find a transfer from Eve to Kerbin that leaves the same day. You can add up the required DV for both legs, but that's going to be a big overestimate if you're just doing a flyby, as you'll never need to match velocity with Eve, and you can do an aerocapture when returning to Kerbin. I'd suspect that 8K DV would be more than enough.

A Kerbin year is far less than 222 days, I believe, and so if you had a trajectory that was more or less completely contained within Kerbin's orbit, it should also take less than 222 days. As for planning such a trajectory, that's a bit more difficult. I suspect that it's possible with 8K DV, but I don't know how feasible it would be to find a workable solution via trial and error. There should be a program floating around this forum that's capable of planning flyby maneuvers. I don't know if it can handle the weird case where your destination planet is also your planet of origin, but it's probably the closest to what you're looking for if you just want to go to Eve and back. The problem gets more complicated if you want to chain together multiple gravity assists, like NASA did with the Voyager missions, and I'm not aware of any existing tools that'll do that for KSP.

I recently stumbled upon http://pagmo.sourceforge.net/pagmo/index.html, which comes with implementations of some real-world trajectory optimization problems provided by the ESA. Need to spend some time digging through the code to figure out exactly what it's doing, but at a glance it seems like it could be modified without too much fuss to be used for KSP - then we could actually plan these things prior to launch rather than just hoping for the best. Maybe I'll play around with it a bit this coming weekend.

Plan and execute a mission to Eeloo that requires at least two gravity assists after leaving Kerbin's SOI (though if you re-enter Kerbin's SOI later and use that as one of your assists, that counts). The rocket you send shouldn't have enough delta-v do make it with fewer.

I've got a non-asparagus that can do 8 orange tanks. Not the most efficient from a fuel perspective, but there's something to be said for simple staging.

I have a 2-stager that can just barely manage 288 tons to a 70km orbit. Part count isn't awful, but it will occasionally fall apart on the launch pad. Maybe one of these days I'll clean it up a bit and post in on here, but the gist is 19 mainsails behind 38 orange tanks in the first stage, and 7 mainsails behind 14 orange tanks in the second. The tricky bit is getting it all to hold together with minimal strutting.

Thanks, I'll definitely give that tool a look. The impression I get from Google is that for truly crazy, Eve-Eve-Duna-Kerbin-Jool-esque multiple assist trajectories, you need to do a lot of really fancy, really time-consuming math that depends on having good candidate trajectories to begin with.

So I understand the general principal behind gravity assists, and can more or less make use of moons to change my velocity in interesting ways, but I can't help but feel my efforts a bit pitiful when compared to what NASA has managed to come up with when faced with a limited budget and, by extension, limited delta-v. The Cassini mission utilized not one, but two gravity assists from Venus, followed by a gravity assist from Earth, and finally one more from Jupiter before continuing on to Saturn. I don't know how I'd even begin to start planning something like that. I'm curious if anyone here has managed anything that roundabout for their missions to the outer planets, and if so, if it was just for the challenge, or because their computer couldn't handle high part numbers for more delta-v, or whatever.

Shouldn't that go both ways, though? If the tail connector is a crossfeed, then shouldn't my mainsails and -30s just all share the same fuel supply, and shut down at the same time?' Will try to add some pics once I get back to my main computer.

Don't have the game in front of me, so I'm not in a position to try and replicate your issues, but parts can be reoriented with the w,a,s,d,q, and e keys (in case you hadn't already figured that out - took me awhile to realize you could do that). Assuming that's not enough, and the game still doesn't like you placing things in certain orientations, you could try playing with some of the strut parts which are small, don't weight much, and good for giving you new orientations to work with. Wouldn't be 100% true to the original design, but for the most part shouldn't be too noticeable if viewed from a distance.

Hmm, that doesn't seem right to me. Langrange points are a solution to the 3-body problem, but our solar system has plenty of langrange points despite having 8 planets countless other smaller bodies. The gravity of Jupiter is going to give the Sun a different path through space than you'd expect if the only bodies in the solar system were the Sun and Earth, but the Earth lagrange points still 'work'. Mind you, I haven't done all the simulations you have, so I'm just going off intuition. Maybe I'll try running some numbers of my own later.

I've got a jumbo-64 with a mainsail beneath it, 6 more jumbo-64s with mainsail radially attached, and then to each of the radial jumbo-64s, I have 3 T800s each with an LV-T30. No fuel lines. Now if I just looks at each of these engines and corresponding fuel tank individually, then MechJeb tells me I should get 58s of thrust for all of them, but when I put it all together and launch, what happened is that first the radial mainsails run out of fuel, then a little later the central one, and then finally the TV-T30s. Now all I can figure is that is happening because my T800s are actually attached by means of a tail connector for reasons of prettiness, and since the model snaps together in such a way that the TV-T30s appear below the jumbo-64, they're somehow drawing fuel from the 64s first rather than the T800s. So I guess my question is what determines which tank an engine first draws fuel from, and how might I get around this particular problem? I tried adding fuel lines from the T800s straight to the LV-T30s, but they still seemed to be draining the jumbos first.