Maneuver Node Changing Delta-V

[pydude]

Hi. I have a problem.

Whenever I make a maneuver node, its delta-v requirements slowly change.  This makes it impossible to accurately use the nodes.  Here are some screenshots to show what is happening. There is no rcs/sas/engines running. The node does not change during timewarp, so it must be a physics issue. The predicted apopsis after the maneuver does not change. How can I stop this from happening? (if the embedded album does not work, here is a link: http://imgur.com/a/pHNpx). Thanks!

 

 

Edited June 30, 2017 by pydude

[Snark]

Hello, and welcome to the forums! 

On 6/29/2017 at 8:53 AM, pydude said:

Whenever I make a maneuver node, its delta-v requirements slowly change.

This sounds more like a bug than a gameplay problem per se, so I'll move it over to Technical Support.

A couple of questions:

• Do you get this for all of your ships all the time, or just for one particular ship?
• Have you tried running stock KSP (i.e. with no mods installed) to see if you can reproduce the problem?  If it stops happening when you're not running mods, then one of your mods is the culprit-- you should figure out which mod it is and then ask about it in that mod's thread.

 

[pydude]

This happens for all of my ships. Hmm, it does not happen in stock. It always happens in orbit, and sometimes in other situations. I'll try removeing mods one at a time and see what happens.

Edited June 30, 2017 by pydude

[pydude]

Wow... I just uninstalled all my mods, problem solved. Slowly added them back in, testing every time. Finally reinstalled them all... and discovered that the problem was gone! One my mods must have been messed up. However, another problem that I hoped was related to this one stayed. I'll make a new topic to deal with it.

[pydude]

Crud... I just looked, and the problem is back. This happened after attempting a rendezvous. The exact same problem as above began happening again. I guess I'll have to try a rendezvous after every mod I reinstall.

Okay, it seems to happen if BetterTimeWarp is installed. I'll do some more testing and probably post on their forum.

[Snark]

Ugh.  Sorry, I feel your pain, dude. 

How many mods do you have installed?  5?  20?  100?

If you only have a small handful, then one-by-one testing may be feasible.  If you have a crapload of them, then doing it one by one would be incredibly tedious.  The good news is that you may be able to mitigate the tedium with a binary search:

1. Install just half of your mods, and go through the repro steps to see if the problem occurs.
2. If it occurs, or it doesn't, then that'll tell you which half of your mod list contains the culprit.
3. Take just that half, and split it in half, and go back to step 1.
4. Repeat until you've got it narrowed down to just one mod.  Since the list gets cut in half each time, you'll need only a few repetitions even if you've got 100 mods installed to begin with.

Other things I can suggest (this is grasping at straws, but if it's quick to check, why not?):

• Have you looked in your KSP log file?  Maybe you'll get lucky and the guilty mod is making itself obvious by spamming lots of messages there or something.  (Don't spend too much time on this-- my guess is that probably nothing useful there.  But it's worth a quick visual skim, just in case.)
• Perhaps post a list here of the mods you've got installed.  Maybe someone reading it might have a suggestion as to which mods might be more likely to cause a problem.  Kind of a long shot (I'm guessing you'll get better results with the tedious narrowing-down process described above), but hey, you might get lucky, right?  Doesn't hurt.

 

[pydude]

After more testing, I have confirmed it. BetterTimeWarpContinued is the problem mod. Luckily, I had only ~5 mods, so it wasn't too bad to test. It's very odd, though. Even with BetterWarp installed, sometimes the problem takes a while to show up.

[pydude]

I posted in the mod's forum. 

 

[Enorats]

Damn, I'm having this same issue myself and it's driving me nuts. It's not just the maneuver node that's changing though, any intercepts and the like outside of your current orbit actually change too. For example, I might get into a stable orbit around Kerbin then burn to get a Mun intercept that'll pass me by with a periapsis of 60 km. After I've finished the burn though that 60 km slowly drops to 59.. 58.. 57.. over about 10 seconds. If I time warp, it freezes.. and once I'm within the Mun's sphere of influence it goes back to being stable again (though my trajectory beyond the Mun's SOI will now begin changing). Something about that mod is preventing the game from accurately predicting course alterations - everything works fine until you ask the game what'll happen when you take the ship off rails.

[pydude]

@Enorats Well, for me it was fixed just by disabling Advanced>Physics Settings>Lossless Physics in the mod's settings.

[sarbian]

On 7/18/2017 at 4:00 PM, pydude said:

@Enorats Well, for me it was fixed just by disabling Advanced>Physics Settings>Lossless Physics in the mod's settings.

Your will experience decay of the orbit for the vessel you control then. You should not deactivate core option for to make a mod working...

[pydude]

2 hours ago, sarbian said:

Your will experience decay of the orbit for the vessel you control then. You should not deactivate core option for to make a mod working...

This is not a "core option". In fact, it says "EXPERIMENTAL" right after the option. The mod functions just fine without the option, physics warp is just more like stock (kraken-prone).

[FelixB]

On 18.7.2017 at 4:00 PM, pydude said:

@Enorats Well, for me it was fixed just by disabling Advanced>Physics Settings>Lossless Physics in the mod's settings.

I have the same problem and thanks to all the hints: You have to set the Losless Physics Accuracy to 1 instead of lower values. at least it works for me on the latest build for 1.3. on November 2017