PLAD

Depart Kerbin y2 d155 h2, from a 75x75km equatorial Kerbin orbit, with a v prograde of 1037m/s and a vz of -460m/s. If you depart on Y2 d163 instead it is vP of 1040 and vz of -482m/s. If you have Mechjeb installed then get Okder's addon and it can guide you from launch to the trans-Eve injection burn. In any case you should flyby Eve (periapsis) as close to y2 d353 h3 m40 as you can, about a +/-6 hour error is the most you should tolerate. I don't know how many flybys you've flown before, if it's not many you should study a run or two. I never get to Jool at exactly y8 d299, I'm often off by something like 30 days thanks to little errors adding up. However, it should be possible to go on from Jool to Eeloo, nominal would be going Jool y8 d299 - Ee y9 d285. Jool flyby altitude should be very roughly 300,000 km. The dv required to brake into low Eeloo orbit will be around 2000m/s. If you have Flyby Finder you can enter the rough flyby dates from above into it and it will give you the rest of the info. Good luck!

Yup, that is the first KEKKJ window start date. It's in Kerbal time (6/426) though, in my old posts I do it in Earth time (24/365), so my old K146-E195.7-K296.2-K509.25-J821 becomes the following in Kerbal time (which pretty much everyone uses now): K y2 d155 - E y2 d353.7 -K y3 d330 - K y5 d330 - J y8 d299. Note that the Kerbin start window is wide, I leave on the early side (y2d155) because I use the Mun for an additional boost, and 48 hours later like hsp did is also OK. (Heck, all the times are flexible if you are willing to use more dv for corrections on the way, though the Eve flyby time is the most critical to get right.) @herbal space program, excellent mission by way!

Thanks! New Horizons.. I haven't studied that mod yet.. I'm running out of room to put new planet pack buttons, and more importantly it will take a lot of time to keep track of more packs so I don't want to add more right now. Unfortunately I didn't originally plan to do more than just stock KSP, so I didn't make it easy to expand. I have a spreadsheet similar to LambertOPM (in in the OP in this thread) that I have been developing to require minimal work between entering the planet parameters from the Kopernicus config files and getting the numbers I need to enter into Flyby Finder, but you still need a Delphi Pascal compiler to put them in. There is also the problem that some packs have planets that Flyby Finder's algorithms couldn't handle properly, so human inspection is still required. So no, there is no easy way to enter a new pack's data into the program. Unfortunately. I didn't foresee 3 years ago that so many excellent packs would be coming out! -edit- I just looked at New Horizons and I have studied it before. The problem is that Kerbin is in orbit around a gas giant, FF would be able to find transfers from a circular orbit around the gas giant to other planets in the system, but not from Kerbin. It is an excellent idea for a planet pack but not for FF.

I've already got that in there, all columns in the table can be sorted into high-to-low, look for the buttons on the bottom of the table. If Imgur is in the mood to display today here is a page from my primer that has one of the buttons circled: http://imgur.com/VvxWJFB Yup, my biggest complication with having multiple star systems is that I have to keep track of them all and update and test whenever a new version comes out. I try to pick mature planet packs that have stabilized the planets orbital parameters. Everyone can feel free to remind me when they spot a change, I think they are all working on new versions for KSP 1.3 right now. I'm not exactly suffering though, these planet packs are gorgeous. Right now in KSS I have a mission on Duna's innermost moon and every view is just spectacular.

I've just released version 0.85 of Flyby Finder. It has the following new features: -Adds the ability to plan for Kerbol StarSystem's Kerbol system (v0.6.1) as suggested by @Voodoo8648. Only the main Kerbol system though. I did not include the 2 comets or Naith because their orbits were too eccentric for FF to handle. I did put Hypat in though it has a high eccentricity, I wanted to see what happens. It turns out that some Lambert calculations for Hypat do not converge quickly enough and so many solutions are not found. I have not seen it find any false solutions yet, but I consider Hypat experimental, use at your own risk! Since it is hard to find Hypat solutions I have an Imgur album below that shows a few I found to help other searchers. Note that I don't have room to put more of the KSS systems in the program right now, I have to rethink the whole design if I will put any more systems in there. -Improved the tabstop order as suggested by @Alshain -Added Grannus to the GPP planets. It has almost same eccentricity problem as Hypat, and in addition it is so heavy with such a huge SOI that the travel time to it winds up being about a year shorter than FF predicts, as such it should only be the last body in a flyby chain. I can still find good paths to it though, below is an Imgur album showing some nice paths to Grannus from Gael and a typical flight to it. -Tweaked the OPM atmosphere heights to match the values in the latest version (2.1). -Tweaked the SMA of Gael in the GPP pack, it changed by about 1 part in 3000 between v1.2.2 and 1.2.3. -Added lots of comments to the source code. I could expand the type of orbits that are allowed in FF but only at the expense of a lot of speed, so I want to continue to not use bodies with an eccentricities greater than 0.25. Grannus and Hypat are just experimental but I figured people might find them useful even though paths that lead to them are difficult to find. edit- This should work fine with KSP 1.3, as I see no changes to the stock bodies masses or orbital parameters, but I won't change the version note until I've run missions involving all the planets in 1.3. This takes a while!

The Youtube video, and the basic Aldrin cycler concept, assume the orbits of Earth and Mars are both circular and coplanar. (They also start with the assumption that the orbital periods are exactly in the ratio of 1.875:1 but that is easy to compensate for.) When the Aldrin cycler, or any cycler, is simulated in an accurate solar system then course adjustments are needed to compensate for the varying motions of the planets. For instance Mars' orbit is quite eccentric so if you encounter it near it's periapsis Mars will be way ahead of its mean position. So the time between encounters has to vary back and forth from orbit to orbit. You can greatly reduce the size and frequencies of the adjustments if you can calculate the ship's motion several orbits ahead, but that takes some serious calculating chops.

I tried a cycler ship in this thread a while back. Ultimately I didn't have the tools needed to plan the cycler path more than a couple of flybys ahead, and without that sooner or later the cycler drifts way off course. The fact that the transfer ship has to have more than enough dv to get to the destination planet just to catch the cycler makes a cycler unnecessary if you're not using life support mods. The Kerbin-Duna run is a quick trip anyway. Maybe a Kerbin-Dres run...

The thread Weywot8 links to above is a good one, I made two runs using the same KEKKJ window (starts Earth day 146.1) in it and give a fair number of details in the imgur albums. I also did KEKKJ run using a different window, one that starts on (Earth time) day 2016.2. Here is the imgur album for that one, note that the last picture shows the details for the run in both Kerbal and Earth time. Note you should skip the start of that one since I used a fairly tricky multi-Mun flyby method to get enough energy to get to Eve, but from there on it is universal. I found a number of KEKKJ windows but I have only run the two shown in the above albums. The day 2016.2 (equals Kerbin Y19 D383.8) one is more forgiving of errors. Let's see if I can show a chart of the others I've found: K E K dbl K J start m/s 146.1 195.65 296.2 0.424 509.25 821 1068 318.75 338 430.2 0.46 643.25 1210 1345 498.5 546.9 639 0.46 852 1062.5 1163 644.75 679.8 767 0.51 980.05 1292 1151 855.8 903 1000 0.44 1213.05 1647 1388 2016.2 2065.6 2165.6 0.445 2378.65 2675 1079 Times are all Earth days, if you enter these in my LambertHOPM spreadsheet (available in the Flyby Finder thread) it gives you the details. The 'dbl' column is a little code Lambert uses to indicate the details of the K-K leg. So for instance the first row means leave Kerbin orbit on day 146.1, flyby Eve on day 195.65, set it up so you are flung back to Kerbin and fly by it on day 296.2, then fly by Kerbin again on day 509.25 (note this is exactly 2 Kerbin years, or 213.05, days after the first Kerbin flyby) and then arrive at Jool on day 821. Don't sweat the arrival day at Jool, but the time of the Eve periapsis should be within +/- 6 hours of day 195.65, the first two K's can be off by +/-18 hours or so. When I wrote Flyby Finder KSP only used Earth time (24 hours in a day, 365 days in a year) so most of my work uses that time mode, nowadays the Kerbal system of 6 hour days and 426-day years is generally used. Lambert translates from Earth time to Kerbal time if you need it. Be careful if you try the windows I've haven't, with some of them the final Kerbin flyby is dangerously low and some luck will be required to be able to make the final K-J leg without a big correction burn.

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 from KSP as it's running and can therefore handle any system.

I find the orbital parameters for the various bodies in the Kopernicus config files, they define the orbits and the starting positions of the bodies exactly. I check every body, even the ones that look stock, but thanks for the warning. (and I have to recheck them all with every new version, doh!) Since KSP uses 2-body physics (rather than n-body like the real universe) math can determine the exact position of any body at any time in the future. For speed I use approximations rather than an iterative solution to the Kepler problem, this means orbits with an eccentricity greater than about 0.25 aren't calculated accurately by FF so I avoid those bodies.

That is impressive. I shall take a while to look at it though, I see at least 4 systems that have enough planets for flybys, and I have to study the orbital hierarchy of the multi-star systems. I see I can't put the Halley's Comet analog in because it's eccentricity is too high... this will take a few weeks of playing. That was an eye opener. My personal style never used the tab key to go from field to field but I just did it now and I see what you mean. It jumps through the fields in the order I made them rather than a logical use order. I'll see what I can do for the next release.

I'll take a look at it but I can't promise anything. Could you give me a link? I didn't see it in the first few pages of Add-on Releases.

Hello, sorry for the delay. I fiddled a bit with an implementation of freepascal a while back and couldn't find most of the graphics commands from the Delphi Graph unit in it. So yup, the porkchop display screen would have to be rewritten from scratch as best as I could see. I also found some of the commands from the Delphi Math unit missing, like the ones that convert ordinal dates to Gregorian and back (used in the FFRSS date converter) and arctan2. It is good to hear that freepascal is close though, after studying Windows 10 I see I'm going to get a Linux machine someday soon. Aah, Borland Turbo Pascal. I wrote my first n-body simulator in that. DOS 3.3 with a 640x480 graphics screen, yah!

I also suggest FFRSS (I wrote it). In one of the guides I made a panorama of Earth-Mars-Earth free returns, it was in the pre-RSS v12.0 version of FFRSS so it will be a bit different now if you are using the latest RSS (which is what the latest version of FF is for). Here it is: I also did a piloted mission to Mars using a flyby of Venus to get there, the path I chose could have aborted the Mars landing and done a free return to Earth, so you can flyby Venus and Mars and get back to Earth with only a few small mid-course corrections. It's here. Watch out though, the arrival speed at Earth can be pretty high if you're not careful.

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.

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.

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.

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

My Flyby Finder can find some flyby paths to get you from Kerbin to Jool for less than the standard Hohmann requirement of about 2000 m/s (from a 75x75-km orbit). Going Kerbin-Duna-Jool can be done for about 1900 m/s, not much savings there because Duna is so small and can't throw your ship around much. Going Kerbin-Eve-Kerbin-Jool can be done for about 1400-1500m/s, here is an example of me doing that that goes into a lot of detail in how to set it up and execute it. You will probably need a different window than the one I used, but if you study the values and search periods and max v at SOI in the first screenie you can search forward to the time you want. As an aside if you have never used FF before you should really study the primer on using it because there is a bit of complication to planning flybys. You can also go Kerbin-Eve-Kerbin-Kerbin-Jool for about 1100m/s, I find this significant for big ships that have low acceleration even in the small stock system. Unfortunately FF does not plan paths that have a double flyby of a planet like this, I have to use the Lambert spreadsheet linked in the FF OP to find these. Here is an example of going K-E-K-K-J for 1011m/s, though a flyby of Mun is also used to save about 80m/s. Using Mun is very tricky, you have to time things to a couple of minutes. I don't recommend starting with this. I find that the timing of the flybys is the most important thing in setting these up, in other words if FF says your flyby periapsis of Eve should be on Year 1 Day 180, 4:32, then you should try to make the flyby be within a few hours of that time even if your flyby periapsis or departure dV will be off. There are several tools out there to make this easier. okder's Mechjeb addon is spectacular for launching into the right departure orbit inclination and LAN and it works with the latest version of Mechjeb. Slingshotter, which has just been revived by linuxgurugamer, is great for making sure you will encounter a planet at the right time- tell it to show you where the flyby planet and your ship will be at the required flyby time and it is easy to adjust a pre-flyby maneuver node to make the two meet at the right time. If you want more assistance then Arrowstar's TOT might be more what you want. It is big and complex but will decide what flyby to use and can put nodes directly into KSP while it is running. TOT can't do double flybys either though. If you are using the Outer Planets mod by CaptRobau or the Galileo Planet pack then flybys are even more useful for getting to those outer planets, they can be both cheaper and faster than Hohmann, and FF can handle those two systems.

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

Thanks for the tip. Because of Flyby Finder I'll always be checking the changelogs for GPP with each release (and the .cfg files just in case) but it's nice to know. By the way, what value does Kopernicus use for little g (I assume 9.81 m/s^2)? Heh, your tip for getting to Ceti is too easy, wait until your LAN on the launchpad is 89 degrees using KER. I use Mechjeb but it doesn't give the correct LAN while the ship is still on the ground (once you launch it snaps to the correct value). I get the little 1-degree fudge factor caused by the LAN of your ship increasing a bit between launch and orbit insertion, I should have noted that. For Iota I made a spreadsheet that uses spherical trigonometry to find the two times in the next day that launching will put you in a plane that intersects Iota's orbital plane at the point where it will be when you get out to its SMA (one encounter where you approach it from below and one where you approach from above) but your way is easier than making a spreadsheet.

Just wait until someone asks for the optimal times to launch to Iota. That gets epic.

As was noted above, Ceti's inclination is almost exactly the same as the standard launch site's latitude. This means that every sidereal day there will be one optimal moment when you can launch due East into Ceti's orbital plane. Here's how I calculate that moment. Ceti's LAN is 90 degrees (relative to the absolute frame of reference), the standard launch site is at Gael longitude 191.8 degrees longitude and 8.84 degrees North, and per the config file Gael's rotation starts with Gael 0 degrees latitude pointing at 90 degrees relative to the absolute frame of reference. Since the launch site is North of the equator what this all means is that if you launch due East at Y1 D1 0:0:0 you will get into an orbit with a LAN of 191.8 degrees in the absolute frame of reference. Since Gael's sidereal rotation period is 21549.41 seconds it will be about 15454.6 seconds before the launch site is closest to Ceti's orbital plane. This is Y1 D1 4:17:34, and this is the first optimal time to launch due East to get to Ceti. Every 21549.41 seconds after that will be another optimal launch time to get to Ceti. (So for example the 2nd optimal launch time is Y1 D2 4:16:44.) I write a little spreadsheet where I enter the current time and it gives me the next optimal Ceti launch time. This is more complex then just putting a craft in low Gael orbit in the exact orbital plane of Ceti and launching when you pass under its orbit, or using it as a target for various flight assist apps, but I love the math.

I wrote an tool that finds flyby opportunities in KSP called Flyby Finder. Arrowstar wrote a more detailed program called TOT that also can find them. TOT goes into much more detail and can even take control of your ship, but it is huge and only finds one flyby path at a time. FF shows a pork-chop type plot of a range of travel times and start dates but you will have to learn some tricks to get into the right start orbit around Kerbin and set up the departure burn, and figure out the flyby periapsis lattitude and longitudes by messing with a node editor. (Okder's addon, linked to in the post, makes the Kerbin departure much easier.) Here are some flights I made using this tool, in the Imgur albums I go into detail on how I executed the flight. Low Kerbin Orbit to Jool for 1051 m/s (later in the thread I did it for 1011m/s!) Kerbin-Eve-Duna-land-Duna-Kerbin. This uses an opposition-class flight to Duna similar to some proposals for a Mars mission. A challenge to get to Moho for the least dV possible. Metaphor executes one of the most epic uses of flybys ever to win it. Getting from LKO to Eeloo's surface and back with 1934m/s. If you look through my Imgur page you will see a lot more flyby flights including the one where I made it from LKO to Jool orbit for 914m/s. (Note that there exists no tool for finding the Mun multi-flyby trick I used at the start, just for the encounters after that.) These days my favorite technique when setting up a flyby is to put a node on my ship's predicted path right at the time when the next flyby is supposed to be and then working to make that node encounter the target planet's orbit at the right time. So for instance if you know you will leave Kerbin on day 10 and are supposed to fly by Eve on day 150 then put a node on your path 140 days in the future when setting up you Kerbin departure burn. Come to think of it I detailed this method in this flight using the Galileo Planets Pack. I personally think gravity assists are awesome, it is one of the few times the laws of physics let us get something for nothing. Good luck!

The Longitude of Ascending Node is the longitude at which you cross the equator of the parent body going North. In this case the parent body is Kerbin, and you start at the equator, so if you launch from KSC heading North your LAN will be whatever the absolute longitude of the KSC was at the moment you launched. If we knew the absolute longitude of the KSC at Y1 D1 00:00:00 then we could compute it at any time thereafter and you could always figure out when the next time to launch into your desired LAN would be. I don't see that information in the wiki so I figured it out by launching a rocket with at 90 degree North azimuth as early as I could and reading the LAN of the resulting orbit using Mechjeb. I come up with a start longitude for the KSC of 16 degrees and about 10 minutes. I say about because it is too difficult to not swing back and forth a bit during launch, but I can repeat the 16 degrees 10' to about +/-20 minutes when getting into a polar orbit, your results may vary depending on the orbit inclination you are going for. (If you will get into an orbit with a very low inclination then tiny changes in your launch profile can make a big change in the LAN, +/- 7 degrees for a 1-degree-inclined orbit for me.) Also don't read the LAN out right after launch because it jerks around all over the place while your rocket is still almost exactly over the equator. Wait until you're in orbit. Note that if you are launching Southward then your LAN will be 196 degrees 10 minutes if you launch at Y1 D1 0:0:0, since your launch point will then be the descending node of the orbit and you have to go halfway around the planet before your orbit crosses the equator going North. Kerbin's sidereal rotation period is 21549.425 seconds. From this we see that the KSC's longitude moves forward at a rate of about 1 degree a minute, and every 21549.425 seconds it will be back at 16d 10m longitude. I leave it to you to make a spreadsheet calculating the KSC's longitude at any given time. Careful if you are using an older version of KSP, Kerbin's sidereal rotational period has changed from earlier versions! The start rotation might have changed too but now you know how to measure it. Inclination is a matter of launching and pointing in the right direction, remember that the KSC is moving at 175m/s due East when calculating what direction will get you into the right inclination.