Search the Community

tl;dr: summary at the end of the post I am aware the problems of the current maneuver planning tool have already been discussed on this forum by multiple players: the prediction stopping when out of fuel, the inability to set the maneuver at the next orbit, the lack of number entries, the inaccuracy of the progress bar... Here I want to bring a mathematical insight to why, even with all these problems dealt with, the current maneuver planning system would still be inadequate. The current advantages of the maneuver tool are the ability to see the real trajectory followed by the spacecraft during the burn, and to evaluate its end point. It is a huge advantage, especially for long burns. However, the predicted path is computed by assuming the direction of thrust is constant, and set at the beginning of the burn, and that is the heart of the problem. Take for example the following vehicle, that has 4072m/s of ΔV and a TWR of 0.29, placed on a 100x100km orbit. I want it to transfer to a kerbostationary orbit at 2863km of altitude. Picture: Test vehicle With a theoretical instant impulse, the Hohmann transfer is 651m/s for the apoapsis raising (going from the 100x100km orbit to a 100x2863km one), and 424m/s for the circularization at apoapsis (from 100x2863km to 2863x2863km). The return trip costs the same, 424m/s for periapsis lowering and 651m/s for circularization at 100km. These are the ΔV computed by the maneuver tool in KSP1, because it was computed assuming an instant impulse. Picture: Principle of a Hohmann transfer Of course in a real situation the maneuver is not instantaneous, and the player has to find a way to perform the maneuver with this limitation. In KSP1, the usual technique was to point the spacecraft in the direction of the maneuver, and start the burn when the time before reaching periapsis is half the duration of the maneuver. So basically the node is approximately in the middle of the real maneuver. By doing this technique, the ΔV is 659m/s for the apoapsis raising and 424m/s for the circularization at kerbostationary altitude. The return trip costs 424m/s for the departure and 651m/s to circularize at 100km. With different spacecrafts, the ΔV cost varies according to their TWR. For this spacecraft in particular with an initial TWR of 0.29, the cost is very close to the theoretical Hohmann transfer (only 8m/s of loss). Picture: Direction of thrust with KSP1 method In KSP2, the new maneuver planning tool computes the predicted path of the spacecraft during the whole duration of the maneuver, assuming that it is pointing in the maneuver direction. This direction is inertially fixed, and computed in the orbital frame at the start of the maneuver. This means it is no longer possible to place the node at the middle of the maneuver. When planning an apoapsis/periapsis raising/lowering, if the player sets a prograde/retrograde maneuver (as was done in KSP1), the spacecraft will be pointing straight in prograde/retrograde direction at the start of the maneuver, and slowly drift away as the orbital frame changes along the trajectory. By doing this technique, the ΔV is 700m/s for the apoapsis raising and 426m/s for the "circularization", but the orbit is much more elliptic than KSP1's technique (2847x2880km instead of 2863km). And the return trip costs 424m/s for the periapsis lowering and 671m/s for the circularization but again it is impossible to circularize with this kind of maneuver. The resulting orbit is 59x151km. So the ΔV cost is much higher using this naive technique introduced by the new planning tool. This is due to the thrust direction being suboptimal. In these maneuvers (apoapsis/periapsis raising/lowering), the goal is to gain or lose orbital energy. The optimal way is to thrust in the prograde or retrograde direction, every other direction introduces a loss. The greater the direction difference, the higher the loss. KSP1's technique keeps the thrust direction pretty close to the optimal direction, therefore the ΔV is close to the theory. In the naive KSP2 method, the direction is prograde/retrograde at the beginning, but the difference is much higher at the end of the maneuver, therefore the loss is much greater. In this particular case, the loss is 81m/s, 9 times higher than with KSP1's planning tool. Picture: Direction of thrust with KSP2 naive method Picture: Resulting orbit after the periapsis circularization With KSP2 current tool, it is in fact possible to perform the same maneuver as with the KSP1 method, but the player needs to correct the direction of thrust with a radial-in/radial-out component. So the new method would look like this for a circularization at periapsis: set a maneuver at periapsis with a retrograde component so that the apoapsis is approximately at the good altitude; move the maneuver so that the the periapsis is in the middle of the path; add a radial-in component to the maneuver so the resulting orbit is closer to a circle; tweak all three parameters until the projected orbit is as close to a circle as you want. It takes only five minutes to do in KSP2 what took two clicks in KSP1. What an upgrade! Now what I'm proposing is to change the way the planning tool computes the maneuver direction. For these kind of maneuvers, I would like the maneuver to be computed in the orbital frame that moves with the predicted path. Which means, when a maneuver is set with a prograde component, the maneuver marker stays exaclty prograde during the whole duration of the maneuver. Picture: Direction of thrust always prograde This is what happens when you burn always prograde/retrograde in my example. The apoapsis raising costs 652m/s of ΔV. It is very close to the theoretical ΔV, but as a side effect it also raised the periapsis by 7km. Therefore less energy needs to be gained at apoapsis, and the circularization costs only 418m/s. The total is less than a Hohmann transfer. For the return trip, the periapsis lowering costs 417m/s of ΔV. For the circularization at periapsis, I start the maneuver at such an estimated time so it ends at the periapsis, and it costs 644m/s. As I don't have an adequate planning tool, the circularization is not perfect, so the resulting orbit is 97x105km, but still way better than with the current planning tool. Again the ΔV is less than the theoretical Hohmann transfer. The total gain is 19m/s, minus some ΔV needed to properly circularize. The difference is even greater between the KSP2 naive method and the one I propose when the TWR is lower or the burn longer (e.g. for interplanetary departure/arrival). So with this change, the planning tool would allow the player to negate the losses induced by a suboptimal direction of thrust. However I don't think the current planning tool should be totally discarded, because in some cases maneuvers need to be planned with an inertially fixed direction. Here are cases I can think of where the maneuver should have a fixed direction: - plane change (changing the inclination) - fly-by corrections (changing the orbit in another SOI) - target corrections (reaching another spacecraft) It is not anecdotic, so it is better to keep the current tool available to the player. But the default planning mode should be the moving orbital frame, because here are cases where it is essential: - orbit changes (periapsis/apoapsis raising/lowering) - circularization - rendez-vous - lunar/interplanetary departure - interplanetary arrival (injection burn) - targeted landing - suicide burns Theses maneuvers are the heart of KSP2 game loop, there are essential to go anywhere. Ideally, I would like to have an option on the planning tool to compute the path either: 1. In the moving orbital frame 2. In inertially fixed frame 3. As an instant impulse The third one can still be useful to plan certain maneuvers that are not possible with the current spacecraft. For example, the player sets a station in high altitude orbit of Kerbin (with no engine), and now he/she wonders how much ΔV it would costs to reach the Mun with a space tug or a resupply module. With instant impulse planning tool, he/she can have that information that is not available in the VAB trip planner. TL;DR The current maneuver planning tool computes the future path by assuming the spacecraft points in a fixed direction. This is useful only for some very specific cases. In most cases such as orbital raising/lowering, interplanetary trajectories or landing, it is suboptimal to say the least. A better way would be to compute the maneuver in the moving orbital frame. It would be easier to plan in terms of QoL, and cheaper in terms of ΔV cost for most maneuvers. P.S. This posts echoes @Superfluous J tutorial (Don't just burn prograde!), where he/she shows the prograde maneuver is nowhere near optimal in terms of ΔV for an interplanetary departure. However, I would say the title is misleading: you SHOULD burn prograde and stay prograde, just not in the direction of the maneuver

For a mission I'm planning, I need to get from Low Kerbin Orbit to the surface of Pol. Due to mass constraints, I might have a tight delta V budget, and want to know how much delta V I'll need. I think I can pull off a capture assist with Tylo or Laythe, but a full KEKKJ chain on the way to Jool is gonna be too risky. (especially because I'm doing it on an LMP server where I can't quicksave/quickload.)

I see TWR in the Engineer's Report in the VAB. Is there a way to see DV? Also, is there a way to see TWR per-stage? Is there Kerbal Engineer / MechJeb functionality coming?

For my grand tour mission, I'm wondering how much delta-v I will need to get to Moho and back. I plan to depart from Gilly to Moho, and on the way back swing by Eve on a path to the outer system, maybe stop at gilly again. My questions: 1. Should I send the main ship over (5-6 km/s), or should I send over a specialized ion vehicle? 2. How much delta-V do I need exactly? Including landing, but if I send the main ship I have ISRU.

I'm trying to make a rocket-only SSTO spaceplane that can get to orbit and dock to a station. I have managed the first part, but only with like 30 m/s remaining - not enough to get to a station and return home. My current design uses a few aerospikes, and has a vacuum delta v of around 4 KM/s. Why I decided to use a rocket SSTO: 1. easier to fly than a jet SSTO 2. noting to have to balance or otherwise deal with, compared to a shuttle 3. cooler than a rocket How can I increase the delta-V in orbit of my space plane to be able to dock to a station? Of course, if all else fails, I might be able to add a few drop tanks or boosters, but I'd like to try and go fully reusable.

I usually use mods, but I've removed them all when this problem arose. Therefore I've put this into the unmodded section. No matter what part combo or fuel type, I cannot get any info in the editor or in-flight. it simply says 0 meters/s and when I click on it to get the more detailed info like TWR, it simply does not display any data within the box. Please help with this as it is making the game almost unplayable for me.

Not sure if im even asking the right question. Lets say for instsance, I build a massive ship designed to travel the solar system. And on this ship I have multiple engine groups that i can toggle via the actions menu. Some are for efficency and others are for high thrust and others even are for finetuning maneuvers. The problem is, no matter which engine groups are active the delta v available and the current twr readout over in the staging section remains the same which makes performing maneuvers kind of a guessing game at burn times, whether i have enough fuel, and when to start each burn. Am i missing something?

It's not effective, either to have a single gigantic tank for Tylo and back, nor having two hundred separate stages for a trip to Mun. Is there a formula to calculate the minimum fuel to dead weight ratio for each stage in order to have a net delta-v gain for adding that stage?

KSP Visual Calculator Online calculator tool for Kerbal Space Program Delta-V Planner Click the planets and moons that you want to visit to get a total required delta-v number for the mission A mission can contain multiple checkpoints to visit, each on different planets, moons, and orbital situations (or surface landed) Also provides a step-by-step breakdown for each leg in the journey Shows the delta-v requirements for every possible trip combination (delta-v subway-maps only work when Kerbin is one of the locations) Configure custom preferences such as aerobraking at specific locations, applying a margin of error to your mission, or calculating the most efficient route instead of a direct route Save & export the mission as a JSON file to share with others CommNet Planner Create satellites, relays, rovers, stations, bases, etc. with a custom selection of antennae, then drag those around the screen to see where commnet connections are valid Every craft automatically indicates if it has control or not based on the relay networks it is connected to Use this to plan out communication network constellations, without having to trial-and-error this in-game Set the DSN Tracking Station level at Kerbin to match in-game upgrade progress Set the CommNet difficulty settings to match the settings in-game Add Remote Guidance cores in craft to test a piloted base providing remote control to a rover, even when a connection to Kerbin is out of reach Shows detailed stats such as cost, power rating, mass, transmission speed, etc. for the entire collection of antennae on each craft Save & export the constellation as a JSON file to share with others ISRU Mining Station Calculator Design a mining base by swapping out different parts to see their effects on the system Select the planets or moon for the mining base, adjust the ore concentration, and even add a specific skill engineer onboard Toggle the type of processing that the ISRU will be doing. Only refining Liquid Fuel? Then only turn on Liquid Fuel refining Fuel cells, solar panels, and RTGs can be added for power supply A handy 'Production and Consumption' panel displays the total outputs, and any deficiencies of the system Number sliders control the amount of each part. Use this to adjust the amount of drills, or power sources, or radiators until the outputs are green with no deficiencies Warning messages highlight potential issues in the design, such as not having 'Ore Storage' parts Choose from 73 stock parts Save & export the parts selection design as a JSON file to share with others https://ksp-visual-calculator.blaarkies.com/ Checkout the github repo

I am trying to design the a rocket that has the exact right amount of Delta-V required to get to the Mun and back. The first stage should be capable of getting the rocket clear of the atmosphere. I have looked everywhere for how much Delta-V the first stage needs and have found nothing. How much Delta-V should I be aiming for for my first stage to be able to get above 70 km?

In one of Matt Lowne's videos I heard that to go to eloo your rocket need to reach a total delta-v of 4000 m/s. But what this mean? Is this means that that's the max deceleration or acceleration what you'll need to make, or what? He also stated out that his fuel just ran out before reaching that speed. I wanna make some rockets and put some stations on distant planets and an ssto that can send crew on them and back to kerbin, and i was just curious what could this total delta-v mean, and how it could help me make it.

I understand the dV map to get from Kerbin to LKO is 3400, another 950 gets me to the sun and then 90 more will get me to a fly-by Eve with another 80 to get into orbit and 1350 to circularize just over the atmo. So to get into orbit of Eve I would need 5850 (plus margin) to simply get to the orbit of Eve. If I want to return from Eve to Kerbin what parts of that do I need to account for? Do I need to add the whole thing back or can I forget that 1330 that was used to circularize?

I have been trying my hardest to design a lander that is capable of surviving an Eve re-entry, and being able to return from sea level. My main problems are first that the lander needs to be quite big and so I need big rockets to haul them into orbit. Sometimes they are not light enough to get into LKO. The second issue is that I am trying to at least land on actual land and not the ocean so Jeb can plant a flag and the rocket can stay upright on landing legs. The problem with that is mainly that I don't know how to do atmospheric precision landings on Eve. Any tips?

From Kerbin to Beyond Delta-v Hey folks, I got a little case of OCD today and decided to make a spreadsheet (link above) of all the Delta-v to get around the solar system when Kerbin is the starting point. This and the KER add-on works together beautifully to figure out proper staging and TWR for any given mission you are planning. This is by far my favorite Launch Window Planner for the nitty gritty. With a little research and elbow grease multiple landings can be had on a single celestial body. Be sure to pack an experiment storage unit if you do. And above all else, remember to pack all the other things you might forget or didn't know you needed. Notes* Downloading or copying spreadsheet may lead to happy accidents. There is a lot of delta-v wiggle room so feel free to adjust all the numbers if you also have OCD. Spreadsheet is linear from left to right. Kinda like how we read. LO = low orbit 2LO = to low orbit. Sources - https://wiki.kerbalspaceprogram.com/wiki/Main_Page https://alexmoon.github.io/ksp/

Is the delta-v map showing the min or max delta-v usage?

Does anyone knows how much delta-v total do i need to get to duna and back? if there is already an answer can anyone send me a link? pls

I have had KSP for the PS4 a total of 4 days now, and it's complexity and intricacy exceeds what I prepared for. I am happy in this, but mortified as well. I have started a science save file, and have only researched 4 additional groups including: basic rocketry, engineering 101, general rocketry, and survivability. With the new parts acquired from researching these groups I built a simple, 3 stage ship, and have decided to try to achieve LKO. To do so efficiently, I delved into the KSP wikis and forums to find the relevant information. I understand to a certain point the rocket equation, or the "*dudes name I can't spell*'s equation". Anyways, I found the ISP of the rockets used in each stage, and I wasn't going for complete accuracy at first, using the ATM ISP for every equation done. Then, I found the total mass of each individual stage, as well as the dry mass of the stages by themselves. In order to do so I had to take the first to stages off, and measure the total and dry masses for the last stage, then add the second stage and subtract the total mass of both stages my the total mass of the last stage to get the total mass of the second stage. Then I proceeded to do so with the first stage attached as well. I found both total and dry this way for the first and second stages. Now that I have the ISP, M_FULL, and M_EMPTY, I figured I could calculate and add the answers together to find my overall delta-v, granted I SHOULD have more than I calculate based on the idea that my ISP for each equation will be the atmospheric ISP. My work: (weights are rounded) Stage 1 (final stage): pod, fuel tank, and 'reliant' thruster. - Dv = 265 * 9.8 * In (4/3) = 747 Stage 2 (second stage): 2 fuel tanks and 'reliant' thruster. - Dv = 265 * 9.8 * In (3.5/1.5) = 2,200 Stage 3 (first stage) 2 BACC thrusters, and 1 'hammer' thruster, with added radiator panels. Dv = 520 * 9.8 * In (19.5/4.5) = 7,472 I am now realizing that each stage must also push the weight of the stages above them, meaning I must carry the mass of those stages into that equation, adding to the total and dry mass of the stage being figured. If this is not so and I have created a false solution, please let me know, thank you.

Personally, I will continue to use Kerbal Engineer as it has a HUD that allows me to see things at-a-glance rather than having to go into and out of the map screen to check my apo- and periapsis. I also perdict that in the future, it will save me from having to scroll through long staging lists to check dV.

Does anyone have a table or list of calculator with the upper limits of the Delta-V require to go from say a 50-100km orbit to a safe landing. I get it wrong too often. I just landed a base segment on Minmus with literally 10 times the Delta-V it needed. I ended up just throwing away all that fuel because it was late at night and I had to get to bed. It would also help if the resource you supply me with also listed optimal acceleration figures for landings. That's been on of my problems in these 155 years too. Help me improve my game, please.

When calculating Delta-V manually the equation would be DeltaV=ln(m_start/end)xISPx9.8m/s^2 Now my question is when traveling to the moon would you change the 9.8 to calculate delta v? Im just confused as 9.8m/s^s is acceleration of gravity on earth. Thanks, Jonda

Hello! Could somebody please explain what Delta-V is, but simply? Currently I think it is how much total thrust my craft can produce with the fuel it has. Now, I do not want a paragraph of mathematical and scientific stuff, I would just like a simple explanation.

We've all heard it...there's frustratingly no working ALT code for a capital Delta on Windows. Every other Greek letter works, except for the one you and I would type consistently on this forum. We have to Google it, and copy and paste it from some website every time. But that's not true! You can make the delta symbol work with the Alt key! I found it here: https://www.reddit.com/r/windows/comments/18joaq/how_do_you_get_the_delta_symbol_on_a_windows/ Go to the Command Prompt, and enter this sequence: reg add "HKEY_CURRENT_USER\Control Panel\Input Method" /v EnableHexNumpad /t REG_SZ /d 1 Then, log off and log back on. Open a text editor. It can even be this forum. Hold [ALT] and [NUMPAD +] and type '0394' on the keypad. Δv

Hey there! So I bought the DLC and apart from all of the other bugs and issues mentioned in many other threads, I have come to notice something: I'm not actually having any fun playing the Stock missions, and generally the stock game. I would dare to call myself a KSP veteran, having started out a few years back. Building rockets that can go to the place you want to go is quite a hit and miss, until you discover the concept of Delta-V and TWR. After my discovery, I started calculating them with pen, paper and a calculator. Then I switched to Excel, but that still got tedious real fast. Luckily I discovered MechJeb (and later KER) that calculated the TWR and the stages for me. I got used to them, and building rockets became second nature to me. When Making History was released, I thought to myself: "OK, let's play these missions as they were intended: with just the Stock game, no mods". I finally got to the third part of the mission (building Jebnik 1), and I come to realize: Wait, how the hell am I supposed to know if this is going to space or not??? I don't have a dV readout, I can't even do trial and error, because there is no Revert to VAB after I've launched the thing. My options are: Build the most "Kerbal Rocket" and create a giant behemoth that by my *guess* will probably make it to space Do trial and error by cheating Get it right by copying an existing design from the forum Go back to my days of calculator usage, calculate the dV of 3 stages by hand None of these is fun for me. Option 1) just isn't my style, and it's not even a guarantee that it will work. Option 2) feels cheaty, and also doesn't work very well. 3) is plain lame, and I'm just too old to do 4), I have moved past this years ago, and it's way too much work for a game meant for recreation. So what now? I'm usually a critic of statements like "this mod should be stock", but I'm coming to realize that the game really, really needs a Delta-V and TWR readout. What are your thoughts about this? How do you deal with building rockets without KER/MechJeb? ps.: inb4 "Just install KER/MechJeb": I know I can do that, and probably will. But in this thread I want to talk about the *Stock* experience that the game provides and that the developers intended.

I have this monstrosity I've constructed a couple of times now. First by four Kerbal-X rocket launches, and later by three cargo SSTO trips. Since this first iteration, I've removed the Mk1 inline cockpit and added three more Liquid Fuel tanks. I also removed a little bit of mass here and there, used smaller parts where I could, and lightened the load as much as I could while still being reasonably comfortable to a six-kerbal crew. Aside from KER, I have DMagic's EVA Struts in use. If I just cheat this monster into orbit, I get slightly more than 3500 m/s according to KER's estimate. Enough for Duna and back. If I launch it as intended, the first module containing the Mk1 crew cabin and engines will have in excess of 7200 m/s. But then I start piling on modules, and the estimated delta-v doesn't seem to change once it's fully assembled. I have one of these out at Duna in a career play-through that has slightly less than half of its fuel, and has landed the rover package on Duna's surface. Yet KER thinks I still have 3700 m/s. First off, the Iktomi II, in Duna orbit, has 257 parts, 56.57 tonnes, and 1866 / 4800 Liquid Fuel. This is the ship that already dropped off its rover kit. Supposedly I have over 3700 m/s. Assuming one unit LF = 5 kg, that's 9.330 t fuel, making dry mass 47.34 t and dV = 1397 m/s. Enough to get home, barely, if I'm careful with Ike and Mun assists, or I could dump a lot of hardware first. Second, the Defrahnz, in Kerbin orbit, is prepared for departure to Eve. This has 306 parts, 75.92 tonnes, and is fully fueled at 4800 / 4800 Liquid Fuel. Supposedly I have just over 7400 m/s, but in reality with 24 t fuel I have only 2980 m/s. At least this craft could reach Gilly and land on RCS alone, and refuel. Is KER not taking into account the added mass of modules as I assemble this thing? Have I missed a setting somewhere?

For just about every journeys there are questions that need to be made. Just about all of us have taken off from Kerbin with 10k dV in the Moho's orbital direction and finding out, when we go close to Moho that we did not have enough fuel left to circularize (or some other nice oversight like pointing the solar panel in the direction of the sun for 6 months). Can we sit down with a spreadsheet and make decisions that factor the choices that are presented. I decided to basically write these posts because of the eccentricity thread in order to illustrate what the real value of eccentricity is when all is said and done. To make the answer short, energy is much more important, but eccentricity gives us on the fly information. For example if you are circularizing from an eccentric orbit close to Pe or Apo (whichever is the burn point) and your delta-e/t is too low compared to time to pe/apo, this informs you that you need to increase thrust or should have carried a more powerful engine. Another situation is during reentry from distal targets, the delta-e/t tells you how rapidly or effective your entry-theta was. If your ship is overheating and your e is not likely to approach zero at some point during reentry then you probably should have used a bigger shield(or kept some retro fuel) and choosen a steeper entry angle (lower no-ATM Pe). The eccentricity argument has an effective range of 0.0005 to 1.0000 below or above which are meaningless in the game. In this case an eccentricty of 0.5 = 0.4995 to 0.5005. This differs from other stats such as dV which are accurate over a 100,000 fold range in the game, altitudes are accurate to >10 decimal places. IOW, the values used to derive e are much more precise than e itself. Does it make a difference, yes and no, theoretically if you had a TWR = infinity, an exactly angle to prograde for a perfect burn (with perfect thruster control) there is no wasted dV and you end up intersecting the minimum orbit of the target planet. In reality the dV calculated at best puts the craft in a range were RCS thrusters in the departure orbit can be used to get within about 5000 meters of the perfect arrival orbit (on a good day). However knowing energy makes some logical sense of what is going on, for example by the Oberth effect works, why burn from low orbit, why use kicks on lowTWR craft in low orbits (versus spiralling away from the celestial). When we are using e for on-the-fly decision making accuracy is not really an issue, however in the formulation of travel strategies we do want to use as accurate as possible starting information. So what about everything else? The procedure is this. Step one. For a target planet orbital ap _and_ pe (meaning two parallel analyses), assign a departure and arrival altitudes relative to kerbol, transform to radius, derive a. Step two. Assign u/a (Escape energy) and u/2a (SKE at a) Step three. Assign SPE changes from kerbin-to-a and from a-to-target. Step four. Assign deltaSPE changes (changes in Kinetic energy) from a to kerbin or target. Step five. Calculate SKE at kerbin or target. Step six. determine dV required to achieve kerbin or target orbits without entering kerbin or targets SOI. Step seven. determine the SKE at planets SOI entry or exit based on step six. Step eight. Add this to planets minimum orbit radius escape energy, this give energy to reach minimum orbit around the planet and free fall to planet. Step nine. Convert this to dV required to free fall from minimum stable orbit Step ten. Subtract the circular orbital velocity from freefall at minimum orbit dV requirement. Step eleven. Add the two dV (kerbin and target planet) together and get total dV. At 6 specific points in the 11 step process unique energy parameters were used to derive decision making information. The table below compares the Total dV (m/s) cost of intersecting orbits (values rounded for clarity) and also compares to inclination dV performed in circumkerbol orbit. Planet Target Intrcpt δV inclination at Apo at Pe dV at a Moho 4724 4001 723.1 1818 (Depart from Kerbin at the Kerbin-Moho inclination node closest to Moho's Apo, inclination nodes are priorities) Eve 2911 2913 002 400 (Eve's orbital inclination nodes are priority) Duna 1928 3009 1081 78 (Depart from Kerbin close to Duna's Pe) Dres 2819 4837 2081 466 (Depart from kerbin closest to Dres's Pe, inclination nodes should be also considered) Jool 5202 5686 484.0 79 (more analysis of satellites requires) Eeloo 3416 3449 32.7 386 (Eeloo's orbital inclination nodes are the priority). As we can see above the analysis is devoid of any consideration of the e parameter, although it is easily obtained from the information we have. How can we get those pesky inclination nodes. One way is to place a satellite in a Kerbinesce orbit at theta = 2/3 pi and 4/3 pi relative to kerbin (in the same orbit as Kerbin but at maximum distance. Then target a planet, the nodes will show up also relative to kerbin. Such satellites can have a dual function since one can also place a deep space array on the satellite. That allows communication to objects that current orbit is on the other side of Kerbol. [Another set of energy and dV calculations that involve the equation The square of the orbital period of a planet is proportional to the cube of the semi-major axis of its orbit. in which we create an orbit a which is 2/3 or 4/3 the period of kerbin by generating a periapsis or apoapsis (respectively) whose average with kerbin orbit gives us a]. Disclaimers. Above assumes two sets of reciprocal process, launch/ascent & descent/land and transfer commence and complete that have a boundary at the minimum stable orbit of both planets. 1. There is a simpler mechanic, single step "star trek" mechanic, in which your ship has so much power that you travel from departure x,y,z, vx, vy, vz to arrival x, y, z, vx, vy, vz before either of which have significantly changed position (arrival point and departure points are oriented to each other). Given that human life could never survive the dV/dt and the dV & TWR required do not exist this scenario can be disregarded and physically impossible and should not be considered. Deep space probes such as New Horizons need not depart into a circular orbit. That if they reach an angle to prograde of theta>090' while still in upper atmosphere while at the same time burning the dV required for a highly eccentric orbit does not require circularization and may use less dV. In such a burn the base assumption is that the best delta-SKE on hill sphere exit is obtained from the lowest altitude burn even if that burn starts at a suborbital trajectory with pe always below safe circular orbit altitude. To convert this to KSP the ascent angle is say inclination is at >15' and you are at alt=45 you simply can burn to Eeloo Apo intersect as you are crossing some theta~90 and have a large plume of overheated gas momentarily burning through the fairings before they are deployed. 2. KSP provides perfect examples, kerbin is in a zero inclination, zero eccentricity orbit about kerbol and as it so happens it common departure planet or arrival planet for most of the transfers. The argument of periapsis differs for all other planets so you are not going to be able to match a Apo/Pe angle of a planetary departure with 180 degree Pe/Apo of a planetary arrival except from Kerbin because kerbins orbit a=Pe=Apo. This has some relevance for the Eeloo, Jool transfer which is damn cheap relative to traveling back to kerbin and traveling to Jool (given some dV spent on plane matching). 3. The smallest-sweep area stable orbit about a planet may be unpreferential. Jool being the example. This infers there is complex decision making involved in getting to a system moon in which the planet is not the target. mechanical thermodynamics can be used to burn less than the amount needed to circularize at the planets rMin, that dV would be used to circularize at an apo that intersects the moons orbit. In the case of Jool, all three inner planets have a=pe=apo, so this is not too much of a problem. In these instances you want to compare intersecting the moons orbit directly (using a different planetary Rx,orbit) versus a hohmann transfer to 200k Jool-altitude and a partial circularization burn to intersect the target orbit and circularize. 4. If we make the assumption that inclination nodes are approximate to r = a (semi-major axis), that the dV required for inclination burn (see table) is low enough not to be a priority. In these cases we can, if we desire burn at a bearing above or below the departure planets equitorial plane on depart to send the inclination node to r = a and get rid of some inclination. In comparing the table below the difference between an Kerbin-Moho transfer Pe-target and Apo-target is delta-dV = 724 but the inclination change dV averages at 1814. Therefore its simply intelligent to set a priority on changing planes over departing theta = Moho's apo theta (fortunately Moho-apo is relatively close to the inclination node). The cost of changing inclination at kerbol is reduced by 100s of dV. The same logic is also true for Eve, and Eeloo. For the other planets a departure window closest to the target planets periapsis is a better choice than choosing a departure window closest to an inclination node. 5. Entry burns particularly on planets like Jool need transfers that seldomly overlap with their pe or Apo, consequently there is a triangulation between time to get good window for efficient inclination change, or close to Jool theta. In other instances like Moho, which is so small oberth effect is minimal, free burn times at pe near a kerbin inclination node is going to occur separately than the moho circularization burn. 6. Depending of kerbol relative altitude of the target the true burn altitude is different from the planets altitude. Our burn starts 670,000 meters closer but a maximum efficiency burns leaves kerbin's SOI at the moment of crafts circumkerbol Apo or Pe (depending on an interior or exterior target). We always want the exit trajectory to be parallel to kerbins path of travel even if the line is not identical with Kerbin, otherwise predicting intercept could be off and correcting dV would be required. This occurs both on kerbin exit and on target arrival. For example a the flat part of the escape curve to moho should generally be at a final angle to prograde ever so slightly more than 180 at kerbin SOI otherwise the Apo for the circumkerbol orbit will occur in the future. This means that the numbers for apo and pe differ slightly relative to the calculation. If the target was exactly one SOI in front or behind Kerbin, the difference would be zero, on an interstellar trajectory that the difference is nominal, from Kerbin 670,000 radius is 0.99995 that of the calculated. On such a trajectory 670000 = 85000000 sin theta, translates to an angle to prograde of is 180.45'.