Search the Community

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?

Sending an ISRU to Vall because AGAIN I have completely underestimated the fuel it takes to get to Laythe and back. I think I saved about 1000 D/V with this slingshot maneuver. This save I have decided not to use MechJeb, only Engineering Redux (I consider the ability to calculate D/V absolutely essential to playing the game). I have MJ installed, but only because some of my old craft from other saves have MJ modules on them and I can't load them unless it's installed. I actually hardly ever used maneuver nodes before, but now that I understand them better, they're a lot of fun to play with.

Hi everyone, I'm just posting here out of frustration that nobody seems to take bug reports about the illogical behavior of maneuver nodes seriously. They get downgraded to "feedback" and low priority, even with the explicit mention that this is unlikely to be changed since it doesn't break the game and users seem to manage just fine. The problem is as follows: When you add a perpendicular input (normal or radial) to a maneuver node, the handles rotate to align with the new trajectory. However, their effect is still relative to the old reference frame which creates a very counterintuitive experience. Rotating the maneuver node handles is simply wrong. They don't act in that direction, so why make it seem so? Is there any vaid reason for prefering this behavior over the much more logical alternative that keeps the node aligned with the original trajectory? Example scenario: - User is in an equatorial orbit (let's call it "horizontal") and wants to transition to a polar orbit - User pulls the "normal" handle (triangle) - The post-maneuver trajectory rotates around until it approaches vertical - Meanwhile , the triangle handle rotates and approaches horizontal. It is pointing exactly in the direction where the user wants to pull the trajectory to reach a polar orbit. - So the user pulls the normal handle some more, but the trajectory does not move in that direction, it just stretches out further upwards - User visits the forums for help - Someone points out that he needs to add retrograde - User is confused, because the retrograde handle is pointing downwards. He tries it anyway, and low and behold, it works, who would have thunk? Must be some weird mathematical reason behind it, orbital mechanics are apparently really complicated and counterintuitive, you probably need a degree in mathematics to figure it out so better just move on to a simpler game. Now compare this with the correct behavior that nodes should have: - User is in an equatorial orbit ("horizontal") and wants to transition to a polar orbit - User pulls the "normal" handle (triangle) - The post-maneuver trajectory rotates around until it approaches vertical, but the node stays put - User sees that he needs to twist the trajectory sideways now to get towards the pole. The retrograde handle is pointing in that direction, so he pulls it. - Great, the node performs the correction exactly as expected. See, orbital mechanics are easy, this is a fun game! So, once again, why would anyone prefer the former behavior? I've really been thinking about this long and hard, and can't find a single reason, not even a small one, for rotating the node. The more I think about it, the more flabbergasting it seems. Why would anyone prefer the current behavior? It makes absolutely no sense. I know that there are mods to correct this, but that's no reason for stock to be so wrong.