[WIN] Flyby Finder V0.86 [KSP1.3]

[PLAD]

This is a tool that searches for flyby opportunities in the stock Kerbal Space Program planetary system. Flybys can often get you where you want to go for much less dV than a direct flight would need, great examples are the real-life Voyager and New Horizons probes. Flyby Finder (FF) can search for paths with up to 5 planets, but it cannot do double flybys of the same planet or flybys requiring deep space maneuvers like the Galileo, Messenger, or Cassini spacecraft used. It is useful for planning Opposition-class missions to Duna, or low-dV trips like Kerbin-Eve-Moho or Kerbin-Eve-Kerbin-Jool.

It also can plan flybys for the Outer Planets Mod,  the Kerbol Star System, and the Galleo Planet Pack.

Here is a primer on using it.

Javascript is disabled. View full album

Here are the links to my Dropbox account. The source code is in the Flyby086source.zip, and the license and simple instructions are in the Flyby086exe.zip with the exe file.

I chose the MIT License.

Version 0.86 is now out (Sep 8 2017). Main changes from 0.85 are: Updated GPP planets to match the GPP 1.5x planet positions. made small changes to detail box's output-removed "Vinf out" and added a total travel time in years. This version of FF is good for KSP stock versions up to 1.3x, OPMv 1.9x, KSS v0.61 and GPP v 1.5x.

Executable:

https://www.dropbox.com/s/xxwbc36ztcpt9iq/Flyby086exe.zip?dl=0

Source code:

https://www.dropbox.com/s/9vy075wcr8vopl3/Flyby086source.zip?dl=0

I will keep 0.85 here for a while as it is needed if you are using an earlier version of GPP than 1.5x.

Executable: https://www.dropbox.com/s/6e3r3h4ltho1bge/Flyby085exec.zip?dl=0

Source Code: https://www.dropbox.com/s/lb5aj6tphv5n45d/Flyby085source.zip?dl=0

See bug notes and revision history in the next post.

Here is the latest version of my Lambert spreadsheet, I use it to test my algorithms, and to doublecheck that FF is giving good results. It can do double flybys. It is not made for casual use and is not user friendly, but you can see the entire process that FF uses, step by step. It now does 6 bodies and includes the OPM planets. If there is interest I can make a version for Galileo's Planet Pack.

https://www.dropbox.com/s/5i2foga1f2j9kq5/LambertHOPMrel.zip?dl=0

If you are looking for the version of Flyby Finder for the Real Solar System mod, it can be found here.

If you are looking for the version that is just for the 10.625x rescale of GPP it is here.

It uses a 5th-order equation of center to find the radius and velocity vectors for the planets, then a simplified Lambert time-of-flight algorithm to find the paths between them, then searches for matches on the incoming and outgoing energies, and finally checks the required flyby altitude against the planet's radius to make the necessary turn.

-PLAD

A new note- okder has made an excellent Mechjeb addon that takes the start day and 1st encounter day from FF, and the start orbit altitude, and gives you the best launch time and orbit to get into, then gives you an updated transfer solution once you are in orbit.  It eliminates the need for a test probe.

Edited September 8, 2017 by PLAD

[PLAD]

This post is reserved for version history, the development plan, and bug reports.

Current version is 0.85

Release history:

Version 0.1: Alpha release May 23, 2014.

Version 0.11:Bug fix May 24 2014.

Mostly bug fix-Eliminated an error that was causing fake results. Added dynamic graph color allocation. Truncated output fields to 3 decimal places.

Version 0.2: May 29 2014.

Implemented data sorting. Added an 'increment' assist for search periods. Greatly reduced the error in indicated Z velocities, to <10%.

Version 0.21: June 1 2014.

Smoothed the graph y-axis display by binning data in .1 day increments instead of 1.0 days. Made truncation of table data consistent. Removed some obsolete bits from the code and improved commenting

Version 0.3: Jun 7 2014

Added detail box for selected flyby (double click on table entry), removed Vinf columns from output table. Moved sort buttons to bottom of table, and all columns can be sorted.

Added a search progress tracking box, changed some labels.

Version 0.4: Jun 14 2014

Added 4th body entry ability. Added more info to detail box. Fixed some sorting bugs. Fixed 86400 second error in detail box. Fixed crash if inclination is near -90 degrees. Fixed crash if empty row was chosen for detail box.

Version 0.5: Jun 26 2014

Added 5th body entry ability. Added a converter to translate KSP's UT time (Y: D: H: M) to the UT day format that FF requires. Added a minimum v-inf field to allow daisy-chaining paths. Eliminated need to ever hit 'clear' button.

Version 0.60: Oct 7 2014

Added 2-body porkchop plot option. Increased search grid to 100x100 (was 80x80 up until now). Travel time axis in graph now scales to fit the search results. Increased maximum flybys found to 4500 from 3000. Added "Equatorial prograde velocity" field to detail box.

Version 0.70: this rev was only used for the Real Solar System version of FF.

Version 0.80: Sep 13 2015

Added ability to select between Kerbin time (6/426) and Earth time (24/365). Added graph display options by Total dV, braking dV, Start vZ, and 1st flyby altitude. Added ability to change search grid from default 100x100 to anything. Added option for Outer Planets Mod planetary system.

Version 0.82: Sep 30 2015

Eliminated the error where false positives would appear in a block resting on the low end of the travel time. Also reduced the number of true positives that were filtered out (I think to zero!). I know of no further false positives. No changes to the interface.

Version 0.83: Mar 31 2016

Added a "subtract" button to allow decrementing the "Search steps per period" field as well as incrementing it. Added a new information item to the detail box, "start boost from equatorial orbit". Fixed an error in the day converter box that gave a UT day value that was 1 too high.

Version 0.84: Jan 19 2007

Added option for Galileo's Planet Pack.

Version 0.85: July 5th, 2017

Added Kerbol Startsystem's Kerbol planets (v0.6.1).

Added Grannus to the GPP planets.

Tiny adjustment to GPP's Gael SMA to match value in GPP v1.2.3

Improved the tabstop order.

Changed some atmosphere heights for the OPM planets to match the latest OPM version (v2.1).

Version 0.86: Sep 8th, 2017

Updated GPP parameters to match GPP version 1.5.x. Use FF 0.85 if you are using an earlier version of GPP!.

Removed Vinf out from the detail box as it was redundant.

Added total travel time in years to detail box.

 

Future plans:

Add double flyby algorithm to deal with consecutive flybys of a planet.

Add ability to search for Juno-style flybys to Jool.

Version 1.0: Beta release. Add rigorous input checking.

Known Bugs:

-Input checking not fully implemented, entering non-numbers in the search fields can cause a crash under some conditions, as can nonsense entries like search periods or search steps of 0 or less.

-Inputting the same body twice in a row (a 'double flyby') is not captured and causes nonsense results.

-Z velocity indicated becomes less accurate at high values (inclination over ~85 degrees). okder's addon for Mechjeb (See end of above post) completely gets around this.

-Setting search periods steps to less than about 12 hours can cause rounding errors that give results a little outside of the real result field.

KPP system's planet Hypat has an eccentricity of 0.41, well above my normal limit of 0.25, I'm experimenting with the result. It seems a lot of valid flybys are not found because the Lambert takes too long to converge for some positions of Hypat, but you can still find useful paths to Hypat, I have not found one that is not real yet. Note that the simple transfer (2 bodies only) to Hypat does not find anything. Fixing this would slow the whole program down considerably.

Edited September 8, 2017 by PLAD

[PLAD]

Let me be the first to post a bug report for my own software...

Someone wondered in another post whether there were one could launch from Kerbin fly by Duna, and continue on to Jool. I hadn't tried that yet so I gave it a look. I searched around the 1st Kerbin-Duna low-energy window (About UT Earth day 30-90) and found something pretty quickly but there were 'fake' results mixed in. This shows the details:

Javascript is disabled. View full album

To reduce calculation steps I made the Lambert unable to handle solar hyperbolic trajectories, since they are very bad for flybys (a planet can't turn you much when you are moving too fast). The program is supposed to skip any hyperbolic path it finds. I thought I caught all the ways that a hyperbolic can slip through, but obviously I missed some. Bug Hunt!!

I have a spreadsheet that I made when I was developing my algorithms. It is tricky to use but quite powerful. It can verify any flyby path, enter the info in the green cells, if you see the "NUM#" error you will know a path is not valid. Here you go. Don't touch any pages but the first unless you know what you are doing! (Or you have a copy stored somewhere.)

https://www.dropbox.com/s/slntsw4l8vaw0mv/LambertE.xls

Quick instructions for the spreadsheet- Enter the planets, UT dates (24-hour days and 365-day years only), and boost/deboost altitudes in the green cells as you see fit. Then adjust the values in the yellow cells by changing the dates in the green cells, until the pairs of yellow cells are roughly equal to each other. So cell K9 should equal K10, and if you have a 2nd flyby cell K17 should equal K18 and if a 3rd flyby K25 should equal K26. You are making the incoming and outgoing speeds relative to the planet you are flying by the same-the key requirement for a coasting flight.

Then check that the flyby altitudes are above the atmosphere of the planet if so, you have a legitimate flyby. The green cells labeled 'double flyby ratio' are only used if 2 consecutive flybys are of the same planet- for instance a Kerbin-Eve-Kerbin-Kerbin-Jool flight would use the double flyby ratio between the 2nd and 3rd flybys. In that case you must make sure that the time between the 2 flybys are an integer multiple of the planet's period- for instance 2 Kerbal flybys must be 106.5, or 213,etc. days apart. Then adjust the flyby ratio until the relevant "Transit T.. over period" is an integer. Check again that the flyby altitudes are above the atmosphere. This double flyby method gets around the fact that the Lambert can't handle a flight that begins and ends at the same point.

Feel free to ask questions, and check out my notes around the sheets for tips and tricks.

Edited May 23, 2014 by PLAD

[diomedea]

I am truly happy to find this tool and to be able to compliment you.

Probably the reference to that request for a flyby planning tool (example Kerbin-Duna-Jool) was mine, as you see I have a true interest in this feature.

I have just tested your tool a bit, and it shows to be working nicely (can't still say about the results accuracy, as that would require quite some time running other tools). I am tempted to already start reporting my inpressions and suggestions, but better to test more accurately before.

About links and license, I can confirm that is all right.

And to finish, I am also really glad to find you program in Pascal. I am an oldtimer as well, Pascal remains my preferred language .

[PLAD]

Thank you. Another Pascal programmer!!

I look forward to comments and pointers from others. It's that old developer's trap, when I write the thing I get a feel for its weaknesses and unconsciously avoid them rather than pushing them past their limits. I think I've already found and fixed the hyperbolic bug but I need to test all sorts of situations (I just found a Kerbin-Jool-Eeloo flyby!) to be sure, but I can't think of as many as a group of people can.

Thanks again,

PLAD

[diomedea]

I tried a few different flybys, your tool has always been able to find solutions, and those seem to be consistent (can't yet talk about accuracy, I don't even know how accurate are other tools I could use to verify those solutions). But what is most evident, is how really fast your tool is. I am running it on a i7-3770 CPU, Win 8.1, 16GB RAM. To make an example, for the Kerbin-Duna-Jool flyby, with a search period extended to 1500 days, it provided 31 solutions in 3,5 seconds!

Not that I am too surprised for its speed, Pascal is extremely good at crunching numbers.

Anyway, till now one single suggestion, about the way Delta-V is shown on the graph: it seems like colors are each coded for a fixed range of DV (@ lines 617-637 in your source), but often most of the solutions are way over the max. Could be possible to first determine the min and max DV found with solutions, and then divide the color cases for the range of DV found?

[technogeeky]

This is quite a nice looking tool. Excellent work.

[diomedea]

Another suggestion, believe will be useful for all players who have installed mods that change planetary data or implement new planets.

All planetary parameters are loaded from within procedure LOADPARAMS, defined in the sourcecode (lines 115-201). That effectively prevents use of this tool with the mods mentioned above. Would be nice if all planetary data are instead loaded from an external file (best if plain txt or xml, to allow customization). Same goes for Kerbol Grav constant (line 107).

Now, I notice moons are not included. Probably too complicated to include a moon flyby when dealing with interplanetary transfers (must think how a Lambert equation would deal with that); but what about flybys within the Joolian system? Could be done if all parameters are in another external file, and users may choose what parameters file to load at start.

[PLAD]

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.

[diomedea]

...

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?

...

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.

There was to be a reason why you had not already made for moons or custom parameters. Well, your approach certainly provides solutions very fast, very understandable there are limits for the solutions to be acceptable. Many thanks for having shown a bit how it works under the hood, very interesting .

I don't use yet and therefore can't recommend any alternate planetary systems; sure you know the main ones, those are the same I would suggest (and probably would forget some).

[PLAD]

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.

Javascript is disabled. View full album

[PLAD]

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...

Javascript is disabled. View full album

[diomedea]

This post shows in perhaps excessive detail how I execute a flight using the data from Flyby Finder.

...

Very interesting method, and very good knowledge.

I am using your tool and KSP TOT to manage flybys (not that I have done a lot of them yet).

Your tool is perfect to find the "flyby windows", similar to transfer windows but with the slected flyby accounted for. So, I am looking for flybys with the minimum "Total Boost".

KSP TOT is able to find a good flyby, and provides quite accurate data. But it also has an optimizer built in Mission Architect, using that is possible to further refine the navigation plan. But with that tool alone currently I can't search for different flybys and select the one I prefer.

So, I can have various "flyby windows" shown with your tool, and then restrict KSP TOT to solve for only the specific flyby I am interested in, with the accuracy I need.

[PLAD]

So, I can have various "flyby windows" shown with your tool, and then restrict KSP TOT to solve for only the specific flyby I am interested in, with the accuracy I need.

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.

[PLAD]

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.

Javascript is disabled. View full album

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

[diomedea]

Very nice, both the revised sorting UI and the added info.

I am beginning to appreciate those images showing how you use your tool. Nice tutorials, more effective than a written manual .

[PLAD]

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...

Javascript is disabled. View full album

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.

[diomedea]

Already very good with 4 planets. Very interesting the K-E-K-J combo. Pity the tool can't work for moons, would be quite useful to find how to build enough DV to leave the Jool system using some gravitational assists.

Interesting the idea about zooming in. Works, and greatly so. Sure if a feature existed to automatically enter proper values for the zoom, from the flyby selected from the table, it would make zooming a lot easier.

[Kerbal01]

Would this work on Mac? I've been looking for something with this functionality for a while.

[John FX]

Looks great, I second the idea for a jool system version, even if it only operates in the jool system. If an exit vector could be a desired result in the jool calculator then the result from the main calculator could be the vector being searched for in the jool one.

hope that made sense, might need another coffee...

EDIT : haven`t downloaded it yet, but will. Can you do a k-k-k-J or a k-k-k-D or k-k-k-E or K-K-D-J for example?

I`ve been toying with the idea of getting just outside kerbins SOI and meeting up with it an orbit later to get a slingshot, possibly twice and using this to get in and out of the system

edit 2: downloaded but having trouble getting results that make sense.

I made a k-d using the numbers in your example and got many results so I added eve to the end (not changing anything else) and got only one result. when I changed k-d-e to k-e-d the numbers didn`t change and I was told I needed to do the same burn...

I must be doing something wrong but I thought I would just get no results from bad numbers.

EDIT 3: So I put the calculator on my laptop and loaded the game onto my main PC, went into the map to find the date and put it into the box and found that the box accepts `day UT` and the map only shows the year, days, hours etc

any chance of having the displayed date format be the format the date is entered in? it will be a pain to convert dates every time I want to do a burn (I have a computer that I use for calculating stuff, hehe). Re-read the thread and found that you use earth time (24/365)

In the mean time, how do I get UT from a date in years, days etc? is it (years*365)+days? (I use earth time IIRC)

EDIT 4: just checked in-flight where I was sure I remembered seeing UT and my UT is Y11,D170 as opposed to a number of days. Also the UT of a burn 51 days ahead of day 4185 (If I`ve worked that out right) as displayed on precisenode is 334466850.543 which seems like seconds from day 0 to me.

all very confusing. I`m sure I`ll figure it out though.

Edited June 15, 2014 by John FX

[PLAD]

Already very good with 4 planets. Very interesting the K-E-K-J combo. Pity the tool can't work for moons, would be quite useful to find how to build enough DV to leave the Jool system using some gravitational assists.

Interesting the idea about zooming in. Works, and greatly so. Sure if a feature existed to automatically enter proper values for the zoom, from the flyby selected from the table, it would make zooming a lot easier.

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.

[PLAD]

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.

Edited June 15, 2014 by PLAD

[PLAD]

Would this work on Mac? I've been looking for something with this functionality for a while.

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.

[PLAD]

I made a k-d using the numbers in your example and got many results so I added eve to the end (not changing anything else) and got only one result. when I changed k-d-e to k-e-d the numbers didn`t change and I was told I needed to do the same burn...

I must be doing something wrong but I thought I would just get no results from bad numbers.

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.

[John FX]

As long as I know I have to `clear` between searches I`ll do that and thanks for letting me know there have to be 3 planets minimum (obvious now I think) and that the maths for k-k-d or k-k-d-j isn`t implemented.

I can`t get the numbers as low as yours yet though, I`ll have to play about a bit (and look at your link)

EDIT : Ah, you use a munar flyby...

Edited June 16, 2014 by John FX