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

[aluc24]

Hey, @PLAD , I hope I'm not necro-posting by reviving this thread. Great tool you wrote. I am now learning how to use it, followed the tutorial, and I am now trying to make my own flyby calculation, Kerbin-Duna-Kerbin. I get a nice porkchop, and I know how to zoom it in, and I know how to extend it left or right (adjusting Departure Date), but I can't seem to extend the plot up and down (the Travel Time). I tried playing around with flyby dates, but nothing I do seems to extend the plot upward. Here's my screenshot:

 

[PLAD]

@aluc24

The travel time axis auto-scales to the range of the flybys found in a search. You told it to search for flybys that started at Kerbin with a certain maximum V at SOI in a certain departure window, and then flyby Duna within a second window, and then arrive back at Kerbin in a 3rd window. It found 828 solutions with those restrictions, and the longest travel time of those solutions was about 880 days, and the shortest about 760 days. You can calculate the longest possible trip by taking the earliest search date (day 1120) and subtracting it from the last possible 2nd encounter time (day 1930+ the 200 day search period=2130). This would be 1010 days in this case. The only way to have a larger range of travel times is to open the search windows and/or increase the max V at SOI. Note that Flyby Finder allows no more than 1 orbit around the sun between encounters so you will need a lot of energy to fly out far enough from the sun that you take more than 1000 days to get back to Kerbin. Try taking the exact search you have above except change the max V at SOI to 3000m/s, and change the 2nd encounter search period from 200 days to 1000 days, and you will see a new 'blob' of solutions appear that have a travel time of about 1250 days (~3 Kerbin years).

  This KDK trip is a fascinating one, try increasing the vSOI and search period more and you can find a solution blob that take about 4 Kerbin years, then 5, etc. Then expand the search start times and you will find a solution blob that flies by Duna on the way out from Kerbin, as well as blobs with about the same travel time but shifted in start time that flyby Duna on the way back toward the sun. At really high energies you can start to find trips that take about half a Kerbin year and 1.5 Kerbin years (these go out to Duna and then way in towards the sun and approach Kerbin from inside its orbit). Those are very small, when you first look for them you should probably have 'search steps per period' at around 200 or so, assuming your 'start at' search period is about 900 days (the Kerbin-Duna synodic period).

-PLAD

[aluc24]

16 hours ago, PLAD said:

@aluc24

The travel time axis auto-scales to the range of the flybys found in a search. You told it to search for flybys that started at Kerbin with a certain maximum V at SOI in a certain departure window, and then flyby Duna within a second window, and then arrive back at Kerbin in a 3rd window. It found 828 solutions with those restrictions, and the longest travel time of those solutions was about 880 days, and the shortest about 760 days. You can calculate the longest possible trip by taking the earliest search date (day 1120) and subtracting it from the last possible 2nd encounter time (day 1930+ the 200 day search period=2130). This would be 1010 days in this case. The only way to have a larger range of travel times is to open the search windows and/or increase the max V at SOI. Note that Flyby Finder allows no more than 1 orbit around the sun between encounters so you will need a lot of energy to fly out far enough from the sun that you take more than 1000 days to get back to Kerbin. Try taking the exact search you have above except change the max V at SOI to 3000m/s, and change the 2nd encounter search period from 200 days to 1000 days, and you will see a new 'blob' of solutions appear that have a travel time of about 1250 days (~3 Kerbin years).

  This KDK trip is a fascinating one, try increasing the vSOI and search period more and you can find a solution blob that take about 4 Kerbin years, then 5, etc. Then expand the search start times and you will find a solution blob that flies by Duna on the way out from Kerbin, as well as blobs with about the same travel time but shifted in start time that flyby Duna on the way back toward the sun. At really high energies you can start to find trips that take about half a Kerbin year and 1.5 Kerbin years (these go out to Duna and then way in towards the sun and approach Kerbin from inside its orbit). Those are very small, when you first look for them you should probably have 'search steps per period' at around 200 or so, assuming your 'start at' search period is about 900 days (the Kerbin-Duna synodic period).

-PLAD

 

@PLAD , thank you very much for your answer, it was most educational. I figured it out - the cut off of my plot at the top was because any other solutions would require me to make a gravity assist below Duna's surface. That's why I couldn't get any more solutions. In any case, thanks again.

Just a few more questions, if I may. When I make a search that takes a very long time, the program becomes unresponsive until it finishes it's calculations. There is no way to abort the calculation or to see how many days it has calculated already. Is there a way to fix it, at least the unresponsiveness part?

And another question - are there any plans to allow more than 4 encounters in the future updates? Surely that would increase time needed to make those calculations, but it would also make it possible to plan grand tours, especially with addon planets.

P.S. Does your calculator take atmospheric height into account? I noticed that it never offers flybys past Even with an altitude lower than 90km, which is exactly the atmospheric height.

Edited November 8, 2016 by aluc24

[PLAD]

@aluc24,

 I'll answer the questions in reverse order:

-Yup, the calculator takes atmosphere height into account, if a flyby would have to go into the atmosphere it is rejected. I originally tried ones that went just a few Km into the atmosphere, but the Oberth effect made the few m/s that the atmosphere took away into a much larger reduced speed at the SOI and severely messed up the flights.

-I decided to stop at 4 encounters for two reasons, one is that it would be too tight a squeeze to put two more rows of numbers in the output table, and the other is that I found it hard to stay on course for that many flybys, by the 4th one I'm usually many days or even months off from the desired time unless I use a lot of MCC's.

-You've discovered a weakness in the program, in certain situations it stops responding to inputs while it is running the search. It seems to happen when a "search period" divided by 'search steps per period' is below a certain value that depends on the outermost planet's orbital period, but I have never nailed it down (though I try from time to time). The 'checking day' box only updates when the "start at" search day is incremented, so if there are a lot of bodies there can be a long time between updates of that box, I didn't want to add the time it takes to update the box to the many thousands of search loops below that. Try lowering the "search steps per period" (SSPP) for a preliminary search, if it finds something note the time taken, then increase SSPP keeping in mind that doubling it increases the run time by 4X, and at some point it might start the no-response error but it will still complete the search. Sorry about that.

[aluc24]

24 minutes ago, PLAD said:

@aluc24,

 I'll answer the questions in reverse order:

-Yup, the calculator takes atmosphere height into account, if a flyby would have to go into the atmosphere it is rejected. I originally tried ones that went just a few Km into the atmosphere, but the Oberth effect made the few m/s that the atmosphere took away into a much larger reduced speed at the SOI and severely messed up the flights.

-I decided to stop at 4 encounters for two reasons, one is that it would be too tight a squeeze to put two more rows of numbers in the output table, and the other is that I found it hard to stay on course for that many flybys, by the 4th one I'm usually many days or even months off from the desired time unless I use a lot of MCC's.

-You've discovered a weakness in the program, in certain situations it stops responding to inputs while it is running the search. It seems to happen when a "search period" divided by 'search steps per period' is below a certain value that depends on the outermost planet's orbital period, but I have never nailed it down (though I try from time to time). The 'checking day' box only updates when the "start at" search day is incremented, so if there are a lot of bodies there can be a long time between updates of that box, I didn't want to add the time it takes to update the box to the many thousands of search loops below that. Try lowering the "search steps per period" (SSPP) for a preliminary search, if it finds something note the time taken, then increase SSPP keeping in mind that doubling it increases the run time by 4X, and at some point it might start the no-response error but it will still complete the search. Sorry about that.

@PLAD I see! But I noticed that setting less SSPP's makes the program miss some flyby options sometimes. For example, I was trying to figure out the period of a grand tour opportunity. I had to set SSPP as big as 2000 to find options in a timeframe of a few centuries - so that I could write down the dates and then zoom in on each. If I set it lower, it jumps through some of the opportunities. But I know there's no other way around it, so I'm not complaining

Yeah, the accuracy is difficult to maintain. For example, I created a Kerbin - Eve - Kerbin - Duna - Kerbin flight plan, and I am now in a middle of flying it:

Spoiler

Start Planet: Kerbin
Orbit Departure Time:
   71676576 seconds UT
   3319,36 days UT
   Y8   D337   H2,1
Start Orbit Inclination: -42,9 degrees
Start Boost from that incl.: 1292 m/s
Start Equatorial Z velocity: -2438 m/s
Start Equat. Prograde velocity: 333 m/s
Start Boost from Equat. Orbit: 2460 m/s
V Infinity Leaving Start Planet: 1560 m/s

1st Encounter Planet: Eve
Time from Start to 1st Encounter: 136 days 1,1 hours
Vinf in: 1580 m/s
Brake to Orbit?: 1589 m/s
1st Encounter Periapsis:
   3455,56 days UT
   Y9   D47   H3,3
   6431 km altitude
Vinf out: 1581 m/s

2nd Encounter Planet: Kerbin
Time from 1st to 2nd Encounter: 344 days 1,6 hours
Vinf in: 2710 m/s
Brake to Orbit?: 1922 m/s
2nd Encounter Periapsis:
   3799,84 days UT
   Y9   D391   H5
   508 km altitude
Vinf out: 2708 m/s

3rd Encounter Planet: Duna
Time from 2nd to 3rd Encounter: 204 days 1,6 hours
Vinf in: 3002 m/s
Brake to Orbit?: 2371 m/s
3rd Encounter Periapsis:
   4004,12 days UT
   Y10   D170   H0,7
   1459 km altitude
Vinf out: 3001 m/s

4th Encounter Planet: Kerbin
Time from 3rd to 4th Encounter: 664 days 2,6 hours
Vinf in: 2375 m/s
Brake to Orbit?: 1715 m/s
4th Encounter Periapsis:
   4668,56 days UT
   Y11   D408   H3,3

Total delta V expended: 3007 m/s
Total Travel Time: 1348,8 days
 

 

By the 3rd encounter, I am already ~30 days behind the schedule. I know I chose a pretty difficult case for starters - the steep encounter inclinations makes getting the dates right extremely difficult. I just wonder if I'll manage to finish the little tour.

Do you have any tips on how to keep the actual flight as close to the flight plan as possible? Arriving at the correct date and velocity is damn difficult for me, I spend nearly hours tinkering with the maneuver nodes and still can't nail it.

You know what would be helpful? A crude visualization of the flight plan in your planner. That would at least help a clueless user to know on which side of the sun the next encounter will be  Just suggesting.

By the way, when making slingshots with a huge inclination, are there any guideliness on how to set the path of the spacecraft past the flyby planet? When things are coplanar, then it's easy, just open up map view, and close up the next encounter. However, when the inclination is steep, hunting for that next encounter becomes a chore.

Edited November 9, 2016 by aluc24

[PLAD]

10 minutes ago, aluc24 said:

@PLAD I see! But I noticed that setting less SSPP's makes the program miss some flyby options sometimes. For example, I was trying to figure out the period of a grand tour opportunity. I had to set SSPP as big as 2000 to find options in a timeframe of a few centuries - so that I could write down the dates and then zoom in on each. If I set it lower, it jumps through some of the opportunities. But I know there's no other way around it, so I'm not complaining

Yeah, the accuracy is pretty difficult to maintain. For example, I created a Kerbin - Eve - Kerbin - Duna - Kerbin flight plan, and I am now in a middle of flying it:

  Reveal hidden contents

Start Planet: Kerbin
Orbit Departure Time:
   71676576 seconds UT
   3319,36 days UT
   Y8   D337   H2,1
Start Orbit Inclination: -42,9 degrees
Start Boost from that incl.: 1292 m/s
Start Equatorial Z velocity: -2438 m/s
Start Equat. Prograde velocity: 333 m/s
Start Boost from Equat. Orbit: 2460 m/s
V Infinity Leaving Start Planet: 1560 m/s

1st Encounter Planet: Eve
Time from Start to 1st Encounter: 136 days 1,1 hours
Vinf in: 1580 m/s
Brake to Orbit?: 1589 m/s
1st Encounter Periapsis:
   3455,56 days UT
   Y9   D47   H3,3
   6431 km altitude
Vinf out: 1581 m/s

2nd Encounter Planet: Kerbin
Time from 1st to 2nd Encounter: 344 days 1,6 hours
Vinf in: 2710 m/s
Brake to Orbit?: 1922 m/s
2nd Encounter Periapsis:
   3799,84 days UT
   Y9   D391   H5
   508 km altitude
Vinf out: 2708 m/s

3rd Encounter Planet: Duna
Time from 2nd to 3rd Encounter: 204 days 1,6 hours
Vinf in: 3002 m/s
Brake to Orbit?: 2371 m/s
3rd Encounter Periapsis:
   4004,12 days UT
   Y10   D170   H0,7
   1459 km altitude
Vinf out: 3001 m/s

4th Encounter Planet: Kerbin
Time from 3rd to 4th Encounter: 664 days 2,6 hours
Vinf in: 2375 m/s
Brake to Orbit?: 1715 m/s
4th Encounter Periapsis:
   4668,56 days UT
   Y11   D408   H3,3

Total delta V expended: 3007 m/s
Total Travel Time: 1348,8 days
 

 

By the 3rd encounter, I am already ~30 days behind the schedule. I know I chose a pretty difficult case for starters - the steep encounter inclinations makes getting the dates right extremely difficult. I just wonder if I'll manage to finish the little tour.

Do you have any tips on how to keep the actual flight as close to the flight plan as possible? Arriving at the correct date and velocity is damn difficult for me, I spend nearly hours tinkering with the maneuver nodes and still can't nail it.

You know what would be helpful? A crude visualization of the flight plan in your planner. That would at least help a clueless user to know on which side of the sun the next encounter will be  Just suggesting.

By the way, when making slingshots with a huge inclination, are there any guideliness on how to set the path of the spacecraft past the flyby planet? When things are coplanar, then it's easy, just open up map view, and close up the next encounter. However, when the inclination is steep, hunting for that next encounter becomes a chore.

Yes, high inclination flights are quite difficult for me too, I avoid them when I can. They are terribly sensitive to the time of periapsis. When flying one it is much more important to get the time right than the Vsoi or flyby altitude. Wait and use a mid-course correction if it is too difficult to get the time just right with the previous encounter, but if you are way up out of the ecliptic plane an MCC can be too expensive....

   I don't know if you have checked out Arrowstar's TOT, it is much more complicated to use than FF but it gives a lot more information. When doing flyby calculations it only gives one flyby within the search windows you set (instead of a plot of many possible flybys like FF) but you could use FF to search for a flyby sequence you like, then run TOT using very  narrow search windows so TOT will be forced to find the one you want. TOT then shows a graph of the overall path and details of the flybys. It will probably still be a chore to get a high-inclination flyby just right though. You can use Okder's addon (see the first post in this thread) to set up the first leg of your trip precisely for you, if you have Mechjeb installed.

 

[aluc24]

17 minutes ago, PLAD said:

Yes, high inclination flights are quite difficult for me too, I avoid them when I can. They are terribly sensitive to the time of periapsis. When flying one it is much more important to get the time right than the Vsoi or flyby altitude. Wait and use a mid-course correction if it is too difficult to get the time just right with the previous encounter, but if you are way up out of the ecliptic plane an MCC can be too expensive....

   I don't know if you have checked out Arrowstar's TOT, it is much more complicated to use than FF but it gives a lot more information. When doing flyby calculations it only gives one flyby within the search windows you set (instead of a plot of many possible flybys like FF) but you could use FF to search for a flyby sequence you like, then run TOT using very  narrow search windows so TOT will be forced to find the one you want. TOT then shows a graph of the overall path and details of the flybys. It will probably still be a chore to get a high-inclination flyby just right though. You can use Okder's addon (see the first post in this thread) to set up the first leg of your trip precisely for you, if you have Mechjeb installed.

 

I heard of that tool, but had problems installing it due to Matlab requirements. I'll try again sometime soon. No, I'm not using Mechjeb at the moment (decided to make things a bit too hardcore for me), but I'll keep that plugin in mind, it seems very useful.

I just finished that flight. Spent more than 300m/s on course corrections... After all, the whole point of slingshots is to save fuel. They become a bit obsolete if you spend so much dV on course corrections that you could have made a simple Hohmann transfer instead... I guess I should work on periapsis timing, as well as course correction timing. If they are executed at the right moment, they are supposed to be very cheap...

Anyway, you made a great program. If you plan on improving it anytime in the future, I would humbly suggest giving some more information for the user about how he should set up slingshot trajectories past each planet. Exact date and altitude is great, but if a few more details (direction, inclination, etc) would also help a lot. Or, visualization of the flight plan, though that may be difficult to do. No pushing, just feedback  I appreciate you replying and helping me sort these things out. It is much more clear now.

[Schievel]

On 1/5/2016 at 8:43 PM, PLAD said:

I still check this thread regularly. Lately I've been using Realism Overhaul a lot and have not worked on the stock version though. I still have the short-term plan to improve the way start orbits are defined, and a long-term plan for double flybys. But it's the old problem of splitting time between the Real World, playing the game, and writing stuff. 

  I have no plans do make a Linux version of FF since I don't have a Linux machine, and even if I had the OS it looks like there isn't a version of Delphi Pascal with full graphics support for Linux. I fear Pascal is a somewhat obsolete language so I'd have to learn another one to port FF over.  Time, time, time.

For the ones who cant wait that long:

It's running fine in wine. For me at least.

I just did a 'sudo apt-get install wine', it ask you to install .NET and Gecko. After that you can start it with wine.

I'm running 64-Bit Linux Mint 18, Kernel 4.4.0-57-generic.

http://imgur.com/a/8h0nC

[PLAD]

7 hours ago, Schievel said:

For the ones who cant wait that long:

It's running fine in wine. For me at least.

I just did a 'sudo apt-get install wine', it ask you to install .NET and Gecko. After that you can start it with wine.

I'm running 64-Bit Linux Mint 18, Kernel 4.4.0-57-generic.

http://imgur.com/a/8h0nC

That is superb, thank you for posting this note.

-PLAD

[PLAD]

I have just just released version 0.84 of Flyby Finder. The one change from version 0.83 is that you can now do searches for Galileo's Planet Pack (current release, version 1.1) as well as the OPM and stock KSP

Edit: Below is an album showing how I executed a Gael-Tellumo-Otho-Gauss-Nero flight. On reflection I should have corrected that 9-hour delay in the Tellumo arrival time that the Gael departure burn inaccuracy created, as every flyby worsened the error by several times. The gas giants are forgiving of fairly large errors though, and I just hate to use a drop more of fuel then necessary.

http://imgur.com/a/xUNHe

-PLAD

Edited January 19, 2017 by PLAD

[Schievel]

Thanks, OPM support is exactly what I was looking for. Actually I didn't notice you have that in your flyby finder until you released that new Version and talked about it.

In fact I only got me OPM to do flyby missions on Jool and the outer planets similar to Voyager and Cassini.

Massive thanks man.

 

// btw can confirm that it still works fine on linux with wine.

• Linux Mint 18 64bit

• Kernel 4.4.0-59-generic

• wine-1.6.2

Edited January 21, 2017 by Schievel

[StickyScissors]

Any chance that 6.4x scaled stock system (and maybe 6.4x OPM along with it) can/will be implemented?

[PLAD]

22 hours ago, StickyScissors said:

Any chance that 6.4x scaled stock system (and maybe 6.4x OPM along with it) can/will be implemented?

Sorry, no. There are a lot of scaled versions of the really good systems, (3.2x, 6.4x, and 10x usually, but I've seen other sizes) and a number of people do their own versions that have slight differences from other people's versions, so there are too many out there for me. I stick with a few original releases that are carefully documented and reasonably settled to make my life easier. FF is kind of simple in that it can't talk to KSP as it is running, or read Kopernicus config files, so I have to enter each system's data by hand and then test the result by doing flybys of each planet in the system and comparing the results to FF's predictions before I release it.

You might try  TOT, it's bigger and more complicated but it pulls the astrodynamic data straight KSP as it's running and can therefore handle any system.

-PLAD

[linuxgurugamer]

What would it take to rewrite this in c#, and have it inside the game?

[Gilph]

On ‎3‎/‎23‎/‎2017 at 8:30 PM, PLAD said:

Sorry, no. There are a lot of scaled versions of the really good systems, (3.2x, 6.4x, and 10x usually, but I've seen other sizes) and a number of people do their own versions that have slight differences from other people's versions, so there are too many out there for me. I stick with a few original releases that are carefully documented and reasonably settled to make my life easier. FF is kind of simple in that it can't talk to KSP as it is running, or read Kopernicus config files, so I have to enter each system's data by hand and then test the result by doing flybys of each planet in the system and comparing the results to FF's predictions before I release it.

You might try  TOT, it's bigger and more complicated but it pulls the astrodynamic data straight KSP as it's running and can therefore handle any system.

-PLAD

Hi, just started using GPP, so thanks for updating your tool.  I tried TOT, but it does not work, and there is no mention of GPP support in the TOT thread. When I create a new bodies file, the new planets are not recognized in any of the drop downs.

[PLAD]

17 hours ago, linuxgurugamer said:

What would it take to rewrite this in c#, and have it inside the game?

Say, you're the one who updated Slingshotter. Thank you for that, I find it makes setting up flybys a lot easier, I have it show me where my ship and a target flyby planet will be at the exact time the flyby peripasis is supposed to be, and it makes adjusting an earlier node to set up that flyby much easier.

   On to your question. Quick answer: a lot of work by someone who knows c#. Long answer: I have used an open license for FF so anyone can use any of my code or algorithms for anything they want to, but if they use it without modification it would be nice if I get a mention. I am one guy working alone and I don't want to take the time I would need to learn c# and how to interface with KSP like that, putting it in-game would drastically increase the complexity and require much more frequent updates and I want to keep it simple. I also like being able to run it on its own since I can spend hours searching for interesting flybys and planning missions before I ever start KSP. Especially when doing a huge search with "search steps per period" set really high which can take 15 minutes to run and sucks up most of my CPU during that time. I think it will always be best to separate the wide search part of finding possible flybys from the setting up of the one specific flyby chain you settle upon.

  I do see how it would be much more convenient to be able to put the results of a search into the game directly, my dream situation would be to search for and settle upon a particular flight path using FF on its own, then to be able to enter the important stats into something that runs in KSP. okder's Mechjeb addon does just what I want on telling you the best launch time and azimuth, and then especially the way it adjusts the initial departure burn to correct for differences between the desired and actual parking orbit. But it only gets you to the first flyby, after that you are on your own. In theory all you would need to tell this app would be the start and periapsis times at the planets, it would then use a Lambert algorithm to determine the necessary departure direction from each planet and compute the necessary flyby parameters to join the arrival velocity from the previous planet to that departure velocity. This is basically what TOT does, only TOT doesn't let you pick a flyby from a porkchop plot or list, it just gives you one that it determines its own way. Also the app would have to be able to set up mid-course corrections due to the inevitable error between desired burns and actual burns and the accuracy limits inherent in a digital simulation. That would be the trickiest part since it is not so simple to determine the optimal place at which to make a MCC. (I find two MCC's between each encounter are usually best, one to correct radial and prograde errors and one to correct z-axis errors.)

If you or anyone else wants to write such a thing I can give advice and explain the methods that FF uses. The Lambert spreadsheet I wrote when developing FF shows most of the calculations used and the source code for FF includes a .pas file that you can open with a text editor to see all the code with my comments. If you don't have Delphi Pascal 5.0 or higher you can't edit and recompile it directly as far as I know.

-PLAD

[linuxgurugamer]

Just now, PLAD said:

Say, you're the one who updated Slingshotter. Thank you for that, I find it makes setting up flybys a lot easier, I have it show me where my ship and a target flyby planet will be at the exact time the flyby peripasis is supposed to be, and it makes adjusting an earlier node to set up that flyby much easier.

   On to your question. Quick answer: a lot of work by someone who knows c#. Long answer: I have used an open license for FF so anyone can use any of my code or algorithms for anything they want to, but if they use it without modification it would be nice if I get a mention. I am one guy working alone and I don't want to take the time I would need to learn c# and how to interface with KSP like that, putting it in-game would drastically increase the complexity and require much more frequent updates and I want to keep it simple. I also like being able to run it on its own since I can spend hours searching for interesting flybys and planning missions before I ever start KSP. Especially when doing a huge search with "search steps per period" set really high which can take 15 minutes to run and sucks up most of my CPU during that time. I think it will always be best to separate the wide search part of finding possible flybys from the setting up of the one specific flyby chain you settle upon.

  I do see how it would be much more convenient to be able to put the results of a search into the game directly, my dream situation would be to search for and settle upon a particular flight path using FF on its own, then to be able to enter the important stats into something that runs in KSP. okder's Mechjeb addon does just what I want on telling you the best launch time and azimuth, and then especially the way it adjusts the initial departure burn to correct for differences between the desired and actual parking orbit. But it only gets you to the first flyby, after that you are on your own. In theory all you would need to tell this app would be the start and periapsis times at the planets, it would then use a Lambert algorithm to determine the necessary departure direction from each planet and compute the necessary flyby parameters to join the arrival velocity from the previous planet to that departure velocity. This is basically what TOT does, only TOT doesn't let you pick a flyby from a porkchop plot or list, it just gives you one that it determines its own way. Also the app would have to be able to set up mid-course corrections due to the inevitable error between desired burns and actual burns and the accuracy limits inherent in a digital simulation. That would be the trickiest part since it is not so simple to determine the optimal place at which to make a MCC. (I find two MCC's between each encounter are usually best, one to correct radial and prograde errors and one to correct z-axis errors.)

If you or anyone else wants to write such a thing I can give advice and explain the methods that FF uses. The Lambert spreadsheet I wrote when developing FF shows most of the calculations used and the source code for FF includes a .pas file that you can open with a text editor to see all the code with my comments. If you don't have Delphi Pascal 5.0 or higher you can't edit and recompile it directly as far as I know.

-PLAD

Yes, i do that (and many other mods).

Right now I'm somewhat busy, getting ready for 1.3 to drop.  But this would be an interesting idea, maybe we can collaborate later

Oh, BTW, would be better to use something other than Dropbox for this, I'd suggest Github, if possible.

[PLAD]

1 hour ago, Gilph said:

Hi, just started using GPP, so thanks for updating your tool.  I tried TOT, but it does not work, and there is no mention of GPP support in the TOT thread. When I create a new bodies file, the new planets are not recognized in any of the drop downs.

Doh, sorry about that. I haven't used TOT with GPP myself, only for stock and RSS, I thought it grabbed all the info from the running instance of KSP, but I know nothing of the nuts and bolts of TOT. I can only point you to his thread.

[linuxgurugamer]

So, I just looked at it, may not be that difficult to do.

Can you explain what exactly happens which you click the "Begin Search" button?  All I have access to is the pascal code, and you seem to use the compiled resource script for most of the graphics.

This may actually give me a good reason to learn the Unity GUI stuff

Edited April 10, 2017 by linuxgurugamer

[PLAD]

4 minutes ago, linuxgurugamer said:

So, I just looked at it, may not be that difficult to do.

Can you explain what exactly happens which you click the "Begin Search" button?  All I have access to is the pascal code, and you seem to use the compiled resource script for most of the graphics.

This may actually give me a good reason to learn the Unity GUI stuff

Yup, that is a problem with seeing only the .pas file, you have to guess which button is giving which input, and which output field is which. I was lazy about naming the buttons and fields properly. My only defense is that I originally wrote it quickly to beat a KSP challenge a couple of years ago and it just snowballed.

I shall give you a detailed answer in a couple of hours, the real world calls right now.

[linuxgurugamer]

1 hour ago, PLAD said:

Yup, that is a problem with seeing only the .pas file, you have to guess which button is giving which input, and which output field is which. I was lazy about naming the buttons and fields properly. My only defense is that I originally wrote it quickly to beat a KSP challenge a couple of years ago and it just snowballed.

I shall give you a detailed answer in a couple of hours, the real world calls right now.

That's fine,take your time.  I won't be able to do anything until the weekend at the earliest.

1 hour ago, PLAD said:

Doh, sorry about that. I haven't used TOT with GPP myself, only for stock and RSS, I thought it grabbed all the info from the running instance of KSP, but I know nothing of the nuts and bolts of TOT. I can only point you to his thread.

What is TOT?

never  mind, found it

Edited April 10, 2017 by linuxgurugamer

[PLAD]

4 hours ago, linuxgurugamer said:

So, I just looked at it, may not be that difficult to do.

Can you explain what exactly happens which you click the "Begin Search" button?  All I have access to is the pascal code, and you seem to use the compiled resource script for most of the graphics.

This may actually give me a good reason to learn the Unity GUI stuff

Hmmm... how detailed should exactly be? For instance here is a general description of the beginning of the program:

________________________________________________________________________________________

When you start FF it runs the little procedure:
Tform1.ApplicationsEvents1Activate
which loads the KSP stock data, sets the graph to show colors by the start dV field and sets a minimum allowed time between encounters of 10 Kerbal days.
Now you can do things like change the star system, the time system, enter data, etc. Now pressing the start search button runs the procedure:
Tform1.StartClick
 which
-turns off or disables a number of buttons for the duration of the search (prevents changing things like Kerbal time/Earth time, search steps per period, etc. while on the fly)
-clears the previous search and sets solcount (the solutions found so far) to -1.
-sets the high and low values for the various output data items to very high values (for the highest startv, totalv, vz,totaltravel time, flyby altitude and braking speed) and zero for the low values.
-does houskeeping on which boxes are visible and where the cursors are.
-runs the procedure LOADINPUTS, which reads and loads the values that have been placed in the input boxes. This procedure has a number of checks of the data as it is loading it.
-counts how many bodies there are. If it is only two then it runs a quick version of the porkchop generator called SEARCH2, if there are more than two it runs the flyby finder SEARCH. All the good stuff happens in these procedures and their children.
After search or search2 is done it computes the graph y-axis limits (hitime and lowtime) and re-enables the buttons. And finally it decides which of the "sort" buttons on the bottom of the table are enabled based on how many columns of data there are.

_______________________________________________________________________________________

 

Or I can put a comment on almost every line in the procedures, here's STARTCLICK:

______________________________________________________________________________________

procedure TForm1.StartClick(Sender: TObject);
{runs whenever the 'begin search' button is pressed}
begin
    label17.visible:=false;                    {turn off the "search complete" button}
    if solcount>0 then button4click(sender);   {clear old solutions count if it exists}
    label50.visible:=true;                     {turn on the "hit clear to enable time change" button}
    radiobutton1.enabled:=false;               {disable the time mode (Earth or Kerbal) selection radio buttons}
    radiobutton2.enabled:=false;               {disable the time mode (Earth or Kerbal) selection radio buttons}
    button26.enabled:=false;                   {disable "select planetary system" button}
    solcount:=-1;                              {set the count of solutions found to zero}
    edit12.text:='0';                          {set the "checking day" field to zero}
    hiv:=0;                                    {set the highest start dv found to 0}
    lowv:=10000;                               {set the lowest dv found to 10000}
    hitotalv:=0;                               {highest total dv found}
    lowtotalv:=20000;                          {lowest total dv found}
    hivz:=-20000;                              {highest vz found}
    lowvz:=20000;                              {lowest vz found}
    lowtime:=10000;                            {lowest total travel time found}
    hitime:=0;                                 {highest total travel time}
    lowpass1:=500000;                          {lowest first flyby altitude found}
    hipass1:=0;                                {highest first flyby altitude found}
    lowbrake:=20000;                           {lowest braking dv found}
    hibrake:=0;                                {highest braking dV found}
    outputgrid.rowcount:=maxsolutions;         {set the dimension of the output grid to the max possible number of results}
    paintbox1.visible:=false;                  {turn off the graph}
    panel3.visible:=false;                     {turn off the "graph color by" choices}
    outputgrid.visible:=true;                  {turn on the output grid}
    LOADINPUTS;                                {load the input values entered by the user}
    if bodycount=2 then SEARCH2                {Execute the search if 2 bodies}
    else SEARCH;                               {Execute the search if 3+ bodies}
    hitime:=int((hitime+10)/10)*10;            {compute the graph y-axis upper limit}
    lowtime:=int((lowtime-5)/10)*10;           {compute the graph y-axis lower limit}
    outputgrid.rowcount:=solcount+2;           {adjust the output grid size to match the results}
    label17.visible:=true;                     {turn on the "search complete" button}
    button5.visible:=true;                     {turn on the "show graph" button}
    button6.visible:=true;                     {Set up the data search buttons}
    panel1.visible:=true;                      {turn on the "sort" panel}
    if bodycount=2 then button8.visible:=false else button8.visible:=true;    {turn off the "2nd enc" sort button if only 2 bodies}
    if bodycount=2 then button12.visible:=false else button12.visible:=true;  {turn off the "1st flyby" sort button if only 2 bodies}
    if bodycount<4 then button15.visible:=false else button15.visible:=true;  {turn off the "2nd flyby" sort button if only 3 bodies}
    if bodycount<4 then button16.visible:=false else button16.visible:=true;  {turn off the "3rd enc" sort button if only 3 bodies}
    if bodycount=5 then button18.visible:=true else button18.visible:=false;  {turn on the "3rd flyby" sort button if 5 bodies}
    if bodycount=5 then button19.visible:=true else button19.visible:=false;  {turn on the "4th enc" sort button if 5 bodies}
end;

_______________________________________________________________________________________________

Then I'll have to do the same for the next level procedures, SEARCH and LOADINPUTS, and so on down.

Logically I should explain the reasons for  various details, like how I chose the starting values for the high and low numbers but I'll wait what you need for clarification there.

 I'm thinking I should update the .pas file with complete comments and especially identification of every button and data field  referenced in it. That will be useful for me too. It will take a few days at least, good there is no rush. I'll put it in my dropbox when I finish and let you know.

[linuxgurugamer]

Ok.  I understand the code, just needed pointers

It's going to be a bit, but when I get started, i'll want you to test what I do

[Arrowstar]

On 4/10/2017 at 11:55 AM, Gilph said:

Hi, just started using GPP, so thanks for updating your tool.  I tried TOT, but it does not work, and there is no mention of GPP support in the TOT thread. When I create a new bodies file, the new planets are not recognized in any of the drop downs.

Hey there, KSPTOT author here.  I'm not sure what GPP is but if you post over on the other thread or PM me we can talk about it.  Thanks!

[Gilph]

On 4/10/2017 at 11:55 AM, Gilph said:

Hi, just started using GPP, so thanks for updating your tool.  I tried TOT, but it does not work, and there is no mention of GPP support in the TOT thread. When I create a new bodies file, the new planets are not recognized in any of the drop downs.

Ignore the idiot that made this post.  After you create your bodies.ini in TOT, edit the file and do a global replacement of "Ciro" with "Sun" and reload the file. My thanks to @Arrowstarfor correcting me.