Maneuver Node Maneuver Node Broken - Anyone Else Seeing This?

[Billy1996]

Same. Maneuver node doesn't work for me.  put SAS on maneuver point ,  did all steps correctly (start/stop burning  with green checks) but after that, my orbit doesn't matches manouvrer orbit , and my ship keep fallen to Kerbin. 

[Double Timan]

The estimated burn time in ksp1 was very useful but the ideal time to start the burn is often not 50% of this time.  It would be nice to be able to set the start of burn time and show a burn line rather than a point.  The more the rocket will change in mass and speed over the burn, the earlier the burn should happen.  I wont get into the math on a bug forum but the current warp to node landing right on the node is definitely not useful.  

[Scarecrow71]

45 minutes ago, Billy1996 said:

Same. Maneuver node doesn't work for me.  put SAS on maneuver point ,  did all steps correctly (start/stop burning  with green checks) but after that, my orbit doesn't matches manouvrer orbit , and my ship keep fallen to Kerbin. 

The video in the following post shows a great workaround for this until the devs tackle this bug.

 

[Poppa Wheelie]

It looks like there are 2 major issues here, both are based on when the burn begins and how to orient the ship, and both seem to have solutions:

1. How do we build a circularizing Maneuver Plan:
   • For KSP1 vets, our first instinct is to place the initial maneuver node on the Ap or Pe.  However, I've noticed that I cannot get a predicted circular orbit from a node placed at the Ap or Pe
   • Knowing that KSP2 intends to start the burn at the node, it should now also make sense that of course you won't get a circular orbit if you start the burn at the Ap or Pe
   • So if we want to circularize, the node must be placed before the Ap or Pe
   • It seems that the solution for getting a circular orbit is to place the node somewhere before the Ap or Pe, play with the node, move it a little forward or backward, until you have something circular
   • For elliptical orbits that you want to circularize, this is probably the way.  I'll have to test it, but it seems to make sense.
   • For circularizing at the Ap on initial ascent, I don't have time for this trial and error method.  I'll have to stick with manual circularization by slowly pushing the Ap out method for now.
2. How do we get the game to execute any Maneuver Plan and get correct results?
   • For whatever Maneuver Plan you have built (circularization or otherwise), we want a method that will produce the same results as the plan
   • A few comments above, and the video referenced by @Scarecrow71 both indicate that this is the method:
     • Have SAS point to Maneuver until shortly before the countdown timer begins
     • Shortly before the countdown timer begins (after T-10 seconds but before T-3 seconds?), switch SAS from Maneuver to Stability On (lock)
     • Begin the burn at T-0 on the countdown timer
     • End the burn as the burn timer indicates

[Johny5]

9 hours ago, Draradech said:

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.

Oh I finally understand what you mean by a new way. The trajectory change during the burn showing as part of the prediction is new. Got it.  I don't think that feature and having the option to adjust the burn start time are mutually exclusive features. 

[XavBell]

I don't trust this maneuver system anymore at least for Kerbin Orbit and when you have more than one stage that will need to be fired during a maneuver

[ColJay]

I found the added extra functionality of the manoeuvre nodes from the latest round of updates for KSP1 much more usable than the ksp2 way.

Not being able to enter values for the prograde, radial etc is a real bind. I like to do a few pre-calcs manually to calc the required deltav, not possible with the new system. Also - I can't figure out how/if it's possible to advance the eta by an entire orbit time value, so again can plan manoeuvres way ahead of time and move on to something else. 

I also find the burn timers very wrong, and no matter what i do - the final tick is never satisfied. For some deep space adjustments decimal values of deltav are often needed, again this is very tricky with the drag drop recheck the periapsis.

Overall - i do get the idea of having the node indiciate the burn start - but that does mean the prograde vector is wrong over a long burn (or a short one for that matter), and i'm unclear whether when moving the node the actual vector direction also changes to prograde of the point (or whichever of the arrows have been dragged) - mathematically - both things need to play together - if the intention is to indicate the position of the burn - the vector needs to be the midpoint equivalent of the burn (ie - 1min burn time - direction of a point 30seconds ahead of the node on the original orbit), that way everything should work out to end up with what would be expected, otherwise the direction would be wrong for the deltav vector. Unless that's already taken into account - but from my testing it doesn't seem to be.

[11JRidding]

7 hours ago, ColJay said:

I also find the burn timers very wrong, and no matter what i do - the final tick is never satisfied. For some deep space adjustments decimal values of deltav are often needed, again this is very tricky with the drag drop recheck the periapsis.

Overall - i do get the idea of having the node indiciate the burn start - but that does mean the prograde vector is wrong over a long burn (or a short one for that matter), and i'm unclear whether when moving the node the actual vector direction also changes to prograde of the point (or whichever of the arrows have been dragged) - mathematically - both things need to play together - if the intention is to indicate the position of the burn - the vector needs to be the midpoint equivalent of the burn (ie - 1min burn time - direction of a point 30seconds ahead of the node on the original orbit), that way everything should work out to end up with what would be expected, otherwise the direction would be wrong for the deltav vector. Unless that's already taken into account - but from my testing it doesn't seem to be.

I feel like this is, at least partially, a combination between a problem with how you are reading the node and a problem with the navball marker for the node. The problem with the navball marker is that it drifts as the node moves, while the actual position you want to be facing does not. To be clear, this means that you do not want your SAS set to follow the marker during the burn, as it will move incorrectly and therefore your rocket will end up not performing the manoeuvre correctly.

Instead, what you want to do is: Five seconds away from the node position, set your SAS mode to Hold Position. This will ensure that you don't move away from the place where the marker should be. When you hit 0 on the countdown, begin the burn, and take into account the below information:

Through testing, I have found that the burn timer is sometimes very incorrect. It seems to be off by an order of magnitude. This is a problem, but it is one that is very easy to work around, as what is not incorrect is the progress marker below the manoeuvre information. That has stayed consistently correct during my testing, and I have found that when the progress marker reaches the end, that is when I want to stop the burn. This is less precise than the countdown that is provided, but I have found that small adjustments - often small enough to be done with RCS alone - are often the key to fixing any errors it causes me.

Edited March 1, 2023 by 11JRidding
Slight correction to wording.

[Rogue Phoenix]

On 2/25/2023 at 3:34 PM, Sea_Kerman said:

the nodes seem to reset when you swap to map view

 

I was seeing this happen while I was planning the maneuver node, without even engaging the engines.
from Map view, create a maneuver node
switch to flight view
switch back to map view
Maneuver node is wonkified

[Shinzo]

On 2/27/2023 at 10:23 PM, Billy1996 said:

Same. Maneuver node doesn't work for me.  put SAS on maneuver point ,  did all steps correctly (start/stop burning  with green checks) but after that, my orbit doesn't matches manouvrer orbit , and my ship keep fallen to Kerbin. 

I had the same problem. It seems like any changing of the orbit inclination with manouver nodes is totaly broken.  If you burn as manouver says when changing inclination you will most likely end up in the planet or moon instead.

[Apop85]

At the moment i just use the maneuver nodes to align my craft. As soon it is aligned i delete de maneuver and do the rest myself.

 

EDIT: With this method i was able to get everywhere i wanted so far (moons of Kerbin, Moho, Dres, Jool and its moons)

Edited March 1, 2023 by Apop85

[LameLefty]

I had a brand new (to me) issue with maneuver nodes today when I got a probe in Jool's SOI: the just stopped working. Oh, I could place a node anywhere along the trajectory through the SOI that I wanted to, but no matter what I did with any of the six axis handles, the trajectory didn't change at all. I had to resort to pointing along the pro/retrograde axis, the normal/anti-normal axis and the radial in/out axis, then burn while watching the Map view to adjust my orbit. I tried multiple saves and reloads and even quitting the game entirely and reloading from scratch, but it made no difference. They are just completely non-functional for me.

 

[Draradech]

On 3/3/2023 at 12:56 AM, LameLefty said:

I had a brand new (to me) issue with maneuver nodes today when I got a probe in Jool's SOI: the just stopped working. Oh, I could place a node anywhere along the trajectory through the SOI that I wanted to, but no matter what I did with any of the six axis handles, the trajectory didn't change at all. I had to resort to pointing along the pro/retrograde axis, the normal/anti-normal axis and the radial in/out axis, then burn while watching the Map view to adjust my orbit. I tried multiple saves and reloads and even quitting the game entirely and reloading from scratch, but it made no difference. They are just completely non-functional for me.

The maneuver planner is dependent on knowing TWR and fuel / dv information to calculate the correct trajectory prediction. I had multiple cases where my dv indicators became confused during flight (showing wrong values / values in the wrong stage / 0 dv). In those cases the maneuver planner becomes inaccurate or stops working completely.

[LameLefty]

28 minutes ago, Draradech said:

The maneuver planner is dependent on knowing TWR and fuel / dv information to calculate the correct trajectory prediction.

See, this gets back to what appears to be some fundamental issues (to me, an actual aerospace engineer) between what I expect and want to use a "maneuver planner" for, versus how the feature is implemented in the game at present. If I'm in orbit around Jool, for instance, and I want to know how much my velocity needs to change in order to change my trajectory and end up on a return trajectory to Kerbin, the ACTUAL AMOUNT OF THAT VELOCITY CHANGE does not depend one iota on my current mass, how much propellant I have in the tanks, or what the T/W ratio is of my craft at any point in time. I just need to know how much faster and in precisely what direction to go. 

To calculate everything precisely and make a good estimate of burn time, motion during the burn, etc. I do need to know all that stuff. But the net change of velocity is all that ultimately matters in the ideal case. 

Edited March 7, 2023 by LameLefty

[Sea_Kerman]

Thing is, net change in velocity where? The new maneuver nodes are non-impulsive so they work by actually modelling how your craft will move while the maneuver is being executed. If it doesn't know your craft's TWR it can't figure out over which portion of space the velocity will change.

Now whether we should have a standby/backup impulsive maneuver planner that works like the KSP1 one is another question.

[LameLefty]

20 hours ago, Sea_Kerman said:

Thing is, net change in velocity where? The new maneuver nodes are non-impulsive so they work by actually modelling how your craft will move while the maneuver is being executed. If it doesn't know your craft's TWR it can't figure out over which portion of space the velocity will change.

Now whether we should have a standby/backup impulsive maneuver planner that works like the KSP1 one is another question.

Yep, I get all that. Thing is, the current system "sort of" works the way I want and expect it to anyway. Go to a craft on a trajectory in space, anywhere. Start off with some prop in your tanks, so the system lets you create a working node. Doesn't matter how much, just some. Now go to Map view, click somewhere along your current trajectory to create a node. Grab one of the axis handles and start dragging. The node will give you a helpful NO FUEL annotation message or words to that effect (I'm away from my PC right now so I might have misremembered how its phrased). Same thing with the burn progress indicator. It will be red from the point at which you run out of propellant during the estimated burn time. The fact that the vessel will be out of propellant well before the end of the maneuver does not stop you from creating (and planning) such a maneuver in the first place. 

So my proposal would be to do the same thing if you have no propellant (or if the game - due to existing bugs - THINKS you have no propellant, as happened to me). Mark the Map view with NO FUEL or whatever, color the burn duration red for its full length, whatever UI cue you want. My suggestion merely extends the existing cues and would make the entire experience consistent, regardless of how much propellant remains in the vessel at the start of the plan. 

Edited March 8, 2023 by LameLefty

[JoeSchmuckatelli]

On 2/26/2023 at 10:59 AM, Draradech said:

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

I still don't know if I'm doing this correctly.

But - it's been working better.

I'm hitting the 'hold target' button for the burn.  In KSP I typically had them hold prograde (mind you, I almost never went anywhere other than the moons) and that always seemed to work.  Prograde is clearly the wrong way to do it in KSP2... but hold target does seem fine.

[Scarecrow71]

3 hours ago, JoeSchmuckatelli said:

I still don't know if I'm doing this correctly.

But - it's been working better.

I'm hitting the 'hold target' button for the burn.  In KSP I typically had them hold prograde (mind you, I almost never went anywhere other than the moons) and that always seemed to work.  Prograde is clearly the wrong way to do it in KSP2... but hold target does seem fine.

Welcome to my world.  Took me a few forum threads to figure this out myself.  Which is why I generally click to go to the maneuver, time warp to the node itself, and then switch to hold SAS.  That seems to work most of the time, provided I have RCS thrusters on my rocket.

[Lowi_Sace]

Same problem while going to dress