PLAD

Thanks! The Soviet LK lander had some pretty bold mission parameters, not the least of which was putting a lone astronaut on the Moon. Its c.g. had to be within 30mm of the thrust axis or it wouldn't be stable...and the astronaut had to spacewalk to and from it to the Earth Return Stage. And they actually made three Earth-orbit test flights of it. At least the lander docked to the ERS before the spacewalk, with the small open lander designs you would have to jump across open space to get back to the ERS. Both sides came up with some even more extreme designs in the early '60s, before the Outer Space Treaty was signed and they no longer had to worry that the first nation to put a man on the Moon would claim the Moon as theirs. I recall there was an early plan by the US to land a lone astronaut on the Moon before they had a way to get him back! They would finished development and construction of a return vehicle while he was waiting on the Moon for about a year, kept alive with resupply missions. Darn, I just looked for a reference to that plan and didn't find one, does anyone remember its name? Edit: found a nice secondary source here. I don't think I can find the December 1962 Aerospace Engineering article online though. Of course, that is a mission most of us (me included) have done early in our Kerbal careers, without exactly meaning to.

The new models and textures are great! I just landed a mission at the Moon's South pole and those those ridge artifacts from where the meshes stitched together are completely gone. It looks superb, I've been itching to build Lunox bases at the poles, and now I can. Next step is to land a rover and scout out the best spot. Everything is prettier too, I even noticed a nice wave effect on Earth's oceans as I was parachuting to a landing. It is superb! Combined with the latest RO updates (improved boiloff management, new configs for SXT and RSB, etc.) this game took a big step upward for me. I tested the new sidereal rotation period for Earth and updated Moonfinder. 86164.0989 seconds, right on the nose.

I've been trying to find the lightest possible Moon landing-and-return mission in RO. In real history there have almost always been at least 2 pilots on a Moon mission for safety reasons, but in the Kerbal spirit I'm flying just one lunatic brave pilot. It helps me to fairly compare the mass requirements among different designs, I'm using a standardized MK I pod for the re-entry so all missions are designed around that. So far here are my lightest weights at launch: Lunar direct (entire vessel lands on Moon ) : 395 tons, 31 tons in LEO LOR (separate lander and Earth return vehicle) : 295 tons, 24 tons in LEO LOR, open lander (see below) : 215 tons, 17.5 tons in LEO For comparison the Apollo -Saturn 5 was about 2900 tons at launch, and the Soviet N-1 about 2750. Below are the highlights of the 215-ton mission. You might think that the open one-seat lander is insanely dangerous. You'd be right. That didn't stop it from being actually considered though. Heck, mine is heavier than the Langley Lightest design, though that was to use H2/O2 and I don't know how they planned to deal with boiloff with those little tanks. Didn't they play KSP in 1961? I use all RO dependencies and all the difficulty recommendations except Remote Tech and saturatable reaction wheels, but I don't use reaction wheels anymore. I only use the RO configs for all parts with two exceptions: 1) Lunar returns inevitably explode when hitting Earths atmosphere from the heat getting around the heat shield and destroying the occluded pod and its parts. I therefore turn off heat damage with the F12 menu. To play it fair I make the heat shield weigh 15% of the total weight it is decelerating, just like the Apollo heat shield did. As long as deceleration stays below 10 G's I call it a successful re-entry. 2) The solar panels got nerfed a couple of versions ago, my favorite panel went from level 3 energy per m^2 to level 2. I buffed it back to level 3. The great thing about my lightest missions is that the mass to LEO is less than 24 tons, so these missions could be put on existing rocket designs. I'm going to grab Necrobones' superb Real Space Boosters and try that next. That little lander is a blast to fly. It amuses me that the ascent stage looks like some ultra-light Munar landers in stock KSP, but the basic design would work in the real world too. Six words I like to say in KSP: "It works in NASA's space program". (Sorry Mr. Munroe)

What a_schack said. I might add that a reason that I don't want to put it in game is that it takes too big a window to show all its info, especially when I'm searching through the table. I tend to spend a long time searching for the best path and when I finally settle on one I copy it as text from the detail box, which is easy to refer to later. The other big reason is that I don't have the programming chops to put it in game.

Thanks for the note on Earth's sidereal rotation period @NathanKell, and as always, thanks for making this superb mod in the first place. I'm looking forward to seeing the new look!

I recommend Flyby Finder for planning multiple gravity assists (disclaimer: I wrote it) but TOT can also plan them. Nether one can handle double flybys of the same planet or multiple orbits of the sun between encounters, but there is still a lot to be found with what we've got. I fine example of using flybys was this mission by Val some time ago, Val used flybys to get out to Jool and then to get back to Kerbin at a lower speed than was possible with a direct Jool-Kerbin flight. In the pre-1.0 days we all just came piling in to Kerbin's atmosphere at extreme speeds but since then we have to slow down first, in this mission Val goes Jool-Kerbin-Eve-Kerbin to arrive at a safe speed. Note that the trip back is easier to plan than the trip out, Val just winged the return. If you are coming back from Eeloo though you can save a lot if you flyby Jool on the way to the inner system, and that could use some planning. I once went from Kerbin to Eeloo landing and back to Kerbin with a 12-ton SSTO, that was many versions ago so the SSTO is obsolete but the path is still good.

I made it to to Duna's surface and back with a stock Kerbal-X, but that was in version 0.90. Back then the KX had 7333m/s of delta-V, but it took a minimum of 4358m/s to get into a 75x75km Kerbin orbit from the surface back then. Now the KX has about 6459m/s but it takes about 3350m/s to get into orbit. The number you really care about is the delta-V available once you are in your Kerbin parking orbit, so back in 1.04 I did some experiments and got it up there with 3012m/s left. That beats the 2866m/s I had left in Kerbin orbit in my attempt, so it should be possible to do this in 1.05, as long as you can survive the aerobraking. Note that I made it from LKO to the Duna aerobraking for 878m/s (thanks to those 5 flybys of Mun), 48m/s from Duna encounter to landing, 1340m/s from Duna surface to 50x50km orbit, and finally 528m/s from LDO to Kerbin aerobraking (with Ike flyby). 2794m/s total. That leaves about 220m/s to deal with aerobraking and drag issues in a 1.0.5 attempt. I think the the stock KX doesn't have any kind of heat shield, so I imagine several braking passes will be needed to survive the Kerbin landing. The stock K-X is a fascinating ship, I think it can just barely do a number of interesting missions. I haven't tried it for anything since a Kerbin-Mun-Minmus-Kerbin mission in 1.02 though. I would be very interested to see the mission if you do this. Edit- Someone else did another Kerbal-X to Duna and back mission only with only one Mun flyby (and one of Ike), he chose the absolute optimal transfer windows out and back (which cost about 140 81m/s more), but landed and took off for about 100 55m/s less than I did, but I have not found that mission report yet. So the mission doesn't have to be as complicated as the one I did. His was version 0.90 too. 2nd edit- found it. Von Ziegendorf made a spectacularly efficient Duna landing and return to orbit. He did LKO to Duna arrival 985m/s, Duna arrival to landing 26m/s, Duna surface to orbit 1307m/s, LDO to Kerbin landing 502m/s. 2820m/s total. The modern aero model might make that impossible to match.

Oops, you're right, I didn't address that method. Excuse me while I figure this out. 1) Get into a 75x75km equatorial orbit. This saves 27m/s over launching into a 28-degree orbit. 2) Get into a 75x 83,000km orbit, which goes right out to the edge of Kerbin's SOI. This will require a boost of 934m/s, and the velocity will be 26m/s at apoapsis. Because Kerbin's SOI does not go to infinity you cannot reduce this number and stay in Kerbin's SOI. Note that you will require several adjustments to get this apoapsis so precise, in practice you will blow all your gains in these maneuvers, or you can settle with a lower apoapsis, but this is an ideal case. 3) At apoapsis change the plane of the orbit by 28.3 degrees. This will require a ~12.5m/s thrust. (Law of sines) 4) at the next periapsis complete the prograde thrust, in this case to get from 934m/s over circular V at 75km to the desired 1058m/s, so another 124m/s and you're on to Eve. Now you have reduced the 27m/s extra required for the 28-degree solution to 12.5m/s extra. Since the 28-degree departure cost 14m/s less (1058 versus 1072) this means the 28-degree solution is very slightly better, but given that it takes about 250 hours to get out to the SOI and back and that course corrections will cost you more than you save I would stick with the equatorial solution. This should get much more useful for higher inclinations, but I think it would have to be examined case by case rather than some rule of thumb though.

Alex Mun's porkchop plotter gives the departure thrust required assuming you are starting from an equatorial orbit. This will usually be a higher number than if you are allowed to start from an optimally inclined orbit, but since Kerbin's surface is moving at 175m/s at the equator it will cost more to get from the KSC into a non-equatorial orbit than to launch into an equatorial orbit. So we come to your question about how much launching into the optimal orbit can save in the departure burn. Looking at the first Kerbin-Eve window, Alex Mun's plotter says the lowest-dv transfer (from an equatorial orbit) leaves Kerbin on Y2 D160.8 and arrives at Eve on Y2 D357.4. From an equatorial, 75x75km orbit it requires a 1072m/s ejection burn (Normal of -201.8m/s, prograde of 1052.4). Note that this would be one burn, done at 75km Kerbin altitude. It would be very inefficient to do a 2nd burn near Kerbin's SOI to correct inclination. I wrote Flyby Finder to compute departure burns assuming you start in the optimally inclined orbit. If you search the same window with it it gives the lowest dV transfer (from any inclination orbit) as leaving Kerbin on Y2 D141 and arriving at Eve on Y2 D339 and requiring a 1058m/s ejection burn (all prograde), but you have to start from an orbit that is inclined -28.3 degrees. I tried it and found that when launching a Kerbal X into these orbits with Mechjeb it costs me 27m/s more to get into the 28-degree 75x75km orbit than an equatorial orbit. So the equatorial is better by a little bit, unless for some reason you need to leave earlier in the window. Note that Mechjeb isn't too accurate in placing you in an exact inclination and LAN orbit, (and I'm far worse trying to do it manually) so the equatorial approach is usually better in practice since that is easier to get into. This is normally the case, either way is pretty close to each other in total dV, so the easier equatorial wins. The exception is when there is no low-inclination solution in a given transfer window (which happens sometimes for the slow-moving Dres, Jool, and Eeloo) or any time you need to arrive at your destination when it is far from Kerbin's orbital plane. Then you can save up to hundreds of m/s by launching into the optimally inclined Kerbin orbit instead of an equatorial Kerbin orbit. And if you are using RSS, or in the real world, then all of this goes out the window since you launch from a non-equatorial site, and the Earth's equator isn't in the plane of the planet's orbits. Here a properly-timed due-East launch is almost always the way to go.

This is extremely useful for the RSS mod too. I will never launch to a planetary departure orbit in RSS without the 'launch to circular orbit' and 'create transfer node' features again. If you reach a point where you do not plan any big changes to that part of the interface I will add this to my FF tutorials. I am not sure what you meant about modifying fields, I have the 'Increment all search dates by' field in FF that allows you to change all the 'Earliest search date' fields at once, is it something like that? I want to keep that in days rather than years so I don't have to write decimal points when entering data. Sorry if I am misunderstanding.

I wrote Flyby Finder for just this sort of thing. If you want to do Kerbin-Eve-Kerbin-Jool then here is an example of that path showing the tricks I use in executing it. If you want to do Kerbin-Eve-Kerbin-Kerbin-Jool then you will be more restricted in available launch windows and you will have to use my Lambert spreadsheet to find them (also on the FF page), or use one of the ones that have already been found. I used what I think is the best one one in the SSTO to Laythe thread. This is also harder to fly, the more flybys there are the more accurate you have to be in your timing, or the later flybys become very expensive or impossible. I might add that somebody worked out a general procedure for using a Juno-style Kerbin-Kerbin-Jool path for getting to Jool, it's only a bit more expensive than K-E-K-J. Argh, I've forgotton the link, I'll find it later today. EDIT-Here it is. The great thing about the Juno path is that it is available every Jool-Kerbin Synodic period, a little less than once a Kerbin year. Bonne Chance!

OK, got it, I didn't understand what the "Choose" button did. I've also since figured out the "PartialBoostGuidance" field and that it is why the blue orbit was elliptical. I should have studied more before commenting! I realized that OffsetHours(firstday) compensates for the fact that I call the start time of the game (0 seconds UT) day "1" instead of "0". What would the year offset do? I have to be careful that I understand it correctly, all the 6/426 and 24/365 and indicated time details take me some effort to keep straight. (When I first wrote FF, KSP only had the 24/365 time system so I didn't make it easy to change.) I'm going to try this with the RSS/RO mod now.

A note for Flyby Finder users, I've tried okder's addon, and it is superb for knowing when to launch to get into the best start orbit, and for setting up the node to depart from your start planet and get to the first encounter planet at the right time. It even corrects for errors in getting into the start orbit! I put a quick review on his thread. It's not perfect yet, but then neither is FF!

You are right that that code could not handle an orbit close to a parabola. But that line only gets fed the results of a Lambert path from one planet to another, and in the stock system that means it will always be well above parabolic energy. For instance the minimum speed at infinity (true infinity, not the SOI) for a path from Kerbin to Eve is about 800 m/s. If I ever tried to use the code for going, say, between Jool's moons it would crash hard. Of course in that case the fact that I used linked conics rather than patched conics would also not work. I optimized the program for a rather restricted set of orbits, but I think it does what it does do well. My greatest weakness right now is the start orbit definition, and I see you've beaten that with your superb addon. I need to at least give the LAN of the optimal start orbit. Next version.

Very nice addon here. I tried it out setting up a couple of flyby paths and it did the job correctly. This is a really handy way to get into the right orbit and especially to set up the departure node from the start planet to the first planet. The fact that it corrects for errors in getting to the start orbit is superb. In Flyby Finder I define the departure orbit using an equatorial orbit for reference, but that is usually not the most efficient orbit to get into from the surface. This addon finds the most efficient orbit to use, and it finds ones where FF gets the 'inclination 90 degrees' error. I made up a little primer to explain what I mean since I can't explain it without pictures. (I can see that okder already knows this, so this is for everyone else.) Something I forgot to say- the diameter of the departure circle varies from about 60 degrees for a minimal trip to Eve to about 120 degrees for a trip straight to Eeloo. My drawings show it too small. Here are my experiences from using the addon: I'm tempted to suggest that you eliminate the 'short path' choice by checking the boost from circular value from both the short and long way and eliminating the one that is much bigger, but I kind of liked being able to see both Lambert solutions. Great Job!

When I saw this incredible picture of Pluto taken by New Horizons and my first thought was "oh crud, finding an area flat enough to land safely in there is going to be a nightmare, and roving over those ridges in that low g will be even worse".

This looks handy! It sounds like you take the departure time and first flyby time as inputs, then use a Lambert algorithm to find the details of the transfer orbits (Two of them, the prograde and the retrograde solutions, FF weeds out the retrograde one but like you say it's easy to choose the right one.) Then you calculate the best time and inclination to launch from the KSC to get into that path, and it sounds like you perform the launch. This would eliminate the need for a test probe and my 'shift the node time back and forth until you get an encounter' trick. I've downloaded it and will try it out. I'll put further comments in the thread you made for it.

It shouldn't matter where the FF .exe is put, the program doesn't read from or write to anything else. To 'turn on' the OPM planets, first have FF version 0.80 or higher running, then press the "clear" button. The button "Select Plantary System" should now be active, and you can press it and select the OPM system. Then hit "done", and now the OPM planets are selectable from the planet selection dropdown lists. Here's a screenshot of the button and selection window: http://imgur.com/kEyOOVJ

Hello, I understand the suggestion, for a while I experimented with using the inter-flyby orbit as a guide to setting up the next flyby, but I found it is not the best way to go. In the interest of keeping the detail box simple and small I therefore do not put details of the orbits in there. The most important thing in executing the flybys is the periapsis time at each planet in the chain, if you going to arrive at the right time and on the right side of the planet you should be able to do a correction shortly before the flyby that will send you right to the next flyby. Below is a run through of the plan you give above to show what I mean. Note the trick I use for each flyby, I put a second node on the path at just the time that the ship should be flying by the planet and then make adjustments to the first node so that that second node is almost right at periapsis. (I don't do it for the final arrival because I usually don't care if that is a little early or late, just that it happens.) You say the second encounter is going to take a couple of orbits, that doesn't sound right. Flyby Finder is somewhat restricted in what it finds, your ship should never go more than one orbit between encounters. The Eve flyby should kick you way out so that it takes 2 years to come back in and flyby Kerbin. See below. One might point out that I don't really need the Vinf in and Vinf out numbers for each flyby, but I like to use them to check that a flight is going properly. I have yet to find a time when the arrival times are right but the Vinf is wrong though, so I might get rid of them eventually.

Yup, I use the AIES+RO RL-60. It has such a high TWR and isp that it blows everything else its size away. And so many restarts! The sad part is that in real life they developed and tested a prototype RL-60 but it has never been flown (AFAIK!) I've cut the launch weights of my rockets by replacing single J-2X's or RD-0120's with 5x-7x of the RL-60. Since it's an upper stage the savings are substantial. Since neither is in mass production now an open question is which way would be cheaper. As for H2 boiloff I noticed a big reduction in boiloff rates in the last two versions of RO (for KSP 1.04 and 1.05). You have to pick the cryogenic tank type though, if you keep the default tank type the boiloff is much greater. With cryogenic tanks I get H2 boiloff rates of 0.3% to 3.5% (of the whole tank volume) per day. I've been having fun trying to figure out why the rate varies so, I've found the shape of the tank matters (spherical is better), the way the tank is attached to the rest of the ship seems to matter, and there seems to be a cool down flush after firing the motor so be frugal in using the main engine. In any case it's good enough for Moon missions but not yet good enough for Mars missions.

I've worked out a lower-dV-than-Hohmann way of getting from LKO to low Munar orbit. It's a bit of a simulation of the low-energy transfer method you mention in the OP, or at least the best you can do without 3-body path calculation. This way goes from LKO just high enough to touch Mun's SOI, Mun then pulls your path up just enough so you get a 2nd Mun encounter that pulls you up the rest of the way. To save even more dV a third pass of Mun then throws you out almost to the edge of Kerbin's SOI, where a deep-space manuever is made to raise your periapsis to Mun's orbit, you then finally approach Mun at a much lower speed than you would from a Hohmann transfer. The total savings is only about 5% over a Hohmann though. (Hohmann: 856+273=1129m/s, mine:844+16+209=1069m/s) In real life of course the Moon's 'SOI' goes all the way to Earth so you can use properly timed little bitty tugs from the Moon to slowly pull your orbit up from much lower. Here's an album showing the approach (I then went on to Minmus, I was trying to land a stock Kerbal-X on both Mun and Minus and return to Kerbin without refueling). I wonder if L1 could be simulated in a 2-body program by treating it as a small mass with a zero diameter and a small SOI, you'd have to force it to orbit Kerbin more slowly than it should though. I don't know if the game engine would allow that.

Flying by Eve to get to Moho is tricky so you are doing well in pulling that off. I flew a K-E-M just now to refresh my memory (Kerbin Y1 D6.0 to Eve Y1 D191.2 to Moho Y1 D317.5) and I had to get the Eve flyby timing to within +/- 1 hour of the given time for it to work. And then there were three possible Moho encounters depending on the flyby altitude and I couldn't get the encounters at all while still in Kerbin orbit since it required more accuracy than the +/-.01m/s that Mechjeb allows. But by getting close and then fine tuning just before the Eve flyby it worked. (LKO to LMO for 4318m/s.) With the little bitty SOI's of Moho and Dres I have to trust that the planet will be there when FF says it will. You gave me a good idea though, I'm going to try Slingshotter so I can see where the planet will be when my ship will pass close to its path, even when I don't pass through the AN or DN at the orbit intersect (since KSP doesn't show the closest approach in that circumstance). Good luck with K-J-Eeloo. From my experiences you can be a couple weeks off of the Jool flyby time and still make it work. Best to leave Kerbin within a few hours of the right time though. Zooming in sometimes causes a solution to disappear. Usually it is because a middle encounter goes outside its reduced search period.

OK, to start figure out what time it is in the game. I shall assume you use Kerbal time (426/6) and not Earth time (365/24). For instance is it Y1 D22 5:45:03? Then compute what that is in what I call "UT", the number of days elapsed since the game started. There's a little converter in the lower right corner of the FF screen that can do the math for you. Now use that number as the search date to search from. In the example below I start from day 3800 (roughly Y9 D400). No need to be precise, the search window will be hundreds of days wide. Start FF. Change the "Start at", "1st encounter", and "2nd encounter" planets to be Kerbin, Eve, and Moho as shown below. Now the tricky part in any search is to pick the right "Earliest Search Date" and "Search Period" to use for each planet. So I've given you good values below. In the "earliest search date" for Kerbin enter the current day in your game. (3800 in this example). In the "earliest search date" field for Eve enter the Kerbin day plus 400 days. In the ESD field for Moho enter the Kerbin day plus 450. Now enter the "search period" numbers as shown below, 500 days for Kerbin, 400 for Eve, and 700 for Moho. Change the field called "V at SOI" to 3000 as shown below. You might want to increase the "Search Steps per Period" field to 200. Leave everything else in its default state. Now hit the "begin search" button. It should search for a few seconds. When it finishes, if you see any 'hits' in the table, hit "Show Graph" to get a graphical representation of when Kerbin-Eve-Moho flybys are possible within the constraints. If you're having trouble, try entering the numbers below exactly as shown and see if you get the same search result. These are by no means the only values that will find results by the way, they are just pretty likely to find results anytime. How is it going so far? What is your search start time? Once you start getting solutions it will be time to winnow them down to the best one for your plans. Is travel time more important than total dV expended? Do you have a dV limit? And what Kerbin orbit will you start from, I usually start from a 75x75km orbit but you might have a space station or some other orbit you like to use. To use all of Flyby FInder's information you are going to need a test probe that is in a circular, equatorial orbit around Kerbin, will that be a problem? If you don't want to use a test probe then FF can only tell you good times to leave from Kerbin and flyby Eve to get to Moho, but it can't help pinpoint the best start orbit and exact maneuver to use.

Here is an example of a Kerbin-Eve-Moho search in Flyby Finder. This is a tricky flyby to search for because Moho moves so fast and the windows are very tight. If you keep "Search steps per period" at the default 100 you might miss the windows completely. The quasi-synodic period for Kerbin-Eve-Moho is about 678 Kerbin-days, though it's not too exact because the orbits are not all circular or inclined the same.

There was a challenge a while back to get from Kerbin's surface to Minmus' surface for the minimum dV expended. At first I tried the standard method of launching into the lowest possible Kerbin orbit and setting up a burn to Minmus from there that used a Mun flyby. Then I tried a straight-up launch that flew straight to Mun for the flyby. Conclusions: For a minimum dV flight to Minmus straight up is better, but for just to a Mun landing it is worse. Note that the ship is much larger than the lightest possible ship to Minmus or Mun, the challenge just cared about dV expended. The key is a very high TWR. If you accelerate hard enough the gravity losses are reduced to less than you lose from a standard ascent, and the shorter time in the atmosphere reduces the drag losses a bit too. If you go too high with TWR though (like a Jules-Verne-style explosive launch) the drag destroys your ship. Here are the numbers: Orbit first- 3010m/s surface to 72x72km orbit, then 845m/s LKO to Mun encounter = 3855m/s. Straight up- 3780m/s surface to Mun encounter. Savings to get from Kerbin surface to a Mun encounter: 75m/s. From my experiments the break-even point was with a TWR of about 5. Less than that and the gravity losses dominate. Note that a simple LKO to Mun trajectory requires 856m/s but you can reduce it to the 845m/s I give by using a complicated multi-flyby of Mun that isn't possible with a straight-up path. But now the part 2- if you use a straight-up path to Mun you will arrive at Mun with a higher relative speed to it. This completely eliminates the advantage of the straight-up launch. For a standard LKO to Mun path you will need about a 271m/s capture burn to get into low Munar orbit, but with the straight-up path you will require about a 371m/s to brake into the same orbit (and it's the same difference if you go straight to a landing). The reason for this is that you have less prograde velocity when you arrive at Mun's orbit after a straight-up launch, so Mun overtakes your ship at a higher relative speed. You do have a little bit of prograde velocity since the KSC is moving sideways thanks to Kerbin's rotation, but it's a lot less. Your speed relative to Mun at the moment you enter Mun's SOI is about 340 m/s for a standard launch and about 538m/s for a straight-up. (Note that Mun's orbital speed is 542.5m/s.) I do wonder if there is a hybrid path that goes almost straight-to-Mun but with a little 'sideways' during ascent that would do better, but the aiming would be a nightmare.