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

[aluc24]

14 hours ago, PLAD said:

It's a good suggestion, I have spent quite a bit of time sometimes trying to find the proper flyby to get me to the next planet at the right time. It's easy when the flight stays near the ecliptic plane, but sometimes a gas giant flyby will surprise me by needing to send the ship on a path way above the ecliptic, and that can be really hard to find. The problem though is that knowing the inclination of the flyby to the planet is of limited use when you don't know the LAN of the flyby path, and most of all because I can't see the inclination or LAN of my flyby until I am in the SOI of the flyby planet (at least using Mechjeb), and then it is far to late to efficiently adjust your path. I suppose something that said "flyby periapsis is at -50 degrees inclination" (note that wouldn't mean the flyby path is inclined -50, just that the periapsis is above -50 on the planet's surface, which you could eyeball) would help.

 I'll think about this.

 

-later edit- I've just asked okder about something that might make setting up flybys much easier, since unlike me he can write stuff that shows up in the game while it's running.

I am not an expert on orbital mechanics, but I think that if slingshot periapsis and date are correct, then the LAN would automatically be correct too (since you can't change it without changing periapsis and it's date). That is, assuming you're passing in the right side of the planet, which is usually obvious. So the only remaining property is the actual inclination, which, if known, should make the fly-by stick to the plan.

I'm making a few assumptions here, so let me know if I'm wrong about it

 

One more unrelated question - often when I'm setting up a maneuver node based on Finder's data, I find that the initial transfer dV is somewhat higher than the Finder says (meaning I need to increase the maneuver dV to make the rendezvous with the first planet at the right date). Before you say it, I always launch into perfect 75x75@0° orbit to start with (and I do mean perfect), which is exactly what Finder is expecting when it states the "Start Boost from Equat. Orbit" dV. Why does this value differ from the real maneuver data? Am I doing something wrong, or is it some sort of calculation inaccuracy?

Edited July 29, 2017 by aluc24

[PLAD]

On 7/29/2017 at 6:34 AM, aluc24 said:

I am not an expert on orbital mechanics, but I think that if slingshot periapsis and date are correct, then the LAN would automatically be correct too (since you can't change it without changing periapsis and it's date). That is, assuming you're passing in the right side of the planet, which is usually obvious. So the only remaining property is the actual inclination, which, if known, should make the fly-by stick to the plan.

I'm making a few assumptions here, so let me know if I'm wrong about it

 

One more unrelated question - often when I'm setting up a maneuver node based on Finder's data, I find that the initial transfer dV is somewhat higher than the Finder says (meaning I need to increase the maneuver dV to make the rendezvous with the first planet at the right date). Before you say it, I always launch into perfect 75x75@0° orbit to start with (and I do mean perfect), which is exactly what Finder is expecting when it states the "Start Boost from Equat. Orbit" dV. Why does this value differ from the real maneuver data? Am I doing something wrong, or is it some sort of calculation inaccuracy?

I think we are talking about different inclinations, I mean the inclination relative to the flyby planet while you are in its SOI, I think you mean the inclination of the solar orbit between the flyby planet and the destination planet. You must approach a planet from a specific direction, but you can tweak the flyby so it is over, under, East, or West of the planet so the flyby path can have any LAN or inclination relative to the planet. But you are right, the solar orbit between flybys or encounters is set by the encounter times. So I think you would want a new line that says something like:

Time from 1st to 2nd Encounter: 272 days 4.5 hours

Transfer orbit inclination: 8 degrees

?

As for an error in the given initial transfer dV, how big is the error? Thanks to the large number of steps, the fact that many of them involve trigonometric functions, and my simplifying the calculations a bit to increase speed, there can normally be about +/- 0.1% error in the equatorial prograde V, and +/-1% in the Vz (the vZ error can be quite a bit more if the departure orbit is highly inclined, especially those last few degrees before it hits 90. Also of course, if the program says vZ should be zero and you turn out to need 1m/s then I guess that is an infinity percent error) There can also be an error caused by the actual departure time being a bit off from the planned departure time, even if you launch into a perfect 75x75 orbit, that orbital period is still 30 minutes so you could be on average about 15 minutes off of the planned burn time. This will normally only be 1 or 2m/s for a 15 minute error though. If the error is larger than we could look at a specific example to figure out what's going on, and details like which version of KSP and FF would be needed.

 

 

[aluc24]

2 minutes ago, PLAD said:

I think we are talking about different inclinations, I mean the inclination relative to the flyby planet while you are in its SOI, I think you mean the inclination of the solar orbit between the flyby planet and the destination planet. You must approach a planet from a specific direction, but you can tweak the flyby so it is over, under, East, or West of the planet so the flyby path can have any LAN or inclination relative to the planet. But you are right, the solar orbit between flybys or encounters is set by the encounter times. So I think you would want a new line that says something like:

Time from 1st to 2nd Encounter: 272 days 4.5 hours

Transfer orbit inclination: 8 degrees

?

As for an error in the given initial transfer dV, how big is the error? Thanks to the large number of steps, the fact that many of them involve trigonometric functions, and my simplifying the calculations a bit to increase speed, there can normally be about +/- 0.1% error in the equatorial prograde V, and +/-1% in the Vz (the vZ error can be quite a bit more if the departure orbit is highly inclined, especially those last few degrees before it hits 90. Also of course, if the program says vZ should be zero and you turn out to need 1m/s then I guess that is an infinity percent error) There can also be an error caused by the actual departure time being a bit off from the planned departure time, even if you launch into a perfect 75x75 orbit, that orbital period is still 30 minutes so you could be on average about 15 minutes off of the planned burn time. This will normally only be 1 or 2m/s for a 15 minute error though. If the error is larger than we could look at a specific example to figure out what's going on, and details like which version of KSP and FF would be needed.

 

 

Well, I meant the inclination relative to the planet too. I think I understand what LAN is, but if, say, I depart from Kerbin at correct time and arrive at Duna at correct time and pass on the correct side of the planet, how can LAN be wrong?

But anyway, what you suggested, transfer orbit inclination, should be good enough for practical use. It's just that KSP doesn't readily display inclination after a slingshot. I think it can be worked around by selecting Kerbin as target and seeing the relative inclination.

Well, I did a Kerbin - Duna - Jool - Sarnus (from OPM) probe mission, and I think the initial burn was something around 1969m/s total, when it should have been 1939m/s. My initial orbit was perfectly 75x75km@0°, and the launch time was off by no more than one orbit. That's an error of 1.55%. Nothing scandalous, but enough to arouse curiosity. Using the data from Finder didn't even get me an encounter, so I had to tweak the values to get that encounter at the right date. If you think it's needed, I could create a new mission for testing purposes. Let me know.

 

One more suggestion... Nothing terribly important, but when I run the Finder with a large number of search steps, the program hangs until it completes calculations. It always finishes them, never crashes, but it would be great if there was some sort of progress bar and/or ETA. It would be even more amazing if there was an "Abort" button to cancel the calculations if I notice I made an input mistake for calculation that will take minutes to run. Not sure how easy would it be to implement this, and if you have time for it, but a progress bar and an abort button would be handy to have.

[PLAD]

On 7/30/2017 at 1:36 PM, aluc24 said:

Well, I meant the inclination relative to the planet too. I think I understand what LAN is, but if, say, I depart from Kerbin at correct time and arrive at Duna at correct time and pass on the correct side of the planet, how can LAN be wrong?

But anyway, what you suggested, transfer orbit inclination, should be good enough for practical use. It's just that KSP doesn't readily display inclination after a slingshot. I think it can be worked around by selecting Kerbin as target and seeing the relative inclination.

Well, I did a Kerbin - Duna - Jool - Sarnus (from OPM) probe mission, and I think the initial burn was something around 1969m/s total, when it should have been 1939m/s. My initial orbit was perfectly 75x75km@0°, and the launch time was off by no more than one orbit. That's an error of 1.55%. Nothing scandalous, but enough to arouse curiosity. Using the data from Finder didn't even get me an encounter, so I had to tweak the values to get that encounter at the right date. If you think it's needed, I could create a new mission for testing purposes. Let me know.

 

One more suggestion... Nothing terribly important, but when I run the Finder with a large number of search steps, the program hangs until it completes calculations. It always finishes them, never crashes, but it would be great if there was some sort of progress bar and/or ETA. It would be even more amazing if there was an "Abort" button to cancel the calculations if I notice I made an input mistake for calculation that will take minutes to run. Not sure how easy would it be to implement this, and if you have time for it, but a progress bar and an abort button would be handy to have.

Yup, you would have to eyeball the solar inclination after a flyby, and usually it will only be a couple of degrees. The ony time I think it might be useful is when there is a very high inclination generated by a gas giant. Note that the inclination of a prograde flight is alway positive x degrees, so I'd have to find a way to tell if the flight goes South of the ecliptic or North of it during the transfer to the next planet or it wouldn't be too useful.

That error is troublesome, if that is common and not a high-Z flight  then I would want to fix it. If you find something like that I would appreciate the flyby details, just the planets and the encounter dates, so for example K241-D362-J800-S1500, along with what you got as the required start burn (Vz and Vprograde would be ideal). Then I can run it myself and try to track the problem.

[aluc24]

14 hours ago, PLAD said:

Yup, you would have to eyeball the solar inclination after a flyby, and usually it will only be a couple of degrees. The ony time I think it might be useful is when there is a very high inclination generated by a gas giant. Note that the inclination of a prograde flight is alway positive x degrees, so I'd have to find a way to tell if the flight goes South of the ecliptic or North of it during the transfer to the next planet or it wouldn't be too useful.

That error is troublesome, if that is common and not a high-Z flight  then I would want to fix it. If you find something like that I would appreciate the flyby details, just the planets and the encounter dates, so for example K241-D362-J800-S1500, along with what you got as the required start burn (Vz and Vprograde would be ideal). Then I can run it myself and try to track the problem.

Well, I tried to re-create it now on purpose to find the problem, but now it worked perfectly, with actual maneuver details matching what I need to get right encounters. I'm using KSP 1.2.2, and 0.85 of the Finder - which is meant for KSP 1.3. Could that be the problem? I don't really think planet positions should be affected after an update, but who knows.

[PLAD]

As @aluc24 and others have noted, it can be time-consuming to set up a flyby when you only know the flyby altitude. However, okder has updated his Mechjeb addon to add a graphical departure asymptote indicator. This makes it much easier to set up a flyby path past the intermediate planets. (It also has some other uses, more details below.) Here is a little primer on how to use it.

https://imgur.com/a/MzWwR

This little album shows more detail on using it to plan a future departure from a planet you are arriving at.

https://imgur.com/a/vSGZB

 I experimented with putting more info in FF's text output, like the inclination of the transfer orbit from one planet to another, but this graphical indicator is much easier to use. It works with RSS and other planet packs as well. Note you will need Mechjeb in order to use this.

The biggest trick is deciding whether to use the short path or long path when setting up a flyby. Long path means you will go more than 180 degrees around the sun during the transfer, short path means less than 180. For a given flight one of them will require you to go retrograde around the sun, that is the wrong way. Looking at the number in the '"boost from circular" field will tell you which that is because the retrograde path will have a much higher value than the prograde one.

 

Edited September 3, 2017 by PLAD

[PLAD]

I've updated FF to work with the latest version of the GPP. FF v0.86 is for stock-scale GPP v1.5x. Keep using FF 0.85 if you are using an earlier version of GPP.

Two small changes were made to the detail box- Vinf out has been removed since it was redundant with Vinf in, and I added total travel time in years to the summary. It already had total travel time in days but for long voyages years seemed useful.

-PLAD

[FoxtrotUniform]

Is there a tutorial?

[Interplanet Janet]

Would you also be able to add in other planet packs? For instance, Stock Planet Expansion by @The White Guardian, Realistic Ascension by @lajoswinkler, or Outer Reaches by @_Augustus_ ?

[PLAD]

On 12/20/2017 at 1:25 PM, FoxtrotUniform said:

Is there a tutorial?

Yup, in the OP I link to a primer on using it. Okder's Mechjeb addon makes it much easier to determine the best launch time and start orbit inclination and LAN to get into, link is at the bottom of the OP and a couple of examples in using it are in that thread.

  You can see typical values to use when searching for flybys in the various flyby reports I've done over the years, here are some examples:

Kerbin-Duna-Kerbin : Here

K-E-K-Jool: here

If you look further through my older adventures be aware that I used to use "Earth Time" (365-day years, 24-hour days) even in stock Kerbal so the the search date values will be wrong for modern KSP and its 6-hour days and 426-day years.

-PLAD

 

[PLAD]

1 hour ago, Interplanet Janet said:

Would you also be able to add in other planet packs? For instance, Stock Planet Expansion by @The White Guardian, Realistic Ascension by @lajoswinkler, or Outer Reaches by @_Augustus_ ?

Hello, sorry, no. Those are great packs but I already have FF for 5 different systems and it is too much for me to keep track of any more (every time something updates I have to install it and check flybys around every planet to make sure nothing has changed, or figure out and test and release a new version.) The supported packs are:

Stock KSP

Outer Planets mod

Real Solar System

Kerbol Star System

Galileo Planet Pack  (1x)

GPP 10.625x

-PLAD

 

[FoxtrotUniform]

On 12/22/2017 at 11:20 PM, PLAD said:

Yup, in the OP I link to a primer on using it. Okder's Mechjeb addon makes it much easier to determine the best launch time and start orbit inclination and LAN to get into, link is at the bottom of the OP and a couple of examples in using it are in that thread.

  You can see typical values to use when searching for flybys in the various flyby reports I've done over the years, here are some examples:

Kerbin-Duna-Kerbin : Here

K-E-K-Jool: here

If you look further through my older adventures be aware that I used to use "Earth Time" (365-day years, 24-hour days) even in stock Kerbal so the the search date values will be wrong for modern KSP and its 6-hour days and 426-day years.

-PLAD

 

The imgur links aren't working. Could you add a spoiler then the images?

Edited January 6, 2018 by FoxtrotUniform

[PLAD]

4 hours ago, FoxtrotUniform said:

The imgur links aren't working. Could you add a spoiler then the images?

OK. It's weird though, I can see the imgur primer just fine by clicking on the link, but I know there are so many possible security settings and ways of linking to something that it won't always work on all devices.

A simple link to the primer

Now a spoiler-style link:

Spoiler

https://imgur.com/a/EQCJC

-PLAD

PS-Here is a link to execution of an Earth-Venus-Mars, land, Mars-Earth mission using Okder's addon. Going Kerbin-Eve-Duna-Kerbin in stock is a similar mission.

Spoiler

https://imgur.com/a/MzWwR

 

[Johould]

If you are interested in a Linux version, it didn't take much to get it running under the Lazarus IDE for Free Pascal (v1.6.2). It has a Delphi project converter, I let it comment out the AppEvnts dependency when the converter asked, then changing five more lines gets everything functioning. (The fonts are different so some text is a little cut off, but it still computes flybys just fine). Here's a patch:

Spoiler

diff -U1 FlybyFinder.just_converted/Flyby086P.lfm FlybyFinder.working_lazarus/Flyby086P.lfm
--- FlybyFinder.just_converted/Flyby086P.lfm
+++ FlybyFinder.working_lazarus/Flyby086P.lfm
@@ -172,3 +172,3 @@
   end
-  object PaintBox1: TPaintBox
+  object PaintBox1: TImage
     Left = 16
@@ -1113,3 +1113,3 @@
   end
-  object ApplicationEvents1: TApplicationEvents
+  object ApplicationEvents1: TApplicationProperties
     OnActivate = ApplicationEvents1Activate
diff -U1 FlybyFinder.just_converted/Flyby086P.pas FlybyFinder.working_lazarus/Flyby086P.pas
--- FlybyFinder.just_converted/Flyby086P.pas
+++ FlybyFinder.working_lazarus/Flyby086P.pas
@@ -43,3 +43,3 @@
     Label15: TLabel;
-    ApplicationEvents1: TApplicationEvents;  {hidden button that activates when FF is started}
+    ApplicationEvents1: TApplicationProperties;  {hidden button that activates when FF is started}
     Start: TButton;             {The "Begin search" button. The only one I named!}
@@ -70,3 +70,3 @@
     Label17: TLabel;                      {"Search Complete"}
-    PaintBox1: TPaintBox;                 {the giant pork-chop plot graph}
+    PaintBox1: TImage;                 {the giant pork-chop plot graph}
     Button5: TButton;                     {The "Show Graph" button}
@@ -1483,3 +1483,3 @@
     begin
-        for y:=0 to maxsolutions+2 do
+        for y:=0 to solcount+1 do
         begin

 

If you can't apply the patch file with "patch" or would rather make the changes manually, you have to start by change TApplicationEvents to TApplicationProperties in the form file with a text editor. Until you do you can't open the form in the graphical form viewer, because there is no type named TApplicationEvents in Free Pascal at all (A type TPaintBox exists but I guess it behaves differently than the Delphi version).

Edited July 28, 2018 by Johould

[HebaruSan]

The stock career mode gave me a contract to flyby Eve, Duna, and Ike with the same craft, so I decided it was time to figure out flybys.

FBF gave me what sounds like a good path 274 days in the future, so I set about trying to plan the trip in-game. I can create a maneuver node that far out (with the help of a mod or two), and add a plane change maneuver to get an Eve encounter, but the problem I'm having is that fine tuning after that to get a good flyby is basically impossible. A tiny movement of any maneuver handle results in big, unexpected, inconsistent jumps in future paths. I can get a mediocre flyby set up that needs some correction, but applying the correction by adjusting the normal component of an existing plane change maneuver to flatten the in-SOI trajectory causes large apparent changes as if the radial or prograde components had been changed as well. I have to go back and tweak the prograde of the original burn, and by then the normal component is bad again, and I end up in an infinite loop.

It seems to gets worse for every maneuver I add. I had an Eve flyby planned that then led to a solar apoapsis at Duna's orbit, but it needed a plane change. I placed a third maneuver for that, and immediately the last orbit patch changed, the (still 0 m/s) maneuver jumped forward, and the Duna-skimming apoapsis was gone, even though none of the previous nodes had been modified at all.

Any tips for this? Are stock maneuver nodes just too fiddly for this kind of work, or is there a way to get them to clean up their act?

[HebaruSan]

Quote

Start Equatorial Z velocity: 1651 m/s
Start Equat. Prograde velocity: 697 m/s
Start Boost from Equat. Orbit: 1792 m/s

I tried to set this up by starting with a prograde maneuver of 697 m/s, then increasing the normal until the total was 1792 m/s. The resulting orbit doesn't even leave Kerbin's SOI. What do these values mean? I looked at the imgur gallery but I don't remember seeing a glossary there.

EDIT: I think this was due to a mod "fixing" the nodes' normal orientation. Inspecting the components of the burn, they didn't match the Prograde and Z values, and adjusting them till they did match gave me not just an escape trajectory but an Eve encounter. Carry on!

Edited September 14, 2018 by HebaruSan

[4x4cheesecake]

3 hours ago, HebaruSan said:

I tried to set this up by starting with a prograde maneuver of 697 m/s, then increasing the normal until the total was 1792 m/s. The resulting orbit doesn't even leave Kerbin's SOI. What do these values mean? I looked at the imgur gallery but I don't remember seeing a glossary there.

EDIT: I think this was due to a mod "fixing" the nodes' normal orientation. Inspecting the components of the burn, they didn't match the Prograde and Z values, and adjusting them till they did match gave me not just an escape trajectory but an Eve encounter. Carry on!

That's why I switched to "Precise Maneuver". It doesn't  mess around with the prograde vector while editing the normal vector but it contains a button to do "perfect" inclination changes.

Also, you will probably never hit the perfect transfer window since FBF doesn't  know anything about the ship position in orbit so you will always need a second,third...burn to do some corrections, especially when you go for multiple flybys and you need to adjust the time for the ejection burn. Sometimes, because your ship will be on the wrong side of the start planet at the calculated UT, sometimes because a moon will be in your way.

You better don't  try to get  every encounter in a single burn, it will drive you crazy

[HebaruSan]

On 9/14/2018 at 4:14 AM, 4x4cheesecake said:

You better don't  try to get  every encounter in a single burn, it will drive you crazy

Thanks, I decided to "trust" the initial burn and try again at the first correction burn, and I managed to set up a full Eve -> Duna -> Ike trajectory at that point. I guess a real orbit is just more stable than a projected one somehow. Either way FBF's advice was completely solid!

[RaceToTheMun]

I don’t know if this mod is abandoned but, if people are still here then can you please provide a simple tutorial (can be a video) on how to plan a flyby for example Kerbin-Eve-Duna.

[Wildcat111]

Is this mod abandoned now?

[Sppion1]

Hi !
I might sound idiots, but.... I don't know how to read details of a burn :S

Like for a K-E-K I got this :
Orbit Departure Time:
   11728800 seconds UT
   544 days UT
   Y2   D118   H0
Start Orbit Inclination: 35,1 degrees
Start Boost from that incl.: 1072 m/s
Start Equatorial Z velocity: 1909 m/s
Start Equat. Prograde velocity: 468 m/s
Start Boost from Equat. Orbit: 1966 m/s
V Infinity Leaving Start Planet: 1003 m/s
 

What I do understand of this is the time of burn (at least I do understand something).
But what about others ?
Orbit inclination, Is this like the inclination difference between th Mun and minmus  ? So i have to be on a very inclinated orbit ? Which seems pretty weird... Or is it like 35,1° from prograde ?

Start boost from that inclination, I imagine thats the boost I give in the prograde direction ? Or is it start boost from equatorial orbit ?

So I'm having a hard time here... Can someone explain it to me ?

[Arrowstar]

On 5/19/2019 at 7:49 PM, Wildcat111 said:

Is this mod abandoned now?

PLAD hasn't been around in 2.5 years.  I'm guessing yes.

[Clamp-o-Tron]

.

Edited December 15, 2020 by Clamp-o-Tron
Disregard