Map & Tracking Station Incorrect maneuver on inclination change (Normal and Anti-Normal)

[Spicat]

It's a major bug for me and really annoying, the maneuver doesn't behave correctly:

• KSP Version: v0.1.2.0
• Operating System and version  (Windows 10, Windows 11): Windows 10
• CPU and GPU models, any other system information which could be relevant: i7-10700 / RTX 2070 / 16GB RAM
• Steps to Replicate

On an orbit, place a maneuver and use the normal arrow. Execute the burn and you will see that the path doesn't match with the maneuver path.

• Description of the bug.  
  • Expected Behavior

In ksp 1, when we use the normal arrow and execute the burn, the maneuver icon move on the navball.

Thus, it results in a path which is not just normal (a orbit with a different angle) but also prograde (a orbit with a different angle AND a different apogee).

• Observed Behavior

Here in ksp 2 the maneuver icon on the navball stay on the normal icon, it doesn't move, so when following this icon we obtain the path of a normal maneuver (just change the angle)

In ksp 2. Either the maneuver should move when executing the burn like in ksp 1, or the maneuver path should show the path of just the normal maneuver (so not like in ksp 1).

• Fixes / Workarounds (if known..): Not a fix but => not using the maneuver, which is a shame
• A list of ALL mods.  If the list is long, please consider using a spoiler window: No mods
• Other Notes / Screenshots / Log Files (if possible..)

Here a video to better understand the problem (I only burn Normal because the maneuver icon is not moving):

https://i.imgur.com/2MviOiD.mp4

I don't know if it's just the normal and anti-normal, but I think the problem is the maneuver icon not auto correcting. I think I have this bug since release.

Edited July 9, 2023 by Anth12

[LeroyJenkins]

58 minutes ago, Spicat said:

Here in ksp 2 the maneuver icon on the navball stay on the normal icon, it doesn't move

Confirmed. I've done normal orbit changes but only for very short burn times (100-200 m/s dV) and all seemed fine. Seems the error is magnified when performing longer burn times.@Spicat video shows a burn of 2000 m/s dV. I recreated this bug at 1000 m/s dV. I did it twice for Normal, with SAS set to track Normal and second time to track Maneuver. Same results as Spicat. I also performed it for an Anti-Normal maneuver, at Pe ( just in case this effect was for non-circular orbits only, and the normal burn was not done at either An or Dn) of the orbit. Again, same result. The post burn maneuver arc does not properly show the final orbit of the actual planned normal/anti-normal burn.  Nice catch @Spicat

I used the stock Kerbal K2 Rocket for my tests, not a custom build.

[LOG 17:57:45.138] Version Info: 0.1.2.0.22258
OS: Windows 11  (10.0.22621) 64bit
CPU: AMD Ryzen 9 5950X 16-Core Processor  (32)
RAM: 130992
GPU: NVIDIA GeForce RTX 3090 (24340MB)
SM: 50 (Direct3D 11.0 [level 11.1])
RT Formats: ARGB32, Depth, ARGBHalf, Shadowmap, RGB565, ARGB4444, ARGB1555, Default, ARGB2101010, DefaultHDR, ARGB64, ARGBFloat, RGFloat, RGHalf, RFloat, RHalf, R8, ARGBInt, RGInt, RInt, BGRA32, RGB111110Float, RG32, RGBAUShort, RG16, BGRA10101010_XR, BGR101010_XR, R16
 All graphics settings at max

Edited April 17, 2023 by LeroyJenkins

[Spicat]

Reported Version: v0.1.3 (latest) | Mods: none | Can replicate without mods? Yes 
OS: Windows 10 | CPU: Intel(R) Core(TM) i7-10700 CPU @ 2.90GHz | GPU: NVIDIA GeForce RTX 2070 | RAM: 16GB

Edit: This message was merged so this is the same information but in version v0.1.3.0

Severity: High, it doesn't gather enough attention but for me it's one of my top bug. You can't make accurate maneuvers because of this and need to eyeball everything, pretty game breaking.

Frequency: High. If you do an inclination change, you will always find this bug.

Description:

So when doing an inclination change and following the maneuver, the orbit you obtain is not the same as the projected orbit. (Following Normal and Anti-Normal has the same breaking behaviour)

Here are two videos showing the behaviour:

https://imgur.com/a/Y3IUZMq

The first one shows the bug, the second one show what you have to do to have the projected orbit (look at the navball to see the change)

I already reported this bug in the previous version, didn't change here (and curious it was never mentioned):

There is also another bug report that might be linked but there isn't enough information to accurately say that, so that's why I made this bug report:

Solution:

So if the goal is to reproduce ksp1 behaviour, the maneuver icon on the navball shouldn't move (while the triangle do move).

This is a matter of opinion,  BUT, I quite like the fact that an inclination maneuver should only do an inclination and not enlarge the orbit. So another solution is to only change the projected maneuver to fit that the ship moves.

 

Included Attachments:

inclination_bug_videos.zip

AutoSaveInclinationbug24_06_202311_33.json

quicksave_1.json

[Tomator]

The aim of maneuver is to change velocity to reach certain target. A maneuver is complete when the velocity vector V is changed by dV planned by a maneuver. Since the acceleration vector is rarely perfectly aligned with dV, usually some deviation occurs. When maneuver mark doesn't follow this deviation, we're unable to compensate. Playing KSP2 I just watch the remaining dV bar to shut down engines when I see it rising. This means I can never do good maneuver. In KSP1 the maneuver mark was going aside so I knew if further burning can get me closer to the desired V or not and in which direction I should compensate.  If I caught an asteroid or for any other reason had asymmetrical thrust the problem with static maneuver mark would be more than annoying. It was done perfectly well once. Please bring the KSP1 experience back!

[Turbo Ben]

I raised a bug report for this weeks ago where I explained the problem. It also applies to radial in/out maneuvers.

The problem is SAS maneuver hold tracks the normal/radial marker as you perform the burn, instead of staying fixed. (for example, the radial out marker will move as you burn towards radial out. Maneuver hold tracks this movement when it shouldn't, as this movement isn't accounted for when you create the maneuver node)

To get a much better result, set SAS to maneuver before the burn, and then switch SAS to hold before you start the burn. It's not perfect as you won't get the minor corrections towards the end of the burn, but you'll get a much better result.

[sleepy_eb]

I can confirm this big is still present in 0.1.3.0/win10/5800G/rtx2060 without mods.

I had this bug happen a couple of times on my trip to Moho today. Interesting, it does not always happen. I have planned several maneuvers which included some normal/anti-normal component that have executed  correctly. 

Is it just me, or do the trajectory and maneuver bugs appear to be worse interplanetary than they are inside Jool and Kerbing SOI?

[Flush Foot]

I thought I’d also reported this exact bug in the forums (with YT clip) a little earlier in April…

I’ll look for it here, Reddit, Discord

Found it!

 

And Reddit

Conversations happened in both threads:

https://www.reddit.com/r/KerbalSpaceProgram/comments/12l4w3c/does_anyone_else_think_the_manoeuvremarker_is

https://www.reddit.com/r/kerbalspaceprogram_2/comments/12m5ict/does_anyone_else_think_the_manoeuvremarker_is

[Spicat]

37 minutes ago, Flush Foot said:

I thought I’d also reported this exact bug in the forums (with YT clip) a little earlier in April…

[snip]

Didn't see your bug report at the time I made this report, sorry. I was asked to move it to the new bug report system not long ago and mods merged it with my old bug report.

But either way, the most important part is that it's high on the list of fixes.

[Flush Foot]

On 6/30/2023 at 7:00 PM, Spicat said:

Didn't see your bug report at the time I made this report, sorry. I was asked to move it to the new bug report system not long ago and mods merged it with my old bug report.

But either way, the most important part is that it's high on the list of fixes.

No worries! Lots of similar sounding reports have probably crossed your desks in these first few months , some related and others not so much

[schlosrat]

On 6/24/2023 at 6:40 AM, Spicat said:

This is a matter of opinion,  BUT, I quite like the fact that an inclination maneuver should only do an inclination and not enlarge the orbit. So another solution is to only change the projected maneuver to fit that the ship moves.

@Spicat, this is a very annoying bug and I agree it really needs to be prioritized. That said, I'm not sure what you mean when you say "an inclination maneuver should only do an inclination and not enlarge the orbit" in the context of a maneuver where only normal or anti-normal burns have been planned. If by this what you mean is that you'd like to be able to set up inclination burns that have the effect that they only change the inclination, then I agree and would refer you to either MJ2 in KSP1 or Flight Plan in KSP2. They both use the same orbital mechanics code for working out the burn vector you'll need to change just your inclination leaving the rest the same.  If you take a look at the maneuver nodes they set up for you you'll find that there are in general prograde and may also be radial components mixed in there.

The thing that is going on is that if you only burn in the normal (or anti-normal) direction - even if the maneuver target point never moved so that your maneuver works like you've shown when you switch SAS to hold - you're going to generally raise your Ap, and for the large burns you're using in these examples, raise it quite a lot. You're adding energy to the orbit when you burn, and that energy does more than just change your inclination, it's speeding you up.

Picture a 2D plane passing through your craft at the point of the maneuver node where the X axis is pointed Prograde and the Y axis is pointed in the Normal direction. You start with a velocity vector that is 100% in the prograde direction, and then you point your craft 90 degrees from that to +Nornmal and fire your engines. Assuming that things work as they should (which, given this bug, they don't), then you have a new velocity which can be seen on the 2D plane as the root sum square of the original Prograde vector and the applied +Normal vector. This new larger vector is your new prograde vector in the new orbital plane, but your distance from the CM of the planet hasn't really changed. So, you've not just changed your inclination, you've sped up quite a bit while you're in the same altitude - you've added energy to the orbit! That added kinetic energy will be turned into potential energy as you coast to your new much higher apogee.

This is just orbital mechanics.

For example, if you start in a roughly 500km circular equatorial orbit (i =0) and would like to change that to a 500km circular orbit inclined at 60 degrees, you're going to need to apply 1541 m/s in the Normal direction, but also -866 m/s in the prograde and 162 m/s in Radial. Either MJ2 (KSP1) or FP (KSP2) will work this out so you don't have to mess around with the math and can just have the node you need. It would then be up to you and your mad piloting skilz to execute it! (or you could hand that off to a droid)

[Anth]

Fixed as of 0.1.4.0
Thanks for reporting it.