Search the Community

I would like to know what people are likely to prefer to see in-game when "Jool orbit capture-burn" is 4 years, 23 days, 5 hours, 12 minutes, and 17 seconds away, do you want the game to show the largest 2-3 items in the Maneuvre Planner? The smallest? 4Y:23D:5H 5H:12M:17S Other? Personally, I would prefer the first option; show me a less-precise (but “more complete”) time rather than telling me my 3200 m/s dV ion-stage will “only” last for 25 minutes and 43 seconds (as that staging-menu seems limited to 'two values'), please tell me instead I’m good for 1d:5h (then adjust/scale to 5h:59m when under 1 day and then 'down' to 59m:59s when under an hour) List of 'times' shown in-game (not necessarily exhaustive): Time for stage to consume all propellant Time until start of planned burn Planned burn's duration Time to next Ap/Pe (Ex: stage propellant-consumption duration seems to only show minutes & seconds, which can make gigantic Xenon/ion engines look like “45 minutes to run out” whereas you likely have days of available thrust) But what are yall's thoughts?

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

as i was going to make a maneuver node, i looked at my navball and noticed that my craft was severely off course. when i went back to game view, i had to turn off and on RCS and SAS. I think SAS and RCS are disabled when you go in map view. to fix this, i tried to pause the game when I went in to map to make a maneuver node. This is another bug, where i cant make a maneuver node while paused. I also have a visual bug. My HUD keeps fliskering as if it is trying to be transparent but failing. please fix this in 0.4

KSP Version 0.1.1.0.21572 Operating System Windows 10 Got a vessel that uses xenon engines in an normal orbit around kerbin and when adding a maneuver node then adding some prograde to it looks like the the trajectory can't calculate it an turns into strange collision course. Don't know whether its the vessel as its using 4 xenon engines and a lot of xenon or it thinks it has over 27k deltaV, that it can't path a normal route out? Took a pic: Wanted to flag it up, can still carry though, just manually plotting a course and doing it by eye should work, in theory

I don't know if I'm the odd one here, but I think the old maneuver node was better. While the new one seems to be more usable (and even that is debatable), it's less aesthetically pleasing, seems unfinished and resemble a dev tool (also it's too aliased): The old one was, in my opinion, better at least from an artistic view. The only downside that I can see is that icons (prograde, retrograde...) were too small (and maybe the arrow needed to be a bit smaller, but not as small as the new one):

The updated maneuver node following the 0.1.1.0 patch no longer works. Dragging prograde on the node eventually stops extending the orbit line. This typically occurs during an ascent of a planet. Creating a maneuver node at the apoapsis of the parabola as a ship is ascending ceases to function properly. In addition, there is no longer a 'next orbit' button, and visually the older maneuver node looked much better.

Issue: Distance of closest approach constantly changes during orbit. Notes: If you have one vessel focused, the closest approach distance will constantly increase. If you focus the other, the distance will constantly decrease. If you time warp, the distance will freeze. Long description: When trying to do a Munar Orbit Rendezvous on a mission. I had to make multiple attempts to get a closest approach lined up since everytime I would get near, my vessels would all of a sudden miss each other by thousands of kilometers. Playing around with this, I set up a bunch of maneuver nodes and got a closest approach of 250m. I took some screencaps and then noted that my approach distaance was now about 2500m.

Maneuver nodes would be more accurate and precise if we can create them on point to the Apoapsis or Periapsis of the orbit. And/or Maybe a maneuver node where you can type in on what altitude the maneuver node will be created which would be useful in many unimaginable ways. Thanks!

The maneuver node / burn timer isn't calculating burns correctly. Anyone else seeing this? I did my trans-Mun injection burn, and it was way short, had to keep burning for a minute or so after the node said I was done. This is game breaking as far as I'm concerned. I mean, I liked the early days of KSP where you figured all this out with the Hohmann transfer equation and a calculator, but that's not the game KSP2 was supposed to be. I'm just so disappointed today with the state of KSP2, between this stuff and the VAB. I knew it would just be the basic sandbox, but I expected a good sandbox. Heartbreaking.

Hey there, In map view, hover mouse cursor over PE (or AP) of your current or any other vessel orbit - no argument of PE \ AP shown, this is ridiculous when planning an orbit via maneuver node dragging, screenshot follows:

In KSP 1 you can pin the periapsis and apoapsis of the resulting orbit of a maneuver node. You can not do this in KSP 2 and so you can't do it accurately. While you can hover over the nodes and get the altitude while the node is not in edit mode, you can not do this in edit mode.

Below are several area of planning a Spacecraft Trajectory that will benefit if maneuver nodes do take into account atmospheric friction! Landing Prediction on an atmospheric planet More complex aerobraking maneuver Etc (Reply down bellow if you have more ideas!) I will be mostly talking about aerobraking because this feature would help a lot on planning aerobraking maneuver, such as better fuel economy because if you can see where your spacecraft might be going after an aerobrake, it would be very helpful if lets say you want to intercept Laythe after slowing down massively in Jool's atmosphere, i find this to be very tricky in KSP 1, I had several mods to help me but even still its a bit finicky. I understand that this feature might be difficult to incorporate into the game considering the prediction wont be 100% accurate and can be affected by many factor during the aerobraking, here are examples of several factor I could think off that might throw off the prediction Angle of attack during the aerobraking maneuver Parts getting blown off causing a slight change in the vessel's aerodynamic characteristic Etc (Reply down bellow if you can think off more affecting factors!) I have no idea how difficult a game development is, so I don't know if these feature are even possible to incorporate nicely into the game but if this feature is going to be added into the game even if its much later, it will still be a very nice addition into the game P.S. It would be awesome to recreate some shots of the Leonov aerobraking maneuver from 2010: The Year We Make Contact in KSP2 with some beautiful atmospheric friction effects

So long story short, I ended up in this really wacky elliptical orbit and I'm trying to rendezvous with my space station in a polar orbit around the Mun. Here's some screenshots: https://imgur.com/a/UP4n12P. I'm creating a maneuver at the relative ascending node with the goal of lowering my orbit so that the burn location becomes the apoapsis, the periapsis becomes 30km (where the polar station is), and the relative inclination is 0. Naturally this involves burning in a combination of all three axes. It's pretty easy to get a very rough burn set up by eye, but refining it is a real pain. The main issue is that I can only edit the burn in the coordinate system of my current orbit, which is completely misaligned from the coordinate system of my target orbit. For example, to adjust the periapsis the best I can do is use anti-normal since its the closest to the prograde direction of the target orbit. However, this is far from ideal since it also adds velocity in the radial out direction (which messes up my apoapsis location) and the anti-normal direction (which messes up my relative inclination) in the target orbit coordinate system. What I end up doing is going in circles fixing the relative inclination, periapsis altitude, and apoapsis altitude one after another until I slowly converge to the optimal burn. I've run into this exact issue several times now, and its always a bit annoying. From what I can tell, the optimal solution would be a toggle that allows you to switch to editing the burn in the target coordinate system. This would mean that the directional indicators would rotate dynamically as you add velocity in the various directions. Has anyone else run into this? Any mods/general tips for making the process easier?

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?

I had a realization that if we can vary the yield on the orion drives, then we can precisely add the exact delta-v at the maneuver node. No more trying to evenly split the burn time around it!

There's some things I find particularly annoying about maneuver nodes that should be pretty easy to fix The game should remember what points in the maneuver node you've clicked. Often times when playing around maneuver nodes you end up intersecting a body you don't want or getting too far for an encounter so apoapsis, ascending/nodes, intersections, nearest encounters often times disappear and when you fix it they're no longer highlighted so I need to right click them over and over again. Show entering SOI point of parenting body. When doing 3-star training missions I need to be guessing where the ship will be when leaving kerbin's SOI by trial and error until I find a point that says it's less than a year away. Proritize orbit of current body. If you've done many rescue missions in low kerbin orbit you probably have a whole bunch of stuff around there, that makes it pretty annoying to operate a ship as you try to add a maneuver node and instead it shows the dialog to switch to another object

With the 1.7 update, we got the extra pane on the map screen to see more and fine tune maneuver node information and etc. I really love it! However, when planning multiple maneuvers (or trying to plan ahead) why can't we see a total Delta V number for all planned Maneuver Nodes? Also, what about having the delta v for each upcoming node appear separately near the Navball in addition to just the one upcoming node?

Hello everyone, after a few months I have recently started playing KSP again and for the first time I have now decided to deal with interplanetary spaceflight that goes beyond Eve and Duna. For that I now first used the Nerv engines as they are so efficient. I have built a few in my opinion quite nice spacecrafts after watching many videos on youtube and I successfully landed on Dres and even Moho already (without returning though). However during these missions and also my current mission to Moho with a new or modified spacecraft I ran into a problem that didn't seem to occur in the videos I've seen. I don't know if it's somehow caused by the Nerv engines or whatever but whenever I set a maneuver, no matter how big it is, the curved Delta v bar to the right of the navball is completely or half red and the estimated burn time is completely wrong aswell. When I start my burns at about half the time to the maneuver as the estimated burn time so that the burn splits into 2 equal sections before and after the maneuver node, my resulting orbit is quickly WAY off the planned one. I didn't find out how to add screenshots but my burn is about 600 delta v and I have about 7000 with my current spacecraft. Does anyone know what's the reason for this .... bug? This way I can't go to Moho or at least it's never as efficient as in the videos I've watched.... annoying

Hi. I have a problem. Whenever I make a maneuver node, its delta-v requirements slowly change. This makes it impossible to accurately use the nodes. Here are some screenshots to show what is happening. There is no rcs/sas/engines running. The node does not change during timewarp, so it must be a physics issue. The predicted apopsis after the maneuver does not change. How can I stop this from happening? (if the embedded album does not work, here is a link: http://imgur.com/a/pHNpx). Thanks!

Hey all, After getting back into KSP recently and going nuts launching ships left and right in career mode I soon found myself desperate for a way to quickly pick out the ships in the Tracking Station that needed my attention next. I saw a couple of other users requesting this feature over the years and some disappointment when the latest update didn't have it. So I decided to try my hand at an add on. Here it is. It's a little thing, but it saves me some sanity, of which I have little to spare. I hope some of you will find it useful! ManeuverQueue ManeuverQueue is an add on that allows you to sort and filter objects displayed in the Tracking Station list. It was developed and tested against KSP v1.1.3 and v1.2 Installation Github: https://github.com/FatHand/ManeuverQueue/releases Curse: https://kerbal.curseforge.com/projects/ksp-maneuverqueue Make sure to get the correct archive for your version of KSP (1.1.3 or 1.2) add the contents of the archive to your KSP GameData folder. Usage When the add on is installed you will see a small toolbar at the top left of the Tracking Station. Switching modes will sort and filter the list in the tracking station. MET - Shows the default Tracking Station list MNV - Shows only those ships with maneuvers nodes - Sorts ships by next maneuver node time, earliest first - Ships with maneuver node times in the past will appear at the top of the list - A ship is only listed once even if it has multiple maneuver nodes - Color coding - Yellow - Two ships' next maneuver nodes are less than 15m apart - A ship's next maneuver node is less than 15m away - Red - The ship's next maneuver node is in the past A-Z - Shows the default list, sorted alphabetically Time Warp - Time warp will slow to 1x when a maneuver node is 15m away. Very high speed warps can lag up to a few minutes when slowing Vessel Type Filters - Switching to MNV mode will unset all vessel type filters. Returning to MET or A-Z mode will restore filters set in those modes. Known Issues - Linux is not supported - Certain tracking station operations such as untracking an object, terminating a vessel, or switching vessel filters causes the list to flicker momentarily Changes in this version - Fixes an issue that caused the list to reset to MNV when terminating a vessel

Many people point to this post from Red Iron Crown as a good way to time suicide burns - I'm not understanding something though. If I'm in orbit and set a maneuver node over the point of impact, when I drag retrograde the Ap doesn't hit the surface. Wherever the Ap started in the orbit, it winds up directly over the point of impact, but will never touch the surface. My "orbit" would drop straight down onto the surface when my retrograde burn exactly matches my orbital velocity. But that doesn't seem like a safe landing since it's not leaving anything to cancel the speed gained by falling. What am I missing?

I have decided to discontinue this mod - as great as its name is - due to the far superior DMagic Modlet Maneuver Node Evolved. This should still work at least during the 1.2.x cycle, but I won't be updating it. It's open source, so if anybody wants to they can take over the mod. Buttons to drop a maneuver node at orbital milestones DOWNLOAD: SpaceDock GitHub SOURCE: https://github.com/5thHorseman/DropAManeuverNode LICENSE: MIT ATTRIBUTION: This project uses Stock Toolbar integration code from KSPCasher https://github.com/armazac/kspcasher CHANGELOG: 0.2: UI "overhaul" so it's not quite so ugly. More to come. Buttons grouped in 3 sections Window locked in place near Toolbar button (actually, where the mouse was) to simulate it being a menu. An/Dn placement (Thanks DMagic, Kerbal Engineer, and random Reddit dude), both absolute and relative to target. 0.1.2: Bugfix. There were multiple toolbar buttons that kept growing, and only the last worked. 0.1.1: Bugfix. I had some "==" where I should have had "!=" 0.1: Initial build. Stock Toolbar support. Buttons to add a maneuver node at certain orbital milestones. BUGS: You can use this mod to drop maneuver nodes even when you have no CommNet connection to Kerbin. You still can't edit those nodes, so I don't think it's that critical of a bug. Also, I have no idea how to fix it TO DO: Save/load settings, if necessary. Blizzy's Toolbar support. Detect when things are not available (like no Ap due to escape) and disable the appropriate button. Detect when a maneuver node is already present at a location (Within a few seconds?) and disable the appropriate button. Detect encounters with targets. Not sure how to handle this, because you generally don't want the node AT the encounter. Maybe X (settable) minutes before it? Better UI "Modify Current Node" button or mode. Look forward past SOI changes, allow to set nodes on future trajectories. Look forward past other Maneuver nodes, allow to set nodes on future projected paths. Allow both of the above at the same time. Basic thrust options like "circularize" or "match tilt" or "kill velocity" "Undo" (may be difficult or impossible) Automation options, like "place a circularization burn at Ap whenever you leave atmosphere." DONATIONS I do not need donations, but if you want to contribute, please donate to SpaceDock:

There's something that has bugged me about maneuver nodes for a while. In fact since I got into maneuver nodes more, I've enjoyed the game more, and they're really cool. And since I'm in the middle of an 18-minute nuke burn to Moho, I thought I'd post this. If you make a maneuver node, and edit it, you can of course grab the prograde, retrograde handles,or whatever handle, and adjust the burn. OK, I get that. And if you pull the handle out further, the amount of the burn will accelerate faster. That is, close to the middle, it increases the burn very little, but if you drag it all the way out, then within seconds you've created a burn that will intersect the nearest black hole. Close to the middle of the handle, very little change, further out (or in), much more change. That's all fine. Here's the problem: You can also do fine adjustments to the node by using the mouse wheel. Move your cursor over the desired direction (prograde, retrograde, whatever) and roll the mouse wheel. Fine idea, but there is something weird about it. If you scroll slowly, you can make fine adjustments, but if you scroll faster, it seems to have some kind of acceleration applied. Slow scroll will increment, say, 2 or 3 m/s per "click" (not mouse click, wheel click, the click your wheel makes, you know), but if you scroll faster, it increases to something like 10-50 m/s per click, or even hundreds of m/s per click. And frankly, it drives me nuts. In fact it's worse than that. Sometimes you scroll one way and it really increases the burn, then you try to correct back the other way with the wheel, and it doesn't... it only increases it a small amount, even when you scroll fast. Since the mouse wheel is supposed to be for fine tuning the burn, it should not have this acceleration applied. One "click" should always be a small, consistent amount of change. Have I explained this adequately? I hope so. Let me know if you have any questions.

So I have a ship on escape out of Kerbin with a Duna encounter in 295d. Great. The encounter track is such that I could easily capture into a polar orbit of Duna. Not great; this probe is bound for an Ike touchdown. No problem. 295d away means the dV to fix this should be hilariously cheap. I plop a node down a little ways out from my probe. (It spawns with 35dV for some reason, I'm not sure why but whatever. That's within my budget.) I start mouse-wheeling on various parts of it to see what effect it will have on the encounter periapsis... none. After about ten minutes of this, I yank REAL hard on various bits trying to provoke ANY reaction out of the encounter periapsis. The orbit goes crazy... but the encounter track remains entirely unmoved.... o.O I decide the encounter might be an error in the tracking and advance time to see if the encounter is real... and that's when I realize that I can slap nodes on the purple orbit, but not the blue one. (The purple orbit is my Kerbol orbit AFTER the encounter.) Nothing I do seems to let me add a node to the track I'm CURRENTLY on. Is there a hotkey for this? Am I just missing with the mouse? I don't even get a mouse-over indication that my current trajectory is interactable...

playing on Xbox and I've got multiple maneuver nodes in place and when I try to delay the first node, it moves the node to a completely different place and messes up all my other nodes. Am I doing something wrong or is this a bug? And if I am doing something wrong, could you explain what I should be doing instead?