PLAD

The following data assumes you're using a path that will leave Kerbin's SOI at about 935m/s, which is the case for my 1011m/s Jool mission. You can get V when leaving SOI from TOT, FF, or LambertE. I make a rough estimate by knowing that Mun will turn your path by about 29 degrees, and Mun will move about 25 degrees in the 2h 45min it takes to get to it, (empirically determined) so I set up an initial ejection-to-Eve burn when Mun is about 54 degrees retrograde from the direction a burn that doesn't use Mun leaves Kerbin's SOI at (don't execute it, just set it up and use a protractor). I then note the altitude above Mun's surface that that flight would need to go to get to Eve and use the empirically determined rule that a change in 1 minute in the boost time changes the required Mun periapsis by 1 km, at least for an hour or so before and after the optimum time. Since you can't see the Mun periapsis altiitude when it is below the surface you should shoot for a too-early initial trial. A big problem is that a low orbit around Kerbin has a period of about 30 minutes, so you can only execute your boost to Mun at a certain instant every 30 minutes. If you can live with your Mun flyby being up to 30km above the optimum possible altitude then just use the window closest to that. Otherwise you will have to change your launch time (hit F5 before you launch) to compensate. I think of it as trial-and-error- if you're not picky then just a couple of trials will do, if you want to squeeze the last possible m/s out of the flyby then 5 or 6 might be needed. Remember each minute of error reduces the benefit of the flyby by 0.5m/s, at least for an hour or so before and after the optimal time. Somebody ought to write something that gives you the optimal launch time for a Munar flyby if you give it the planetary transfer dates, like 'I want to leave Kerbin around day 147.0 and get to Eve at day 195.6, when is the best time to leave Kerbin and use the Mun?'. Hmmmm...

So I'm trying to find a way to get to Eeloo with as little dV as possible, and I've found that such a mission has to fly by Jool on the way to Eeloo. So I've revisited this Jool mission to see if I can squeeze a little more out of it. I've tried to give some tips on how to cut your delta-V usage to the bone. I did it with 1011m/s!! Can it be reduced even more? I think so. For reference the next numbers all refer to starting from a 75x75km orbit and not using a Munar flyby (which we know would save 87m/s). -This minimum start for the initial K-E in this window is 1068m/s. But you can get to Eve for as little as 1025m/s in other windows. Could we start with that? No. I found you cannot go K-E-K and arrive back at K with more Vinf than you left with if your start boost is less than 1044m/s. -So can we start with 1044? Not exactly. When flying K-J you must leave the last K with a Vinf of at least about 2670m/s. But I have found no K-E-K-K-J window that starts with less than 1068m/s that gets up to 2670m/s by the time you head to Jool. -I did find a route that theoretically gets to Jool with a starting dV at Kerbin of 1044m/s. It goes K-E-K-K-E-K-K-J*. So 24m/s less than 1068 but with 3 extra flybys. I budget 5m/s per flyby so your net savings would be about 9m/s over the mission shown above. Conclusion: I hereby contend that you cannot get to a low Jool orbit from a 75x75km Kerbin orbit for less than 997m/s, except by random luck which might save a couple of m/s. (Or maybe there is a multi-orbit solution that can do a little better? Or a small periapsis thrust at Eve? Argh!) *Here are the start and encounter days if anyone is crazy enough to try it, enter them into LambertE to get all the mission data: K817.4-E853.6-K932.4-(dbl.96)-K1358.5-E1394.9-K1481.9-(dbl.435)-K1694.95-J2300. Note that you'll orbit the sun 5 times between the first two K's.

Thanks! Although the sad truth is that my tools can't do multi-orbit Lambert calculations so I was forced to have a gravity assist after every orbit. One probably could knock a few m/s off by using some multi-orbit transfers in there, so I don't knock long travel times unless it's part of a challenge.

Yup, my guess is that if someone can figure out how to use a large moon or maybe even Jool's atmosphere to slow down they will win. The thing I can't figure out is how to use them to slow down and still leave Jool moving in the right direction.

And here is my entry. How I found it- Arrowstar demonstrated in my Flyby Finder forum that TOT can do 7 flybys in one calculation- he used a K-E-K-E-K-J-Ee flight path. Look at it here. I used LambertE to discover that the first K-E could be eliminated and some small changes made to the start and finish encounters that would make for a very low-dV mission. So although I'm calling this my entry I give a lot of credit to Arrowstar for finding this window. I admit that it pains me no small amount that TOT, because it finds flybys that have a periapsis thrust, can find a better path to Eeloo than FF can. Once FF can do double flybys that might change. I saw Immelman's trip to Eeloo and it is good, but when you add the Eeloo landing in it would be over 2344m/s. Immelman's mission reports are so good with so many details that I used them to test my flyby programs as I was writing them. Maybe we could find a fair way to estimate what it would take to land from a 22x20km orbit?

The goal of this challenge is to get from a low orbit around Kerbin to the surface of Eeloo with the least amount of delta-V expended. It is similar to the Lowest Delta V to Moho challenge that Otis made a while ago, the difference here is that the delta-V recording does not start until you are in a low orbit (apiapsis less than 80000 meters altitude). I feel that getting into orbit cheaply is a very different engineering problem from the vacuum part of the mission so I cut it out. The rules: 1) Accurate delta-V recording is key. So one ship only, no docking, and no air-burning, kraken, or exotic-physics motors that would taint the dV readings. You must use Mechjeb or a similar mod that displays the expended dV in all screenshots, which are taken before all major (>20m/s) manuevers. Please also give the KSP UT time of the major points of the mission-departure, flyby periapsis and landing (in the screenshots is best). Edit:I shall also accept entries that give enough information to accurately compute dV used by telling the Isp of the motor(s) used and the ship mass at the start, finish, and before and after staging events. 2) Start- First shot must show the ship in LKO, with altitude and orbital speed visible, or the map view with the AP flag highlighted showing the apoapsis is <80000m. Note you can get the ship there any way you like, multiple-launches, even Hyperedit. No Hyperedit after that though! 3) Arrival- Your ship must end up on the surface of Eeloo undamaged. Last screenshot must show delta-V expended and UT time. (Edit: and ship mass if not using Mechjeb) 4) Mods- any mod that doesn't affect the dV recording or allow you to survive a landing faster than the stock landing struts would (12m/s) is fine, as long as no motor has a thrust-to-weight ratio higher than the best stock motor, which is 39.2 (the Kerbodyne KR-2L). 5) Scoring-lowest dV expended wins. In the unlikely event of a dV tie the shorter elapsed time wins. This is going to be all about finding and executing flybys. We have some great tools that didn't exist a few months ago to use for this- I direct you to Arrowstar's TOT and to my Flyby Finder (FF) and LambertE spreadsheet. Leaderboard: 1. PLAD 1934m/s 2. 3. 4. 5. Honorable mention: allmhuran: estimate around 2200m/s

I have found that I can follow a plan like this to within +/-8 hours or so, at least for the inner planets. See my old mission report '1051 m/s KLO to Jool Orbit'. By the time I get to the outer planets the error is often several days though. You do have enough information to follow the plan in the challenge, all we really need is the dates and planets, one can figure out the rest. It's nice to have the total start velocity and normal component though, and especially the altitude and thrust magnitude of the flyby periapsis burns, that makes finding the path much easier. And you've got those but they are spread out through the various screens. But there was a good point- I always have to do small course corrections far from any planet to execute a mission like this, because KSP cannot accurately do a thrust to better than about +/-.1 m/s and you would need better than that to set up a second flyby while doing a first flyby. There are also errors when changing your SOI, often 10m/s or more depending on your time warp when you cross the SOI. So 'no deep space maneuvers' would have to go. TOT is the best tool I've seen for finding a low-dV path from Kerbin to Eeloo but I know I could do much better than this particular path so I would rather not fly it.

FF V0.50 is out. There are several new features: -Up to 5 bodies can now be entered. -Added a time converter. You can now take the Y D H M that Kerbal displays and convert it to the UT Earth-style days that FF requires in its input fields. -You don't have to hit 'clear' anymore. If there is any data from a previous search in the output table it will automatically be cleared. If there is no data then the clear will be skipped for speed. I left the clear button in just in case, if I find I never use it then version 0.60 will get rid of it. -I added a field for minimum V infinity right next to the 'max v at SOI' field. This is to allow you to 'daisy chain' one set of flybys to another. You do this by taking the last two encounters in a chain of flybys and entering their data in the first two fields ('start' and '1st encounter'). By restricting the start energy to a tight range, and making a tight start search period and 1st encounter search period you force FF to start with a specific path. I will prepare a primer to show how to do this. V0.60 is going to take a while because adding double flybys is a big step up in complexity. I might also add the ability to make a standard 2-body porkchop plot since that helps find good places to start searches in.

Nope, not at this time. You can copy and save the detail box's contents to a text file though, giving something relatively small and quick to alt-tab to during a mission.

Well I ran the K-E-K-J-Ee path suggested by TOT and it worked. Total dV from the surface of Kerbin to the surface of Eeloo was 6757m/s, about 300m/s less than anything that doesn't use a periapsis thrust while flying by Jool. The cheapest way to get to Eeloo or Dres is via Jool because it is closer, energy-wise, than any other planet to them. The problem is that if you arrive at Jool from the inner system you have a lot of excess speed relative to Jool, but to get to Eeloo or Dres the lowest-dV way possible you need to leave Jool with a lot less speed. So the best way to get to them is to slow down at Jool. FF does not do that and TOT does so TOT is clearly superior for those situations. I figured out that TOT gives the V infinity and not the start V at a given altitude, so my 500km-orbit assumption earlier was wrong. Now I'm trying to decide whether to post a mission report or a challenge on this lowest-dV-to-Eeloo mission!

An interesting exercise. First let me say that being able to calculate a 7-waypoint mission is impressive. However I've found making more than one K-E-K run is not useful, since to go K-E-K-E you have to lose energy to go back to Eve from Kerbin, since if you go outward after the 2nd K your periapsis will be too high to get back to Eve. In fact on this K-E-K-E-K-J-Ee mission the first K-E is unnecessary, see the pictures below. I assume you started at Kerbin in a 500x500km altitude orbit since that makes the numbers match. I want to fly the TOT mission to see if I can do it since thrusting during a flyby can be rather tricky, you have to be at exactly the right altitude to pull it off. Where is the altitude for the 232m/s Jool thrust given? All other needed information is given in a nice format. If it works then that is the lowest-dV mission to Eve I've ever seen. EDIT-never mind, got it, 17848km. TOT took 51 seconds to run the search. Impressive. But back to the question at hand, I see TOT also does not do multi-orbit legs, I imagine for the same reasons FF doesn't- much longer calculation times and the missions would have a long travel time. And it also doesn't do double flybys. A dream flyby finder would do all these things and even allow thrusts at the apoapsis of multiple-orbit-between-flyby paths, but lord would it be complicated and slow!

Something that has been weighing on me lately is that Flyby Finder does not find multi-orbit solutions in its searchs. What does this mean and why doesn't it? I did this little study using FF and Alex Mun's pork chop plotter. The chart below shows what the lowest delta-V path is from Kerbin to Duna on a given day during the first synodic period between Kerbin and Duna. Note that I'm only showing the lowest-dV possibility for each route on a given day- there are lots of higher-dV paths on a given day that can take more or less travel time. We see that sometimes the flybys offer a better choice than a direct flight. K-D is a direct path from Kerbin to Duna.The pattern shown with that red line repeats every 227 days with small variations due to the eccentricity and elliptical nature of Duna's orbit. In this path you go less than 1 orbit around the sun during the trip from Kerbin to Duna. K-E-D flies by Eve on the way to Duna. This repeats roughly every 170 days- the synodic period between Kerbin and Eve. This is because Eve has the gravity to throw your ship to Duna wherever it may be, however the shape and magnitudes of the trip vary a lot from window to window. The windows have finite width, unlike the K-D windows which are continuous. For long periods you can't fly K-E-D for any starting dV. (Well, without a big thrust at Eve, TOT can find those paths for you.) K-E-K-D flies by Eve and Kerbin on the way to Duna. This repeats very roughly every 170 days and varies a lot from window to window. Same comments as K-E-D. K-D 2 Orbits flies directly from Kerbin to Duna, but goes around the sun twice during the transfer. So the first time it crosses Duna's orbit Duna is not there then it coasts back to where it left Kerbin's orbit (but Kerbin is not there anymore) and then goes on to intercept Duna. This dark red line repeats every 227 days and has roughly the same shape as the bright red line, it just has a longer minimum travel time, in this case around 240 days instead of the 66 days that a less-than-1-orbit transfer has. I see there are times where it has both a lower dV and a shorter travel time than the other options and so would be the best path by either standard, assuming you had to leave Kerbin on a particular day. Now on to how this affects Flyby Finder. FF only searches for single orbit solutions, it does not use what is known as a multi-orbit Lambert algorithm, so from one encounter to the next you can't go more than once around the sun. (For a whole flight with many encounters you can end up going many times around the sun.) Why not? First consider this- If you are willing to go 3 orbits around the sun when going from Kerbin directly to Duna then there is another line that would have the same shape as the K-D one orbit line, but its minimum dV would be located at the 177 days departure date and have a value of 1067 m/s and a minimum trip time of 366 days. If you are willing to go 4 orbits then there is yet another line, this one centered around 116 days and around 500 days long. And so on. If you are willing to travel long enough then it is possible to get directly from Kerbin to Duna for less than 1100 m/s when leaving on any day! This sort of defeats the whole purpose of a pork chop plotter. Now, if FF was to look for multi-orbit paths it would probably be best to do it for every step. So for instance for the Kerbin-Eve leg there are 1 orbit, 2-orbit, 3-orbit etc. solutions, then for the Eve-Duna leg there are another infinite series of solutions. One can decide to look no more than, say, 2 orbits, but then with K-E-D there would still be 4 solutions to pick from, and with K-E-K-D there would be 8 solutions to pick from. It would take much longer to find and check them all for the lowest-dV or shortest one. The total travel times would usually be much longer. So I have elected not to have FF search for multi-orbit solutions at this time, though I bet there are some great ones....

I know how this can happen- you have to press 'clear' after any search that found something, or the results of that search will stay in memory and in the output. If the next search finds more results then they will overwrite the old results, but if the 2nd search finds nothing then the old results will still be there. I haven't made the clear happen automatically yet for two reasons- one is that the clear takes time, even if there is nothing there, and most of the time I just go 'increment'-search-increment-search' without finding anything. so no autoclear makes it faster. The 2nd is that if I find a detailed region and graph it, if I don't clear and then look at a large region around the detailed region the original detail will still be there, superimposed on the wider data. I've got half a mind to make large high-detail graphs that way. Any opinions on this? Having to hit 'clear' before every new search can be a pain.

I don't have a Mac (although my first computer was an Apple II) so I don't know if the .exe will work on one. Has anyone tried it? I released all of the source code for anyone to modify as they see fit, if someone can run Borland Delphi 5 or higher or maybe Embarcadero on a Mac then worst case they could copy the source code over and make a Mac build. That would be cool.

Good questions John FX, See my note on Jool's moons above. Your question on doing K-K-D-J or other flights where you go by the same planet twice in a row stabs to the heart of the Lambert algorithm. The Lambert can't do that, since it can't handle any orbit where the start and finish are 0 degrees or 180 degrees apart. The trouble is that there are an infinite number of possible orbits for those conditions (for instance an orbit with the same SMA but of any inclination would work) so the algorithm can't settle on one. I have a plan to deal with this though. Quick Answer: Flyby Finder version 0.60 will implement this function. Long Answer: In my 'LambertE' spreadsheet I have a method to handle a 'double flyby' where I take the vector you first approach the double planet with, and the vector you go from it to the next planet with, and 'draw' a line between those two vector's directions. I then assume the intermediate vector that you leave the double flyby planet with the first time will be on this line. I determine where on the line you would have to go in order to have an orbit around the sun that gets back to the double planet when the planet is back there, so an orbit who's period is an integer multiple of the double planet's period. If I find one then I check that both flybys can be above the double-planet's surface. It works in the spreadsheet but it is tricky. My development plan for Flyby Finder is that version 0.60 will implement this function. It will be the hardest part of the whole project and might take a while but I'm sure it can be done. You mention triple flybys in your question. I'm not sure I'm going to tackle that. Depends how the double flyby goes. Note that neither the 1st not the last planet in the chain can be a double-flyby planet. That should be OK though, if your only thrusting is done at the beginning of the flight and at the final arrival (and FF only deals with this kind of flight) then there is no advantage to flying past the start planet twice. Multiple consecutive flybys of the same planet do not change your speed relative to the sun or the flyby planet, they only change the direction. If you do a large thrust between the flybys, or flyby another planet, then your arrival energy back at the planet can change by a lot, but if you just coast around back to the same planet you can only change your direction. Changing direction can be very useful though, check my flight to Jool from LKO for 1051m/s to see what the double flyby of Kerbin does. At the speeds I'm moving after the Eve flyby Kerbin can't change my direction enough to throw me to Jool in just one pass. You bring up a good issue about how FF does dates and times. I use 24-hour days as the basic unit of time measurement, with Year 1 Day 1 as UT day 1, since it makes for one number to adjust up and down as needed. For translating from days to KSP time I have the detail box which converts the 24-hour day times to the Y: D: H format (365-day years only for now) so you can see when to launch or when you have to flyby a planet. The detail box also gives the UT seconds of the start thrust, I give this because if a flyby I want to test occurs several years into the game I start a new game, quit it, then go into the persistent.sfs file and find the entry for UT seconds and change it to a little before I want to launch, then go back and run the game. This way I don't have to sit there at maximum timewarp for many minutes waiting to get to the launch date. But this does not help when you know a KSP time and want to search for the next flyby. I could put a little calculator in FF that allows you to enter Y: D: H and gives you the 24-hour days equivalent. The formula is (Y-1)*365 + D = UT days. So year 11 day 170 would be UT day (10*365)+170= 3820. You have to subtract 1 from the year because KSP calls the first day 'Year 1 Day 1', not 'Year 0 day 1'. I'm looking at your other questions now. One thing is that FF does not allow you to run it with less than the first 3 bodies entered, if you only enter Kerbin as the start and Duna as the 1st encounter, but nothing else, it will automatically put a second encounter in when you run it, by default it's Kerbin. I should probably switch to an error message and refuse to run in that circumstance. It doesn't prevent double entries either, and right now that can cause a bad results. I admit I've been putting off input checking until I manage the double-flyby part. Thanks for the questions, they help me decide what needs to be done next.

You and John FX are quite right, making something like this for Jool system would be very useful, even for flights that take place mostly outside of Jool's SOI. For instance I am trying to find a very low total-dV way to get to Dres. The lowest possible approach speed to Dres is from Jool, but if you arrive at Jool from any of the inner planets you have too much energy to make a slow approach to Dres. If you could use the moons to slow down you could do much better to get to Dres at slow speed, or Eeloo for that matter. The problem is the giant SOI's of Jool's moons relative to their orbits- for speed I use a linked-conic algorithm that assumes the planets are points in their orbits around Kerbo,l this works fine when the SOI's are small relative to the orbits, but it would fail completely with Jool's moons. For now I'll finish this Flyby Finder for the planets and then think about what can be done for Jool's moons. That's a ways in the future though. It is needed.

Version 0.40 is out. Now you can put a 4th planet in the flyby chain. It's getting complex, with 3 planet encounters there were 252 possible flyby combos (start at any of the 7 planets, go to any of the other 6, then finish at any of the other 6). Now there are 1512 possible combos. Some notes on searching - I always make sure there is a path with 3 planets before adding the 4th planet. See examples of this below. This is because a search with 4 planets takes about twice as long as one with 3, even if you will find nothing. But once you have 3-combo, especially if it ends with Kerbin, Eve, or Jool, you have a pretty good chance of finding a 4-combo. Sometimes lots of combos... Just make sure your search window is wide enough and the 'Max V at SOI' is high enough, at least at first. Going straight to Jool from Kerbin takes about 2000m/s minimum. With three planets the best dV to Jool (so far!) is Kerbin-Duna-Jool at about 1900m/s (repeats every ~235 days). With 4 planets it seems to be Kerbin-Eve-Kerbin-Jool for a minimum of 1328m/s (repeats every ~345 days). There are similar sequences for Dres and Eeloo. It will be interesting to see what happens with 5 planets.

Version 0.30 is out, it adds sorting to every table column, and if you double click on a table entry (not a graph point at this time, alas) it will give lots of details about the flight. Here I used it to plan a Kerbin-Duna-Jool flyby, and got some bonus encounters too. Now that I've cleared some space in the FF output table I can work on putting in the 4th and 5th encounters. It will be tricky to do this and keep the searches short, we'll see. That's why I added the little box that shows where it is searching even if it is not finding flybys. It might be a couple of weeks before 0.40 comes out. -PLAD

Here's what caused me to choose to graph departure date versus total travel time in my plots: Dennis Tito Inspiration Mars So I sure don't have a claim to that approach. Notice that it's x-axis is 25 years wide, so there are a bunch of blobs that repeat every synodic period between Earth and Mars. donfede pointed it out in a KSP challenge, Inspiration Kerbal. My third 'axis' (color code) is start delta-V, but total delta-V might be better. Arrowstar you have a really good question in just what should be graphed, I suppose it comes down to what people will use it for. If you're looking to get from Kerbin into orbit around an airless world cheaply then total delta-v is the most important thing, if you're ending at Eve, Kerbin, Duna or Jool then only start dV matters. If it's a free-return mission then total flight time is important. For planning multistep missions, for instance Kerbin-Eve-Duna and land on Duna, then return to Kerbin at the next Hohmann window, then arrival date at Duna is most important. For science points you might choose the path with the lowest flybys. I'm guessing that departure date vs travel time, with total dV color coded would be the most popular?

Diomedea, Within a fraction of a day, 4 Kerbin/Eve synodic periods = 680 days 3 Kerbin/Duna synodic periods = 682 days and 7 Eve/Duna synodic periods = 681 days so Kerbin/Eve/Duna situations repeat every 681 days or so for many years. Eve's high inclination makes some worse than others, and Duna's high eccentricity makes the optimal date move forward or back from the average. The thing that makes it work is that a transfer window can be 10 or 20 days wide so some error can be tolerated. It turns out there are a lot of these coincidences in KSP, for instance Kerbin/Eve/Jool repeats every 345 days and Kerbin/Duna/Jool every 234 (though that one is rough and doesn't repeat too many times). I wonder how often the position of all 7 planets repeats to within, say, 5 degrees...

Hello Arrowstar, I've been using TOT for several months, it is an impressive piece of work. Flybys are my pet project these days, and I'm writing a flyby finder to plot flyby possibilities in a sort of porkchop-plot style. I use TOT to check the results my Flyby Finder (FF) kicks out and am curious as to how TOT selects the particular flight it proposes for a given flyby sequence and window. Does it search for the lowest total delta-V, that is, the boost to leave the start planet + any boosting done during a flyby + the deboost to get into orbit at the target planet, or the quickest flight within reasonable delta-V constraints? I get the impression it's a combo of delta-V and flight time. I sometimes find cases where TOT has a problem finding a flyby, Most of the time it finds a good solution. Here are examples of each: I was using the version you released a few days ago, looks like you released one last night, I'll upgrade. I'm getting a feel for just how complicated it is to catch all the things that can go wrong with a multiple-flyby search algorithm. There are too many possibilities for one person to check them all.

Arrowstar's TOT was the first thing I used to find flybys. At the time it was slow (it is superbly fast now), and it only gives one solution, leaving me wondering how many other possibilities there are out there. So I'm writing FF. And now I'm doing what you described too- I find good windows with FF and then see what TOT finds in there. TOT's level of detail and especially that clever option to send the flight data directly to your ship while running KSP are things I have no plan to put into FF. And a big difference between TOT and FF is that TOT allows for large thrusts during a flyby, thereby opening up more possibilities- it will almost always find something in a given window though it can sometimes be pretty extreme ( I saw a 4000m/s boost during a Duna flyby I asked it to find for a Kerbin-Duna-Jool flight in a really bad window). But I like seeing the possibilities and picking one out myself.

This post shows in perhaps excessive detail how I execute a flight using the data from Flyby Finder. If you've never done a flyby this might help. I also check 5 solutions that FF gives to see if they are real or not. It's rather long, so here's a quick summary: -FF seems to do OK, with these flights at least. -Avoid flights that require a very high start vZ if you can. -I need to include the start orbit inclination in FF's output. -You don't need to know the flyby altitude to execute the mission, it will appear as a side effect of what you do know. -The Vinf numbers are not necessary either, they are just a safety check. After this post I will only post specific interesting-looking flights from start to finish. Although you could use one of these flights to simulate a free-return flight to Eve, where something goes wrong on the way and the crew has to abort Eve insertion and get back to Kerbin on small thrusts only...

I'm up to version 0.21 of Flyby Finder so far. I'm alternating writing it with using it to get a feel for what is useful to know when searching for and executing flybys. Here is a little primer detailing the features it has so far and how to use them.

Diomedea, thanks again for looking at it and you have some good suggestions. You are right about the color, I have them fixed to certain speeds rather than dynamically spread across the actual range of flybys found. And that is not sufficient for all possible flyby types. I will add this to 0.2. I haven't tried any of the alternate systems yet though some of them look quite interesting. My one issue with making it easy to use this with other systems is that I took some shortcuts to make this program as fast as possible with Kerbol system, and things might become inaccurate with other planets. In particular the 5th-order equation of center starts to become rapidly more inaccurate if a planet has an eccentricity over around .25 -.3. The other is my cutting out of most hyperbolic trajectories, if some system has a planet very far out from the sun then paths to that planet will often not work. So for now I prefer to keep the parameters locked into the program. Though if I wind up using one of those alternate systems and the planet orbits look safe, it would not take long to make a version for that system. Can you recommend one? I thought about Jool's moons quite a bit. I decided not to do them because of the huge SOI of those moons relative to their orbits. It's another shortcut- I use a linked conic method to hitch the paths between planets together rather than a patched conic method. This works fine with Kerbol's planets because the SOI's are so small compared to their orbits. The errors in timing and velocity that my approach causes are smaller than the errors naturally generated in KSP from switching between one SOI and another, and the fact that one can't perform a thrust with more accuracy than about +/-0.1m/s. One can verify my accuracy estimates with Alexmun's superb porkchop plotter, he has a button 'refine transfer' that takes the SOI's into account and updates your chosen transfer's data. My philosophy for this program has been if the total errors are less than 10m/s over the whole transfer then it's acceptable. But the errors in Jool system would be much larger than that. Speed was a key design criteria for this, but only if the solutions found are real. I think I got the balance right but we'll see.