PLAD

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

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

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

I have released versions of Flyby Finder and the Lambert and Moonfinder spreadsheets for GPP version 1.5.x with the 10.625x rescale only. They are in the OP above. Note that I assume the user will install Kronometer and therefore have 347-day years for Gael. In earlier versions of the 10.625x rescale this time change was put in automatically, now you have to install Kronometer yourself. GPP v1.5 moved most of the planet start positions, so all the flyby paths I had used so far are obsolete. A quick check shows Tellumo is still the boss for throwing you to other planets, and the gas giants are even better positioned for an early grand tour. No plans for other rescales right now, they have custom day lengths as well as custom year lengths so will take more time.

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

It would be an honor! Or if more a more formal reply is needed I authorize anyone to use that picture any way they see fit. Especially Galileo.

Just look at it... Taken during a very low 10.625x Tellumo flyby. Look at the feathering in the planet's shadow, as if some parts of the ring are thicker than others. Did you design that in or is it luck? And then the probe spotted Beautiful work.

Here is a flight from Gael to Tellumo-Niven-Icarus. This is the lowest-dV way I've found to get to Icarus launching in the first year. This one takes 5618m/s from a 240x240km Gael orbit, but at the end of the album I show the next GTNI window that can get you there for about 4880m/s in year 5. https://imgur.com/a/dfCz4 Note that it is hard to do a giant burn accurately, I had to do a 100m/s correction right after I finished the burn because of burn time and position inaccuracy, but after that it was less than 10m/s total for all the rest of the course corrections.

I have released a version of Flyby Finder that is just for GPP with the 10.625x rescale. It is here. Also there is a version of my Moonfinder spreadsheet for Gael 10.625x, and a version of my Lambert spreadsheet for GPP 10.625. For those using stock GPP regular Flyby Finder is still the place to go. I don't know if I'll make ones for other rescales since I have to play them first, and once you've gone full scale it's hard to go back to the little ones as @Yakvi said. FF is most useful for the full scale in my opinion, especially in the GPP system. In other news I made a rocket to launch from 10.625x Tellumo's surface to orbit. It was much easier than I anticipated because of the launch site I chose, it was at 9600 meters ASL and the air pressure up there is only 70KP, less than at Earth's surface! It is 1013KP at sea level, I'll probably try launching a rocket from there next. But because of the low air pressure up high, which drops off very quickly relative to Earth or Gael, a rocket can accelerate brutally fairly early and not burn up. I wouldn't want to ride it mind you, two stages hit 7 gs during the ascent. As an aside it is hilarious to launch this thing on Gael, it burns and explodes pretty quickly. https://imgur.com/a/wlIfi Now the problem is landing something big enough to get back to orbit from orbit. It would be easy to land low with the thick air as a cushion, but takeoff needs to be high up. *Note-launching from Tellumo's equator gives you 580m/s to start with, which is nice.

This is a set of tools to use with the 10.625x rescale of the Galileo Planet Pack only. If you re using stock GPP then you must use the standard Flyby Finder available here. Tools for the Real Solar System mod are here. I don't offer any other rescales at this time. GPP 10.625x uses a custom time scale with 24 hour days and a 347-day year, and I have to tweak some other parameters to fit the giant size of this solar system. Here is Flyby Finder itself, I'm assuming that by the time you get here you have used it in stock, if not the instructions are in this thread. The following files are for GPP versions 1.2.2 and 1.4 (with the 10.625x rescale) Executable: https://www.dropbox.com/s/fop7rdzdql9z0ah/Flyby085GPP106xExe.zip?dl=0 Source Code: https://www.dropbox.com/s/g21ig7ieb7z51ps/Flyby085GPP106xSource.zip?dl=0 Next is my Moonfinder spreadsheet, this tells you the next time to launch due East into an orbit that will allow an efficient transfer to Iota, and the next time to launch into the plane of Ceti. it's taken straight from the version for RSS that is in the FFRSS thread. https://www.dropbox.com/s/tpu8wyrrqhdxgts/GaelMoonfinderC10X.xls?dl=0 Finally here is my Lambert spreadsheet modfied for GPP 10.625. This is tricky to use but powerful, it helps to have a fair understanding of astrodynamics to use it. https://www.dropbox.com/s/pwoo8k6dbvcg1h2/LambertGalileo10625Xb.xls?dl=0 GPP version 1.5.x moved the starting positions of the planets so a new version of FF is required for it. The following files are for GPP version 1.5.x, 10.625x rescale only. Flyby Finder and Moonfinder assume you have installed Kronometer and have the 347-day Gael years only! Executable: https://www.dropbox.com/s/r7bbu2hq9eriasl/Flyby086GPP150r10625exe.zip?dl=0 Source code: https://www.dropbox.com/s/lymue9g31brkl6p/Flyby085GPP150Res10625source.zip?dl=0 Moonfinder spreadsheet: https://www.dropbox.com/s/hc173ls95439zhh/Gael150MoonfinderD10625X.xls?dl=0 Lambert spreadsheet: https://www.dropbox.com/s/ac01ibhr6onwhfp/LambertGPP15010625X.xls?dl=0 okder has made a Mechjeb addon tool that makes finding the best time and orbit to launch into when starting a mission, and it now can help you set up flybys as well. I use it 100% of the time for interplanetary flights. Try it out! PLAD

Yes, thanks, I am going to need it. I just have to know what it would take for some hapless species that evolves on a planet like this to get into space. First will be building anything that can go surface to orbit, and then 2nd trying to fly that from Gael's surface to Tellumo. I calculate a Tellumo orbital speed of 14,011 m/s at 90km altitude, and then the gravity and drag losses should be savage. With a surface gravity of 1.9 the TWR will need to be well over 2 all the way... I'm not above trying an Orion with realistic stats. I was worrying about entering the atmosphere at the 20km/s that you get when falling from infinity, but then I remembered the Galileo Jupiter atmosphere probe hit Jupiter at 47km/s and survived, so it's reasonable (though it was 45% heat shield by mass).

I'm working on a version of Flyby Finder just for 10.625x GPP. A question-I'm using my RO mods and configs so I'm sticking with KSP 1.2.2 and therefore GPP 1.2.3 for now. I see no .cfg changes to the planet orbit parameters in stock or 10.625x between the GPP1.2.3 and 1.4 versions. (Things related to rotation don't matter to FF.) Is there anything that isn't visible in the rescale files that changed between the two? For instance the atmosphere heights get multiplied by 1.8 in 1.2.3 but I can't see that number in the rescale files or Sigma configs. I can't think of much else that could have changed, but I got thrown for a loop when KSP slightly changed the value of big G a couple of versions ago. I'd like to be able to claim FF GPP 10.625x is good for both 1.2.3 and 1.4 without having to build a KSP1.3 RO setup. Tellumo is awesome in 10.625x, that giant rock can throw you all over the place. For 4800m/s from a 200km orbit you can go Gael-Tellumo-Niven-Icarus (though you'll fly by Icarus at 27 km/s). But how will one return from a trip to Tellumo's surface?!?

As some 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 stock, RSS and other planet packs. 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.

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.

Hello @okder, I just wanted to say that I have tried this with stock KSP, RSS/RO, GPP, and the GPP 10.625x rescale and it works well with all of them. I use it for all my interplanetary flights now including simple 2-body transfers, since the launch guidance, transfer node, and correction node work for any flight whether it will lead to a flyby or not. It also greatly simplifies setting up a flyby, I don't bother to try setting one up without it now. Thanks again for this.

This works for setting up flybys too. I'm in the middle of a Earth-Venus-Mars, land, Mars-Earth mission and I used it to set up the Earth launch and departure (as usual), the Venus flyby, and the Mars orbit selection. I realized I can always find an arrival orbit that will pass through a given DA line, you just might not be able to reach everywhere on the planet from that orbit. On setting up a flyby it doesn't give a perfect DA direction because my arrival energy will probably never be exactly right for a given transfer, but it is so close that it is easy and fast to fine tune the flyby using the DA line from your addon as a starting point. Figuring out whether to use the short path or long path is easy because the wrong one will have a "boost from circular" of many times the dV of the right one. (For instance with my Venus flyby one was 55 km/s, the other about 6 km/s). More testing.... (to the casual observer this may look like playing, but I'm testing, testing)

Looks like you Ninja's me. Here is a little album showing what I have in mind but I shall download what you just made and look at it now. Adding the periapsis circle sounds nice, that is basically the departure circle in reverse I think. Let me study your work before I say anything else. edit: OK, I ran it and that is superb! It did just what I wanted, I've put 2 more frames in the album above that show it worked. I went into an orbit around Mars that crossed the AD line your addon gave, then set up a node for execution 18 months later with the magnitude that FF gave me for the return trip and it worked as perfectly as my sloppy orbit circulization allowed. The periapsis circle is a nice touch to make the departure node setup a little easier. You nailed it! Geezum that was fast. I'm going to try some more things with this over the next few days, like flyby assistance, and testing cases where I can't get into the right arrival orbit without a normal component to the periapsis burn. Thanks for this!

1. I would have to select the planet independently of the SOI I'm currently in. For instance if I am currently in the Sun's SOI while traveling from Kerbin to Duna I want to see the departure asymptote (DA) for a future trip from Duna back to Kerbin. That way I can make a mid-course correction to adjust my incoming (to Duna) path to cross the DA, which makes it possible for my future Duna-Kerbin burn to be as inexpensive as possible. 2. I don't need the future ejection trajectory, just the straight line of the DA. You are right that if I go into an elliptical orbit I would need to set the periapsis properly for maximum Oberth effect on the future departure burn, but I usually go into a fairly circular orbit (it is generally cheaper to put extra dV in the orbiter rather than the land/ascent vehicle). Knowing the direction of the future DA will give me a good idea of where the periapsis should be if I want that though. The problem I foresee is that it will sometimes be impossible to make the incoming orbit cross the future DA , or to put the periapsis near where it should be for maximum efficiency. There would still be benefit in getting as close as possible. Note that I don't need to know the LAN or inclination of the future departure path since anything that goes through the DA will be good enough. http://imgur.com/vWDUOx4 There might be a problem in that the incoming path that crosses the DA does not have a high enough inclination to reach my desired landing spot, but once again I could still try to get as close as possible. I could execute a plane change simultaneously with the orbit entry burn (just like Apollo did at the Moon). If the DA was showing I could place the orbit entry burn node and adjust it to cross the DA. I really just want something like the black DA line in my old drawing: http://imgur.com/rFv4gGo I should make a drawing showing how I figure this would look when I'm using it.

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.

I got slightly different results from Zhetaan on the lowest dV K-D-K flight in the first window and the lowest flyby altitude flight. You can see the Flyby Finder readouts along with images of what the flights look like in the game. I'm using the latest KSP and v0.85 of Flyby Finder, maybe that was different? His start date and flyby date are right on. Both flights leave on the same day and fly by Duna on practically the same day (at vastly different altitudes), but the arrival times back at Kerbin are different. Check out the last panel though, there are many different windows for this flight path. Caution: It is risky to go for the absolute lowest flyby altitude possible, there are always little inaccuracies in the departure burn magnitude and time that make the needed flyby altitude change a bit, and if you are skimming the atmosphere then you can't correct with a lower flyby. That's why I went for a 70-km flyby in my example.

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.

Hello Okder, I still use your addon everytime I start a flyby mission, I'm glad you are keeping it updated. I have a suggestion for a new function if you are looking for ideas from your users. Here's the quick version- I'd like a way to enter a start date and start planet, then an arrival date and arrival planet, and then see the departure asymptote line for the transfer projected onto the start planet. I won't need delta-v info, or a drawing of the departure orbit itself, just the asymptote line. There will be the complication that the Lambert finds two solutions but I'd only want the solar-prograde one. Here's why- when I perform a piloted mission to a planet I usually leave a carrier ship in orbit around the planet while a lander brings the crew to the surface. After a pre-planned amount of time the crew returns to the carrier and uses it to go off to another planet (usually back home). The problem is that it is hard to visualize what the optimal departure orbit for the carrier will be, since it can be hundreds of days between arrival and departure from the planet. I do know when I plan to leave the planet before I get there. I want a way to visualize what the optimal departure orbit will be before the carrier arrives in orbit at the planet, so that I can make the arrival orbit be one that will allow an optimal departure later. The only things the arrival orbit will need is to intersect the departure asymptote line and to have an inclination high enough to reach my desired landing point on the planet. This might also be useful for setting up flybys. If you were, for instance, supposed to leave Kerbin on day 1, flyby Eve on day 186, and then arrive at Duna on day 744, after you had left Kerbin's SOI (using your departure guide) and were fine tuning the Eve flyby you could show the departure asymptote for the Eve (day 186) to Duna (day 744) flight on Eve to set it up properly. Your flyby path would only have to intersect the asymptote on the right side of the Eve and have the right periapsis altitude. This would not work perfectly if your Kerbin-Eve transfer was a bit wrong since the energy of the E186 to D744 leg might no longer match your incoming energy, but it would be close enough to make setting up the flyby much easier. I picture it as a straight line going through the center of the planet and up several planet diameters, and the user would rotate the view so that they are looking at the line 'head on' (so it appears as a point) and adjust their path so it crosses that. There might be two solutions, one that goes retrograde around the planet and one that goes prograde, but it would be easy for the user to decide which solution they want to use. Thank you again for writing your superb add-on! PLAD

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.

The link to the latest version of Flyby Finder, 0.85, is available in the first post of this thread.

TOT and Flyby Finder, both mentioned above, are the two tools I know of for planning flybys in KSP. I've done Kerbin-Duna-Jool and as mentioned above Duna does not give you much of a push, it reduces the roughly 2000 m/s a direct flight to Jool would need to roughly 1900 m/s. On the other hand it is easier and much faster to execute than the more powerful Kerbin-Eve-Kerbin-Jool route so you might want to try K-D-J first.