Maneuver Node Maneuver Node Broken - Anyone Else Seeing This?

[Bej Kerman]

15 minutes ago, JoeSchmuckatelli said:

Hey thanks - but I haven't grasped the intuitive part yet. 

I just think in hindsight how weird it is that we've just sort of... accepted that the maneuver was put in the middle of the burn.

16 minutes ago, JoeSchmuckatelli said:

Let me explain where I am coming from and maybe you can help me make the necessary paradigm shift! 

I'm not sure how I can explain it. I just think it's more intuitive and more flexible that the maneuver marks where your old orbit ends.

17 minutes ago, JoeSchmuckatelli said:

The advertised improved node for KSP2 (as I understand it) is that you are supposed to be able to rely on the timer, to start the burn at zero and then stop when it says to.  Every burn I've done like this fails to result in what I've hoped to accomplish.  So, either there is something wrong with the burn timer/node - or my understanding is way off. 

19 minutes ago, JoeSchmuckatelli said:

Case in point - after manually getting a circular orbit, I spent a bunch of time fiddling with the maneuver node to get an Intercept with Minmus and finally with a good solution ran the burn as the timer told me to.  Ended up with a Kerbin SOI escape velocity.  Took several tries and some manual fudging (based on KSP experience) to resolve the problem and actually get a capture.  Then that node, instead of giving me a PE at around the altitude planned gave me an impact path.  Each time I have been able to manually fix it - but only because I have so many hours in KSP. 

With no details to go off of, I can't know what your doing wrong or if your game is bugged. I can only say that, on my end, I end up almost exactly on the orbit I planned. If you really need help, you could probably post a video of you doing your maneuvers to the support forums, then we can see what's going wrong.

 

[JoeSchmuckatelli]

1 minute ago, Bej Kerman said:

ith no details to go off of, I can't know what your doing wrong or if your game is bugged. I can only say that, on my end, I end up almost exactly on the orbit I planned. If you really need help, you could probably post a video of you doing your maneuvers to the support forums, then we can see what's going wrong

I might have to do that - but after reading @Draradech 's post above I need to go see if that is the source of my error 

[Bej Kerman]

4 minutes ago, JoeSchmuckatelli said:

I might have to do that - but after reading @Draradech 's post above I need to go see if that is the source of my error 

Yeah, I probably should have mentioned that at some point. A prograde maneuver with an ion engine won't put you on an outward spiral orbit, it'll just crash you into the surface because, on the opposite side of the orbit, what was prograde is now retrograde.

[Bej Kerman]

I've found that closing and opening the map view causes maneuvers to break - midway through a circularisation burn, I found my maneuver putting its into a way higher orbit than I told it to. Worth making sure you don't toggle the map view during burns so that the timer remains accurate.

[Racescort666]

@Draradech @Bej Kerman @JoeSchmuckatelliIt is also worth noting that there is a bug where the  burn timer is reset when switching between map and vessel views. I've been experiencing this as well. 

Also, I would like to throw my hat in the ring  as one of those people who likes to execute burns with scalpel precision but I don't think KSP2 is at a maturity level that can support that yet.

[JoeSchmuckatelli]

1 hour ago, Bej Kerman said:

I've found that closing and opening the map view causes maneuvers to break - midway through a circularisation burn, I found my maneuver putting its into a way higher orbit than I told it to. Worth making sure you don't toggle the map view during burns so that the timer remains accurate.

Yeah, that's gonna be a problem. 

See, like, ya know, I like to watch the animations during the start of the burn and stage separation (if required) with the new engine start.  But most of the time I'm watching map view with persistent (cough) AP/PE numbers.

So, yeah.

[DadJokeCinema]

I've found a decent amount of accuracy on Mun insertion burns (on 4 tries) for starting the burn at 0 on the timer, staying in Map view, and using SAS set to the maneuver target mode.  

[Draradech]

The maneuver reset with map toggle already has multiple reports. The maneuver direction indicator drifting resulting in failed burn with SAS pointed at maneuver is now here:

 

Edited February 26, 2023 by Draradech

[Scarecrow71]

I submitted a bug that's similar in scope to this, but deals more with the outcome of the burn as opposed to the plotted course.

 

[Immabed]

To get back on the original topic, I think we need to all change our understanding of maneuver nodes, the new system is ultimately more intuitive and better at predicting trajectories (current bugs notwithstanding).

In KSP 1, the node assumed instantaneous change in velocity, so in practice it was essentially centred in the burn (though not completely, since decreasing mass as you use fuel mean the second half of the velocity change takes less time). This was simply a workaround for the node's lack of understanding of motion during the burn. In practice, if you start a burn ahead of the node, you never actually pass through the location of the node exactly, as your trajectory is altered ahead of the node, and depending on the burn this could be quite significant. I'm sure many of us can remember instances where our actual trajectory took us a bit into the atmosphere or otherwise did not match the presumed trajectory if you just look at the node itself, particularly when the burn itself was quite long in comparison to the period of the current orbit.

The KSP 2 system takes time under thrust into account, so the node location marks the start of the burn, as that is the only time during the burn that you are actually on the pre-burn trajectory. Since the trajectory is calculated throughout the burn, the exit point of the burn should also be exact (assuming no bugs, perfect pointing, and precise burn start and end time), so your actual trajectory follows the planned trajectory basically exactly. This doesn't match with our intuitions of maneuver nodes in KSP 1, but it is fundamentally better for predicting exact trajectories, and immensely more useful for longer or lower thrust burns. For a simple circularization, you should be able to adjust the node to a bit before the relevant apsis, and find that you get better results then if you set the node right on the apsis, with the separation based on burn time etc.

If I was new to KSP, and had no knowledge of KSP 1's node system, KSP 2's system would be much more intuitive. This is exactly the sort of fundamental improvement KSP 2 should bring, it is just unfortunate that this wasn't made clear to us, as it is leading to confusion (myself included, at first) due to the different implementation from KSP 1.

The new system is also more realistic, as it accounts for the extended burn duration, and it makes more complicated calculations to improve accuracy. You would absolutely need to take these things into account for longer burns in real life, like for instance the initial planned trajectory of the DART mission which was to spiral out of Earth orbit on ion engines (but since Falcon 9 had the performance, it was launched on an escape trajectory directly).


Now, for a suggestion:
There is one aspect that I think deserves some possible attention, and that is burn direction. In KSP 1 in made sense that the burn direction was basically static, and if you strayed off course it would adjust to best approximate the initial trajectory. With longer burns expected in KSP 2 (I already did a 17km/s nuclear burn that I went up to 1000x timewarp for, ION would be worse), I don't know if that is the only valid option. Take for instance, a slow burn out of LKO, slowly spiralling out. The ideal burn direction is to always face prograde, since the burn itself takes several complete orbits of Kerbin. A static burn direction makes absolutely no sense for this type of slow escape, but I can easily see large interplanetary ships with ION propulsion needing such a burn. I don't know how you would implement that into the maneuver system, or how you would communicate it to the player, but I think it would be valuable. This of course also would require SAS to be able to work under timewarp, which it currently does not do. Even a slow escape burn that takes say 5+ minutes to get out of LKO to an escape trajectory would see deltaV gains if it could follow prograde rather than just a static burn in the initial maneuver node direction, which is something we already did in KSP 1.

Edited February 26, 2023 by Immabed
Added more detail.

[Sea_Kerman]

yeah, some sort of contingency for spiralling trajectories is needed

[Johny5]

2 hours ago, Immabed said:

The KSP 2 system takes time under thrust into account, so the node location marks the start of the burn, as that is the only time during the burn that you are actually on the pre-burn trajectory. Since the trajectory is calculated throughout the burn, the exit point of the burn should also be exact (assuming no bugs, perfect pointing, and precise burn start and end time), so your actual trajectory follows the planned trajectory basically exactly. This doesn't match with our intuitions of maneuver nodes in KSP 1, but it is fundamentally better for predicting exact trajectories, and immensely more useful for longer or lower thrust burns. For a simple circularization, you should be able to adjust the node to a bit before the relevant apsis, and find that you get better results then if you set the node right on the apsis, with the separation based on burn time etc.

Where did you find this information? Was there a Dev note explaining how KSP2 nodes are different from KSP1?

[Black-Talon]

6 hours ago, Draradech said:

Maneuvers are assumed to have constant pointing. If you execute them as such (with SAS hold) they will be correct (and that will work during warp as well). Prograde changes during burn, but the planned maneuver has a fixed direction. So burning with SAS set to prograde (for prograde-only maneuvers) will also end up wrong.

Since burning prograde is the most efficient, isn’t adjusting heading to the changing prograde over the duration of the burn giving you the most bang for the buck? The OP’s issue isn’t necessary making burns “impossible,” as we can see from current game play.  But consider moving the node to points prior to Pe, that the burn will begin prograde at the point of the maneuver, right? And prograde being tangent to the orbit  means that once the craft has proceeded past Pe the original fixed direction of the burn is significantly far from prograde and inefficient.

So, users can adjust the node to be prior to Pe. But the combination of these conditions can’t work for interstellar without detrimental efficiency implications? How would you burn prograde all the way to the halfway point, flip, and burn retrograde all the way to the destination without holding prograde and then retrograde during the duration of those burns all while under time warp with the current system?

So two things would be needed? A better maneuver planner surely, one that potentially optimizes the start point of the burn to a location other than where the user clicks to create it. And the ability to hold to heading that moves relative to the continuously changing orbit. Probably some brutal math…

Or am I just wrong about continuously adjusting heading to match prograde (such as with lock to prograde sas) throughout a burn being the most efficient? Or is it irrelevant on a hypothetical interstellar burn since we’re spending most of that burn outside spheres of influence and a long ways from the Pe?

The implications of interstellar burns are quite daunting and thus OPs “bug” is perhaps reflecting that despite the improvements to the maneuver planning it isn’t the approach interstellar will require. …more work to do as part of the progress towards the interstellar milestone. 

[Immabed]

1 hour ago, Johny5 said:

Where did you find this information? Was there a Dev note explaining how KSP2 nodes are different from KSP1?

This is just simply looking at how they are working right now. Pretty easy to tell if you do some complex maneuvers.

[lemon1324]

35 minutes ago, Black-Talon said:

Or am I just wrong about continuously adjusting heading to match prograde (such as with lock to prograde sas) throughout a burn being the most efficient?

Your ship will have some velocity vector with respect to the parent body before the burn, and some velocity vector after (which is on your final orbit).  For impulsive burns (i.e. burn time much shorter than orbital period), the most efficient burn should be to take the velocity vector difference and burn only in that direction. The difference in KSP1 and KSP2 maneuver nodes (ignoring bugs), is that KSP1 nodes assume the burn happens instantaneously for computing the changed orbit, but this isn't actually true, leading to the "start your burn ahead of the node" we've gotten used to.  Even that isn't totally right, since your mass changes, so more than half of the delta-v comes in the second half of the burn.  KSP2 nodes actually compute the time-varying thrust along your burn vector, assuming the burn starts at the node.  This means (again, assuming no bugs) executing the node as planned will result in the final previewed orbit, regardless of the thrust-to-mass of your ship.

Spoiler

Here's an example of plotting a plane change with an ion engine.  The maneuver node shows the actual curved trajectory the ship will take, unlike in KSP 1 where the new orbit would be shown as intersecting the maneuver node.  Assuming they fix bugs and make the maneuver node system usable while switching to/from map mode, this should actually make it easier to match orbits with a target.

This won't be true for a spiral-out type of burn with an ion engine, but at least currently that type of maneuver isn't supported under warp because orientation cannot change under warp.

[JoeSchmuckatelli]

8 hours ago, Bej Kerman said:

Yeah, I probably should have mentioned that at some point. A prograde maneuver with an ion engine won't put you on an outward spiral orbit, it'll just crash you into the surface because, on the opposite side of the orbit, what was prograde is now retrograde.

This does not make intuitive sense to me.  When I hit the hold prograde button, the SAS keeps the nose pointed in the direction of travel.  Thus a constant burn with an Ion engine should actually describe a spiral, right?  Because Prograde at AP and PE should be in the same direction (the direction of travel) even though they're in opposing directions w/r/t the background stars - resulting in an ever-increasing orbit around the planet until you hit escape velocity.

I always thought that with an ion engine you wanted to make successive burns on the same side of the planet (w/r/t the background stars) in order to raise AP to the desired distance or gain an escape / encounter.  Burn, coast, burn, coast, burn, etc.

Edited February 27, 2023 by JoeSchmuckatelli

[lemon1324]

Holding prograde and burning with an ion engine would be a spiral, the only problem is currently you can't time warp and hold local prograde at the same time - your orientation during warp is fixed w.r.t. the inertial frame, not the orbit-relative frame.

[Johny5]

5 hours ago, Immabed said:

This is just simply looking at how they are working right now. Pretty easy to tell if you do some complex maneuvers.

My testing while playing the game, using a quick save and repeatedly trying the same maneuver executed different ways, tells me that KSP2 works exactly the same as KSP1.
 

The result is much more accurate to the prediction if you spread the burn before and after the node and use SAS locked on the maneuver (without time warp). At least it is for me.

In one test I set up an encounter with Duna which predicted hitting the planet, since we can’t see orbit lines at target SOI yet. Using the timers, I missed the planet every time. When I ignored the timers and eyeballed an early start, KSP1 style, I could hit the planet. 

Edited February 27, 2023 by Johny5

[Ross B]

The Problem

By changing the user controlled time to "start of burn", the KSP2 maneuver planner will never be as useful as the KSP1 planner. I am assuming that a fix will soon allow us to expand and lock the details in the Pe/Ap and other points. Even when that works again, the new maneuver planner will still be worse than KSP1. By increasing the delta-v with the start time fixed, you're actually changing two variables: the amount of delta-v applied and the effective time it's applied. You'll have to make at least one other compensating adjustment to correct this issue and it will always be a worse experience.

KSP1's maneuver planner was a fine educational tool (change the input, see the effect on the output) but you could never graduate from playing with the inputs to specifying the outcome. There are a couple of real improvements that can be made to the KSP1 planner without losing the game vibe, and two steps beyond, for those who want to leave the wacky variability of manually executing inaccurate maneuvers to a time when they were getting the hang of things.

A Possible Solution (that stays true to the game)

I suggest there should be two planners and an autopilot that players can opt into via the tech tree. The two planners are 1) a slightly improved KSP1 planner and 2) a "Kerbonautic" maneuver planner. The autopilot can put you on the maneuver vector, start and stop the burn precisely.

Slightly Improved KSP1 Planner

The two improvements I would make to the KSP1 planner are 1) the maneuver vector should be relative to prograde and should follow prograde during the burn and 2) you should be able to set the engine throttle for a maneuver.

On the maneuver vector:

1. Orbit angle adjustment maneuvers are more efficient if you burn orthogonal to the path (lock to the normal or anti-normal) and not on a fixed vector. For large angular changes, it's ridiculous not to.
2. Same is true for ends of Hohmann transfers. Locking to prograde/retrograde is more efficient than a fixed vector.
3. It should be verified mathematically, but I'm confident that the same general principle is applicable for all short maneuvers (where burn time is a quarter orbit or less). There is a most efficient maneuver vector, but it isn't fixed to the orbiting body. It's a heading relative to prograde and it keeps that same relationship to prograde as the maneuver continues.
4. I don't pretend to understand the details for long burns. I excelled at differential equations in school, but the math for full revolution continuous power burns is currently beyond me. 

On the throttle: The maneuver planner assumes that all engines enabled in the current stage (and only those engines) will be throttled to the current thrust limiter. When I want a small burn, I have to run around to the relevant engines and adjust the thrust limiters in order to draw out the burn to something I can manage. I'd prefer that you could adjust the throttle in the planner (and that it would be a temporary override of the actual limiter).

A Kerbonautic Maneuver Planner

An ideal maneuver planner needs to work from the desired end conditions (a particular orbit around a particular body) and calculate back towards the vehicle controls (vector, throttle, start time, end time). To get into a non-intersecting orbit will require two or more burns. There are additional trade-offs (thrust vs delta-v vs time, gravity slingshots, etc) which will manifest as additional player choices. Sources of error (staging, engine failure, rounding issues) could result in residuals and the need for occasional correction burns. The SOI simplification, which I accept as essential to KSP playability, means that we aren't trying to replicate a NASA/JPL maneuver planner. This solution will be specific to KSP.

I'd appreciate any pointers to ongoing relevant discussions in the replies. Very happy if this gets folded into an existing thread covering similar thoughts.

[Sea_Kerman]

It's being discussed here: 

 

[Gargamel]

9 minutes ago, Sea_Kerman said:

It's being discussed here: 

 

Please report threads that need merged or redirected, instead of posting in thread.   It keeps the resulting merged thread less confusing.   
 

But alas, not this merge.  

[Cailean_556]

I'm not a physicist, astrophysicist, scientist, rocket scientist, astronaut, a rocket surgeon or even a space shuttle door gunner.

My understanding of orbital mechanics stems completely from KSP (and lately also Juno: New Origins...which does some things I like - like auto burn even though I sometimes prefer to do it myself), and I'm not even very good at understanding most of that. So when you all talk about Delta V in the second half of the burn being easier due to less mass, or the efficiencies of burning prograde and not pointing to target or pointing to target and using SAS hold, I'll just smile and nod. I understand the concept of what you're saying, but not the math involved.

I know how to get to the Mun without using manoeuvre nodes, how to get into an orbit (in transit) if my periapsis is too low and how to circularise an orbit without them too. Getting an orbital encounter I can do in KSP1 - with nodes, not without...not so great in KSP2 in part because of the node system and it's "intuitiveness". But that's not the point - the point is the manoeuvre node is supposed to correctly and accurately calculate these things for me way better than I ever could.

I like the fact that the nodes now tell me when to burn, and grab my attention in some way just prior to the burn however, as it stands, every burn I make "trusting the node" is wrong and I have to fix it manually using what little I know of orbital mechanics. Even getting a circular orbit in KSP2 - starting the node from apoapsis, or even before it - is difficult. I have to make significant correction burns if my intent is for a circular orbit - otherwise I generally just burn out of orbit from whatever kind of orbit I'm in to get where I'm going. "Brute force it", so to speak.

What I would like is if the node was "intuitive" enough to figure out I'm trying to burn for Mun (or any planet) periapsis, or get into/circularise an orbit, or intercept/encounter a target and apply some sort formula to compensate when calculating the burn based on the parameters I've set when planning my node - so I don't need to figure out how many seconds three minutes and 49 seconds), what half of that is and then subsequently realise I've missed the start of the burn because I was too slow with my calculations and there's nothing grabbing my attention to start said burn (in KSP1) - and in what direction to burn in order to make the burn I planned work as I intended.

What I would also like to see is, potentially in the right click radial menu of the node, a button for calculating an orbital circularisation burn based on the current/intended apoapsis (as we all do this A LOT, so this will save us a lot of time) and a button for calculating an intercept of the target (something else we'll be doing a lot of, I imagine) be that a ship or a celestial body - and if it can't get us a perfect intercept/encounter, it gets us close enough to whatever we're trying to get close to so we can do a mid-course correction burn to get us even closer, rinse repeat until intercept/encounter).

I would also like to see a way to manually input our desired apo/peri either in our current or desired orbit (at the desired target) and have the manoeuvre node calculate a burn to accommodate that for us.

In "campaign mode", these options would be later-game but in EA sandbox (i.e. what we have currently) they could be implemented and fine-tuned so that come v1.0 release we're all singing off the same sheet of music. It doesn't have to be perfect (or perhaps, 'perfect' course plots can be another upgrade) it just needs to get us in the ballpark so we can course correct or establish an elliptical orbit or whatever our plan is for where ever we're intending to go.

In KSP2, I feel that automation of the more common navigational manoeuvres should have "quick access" (circularise, intercept - as this would also cover interplanetary insertion burns) buttons in the manoeuvre node. I also feel that automation of the more repetitive tasks (such as getting a ship into orbit, and/or circularising an orbit, and docking) could (or perhaps as a selectable option, should) be a thing the devs prioritise - especially to make the game more accessible and especially when we have colonies and resource gathering to worry about.

Example 1: You've been manually launching rockets for 20 hours - but since you've upgraded to the Level 3 Tracking Station, here's a series of buttons to help you automatically launch your craft, circularise its orbit and, if need be, calculate an intercept of a designated orbital target.

Example 2: You've been building ships module by module in orbit with varying degrees of success (if you can get the nodes to work for you) for the last 50 hours - but since you've upgraded to the Level 4 Tracking Station, here's a button that will 'auto-dock' you - right way up, every time - to your target, provided you're within 1000m and your velocity relative to target is 0 m/s. No more twisted, misaligned modules from now on.

Example 3: You've gone to Debdeb and back, six times, and docked landers to your orbiting ships 9,700 times in your 120 hours of KSP2 - but since you've upgraded to the Level 5 Tracking Station here's a button that calculates the intercept of a celestial body and more accurately calculates orbital intercepts from the ground - and also plots the trajectory of an interstellar burn. Good job, you've earned it!

Does that make it "too easy"? In Sandbox, yeah maybe. But if you wanted the challenge, you'd be playing a career mode. And if you're playing career mode, after doing the same thing a billion times (like you do in career mode), a more efficient way of doing it would be appreciated. You'd obviously have to "do the hard yards" to earn (and therefore deserve) them by the time you've reached the late game.

Plus, these are/could be optional, with the unchecking of a box in the Settings menu you can still do these things manually either as good as, or perhaps even better than, the nodes can. But they're there to help players and reduce the micromanagement and monotony of constant launches, orbits and trans-planetary insertion burns and whatever else.

But for any of that, we need this manoeuvre node thing looked at because as it stands right now, I'd much rather "do things manually" (yes, I'm aware MechJeb is a thing) in KSP1 than deal with whatever the hell is going on with KSP2.

Edited February 27, 2023 by Cailean_556

[Draradech]

7 hours ago, Johny5 said:

My testing while playing the game, using a quick save and repeatedly trying the same maneuver executed different ways, tells me that KSP2 works exactly the same as KSP1.
 

The result is much more accurate to the prediction if you spread the burn before and after the node and use SAS locked on the maneuver (without time warp). At least it is for me.

In one test I set up an encounter with Duna which predicted hitting the planet, since we can’t see orbit lines at target SOI yet. Using the timers, I missed the planet every time. When I ignored the timers and eyeballed an early start, KSP1 style, I could hit the planet. 

This works as a rough approximation, because the error introduced by turning with your orbit is split in two halfes with different direction (as we did in KSP 1). Also it will stop working when they fix the maneuever indicator turning with your orbit. It is not as accurate as the new way (especially for low-thrust burns) and will break for maneuvers with time warp. The new way is much more accurate for me than KSP1 was, especially for low-thrust burns. I get that it is currently confusing due to compounding bugs that make it hard to tell what's going on, but the way to fix it is not by going back to the old method, but fixing the new method so that "point at the node, burn as indicated" just works.

[Johny5]

I’m still not seeing any evidence that there is a new way at all. 

And I absolutely love the timers with the drag racing style countdown and kerbal announcing when it gets close. It really great  but it right now doing what it tells you to do gives a poor result.

The devs have put great effort into making the tutorials so that new players have an easier time learning the game. I have a hard time believing that they intend new players to understand placing a node at the right position before PE/AP. The tutorials imply otherwise.
 

We can all agree that regardless of if new calculations are going into a maneuver prediction or not, it would never be most efficient to start a burn on PE/AP if your goal is to simply raise or lower orbit. 

 

 

[Draradech]

16 minutes ago, Johny5 said:

I’m still not seeing any evidence that there is a new way at all. 

And I absolutely love the timers with the drag racing style countdown and kerbal announcing when it gets close. It really great  but it right now doing what it tells you to do gives a poor result.

The devs have put great effort into making the tutorials so that new players have an easier time learning the game. I have a hard time believing that they intend new players to understand placing a node at the right position before PE/AP. The tutorials imply otherwise.
 

We can all agree that regardless of if new calculations are going into a maneuver prediction or not, it would never be most efficient to start a burn on PE/AP if your goal is to simply raise or lower orbit. 

 

 

Please look at the screenshots in this bug report, there's your evidence. These results are with burning as indicated by the timer. And when they fix this bug, "point SAS at the maneuver, burn as indicated" will work

.