Zhetaan

If your trips are not getting logged, it sounds like a bug. Do you have any mods? Crew members get increasing experience for flybys, orbits, suborbits, landings, and planting flags on other bodies (at the least; there may be others) for every body except Kerbin, where, for obvious reasons, experience increases going out from the surface. The experience is not additive for a body; the kerbals get the single greatest amount of experience available for single event on a given body. For example, the single greatest amount you can get is for planting a flag; however, to do that, you need to also do everything else (flyby, orbit, land). If, to continue the example, a Kerbal gets one point for a Mun flyby, two for orbit, three for landing, and four for a flag, doing all of these things will net ... four experience points. A kerbal who lands but does not plant a flag gets three; if you remember and have it plant that flag, it gets one more point. There is no limit to the number of bodies a kerbal can use to gain experince; the only limit is the amount of available experience to each one. A kerbal gets nothing for orbiting a body once landed on, but when trying to design a training mission, it may make more sense to do less at several easy-to-reach targets than to try to plant flags at each one. Planting flags on the Mun, for example, aren't worth the expense of landing when a flyby, flag at Minmus, and brief trip into the solar sphere of influence will get them to level three (and they can't reach four without an interplanetary mission). It is possible to do all of this training on one trip. You could send a zero-star kerbal on a grand tour and recover a level five; however, the experience points are not added until the crew is recovered back on Kerbin, so the zero-star kerbal will be zero stars for the entire trip.

It's not a bug. Press 'X' to change your symmetry mode. It cycles through one, two, three, four, six, eight, and back to one again. You can see the indicator for this on the bottom left of your screen; it's the one with a single dot in the centre.

Ancient Japanese proverb: Nanakorobi yaoki Roughly translated: Fall off ladder seven times, fly up to hatch eight times. Also, if nothing else, please take with you the notion that even though KSP can be all about exploration of strange, new worlds, you should take nothing for granted. As others have said, it's beyond frustrating that these things don't work intuitively, but the best time to find out about it is when you can do something about it: i.e., on the pad.

@BgDestroy: Kepler's Third Law says that the square of the orbital period is proportional to the cube of the semi-major axis. In other words, if: T = orbital period a = semi-major axis k = constant of proportionality Then: T2 = a3 * k It happens that k = 4π2 / GM, so to calculate it out, let's look at both cases. Circular orbit, Ap = Pe = 100 km: a = (Ap + Pe + dKerbin) / 2 = (100 + 100 + 1200) / 2 = 1400 / 2 = 700 km = 700000 m GM = 3.5316 * 1012 m3 / s2 k = 4π2 / 3.5316 * 1012 = 1.1228 * 10-11 T2 = (700000)3 * 1.1228 * 10-11 = 3851204 s2 T = 1962.4 s = 32.7 min Elliptical Orbit, Ap = 500 km, Pe = 100 km: a = (Ap + Pe + dKerbin) / 2 = (500 + 100 + 1200) / 2 = 900 km = 900000 m T2 = (900000)3 * 1.1228 * 10-11 = 8185212 s2 T = 2861.0 s = 47.7 min The travel time from the new Pe to the new Ap would be half the orbital period, or about 23.9 minutes. The orbital speed when you get there is a different set of calculations: v = (GM * [(2 / r) - (1 / a)])1/2 where v is the orbital speed, a is the semi-major axis, and r is the distance to calculate the speed. For your question, when you arrive at a 500 km apoapsis from a 100 km periapsis: a = 900000 m r = Ap + rKerbin = 1100000 m v = (3.5316 * 1012 * [(2 / 1100000) - ( 1 / 900000)])1/2 = (3.5316 * 1012 * [1.818 * 10-6 - 1.111 * 10-6])1/2 = (3.5316 * 1012 * 7.07 * 10-7)1/2 = (2.497 * 106)1/2 = 1580.1 m/s In like fashion, the speed at the periapsis: r = Pe + rKerbin = 700000 m v = (3.5316 * 1012 * [(2 / 700000) - ( 1 / 900000)])1/2 = (3.5316 * 1012 * [2.857 * 10-6 - 1.111 * 10-6])1/2 = (3.5316 * 1012 * 1.746 * 10-6)1/2 = (6.167 * 106)1/2 = 2483.2 m/s

I'd go Terrier. The Terrier and Dart have nearly equal efficiency in vacuum, but the Dart is twice the mass, ten times the cost, has no vectoring, and while it is true that you can tweak the thrust down to Terrier levels for low-gravity moons, there's a much easier way to get Terrier-like thrust (guess what it is!). If you think you need extra thrust, I'd suggest that you bring two Terriers. The Dart only starts to carry its rather heavy weight when you need three Terriers' worth of thrust or you want a single-engine solution for an atmospheric lander.

... Because you're forgetting to add the planet. You're using your apsis values. That's a mistake, because those numbers are altitudes. In other words, they measure from Kerbin's surface and ignore the big, rocky part that goes down to the actual centre of the circle. Kerbin has a planetary radius of 600 km. Adding that to the calculation, we get: 3 * (1.2 + .6) / 1.73 3 * 1.8 / 1.73 = 3.12 Mm 3.12 Mm > 2.5 Mm Working backwards: 2.5 Mm * 1.73 / 3 - .6 = roughly 840 km. Communotron-16s in a circular 3-sat configuration such as you have won't make a network above that altitude.

@Streetwind: On seeing your signature, I suppose you would have the last word. It's been some time since I was last able to run NF Tech (though I have it now; I just haven't run any of the big electric engines yet).

How much battery capacity do you have? It sounds as though your engines are outstripping your ability to produce power. Using an NFE reactor to test wouldn't work very well, either, for the same reason: NFE reactors are designed to produce steady output for constant electrical loads. Intermittent loads require the reactors to spool up or down, which takes enough time that they can't keep up with the demand unless there are electrical reserves. To test it, try a big battery stack instead of a reactor and see whether you can run the engine for a longer time. Generally, the way to design these kinds of missions when using NFE is to acknowledge the fact that you can't use solar power to run electrical engines directly with anything smaller than blanket arrays, and instead make use of the fact that solar runs constantly but the engines run intermittently. Batteries have mass, of course, so you have to mind that battery mass in much the same fashion as you do mass fraction for chemical rockets. You could, for example, put a couple millions of EC in batteries on your craft and run the engines forever--which you will need to do in order for those engines to push it anywhere meaningful. There are several ways to squeeze the most out of batteries while keeping the craft both light and capable. One is to use (for example) half the batteries, but also to thrust-limit the engine so that it only uses battery capacity at half the rate. You only get half the thrust, though, so the engine has to run twice as long. Total savings: whatever dV you get from not carrying half the batteries, and the reduced drain rate compared to the solar panel input rate is a better charge ratio. It might be enough to let the solar panels keep up enough to complete your burn. Another is to use capacitors. This is one of the intended uses of NFE capacitors; you store charge in them when you have extra power so that you can use it when you need extra power. Functionally, it's exactly the same as extra batteries, except that capacitors have a much better charge-mass ratio than batteries do. Keep in mind that with capacitors, you still need to carry some batteries; the charge needs somewhere to go when you release it. Yet another is to use blanket solar arrays. This is heavy-handed and the electric engine equivalent of 'moar boostrz!' but it bears mentioning to illustrate that the problem with running electrical engines is less one of capacity and more one of charge-discharge rate. With enough panels, you can direct-drive your engines with any battery configuration. You can use RTGs, not to replace the panels, but to supplement them. Every RTG is a constant .75 EC/s of charge rate that your panels don't have to supply (unless you're using DecayingRTG, as well), at the cost of terrible mass ratio. Lastly, you can do what Juno did: use a chemical rocket for orbital insertion and rely on the solar panels to run everything else.

In his thread LKO to Jool for 1051 m/s, @PLAD goes into a bit of detail on how to do multiple gravity assists. In this thread, it is further mentioned how to take advantage of the great disparity in orbit size to easily get the resonances that you will need for good encounters. I'd also suggest going into your settings.cfg file and changing your patched_conics_limit to something high enough that you can plan far enough ahead to see what your assist is doing, but without going so far as to really hurt your computer's performance or introduce glitches. Six seems to be the de facto standard choice. To really put this together, I think that Flyby Finder is what you need. I looked at it myself and found that it appears to be possible to get a Dres-Jool-Kerbin burn starting on day 2095.96 (Year 5, day 391, hour 5.7) for 964 m/s from a starting altitude of 75 km, that then flies by Jool at an altitude of 42770 km (about Vall's orbit) on day 3026 (Y8 D44), and finally encounters Kerbin on day 4146 (y10 D 312). Braking delta vee brings this trip to nearly 3100 m/s, but since you don't have that, slowing down when you get there is your problem. I hope you have lots of ablator. Bear in mind that I am no expert on multiple gravity assists--you may well need to figure out something else--but this is what the first-pass search has found. Here's the detailed information on the burn: Start Planet: Dres Orbit Departure Time: 45251136 seconds UT 2095.96 days UT Y5 D391 H5.7 Start Orbit Inclination: -4.9 degrees Start Boost from that incl.: 964 m/s Start Equatorial Z velocity: -110 m/s Start Equat. Prograde velocity: 960 m/s Start Boost from Equat. Orbit: 966 m/s V Infinity Leaving Start Planet: 1201 m/s 1st Encounter Planet: Jool Time from Start to 1st Encounter: 930 days 0.2 hours Vinf in: 1706 m/s Brake to Orbit?: 2962 m/s 1st Encounter Periapsis: 3026 days UT Y8 D44 H0 42770 km altitude Vinf out: 1706 m/s 2nd Encounter Planet: Kerbin Time from 1st to 2nd Encounter: 1120 days 1.1 hours Vinf in: 3021 m/s Brake to Orbit?: 2131 m/s 2nd Encounter Periapsis: 4146.2 days UT Y10 D312 H1.1 Total delta V expended: 3096 m/s Total Travel Time: 2050 days

You keep researching. The idea is that scientists, over time, convert the data into science points. When they do this, the data points go away and science points take their place. The reason you're not seeing this happen very quickly is because your conversion rate is low: you're only getting .2284 science points per day. Since the conversion ratio of data to science is 1:5, that means you're using up around .04 data per day. Get a higher level scientist in that lab. Better yet, get two. Even with top-level scientists, though, you should understand that this is meant to be long-term research. Those scientists will be in that lab for a long time--think on the order of a few hundred days. Also understand that because you get five science points for every data point, the science will fill and you will need to revisit the lab to transmit it. Furthermore, remember that research is exponential, meaning that as the data points are used up, research slows. In order to keep a lab as a going concern and producing science points as quickly as possible, you need to visit it periodically to add more science experiments as well as to transmit what science points have accumulated.

Get the dev build.

As @Warzouz indicated, the greatest part of interplanetary transfer is getting the angle correct. (Warning: Wall of text) To calculate this yourself, you need to start with orbital information for the planets involved. Kerbin is easy; it's in a circular orbit of 13.600 Gm. Duna is harder; it has an eccentric orbit that goes between a periapsis of 19.669 Gm and an apoapsis of 21.783 Gm. If you draw a line connecting the two apsides, you get what is called the major axis and it is 41.452 Gm. For orbital calculation, we're interested in the semi-major axis, which is simply half that value (or 20.726 Gm). Note that all of this information is easily found or derived from easily found information in map mode. Since Kerbin is in a circular orbit, its periapsis is its apoapsis is its semi-major axis. As I said, Kerbin is easy. Now, let's consider how we're getting to Duna. Never mind that we don't have a good flight plan yet; let's assume that we're starting at Kerbin's orbit and going to Duna's orbit. These orbits exist whether or not the planets occupy them (consider moving a satellite between a 100km to a 500 km Kerbin orbit, for example; you can do it even if there are no other sats in the sky), so the concept of moving between orbits doesn't require there to be anything at either the departure or arrival points: we're only insterested in the path to get there. The type of path we're going to use is called a Hohmann transfer orbit (apologies if you know this already) and it's based on the premise that the most fuel-efficient way to go from lower orbit A to higher orbit B is to set up an eccentric orbit such that its periapsis is on A and its apoapsis is on B (it isn't always the most efficient, but the exceptions are rare). In other words, when you start, you're at A, and half an orbit later, you'll be at B. Half an orbit after that, you're back at A. How do we find the orbital parameters for the transfer orbit? We use the departure and arrival orbits! Our interplanetary ship is starting at Kerbin's orbit and ending at Duna's orbit, so the transfer orbit's periapsis and apoapsis will correspond closely to Kerbin's and Duna's semi-major axes. Again, this is a rough estimate that assumes Kerbin and Duna's orbits are perfectly circular and perfectly aligned with one another, but they are fairly close to that ideal and so provide a good example. Our transfer orbit's periapsis is Kerbin's orbit, i.e. 13.600 Gm. Its apoapsis is Duna's orbit, i.e. 20.726 Gm. The total major axis of this orbit is 34.326 Gm, so its semi-major axis is 17.163 Gm. Now we need to know how long it will take to travel this orbit. For this, we can use Kepler's Third Law, which states that the orbital period (time to orbit once) is related to two things: the semi-major axis of the orbit and the gravity of the object it's orbiting (specifically, the equation is Torbitalperiod = 2π * (Asemi-major3 / MG)1/2. The nice thing about Kepler's third law is that eccentricity doesn't matter: all orbits of a given semi-major axis in a system will have the same period. The nice thing about these orbits is that they all orbit the same thing (the sun) so the gravitational parameter (MG) is the same in all three cases, which means that you don't actually need to figure out the mass and gravity of the sun if you know the orbital period and semi-major axis of at least one of those orbits. Kerbin's orbital period is 426 6-hour days. For Kepler's laws, we need this in seconds (and Kerbin's year is not exactly 426 days long; but the remainder can be sucked up into the rounding error), so 426 (days/orbit) * 6 (hours/day) * 60 (minutes/hour) * 60 (seconds/minute) = 9201600 seconds/orbit. Plugging in what we know and a bit of algebraic wizardry later (you mentioned wanting to work this stuff out for yourself, so I won't show the specifics), it works out that for any object orbiting the KSP sun, the orbital period equals the semi-major axis raised to the three-halves power (break out your scientific calculator) times a constant equal to 5.8017 x 10-9. To check the answer, we can use Duna's semi-major axis: again, I'll leave the details to the student, but all told, it gives an orbital period of roughly 801.5 days, which agrees pretty well with Duna's actual orbital period of 801.6 days. Now, let's try it on the transfer orbit: with a semi-major axis of 17.163 Gm, the orbital period works out to about 13,045,000 seconds, or 603.9 6-hour days. Just by looking at it, it makes sense: the transfer orbit should be somewhere between the other orbits. However, this isn't the number we want: the transfer takes place over half an orbit. Therefore, we want half the orbital period, or 302 days. Now we know how long we'll be in transit. The next job is to find out when to leave so that when we arrive at Duna's orbit, Duna will be there. For that, we need a little creative imagery: imagine the solar system as a clock face, and let's put Kerbin at the six o'clock position at the time of departure. We want to time our departure so that when our vessel arrives at the opposite point of its orbit (at the twelve o'clock position), Duna will be there. The clock visual isn't the best because the orbits in KSP go anticlockwise, but so long as you understand which direction you're going, you'll be fine. If we want to arrive at Duna when Duna is at the twelve o'clock position, and our trip there takes 302 days, then we want to start when Duna is 302 days away from the twelve o'clock position. That should be obvious. To get that, we need Duna's orbital period--but wait! We figured that out as a check on our modified Kepler equation! 302 days out of 801.5 days (I'm using the calculated value; I'm assuming you don't want to use anything else for this) is .3768 of the orbit. We're assuming Duna's orbit is circular (if it's very eccentric, it needs another layer of calculation), so .3768 of a circle is, out of 360 degrees, 135 degrees away from twelve o'clock. There's no reference point for the twelve o'clock position on our solar system clock, however, so let's use what we have. Kerbin is at the six o'clock position when we start, which is 180 degrees away from twelve o'clock. Subtract off the 135 degrees of Duna's position with respect to twelve o'clock and we get 45 degrees for Duna's position with respect to six o'clock, i.e. Kerbin. The fact that it is positive 45 degrees means that Duna needs to be 45 degrees ahead of Kerbin in its orbit when you launch--again, this should make sense. Duna's orbit is higher, therefore slower, so for your faster transfer orbit to get to the same place at the same time, you need to give Duna a head start. Set up a manoeuvre node when Duna is 45 degrees ahead of Kerbin and you should get the encounter. It may take a bit of tweaking and will certainly require a mid-course correction, but it should work. Needless to say, this is the quick-and-dirty method of getting encounters. It works well for Duna because Duna's orbit is nearly circular, coplanar, and concentric to Kerbin's. It works less well for other planets with different orbital parameters. For example, even with Duna, the slight eccentricity and inclination make it so that some transfer windows are better than others because there are extra dimensions of alignment that you need to consider in order to get the absolute best efficiency. For a better example, consider Dres. Dres transfer windows recur about every 1.25 years; a window is available before the end of Year 1, but if you wait for the window in Year 3, you can save nearly 500 m/s of delta vee by taking advantage of a more favourable orbital alignment. However, these extra-favourable alignments only occur about every decade, so you may want to just pack a little extra fuel instead of a lot of extra snacks. Besides, overcoming the limitations of planetary orbital arrangement is part of why you play KSP in the first place--you learn nothing by sitting at home and time warping!

You don't have enough fin, and another (often overlooked) issue is that with the fuel tanks you're using, you can increase instability as you fly. The little basic fins may be enough to hold you steady on the stick until the solid booster burns out, but once you stage the booster away, you have nothing to stabilise your upper stage. Try putting basic fins up there and larger fins on the solid booster, if you have them. Alternatively, use more solid boosters with the thrust turned down so that when they burn out, you're out of the thickest part of the atmosphere and don't need fins. The fuel tank problem is a lot more subtle. The issue is that as you use fuel, it drains downwards. Thus the upper tanks empty first and the centre of mass shifts lower, which makes the rocket unstable. To remedy this, you can use either a larger fuel tank or try to transfer fuel from the lower tanks to the upper tanks while in flight. However, given the state of your rocket, I'll guess that you're in the very beginning of career mode and have neither the larger fuel tanks nor the building upgrades necessary for resource transfer, so the remedy available to you is simply to be certain that you don't become unstable until you're out of the thickest part of the atmosphere and therefore out of danger of flipping. If that doesn't work, then you may need to get rid of the Goo canisters until you can unlock some better aerodynamics tech. They interfere with the airflow.

That's a very interesting example, not least because in reality, plutonium is almost the opposite of a non-tweakable resource: it isn't found except in trace amounts in nature, so you have to buy or manufacture it. I imagine it would be possible to set up a breeder reactor dynamic for KSP Plutonium, but if it's made from DepletedFuel, which in the CRP costs nothing, then anyone could get it for free in the VAB, thus breaking balance ... ... And that brings us right back to why things like the CRP were put together in the first place. Thanks for your time, @RoverDude! That was illuminating.

@RoverDude: That makes sense, though I will be the first to admit that there are a lot of finer points that I don't understand. To use the relevant example, keeping Karborundum in-line with other resource costs is obviously important, especially if you're going to let people buy (and sell) it, so making it cost the same as XenonGas doesn't make sense if it's supposed to be this super-special, super-rare stuff. At the same time, if you want buying it to be an option, it doesn't make sense to raise the price to the point that the stuff may as well be non-tweakable because no one will pay for it. But, my thinking goes, that only covers the edge cases of cost-setting. Why make it four thousand Funds per unit instead of, say, eight? Or two? If it isn't a bother, I would like to ask you about how you go about setting resource costs: what points you consider to set the initial cost, how you balance against other resource costs--that kind of thing. I think that out of the entire modding community, your stuff has the most resources that need to work together at the same time (though maybe KSPI-E and RF are in the same realm as USI). Add in the fact that over time, you've tended to simplify your resource chains (I remember MEPs!) and I doubt there is anyone who has had to consider the question as much as you have.

@iliketrains0pwned: That's the relevant text, but do please look at @Booots's excellent graphical analysis above. The short of it is that interstellar jumps are expensive, but not prohibitively so. Well, no more prohibitive than the ungodly-high cost of Karborundum in the first place, that is.

Doesn't this imply that one can get shielding simply by surrounding the vessel with a well-watered greenhouse? Since a food supply is a concern anyway, doesn't that make this a multiple-purpose solution?

It sounds as though you're using RasterPropMonitor. If that is true, you would have to talk to the RPM people. It may be that there's no default or saved settings feature, in which case you should suggest one.

OhioBob's Oberth Tables He really ought to name it the Near-Kerbin Astronomical Gazetteer or something similarly important.

@Snark is absolutely correct and offers a solution so obvious that I completely missed it: when in doubt, put heat shields on the side that flips to face forward. That answer is, as I said, obvious, but it's certainly a valid one. Just don't overdo it: you can't just plaster your whole rocket in heat shields and not worry at all. Moar heat shields!

You had bad information, then. The general rule for atmospheric rocketry is that you want the heavy bits at the prograde end and the draggy bits at the retrograde end if you want a stable flight. The idea is that the draggy bits, by dragging through the atmosphere behind the centre of mass, will stabilise the craft so it flies in a straight line without flipping. For ascent, it's possible to put so much drag on a rocket that it won't turn even when you want it to do so--this is why, for example, a gravity turn ascent requires you to manage the throttle, especially if you're using static fins instead of actuated control surfaces. Going too fast makes your fins essentially put your rocket in a groove that it can't escape, and that costs you a lot of efficiency. Now consider re-entry on Eve: you're going at orbital velocity, and in addition, the atmosphere is thicker. All of those drag effects I just described are magnified and your rocket flips. It's unpowered, so it doesn't cost efficiency. It just costs you your rocket. Try using F12 and looking at the aerodynamic forces overlay as you drop your rocket into Eve's atmosphere. The red arrows will tell you your drag vector; the longer the arrow, the more drag from that part. See which parts make your rocket flip: I urge you to do this so that you can see the effect in action for yourself, on your own rocket, without needing to rely on anyone else's say-so. The solution is the same, though: move your centre of mass down so that your centre of drag is above it. Just so you know, that will make this an interesting mission to get off the ground back at Kerbin; you'll need to use both fairings and creative construction techniques to be able to fly it (or maybe just fly it upside down). Ascending from Eve can be made easier if you make the draggy parts with decouplers so you can jettison them and keep them from flipping your rocket on launch thereby.

Your heat shield stack looks like a parachute. When you put it in Eve's atmosphere, it acts like a parachute. Note the location of your centre of mass: the heat shields (plus all the extremely draggy struts) are all far away from it, so they have a lot of torque and can wrench your rocket around no matter how much the SAS tries to compensate. Is there a reason you put those heat shields on such a long boom? Move them closer to the base of the rocket and see what that does.

From the man himself, not fifteen minutes ago: http://forum.kerbalspaceprogram.com/index.php?/topic/142300-could-mechjeb-fly-a-real-rocket/&do=findComment&comment=2644204

Not to be unnecessarily picky, but you're describing a geostationary orbit. Geosynchronous orbit always remains at the same longitude; geostationary orbit always remains at the same point. Snark has the best approach for a direct rendezvous with your target point; there are few problems in KSP that mathematics won't solve. If you miss your mark, however, then the second-best option is to get the altitude right and go for a circular polar orbit. In this fashion, you're just about guaranteed to get your objective within three hours (a six hour day plus the orbit going round the back of Kerbin means you make two tracks over the ground). The only way this won't happen is if your target window is very small and Kerbin rotates too far each time you pass near. In that case, your problem is orbital resonance: a half-hour orbit on Kerbin's six-hour day is a simple integer ratio that means you exactly repeat your ground track every twelve orbits (ground track in this sense means a unique orbital path as a projection onto Kerbin's surface; it has nothing whatever to do with rovers or other ground vehicles). If none of those twelve is close enough, you'll never get where you need to go. The solution then is to destroy the resonance, which you can do by modifying inclination or eccentricity. Each of these has a drawback: changing inclination changes your ground track at the cost of missing certain latitudes; changing eccentricity changes your ground track at the cost of missing certain altitudes.

ESLD Jump Beacons may be what you seek. The beacons are an in-game set of jump gates; there are three different kinds of stationary beacon with different range and tonnage limitations, and one mobile beacon that can jump itself (and the ship attached to it). It's meant to be in balance with the game mechanics, so it isn't cheap to set up and use the beacons. The beacons have altitude and gravity requirements (they have to be well out of the gravity well), and they have to be at both ends of the jump (so the destination beacon has to get there the slow way). They also take a special fuel that can only be found in a few places (however, you can set the config for other options) and they conserve momentum until you unlock some esoteric high-tech gear. This means that, for example, if you decide to jump from Kerbin to Jool, you'll go there ... and take all of your Kerbin-relative velocity with you. Thus, you'll need to pack all of the dV of a Jool transfer and use it all at once when you arrive, which usually means that it is less efficient. If you decide to use the high-tech gear, you will have near-zero relative velocity to Jool, but that will cost a lot more of the special fuel. It's an interesting mod, and I like it a lot, but it does come with a new set of rules that makes you rethink orbital mechanics on a system-wide scale. Hohmann transfers minimise relative velocity differences; with ESLD, you have to consider relative planetary motion coupled with the beacons' orbital motion in order to reduce the cost of the jump. It's very satisfying for me, but it can be frustrating if you're not expecting the magnitude of velocity differences between inner-system and outer-system orbits.