Bug #28693
Maneuver node/projected trajectory (conic) glitch
0%
Description
Any long distance trajectory (typically interplanetary) drifts from a set up maneuver. The maneuver tool proposes a maneuver node, however, any changes to it (or any update by holding a maneuver node on the new trajectory) result in the trajectory being changed as if it is being constantly recalculated with different results (despite no changes to the maneuver being made). Observed changes of the encounter are on the order of 1e8 metres. Makes planning any maneuver beyond Minmus impossible. Video "2023-01-24 10-13-20" in attachment.
This also results in the predicted maneuver showing constantly changing delta V next to the navball, therefore the initially planned maneuver cannot be performed accurately (therefore I don't know if the calculation is corrrect and it is just the visuals acting up, or whether the calculations are wrong). Attachment "2023-01-24 10-25-49".
In a freshly created sandbox save and with certain planets, this issue is less pronounced (Duna) than with others (Eve). Video "2023-01-24 11-33-05" in attachment.
A quicksave is attached where the issue is really prominent.
No mod installed, no DLC.
Steps taken to troubleshoot the issue, none of these seem to have an effect on the result:
-restarted the game
-verified game files in Epic store
-reinstalled the game
-started a clean save (sandbox)
-timewarped years into the future
-updated graphics driver (to Geforce 528.24)
-forced KSP to use integrated graphics
-updated Windows
History
#1
Updated by Anth12 over 1 year ago
Updated by Its extremely unlikely that KSP1 will ever have a bug fixing update however here's how I do bug reports:
I make sure that the developers can test a bug like yours within minutes.
The quicksave you have supplied doesnt match the videos at all which means an hour of testing with the possibility of not being able to replicate it.
3 quicksaves which match the 3 videos exactly is 5 minutes of testing with the high probability that it will be confirmed by the developers.
Remember time is money so when looking at a bug report so developers have to think is it worth it financially to investigate or to investigate for a long time.
#2
Updated by JohnG over 1 year ago
Updated by Edit:
Steps to reproduce within a minute:
1) Load the save, launch map view, focus view on Eve
2) Update the predicted conic (either by resubmitting the maneuver burn values or by creating and dragging a maneuver node on the conic shown as fly-by)
3) Watch the trajectory constantly drift either by eye or by checking the fly-by periapsis altitude, like demonstrated in the videos
@Anth12: I agree that it is very unlikely I'll get a reply, since the last thing that received a developer reply here is over a year old and a newer version is said to be released.
#3
Updated by JohnG about 1 year ago
..So, I did quite a bit of digging and might have found the cause.
1) If I understand it correctly, KSP uses the spaceship in control as the origin of its reference frame to avoid errors at distant locations - most of the time everything is as close to your focus as possible. However, I suspect that since it repositions the universe around it with respect to the center of the craft, it may also reorient the universe, change the direction of principal axes.
2) If the spacecraft is rotating, the universe around it is actually rotating and the spaceship is staying at rest with regards to its reference frame. However, reading the code the game generates, the space the game works with is cartesian, meaning that any object not precisely along the principal axes (and moving in the respective direction only) need to be re-angled, which can cause quite a bit of error if large distances are considered, I imagine.
3) A rotating spacecraft will always change the direction of the principal axes of the universe around it (any slightest wiggle, mind you! Good luck with large ships..), and any rounding errors will result in objects being slightly off their original positions. Since these calculations are chained (the position in the next instant is calculated from the results of the previous one), the errors are propagating further and further, resulting in a drift (e.g. you are constantly rounding down or up, cycling around the predicted position).
4) Now, the fix... I imagine that if you center the universe on the craft but keep a fixed coordinate system orientation not bound to the craft, you may circumvent this bug/"feature", but maybe I'm missing something. I.e., make the universe translate around (e.g.) the root part of the craft, but make the craft rotate within this reference frame. This way, the universe should care only about the distances (and the angles from the craft will change only with the movement of the planets, not the craft), not the orientation of the spacecraft.
#4
Updated by JohnG about 1 year ago
..Or, if the game uses cartesian coordinates for mapping the universe, spherical coordinates could help, as with any rotation, there will be only changes to anglular components, not all XYZ distances. I imagine it is not common that any two objects would move exactly parallel to the cartesian axes anyway.
..Or, the origin that the game chooses for the reference frame changes slightly with any rotation (wonder why that would be), which causes periodical small adjustments to the mapped universe. If the frequency of these changes is similar to the game refresh rate (inverse of time between two successive snapshot calculations), aliasing could happen. Artificially dampening any ship oscillations matching the refresh rate (or exceeding at the bare minimum half of it, as the Nyquist theorem states) could help with this.
#5
Updated by JohnG about 1 year ago
Another "proof" that this drift is bound to the principal axes of the spaceship rotating with respect to the universe: time-warping (non-physics time-warp) keeps the craft perfectly steady and there is zero drift in the predicted pathways if the maneuver is set up while time-warping.