Maneuver nodes/conics glitchy?

[JohnG]

Hi,

I'm quite new to the game but I feel I understand the basics. Recently I received a contract to do an Eve fly-by, so I started planning my first interplanetary mission - so far I only visited the Kerbin moons. I didn't want to complicate it and decided to do two maneuvers - one to excape Kerbin and then a correction at the descending node around the Sun to match the inclination.  Escaping retrograde at about 1020 m/s dV and then a correction of about 360 m/s would give me an intercept it seemed (and an equatorial orbit more or less).

However, when I wanted to fine-tune the intercept, the controls and predicted trajectories began to glitch out. First the maneuver node controls started acting up - no matter what button I pressed in the bottom left window, the distance was getting worse (clicking to add both normal and anti-normal resulted in a change in trajectory towards the same direction). Then, when I created a maneuver node at Eve and tried to drag it, the whole Eve fly-by conic started drifting away from the planet, as if the game was recalculating the maneuver over and over and getting a different result every time (it was not "jumping" back and forth, but steadily drifting/shifting when I held the node). Last, after another few minutes I noticed the burn dV bar next to the navball started to change values, the maneuver is set to 1020, but the displayed dV is constantly rising, past the 1500s now.

Never seen this happen when dealing with the moon transfers.

I thought it might be because the manuver is far ahead (about a year), but time-warping to 1 day before and setting up the maneuvers again resulted in the same thing. I tried restarting the game, verifying the files in the launcher, none of it helped. No mods installed, no DLCs. 

Any ideas how to fix this?

Edit: here is a visual demostration of what I mean by "drifting" and by "the delta V meter starts racing up". https://imgur.com/a/1iGNz49

Edited January 24, 2023 by JohnG
added video of what is happening

[Vanamonde]

Unfortunately this has always been a randomly occurring problem . I know of no fix.

Welcome to the forum, though.  

[JohnG]

Thanks for the reply and the welcome.

Oh, that's unfortunate. So, how do you deal with interplanetary transfers? Should I just eyeball an escape and then hope once I'm orbiting the Sun, the floating point errors (or whatever is the cause) stop acting up?

[Anth]

When Kerbin and Eve are at a certain orbit around the sun in relationship to each other there is a point where the least amount of fuel is needed to get to Eve from Kerbin. Its called a transfer window.

There is a Planner built into KSP that can create a maneuver that will get you close. Then you can make some adjustments if its a bit off.

There is no need to get into solar orbit first or even change inclination to get an encounter if you use that feature correctly.

Here it is in action:

If you want the graphical representation there's a little arrow thing at the top left where it says ManeuverTool.

Make sure the craft is pretty close to a zero inclination for it to work.

Edited January 23, 2023 by Anth12

[Jacob Kerman]

Welcome to the forum!.

Edited January 23, 2023 by Jacob Kerman

[JohnG]

Thanks Anth12, I have now tried the maneuver tool, but I'm having the exact same issue  The maneuver gets created, gives me a fly-by at about 70M m, but when I go to improve it, the encounter disappears (any change in parameters updates the new conic, which is getting worse) and the delta V countdown starts racing to some ridiculous number. I would just perform the initial burn that was planned, the problem is I can't see the remaining delta V (since it is constantly going up), only the slider and that is not accurate when it represents a 1000-1100 m/s velocity change. 

The delta V even starts to change suddenly on its own even when I don't alter the parameters. I wanted to upload two screenshots to show what I mean, but I cannot find a button to do it, I can only upload from URL, so here: https://imgur.com/a/St0LwJA

The images are taken a few seconds apart, nothing about the maneuver parameters changes, but the delta V bar is racing up, changing the displayed prediction for trajectory - even though it was set up as an encounter for Eve, now it seems I won't be hitting it at all.

Edited January 23, 2023 by JohnG

[Vanamonde]

If the intercept indicators are acting up I just try to get as close as I can and then do the transfer anyway. The impossibility of doing the burn with mathematical precision means that a mid-course correction is almost sure to be necessary whether the markers were reliable or not. 

[Anth]

1 hour ago, JohnG said:

Thanks Anth12, I have now tried the maneuver tool, but I'm having the exact same issue  The maneuver gets created, gives me a fly-by at about 70M m, but when I go to improve it, the encounter disappears (any change in parameters updates the new conic, which is getting worse) and the delta V countdown starts racing to some ridiculous number. I would just perform the initial burn that was planned, the problem is I can't see the remaining delta V (since it is constantly going up), only the slider and that is not accurate when it represents a 1000-1100 m/s velocity change. 

The delta V even starts to change suddenly on its own even when I don't alter the parameters. I wanted to upload two screenshots to show what I mean, but I cannot find a button to do it, I can only upload from URL, so here: https://imgur.com/a/St0LwJA

The images are taken a few seconds apart, nothing about the maneuver parameters changes, but the delta V bar is racing up, changing the displayed prediction for trajectory - even though it was set up as an encounter for Eve, now it seems I won't be hitting it at all.

Ok I love a good puzzle. Can you give me a quicksave of exactly where you are having this problem? Ive been playing KSP for years so whatever is happening I will know a way to counter the problem.

Easiest way to do it would be to go to the official Intercept Games Discord where you will find me as anth1256. then direct message me there. Invite is https://discord.gg/rKN46zTf Once you have opened a DM with me you can drag the Quick Save right into our private message.

Another alternative would be to submit a bug report to https://bugs.kerbalspaceprogram.com/projects/ksp and put the quick save there, though you will need to register and it will be a little more complicated.

Give me about 12 hours to respond though. I am about to do a clean install on my main computer to get back to Windows 10

[miklkit]

That sounds like my experiences with Eve also.  I have had 100% success everywhere else I have gone but only a 50% success rate with Eve.  The successes were the result of dumb luck on one and having way more fuel than needed and still using most of it in course correction after course correction.  There is no good reason to go back there.

[JohnG]

3 hours ago, Anth12 said:

Ok I love a good puzzle. Can you give me a quicksave of exactly where you are having this problem? Ive been playing KSP for years so whatever is happening I will know a way to counter the problem.

Easiest way to do it would be to go to the official Intercept Games Discord where you will find me as anth1256. then direct message me there. Invite is https://discord.gg/rKN46zTf Once you have opened a DM with me you can drag the Quick Save right into our private message.

Another alternative would be to submit a bug report to https://bugs.kerbalspaceprogram.com/projects/ksp and put the quick save there, though you will need to register and it will be a little more complicated.

Give me about 12 hours to respond though. I am about to do a clean install on my main computer to get back to Windows 10

If you wish, the quicksave is right here https://www.dropbox.com/t/nsRadLGmTFCEAE61, feel free to investigate  (or anybody else that is interested). 

If I try to adjust the maneuver and click e.g. one step prograde, the click one step back to revert it, the trajectory is not the same before and after. Also, when I lower the step to the minimum, it is low enough that if you click it in any direction, the trajectory changes only one way. The game seems to be recalculating the maneuver, but the graphics upgrade only after you change something. If you delete the maneuver and then ask the tool to set it up, the delta V drift starts almost immediately and is much faster (or maybe I didn't wait long enough in the first case). 

No rush, I've set an alarm to remind me in a year of game time to try again, I'm running other missions in the meantime. I'm interested whether you can replicate the problem, though.

 

3 hours ago, miklkit said:

That sounds like my experiences with Eve also.  I have had 100% success everywhere else I have gone but only a 50% success rate with Eve.  The successes were the result of dumb luck on one and having way more fuel than needed and still using most of it in course correction after course correction.  There is no good reason to go back there.

Well, I haven't tried any other planets yet, I was about to wait till I have all the science unlocked, but then I got a contract for Eve (for Gilly as well, actually), so I started to plan a trip there. I'll try to set up a maneuver to other planets though, see whether I get the same problem.

Edit: So I just checked, it happens with all the interplanetary transfers. With some the drift is slow (Eeloo, Duna), with some the drift is very fast (Dres, Eve)

Edited January 23, 2023 by JohnG
additional info

[Anth]

2 hours ago, JohnG said:

If you wish, the quicksave is right here https://www.dropbox.com/t/nsRadLGmTFCEAE61, feel free to investigate  (or anybody else that is interested). 

What I did in this case was take your maneuver node and made it more circular. Then showed how I do Kerbin to solar orbit to Eve encounter. This isn't the optimal way but it's the easiest way to do it for newer players.

I have time stamped it so you can fast forward through timewarp. There's a few points that I make little mistakes but for the most part it should show you how I would do this.

This is from the quicksave you posted hours ago which was either deleted or hidden.

Edited January 24, 2023 by Anth12

[JohnG]

24 minutes ago, Anth12 said:

What I did in this case was take your maneuver node and made it more circular. Then showed how I do Kerbin to solar orbit to Eve encounter. This isn't the optimal way but it's the easiest way to do it for newer players.

I have time stamped it so you can fast forward through timewarp. There's a few points that I make little mistakes but for the most part it should show you how I would do this.

This is from the quicksave you posted hours ago which was either deleted or hidden.

Yes, the save is correct, I edited the post later on to update that the same drifts were ocurring for other planets as well, not just Eve. I guess it is still waiting for approval by mods.

Thank you for taking the time, l can get an encounter like this as well, one step at a time, but the cost is about double of what it is supposed to be if you eject correctly from Kerbin  

My problem, however, still remains, that the predictions drift and don't stay constant. I was just doing a randezvous around the Mun and noticed that it happens in the Kerbin system as well (except here it was give or take 10 metres which can be easily corrected for later, unlike with an interplanetary transfer). It seems it is a global error somewhere. Did you by any chance notice that the maneuver would change amplitude in the delta V bar or that changing the parameters of the burn there and back didn't return it to the same state? Or is it happening just with my game?

[Anth]

14 minutes ago, JohnG said:

My problem, however, still remains, that the predictions drift and don't stay constant. I was just doing a randezvous around the Mun and noticed that it happens in the Kerbin system as well (except here it was give or take 10 metres which can be easily corrected for later, unlike with an interplanetary transfer). It seems it is a global error somewhere. Did you by any chance notice that the maneuver would change amplitude in the delta V bar or that changing the parameters of the burn there and back didn't return it to the same state? Or is it happening just with my game?

To clarify what is happening a video would be helpful.

Also @Vanamonde mentioned course corrections. If done at strategic points (far away from the target generally) these can tweak current trajectories.

[JohnG]

8 hours ago, Anth12 said:

To clarify what is happening a video would be helpful.

Also @Vanamonde mentioned course corrections. If done at strategic points (far away from the target generally) these can tweak current trajectories.

Definitely, here it is: https://imgur.com/a/1iGNz49 (just noticed that I recorded it at 60fpt, but the created gif is at half the rate and therefore slowed down, sorry).

The first gif shows that without me doing anything, the conic is drifting - I'm just holding the maneuver node so that it gets updated visually.  Then I change the timing there and back, but the conic still drifts only one way. This is for a node created for Duna by the maneuver tool, if I try with Eve, the conic drifts away from the encounter before I manage to create the node.

The second gif is at Eve where it is more obvious, after creation of the node, the delta V next to the nav ball goes crazy - even though I don't change the parameters, it is going up. resubmitting the initial burn parameters resets it, but it starts going up immediately again (it also updates the trajectory prediction so there is no longer an encouter once I do that). Once I adjust the node parameters in the slightest, I lose the encounter, because the predicted path in Sun's SOI changes so that it misses Eve.

Sure, I am used to midcourse corrections when I don't perform a burn perfectly, but here, I don't even know whether I'm supposed to burn 1020, 1080 or 1800 m/s, because the values keep changing.

 

Also, thanks again for taking the time  

 

Edit: I have tried creating a fresh sandbox game, cheated the ship into orbit and tried again - in the fresh save, I can see the trajectories oscillate a tiny bit (https://imgur.com/a/FNHuuRj), as I would expect with the discrete math the game does, but nowhere near to the extent by which they change in my actual save. I time-warped to about 150 days to the future (where my posted quicksave is) and the drifts/oscillations stayed the same, so it is not exclusively linked to the game time elapsed. It must be a problem with my particular gamesave then (or a combination of factors), as if the rounding errors there are greater by a few orders of magnitude for some reason.

Edited January 24, 2023 by JohnG

[Anth]

1 hour ago, JohnG said:

The second gif is at Eve where it is more obvious, after creation of the node, the delta V next to the nav ball goes crazy - even though I don't change the parameters, it is going up. resubmitting the initial burn parameters resets it, but it starts going up immediately again (it also updates the trajectory prediction so there is no longer an encouter once I do that). Once I adjust the node parameters in the slightest, I lose the encounter, because the predicted path in Sun's SOI changes so that it misses Eve.

I just don't have this problem in how I set up my maneuver nodes.

One thing I do differently is that I will get the trajectory to be at around 130000m from the Eve surface. I don't generally allow it to stay as  far away from Eve like that unless Gilly is my actual target.

The first gif was weird but if the deltav was changing on me like that I probably wouldn't even notice.

[JohnG]

10 minutes ago, Anth12 said:

I just don't have this problem in how I set up my maneuver nodes.

One thing I do differently is that I will get the trajectory to be at around 130000m from the Eve surface. I don't generally allow it to stay as  far away from Eve like that unless Gilly is my actual target.

The first gif was weird but if the deltav was changing on me like that I probably wouldn't even notice.

Well, this encounter was just for demonstration of the problem. In the actual save, I cannot get an encounter, let alone to pick the altitude. I would love to get an encounter around 130km altitude, it's just that I'm unable to for the presented reasons.

Well, I notice because before I'm able to get a decent encounter estimate, the trajectory moves away by thousands of km.

Since you don't see any such oscillations/drifts in your game, do you know whether the calculations the game makes are done on the GPU or CPU? I will try to reinstall my drivers, but it would be nice to know where to begin and not do it blindly.

[Anth]

7 hours ago, JohnG said:

Since you don't see any such oscillations/drifts in your game, do you know whether the calculations the game makes are done on the GPU or CPU? I will try to reinstall my drivers, but it would be nice to know where to begin and not do it blindly.

Any drift is from CPU calculations.

[JohnG]

So, I did quite a bit of digging and might have found the cause.   ...if anybody is still interested/puzzled by this strange issue. Let's hope they fix it in KSP2 at least.

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 the principal axes within it. 

2) If the spacecraft is rotating, the universe around it is actually rotating while the spaceship is staying at rest with regards to the KSP's used reference frame. However, reading the code the game generates, the space the game works with is cartesian (at least for part placement, I assume they also use it for the game-space, but I might be wrong), 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. 

5) Or.. maybe the game is already running like this and there are small deviations in the calculation of the center of the craft (or the origin of the coordiante system) resulting in small shifts/oscillations in the repositioning of the universe around, nevertheless, any non-translational movement of the craft changes results in errors in the universe drawn around. The problem is, the errors stay there, so the adjusted "wrong" calculations that you got in the first place will only get corrected once you get closer and the game recalculates the path with a higher precision.
Or, rewriting the code to use spherical coordinate system could help, as any rotation will result in the change of angles only, not all the XYZ distances of the objects. Just spitballing here.

A demonstration with a tiny craft that I posted on the KSP bug-tracker: https://bugs.kerbalspaceprogram.com/attachments/59003/2023-01-28 20-55-29_trimmed.mp4
A small craft (just a small tank, small engine, and a control unit) cheated into a random non-trivial orbit and set up with a maneuver to  reach a solar orbit (I tested this meanuver before recording and cut out the 30 seconds of maneuver adjusting). When the craft is stationary, the uncertainties in the predicted path are small (as seen by the oscillations of the predicted marker position by hundreds of metres halfway across the solar system), when the ship starts to rotate, the uncertainties get significantly larger, and, what is worse, the changes stay after the rotation is stopped. With a large craft that is still wiggling from the launch (and the wiggling doesn't stop completely, ever, even though it might not be visible), these errors can get multiplied if the frequencies of the oscillations/wiggles are similar to the frequency with which the game recalculates the next sample - we could call it aliasing of the calculations. In molecular dynamics, we say that the simulation blows up when the sampling interval (time step) is too small for the changes that are calculated within the system.

Edit: 

Also, if you have the same problem as I do, when you're setting up a maneuver, use 5x time-warp (not the physics one), this keeps your craft steady and prevents any observed drifts. Although, since the errors in the calculations propagate, while you may be able to set up a maneuver to your liking, in the end you might end up missing, since the game only recalculates the trajectory once you get closer... 

Edited January 30, 2023 by JohnG