Pre and post-encounter trajectories are always different

[herbal space program]

Apologies if this has been pointed out many times before, but in my latest 0.90 career game (Windows 7, no mods) , I've found that how I am approaching various distant bodies according to the maneuver node interface changes quite a lot between being outside and inside of that body's SOI. For example, on a recent mission I fine-tuned my approach to Duna from around 10 days out so that the maneuver node interface said I'd hit a periapsis of 40km on an equatorial prograde orbit. When I then fast-forwarded to the inner edge of the SOI, I found that I was headed for a periapsis of 10000 km instead. As far as I can tell, the attitude of the orbit was the same, so it seems like an error in translating speed rather than direction at the SOI boundary. Anyway, this has happened to me multiple times in 0.90, and I don't especially remember having this problem in earlier versions.

Edited February 12, 2015 by herbal space program

[Superfluous J]

It's a well known bug, actually.

Don't go through SOI changes faster than 50 times. Preferably 5x, 10x, or no time warp.

I personally set up KAC alarms for all SOI changes so I'm going at normal time for every single one.

[perk]

Since 0.9 i more often encounter a problem with plotting paths into other SOI, not only on the boundery, but already at setting up the maneuver node, by continuously changing the prograde delta v i cover a region that should in its entirety lead to an encounter (change of SOI), and it shows the encounter paths for some values, but in that whole spectrum of delta v (lets call it v_min to v_max for the encounter) there are regions where the shown path flickers between "orbit around kerbol without encounter" and "path before and after the encounter", fast forwarding to the SOI change usually leads the path to be resolved into an actual encounter, even if the flickering effect stopped on the "no encounter"-version.

This is badly conveyable in screenshots but maybe i can capture a small vid of it later today.

This behaves like a precision problem, but as i described, it is not bound to a particulary hairy maneuver with 0.1 m/s making the difference of encounter or not.. its a range of several m/s where it flickers between the states (even after stopping ship parts movement with hitting fast forward)

[PB666]

It's a well known bug, actually.

Don't go through SOI changes faster than 50 times. Preferably 5x, 10x, or no time warp.

I personally set up KAC alarms for all SOI changes so I'm going at normal time for every single one.

Right, I also go down to as close to 1x as possible in crossing the SOI boundary. But I have also see the change in very steep trajectories before getting to SOI.

This is cause, i believe to an imbalance in RCS and torque wheels. What I do when a vessel is prone to this is that is:

Make sure my solar panels can pick up at any sun angle (if you can do this roll your vessel to optimal sun before making you final pre-warp config).

Kill the RCS after setting the Ap

Kill the torque of all wheels except one wheel, you can even kill the torque on the one wheel but you will have to remember to reactivate as you approach the SOI.

Validate that the closest approach did not change.

Cross fingers,

One of my complaints with 0.90 is that RCS and torque of vessel in cargo bays are active by default, and with RCS its difficult to deactivate them, this causes ships to behave oddly during turns.

The other thing I would point, the game is not very accurate for distant intercepts. Its actually a good idea to make adjustments about half the distance to the planet, you sometimes have better control along certain vectors getting away from the periapsis. On very steep trajectory the problem may be the numeric resolution limits of the operating system. For example if one is transitting Moho orbital radius to Eeloo, you may not even get an intercept, and have to travel half way to the planet on a close to intercept and then make final adjustments. If you manage to get an intercept (about 2/3rds of the time for me) it will change with anyvariance of the craft, and may change anyway in flight. I wouldn't neccesary call this a bug, per say, because minor adjustments in real flight are necessary. Of course they cannot time warp so . . . . . .

[perk]

When i tried to replicate my problem for the video i realized i was most likely wrong about the range of velocities, but non the less the soi and precision problems are huge:

after the first change of the maneuver node to 941.2 m/s it should give an encounter (it is right between v_min v_max for the encounter) but it flickers out.

After that i just show how slightly changing speeds around that critical speed totally brakes the maneuver node as it now wildly fluctuates even the delta v for the maneuver it self all by its own.

To explain a bit more: the spacecraft is in the SOI of kerbin on a kerbin escape course, and since the "escape" vector in the kerbol frame is really imprecise at that point, the orbital maneuvers in the kerbol frames glitch out.

Now it got even weirder.. while i changed nothing but the maneuver node in the video, my current path resolved from an escape from kerbin to a bound orbit with a little over 126m meters apoapsis.

The craft has 132 parts and 83 tons, which seems part of the problem. From what i am understanding about the game that is not even big, how do others cope with those huge discrepancies?

Edited February 14, 2015 by perk