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

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

Community Delta-V Map 2.6 - KSP 1.3 View full size PDF versions (A4 & Letter) KSPedia Version (v2.6) Lights-out Theme (v2.4.1) (Thanks @Siege /u/s13g3!) Outer Planets Mod adaptation: By Swashlebucky; original by Misucat and his wife PDF version (v2.4.1) OPM - Lights-out Theme (v2.4.1) (Thanks @Siege /u/s13g3!) OPM - KSPedia Version (v2.4.1) (Thanks @AlexSheFF!) Changelog GitHub Check it for development, pull requests and other maps. All required tools for map editing are referenced there. How do I use it? It's simple! 1. Pick a planetoid you wish to visit. 2. From your initial position, add up the numbers between every checkpoint until you reach your desired checkpoint. 3. The total is the general Delta-V value needed to reach your destination. Example: - Kerbin surface -> Duna Surface 3400+950+130+10+250+360+1450 = 6550* *Aerobraking can reduce the needed dV to almost zero. Using it would result in the following: 3200+950+130+10 = 4490. - Eeloo Surface -> Kerbin SOI 620+1370+1140*+1330* = 4460 *Aerobraking can reduce this number to almost zero. *Numbers outside the stripes are the maximum dV needed to change between planets inclinations. Pay attention to them! Elliptical or Low Orbit? What's the difference? A Low orbit assumes a circular orbit 10km above the nearest obstacle/atmosphere. Elliptical orbits have the Periapsis at Low Orbit altitude and the Apoapsis at the planet's SOI edge. I added the Elliptical orbit checkpoint for two reasons: 1. It shows you the required dV needed to get your vessel grabbed into the planet's SOI, disregarding the value needed to circularize on a low orbit. 1a. It assumes you have set your encounter to the lowest periapsis possible, during the encounter maneuver. 2. If your destination isn't the planet, but instead, its moons, you don't need to count the whole dV needed to circularize around the planet's low orbit, since you won't use that. Instead, a simple capture/elliptical orbit is enough to transfer to a moon. That way, you can reduce the needed dV for a trip drastically. I hope this helps. Enjoy! License This work is licensed under CC BY-NC-SA 4.0. You are permitted to use, copy and redistribute the work as-is. You may remix your own derivatives (edit values, design, etc.) and release them under your own name. You may not use the material for any commercial purposes. You must use the same license as the original work. You must credit the following people when publishing your derivatives in the material: JellyCubes (Original concept) WAC (Original design) CuriousMetaphor (Original vacuum numbers) Armisael (Additional vacuum numbers) Kowgan (Design, original atmospheric numbers) Swashlebucky (Design) AlexMoon (Time of flight) Official Wiki (Relay Antenna calculations) -- This was originally a continuation from WAC's Delta-V Map from KSP 0.23. Since then, a lot of people (credits above + advice from people in this thread and over the internet) have contributed to improve this chart and keep it up-to-date with the latest KSP version. I am very thankful to all those who helped make this chart possible. Seriously, thank you guys.

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

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.

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?

Jool 5 Delta-v Chart NOTE: This is based off of my flown mission but can be used to plan other missions to Jool. This chart is nowhere near perfect, but it should give you an idea of what to do or how much to build. I know circularization is not a word but I am trying, I am meaning it as making you orbit less eccentric. If you have any questions please ask me or someone else in the Jool 5 Challenge's main page listed here... The Chart Itself Action Rough Delta-v Requirement (meters per second) Launch to LKO (Inefficient launch) 3000 LKO -> Jool Transfer 2000 Jool Capture (moon assist) to Low Laythe Orbit This can range ALOT but I managed to do it with around 1500 Low Laythe Orbit -> Low Tylo Orbit Transfer 1400 Low Tylo Orbit -> Vall 800 Vall Capture 415 Low Vall Orbit -> Pol 800 Pol Capture 500- Including low Pol orbit circlularization Low Pol Orbit -> Bop 200 Bop Capture 190- including circularization Bop to 79,000 kilometer Jool parking orbit 660 Jool-> Low Kerbin Orbit 4110 FOR THOSE WHO MIGHT BASE A MISSION OFF THIS CHART - Do not base a mission only off of this chart, this does not include landing amounts yet - If I were you I would ensure that you have more delta-v that I have shown to be safe, especially for Jool capture as the moons are not always lined up to help you - I am basing all these values off my submission to the challenge (shown below).

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?

Space - the Kerbal playground. These are the voyages of a rescue space program. It's noble mission: to explore recently visited worlds, to seek out new science and new anomalies, to boldly rescue every kerb who tries to go where they haven't gone before - and fails. Recover Obemy and His Debris from Low Sun Orbit I posted this in the "Self imposed KSP rules. Things we do that make things more difficult." thread: So, of course, a few days ago I pop into Mission Control and accept a rescue mission... The words "low Sun orbit" seemed very ominous. In the tracking station I saw this.... Other than a string of expletives, I was at a loss for words. How would you approach this? Happy landings!

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