Jump to content

Search the Community

Showing results for tags 'maneuver node'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • General
    • Announcements
    • Welcome Aboard
  • Kerbal Space Program 2
    • KSP 2 Discussion
    • KSP 2 Suggestions & Development Discussion
    • KSP 2 Dev Diaries
    • Show and Tell
  • Kerbal Space Program
    • The Daily Kerbal
    • KSP Discussion
    • KSP Suggestions & Development Discussion
    • Challenges & Mission ideas
    • The Spacecraft Exchange
    • KSP Fan Works
  • Community
    • Player Spotlight
    • Science & Spaceflight
    • Kerbal Network
    • The Lounge
  • Gameplay and Technical Support
    • Gameplay Questions and Tutorials
    • Technical Support (PC, unmodded installs)
    • Technical Support (PC, modded installs)
    • Technical Support (Console)
  • Add-ons
    • Add-on Discussions
    • Add-on Releases
    • Add-on Development
  • Making History Expansion
    • Making History Missions
    • Making History Discussion
    • Making History Support
  • Breaking Ground Expansion
    • Breaking Ground Discussion
    • Breaking Ground Support
  • International
    • International
  • KerbalEDU Forums
    • KerbalEDU
    • KerbalEDU Website

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start



Website URL



About me



Found 14 results

  1. 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?
  2. 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!
  3. 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
  4. 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?
  5. 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
  6. 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!
  7. 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
  8. 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?
  9. 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:
  10. 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.
  11. 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...
  12. 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?
  13. 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.
  14. 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.
  • Create New...