Current inconsistency between maneuver plans and markers

[BComFly]

Recently I found that performing plane-changing maneuvers using the maneuver planer will give very inaccurate results. I noticed that the maneuver marker was changing its position during the burn. After a little investigation,  I can finally confirm that there is currently an inconsistency between a planned maneuver node and the maneuver marker.

When you are planning a maneuver node, the system assumes you will be accelerating in a fixed direction relative to the celestial body. However, when you are performing the planned maneuver, the maneuver node marker (on the Nav ball) is calculated relative to current velocity. So if you are following the maneuver marker during a plan-changing burn, the result will be significantly different. If you want to perform a burn similar to your plan, you will need to change to SAS lock when the burn starts.

Surprisingly, this inconsistency does not apply to prograde/retrograde burns, because a prograde/retrograde maneuver in the planner will actually consider the velocity change during the burn. I can see that this is a good addition to prepare for the very-low-thrust spacecraft in the future, but why does this feature only apply to prograde/retrograde burns? We at lease expect some consistency in all directions.

Edited May 2, 2023 by BComFly

[Lyneira]

This bug is pretty extreme when making large plane change maneuvers, such as turning an equatorial orbit into a polar orbit. Would appreciate the maneuver marker staying in place so that targeting it while executing the burn actually result in the planned trajectory.

[Tomator]

I miss the way how maneuvers worked in KSP1. 
Here the maneuver's aim is to change velocity by adding planned vector.  In KSP1 it was to achieve specific vector of velocity, when the target velocity was a sum of maneuver's vector and the ship velocity at the point of the maneuver. The difference is significant when, during the maneuver, any deviation appears. In old game the marker reflected this deviation so it could be corrected during the burn and get quite accurate result. In KSP2 the change vector is constant and when deviation occur, the remaining dV just won't hit 0. Instead, it'll bounce up. The burn cannot be the done as accurately as possible since the player must wait for the bar to bounce back to shut engines down. I KSP1 when the marker went off sight on the navball it was a sign the burn must end. Ant, if maneuver's dV was significant, the ship could be rotated and the remaining portion of velocity change could be done. In KSP2 another maneuver is necessary to be planed. And another...

[appenz]

100% agreed that this is an issue. I am calculating and burning nodes with KontrolSystem 2 and for many maneuvers I have to split them into multiple burns because the precision of a single burn is just terrible. KS1 was vastly better.

[Spicat]

Go to bug reports for this, I already reported this  pretty annoying bug:

 

[Turbo Ben]

I submitted a bug report for this a few weeks back and did a bit of investigating.

The issue applies to normal, anti-normal, radial in and radial out. I will refer to these four as "X" to save time.

So, notice that X is always 90 deg away from prograde. Always. As you burn towards X, prograde changes. Therefore, to remain 90 deg from prograde, X must also change. You can see this easily in game. Point at X marker and lock SAS (Basic SAS hold, not hold on X). Burn your engine and watch the X marker wander off.

When you plan a maneuver node with an X component, it doesn't account for X moving as you burn. The bug lies in SAS "hold to maneuver" which tracks X as it moves, when it should remain stationary. For small burns towards X, you'll hardly notice, but the error will get larger the more you change your direction, such as in large inclination changes.

On 5/2/2023 at 5:59 AM, BComFly said:

Surprisingly, this inconsistency does not apply to prograde/retrograde burns, because a prograde/retrograde maneuver in the planner will actually consider the velocity change during the burn. I can see that this is a good addition to prepare for the very-low-thrust spacecraft in the future, but why does this feature only apply to prograde/retrograde burns? We at lease expect some consistency in all directions.

The reason pro/retrograde are not affected is because they don't change your direction as you burn towards them. The only thing changing is your speed.

Hope that's not confusing, it's quite difficult to put into words.

[Lyneira]

On 6/28/2023 at 4:03 AM, Turbo Ben said:

The reason pro/retrograde are not affected is because they don't change your direction as you burn towards them. The only thing changing is your speed.

They might not change from the burn directly and higher TWR makes this effect less, but as you execute a long burn in low orbit, prograde does change with respect to the point the maneuver was made. I can't be sure, but I do wonder if this also results in burn inaccuracy the longer a burn takes relative to the current orbit.

[Turbo Ben]

1 hour ago, Lyneira said:

They might not change from the burn directly and higher TWR makes this effect less, but as you execute a long burn in low orbit, prograde does change with respect to the point the maneuver was made. I can't be sure, but I do wonder if this also results in burn inaccuracy the longer a burn takes relative to the current orbit.

Very true, and yes it does result in burn inacuracy, quite a lot in the situation you mention (long burn, low orbit, such as Mun transfer burn). This is why in KSP1 you would start your burn early, so you hit the maneuver node in the middle of the burn. KSP2 integrates this into the burn timer. It's never 100% accurate, but SAS maneuver hold will try to correct for errors, usually very noticeably towards the end of the burn.