Jump to content

Maneuver Calculation Glitch


Recommended Posts

In KSP 1.2.1, I had been noticing an issue with maneuver calculations.  I am running Extraplanetary Launchpads, Kerbal Attachment System, and Module Manager, and I frequently launch missions from my EL-supported bases on Minmus and Gilly.  Gilly is used more frequently due to launch window frequency.  During some recent missions to Duna, my Trans-Duna Injection would be long enough that I would still be burning when I exited Gilly's Hill Sphere.  At the moment I transitioned to Eve's influence, the maneuver calculation would be thrown off, projecting me beyond Dres and requiring that the rest of the burn be completed without accurate delta V information (or worse, requiring me to switch the SAS to hold position mode to avoid a directional change that would ruin the TDI burn).

Upon yesterday's release of KSP 1.2.2, things got worse.  I launched a vessel from Kerbin on a mission to Gilly to recrew the base there.  I was able to get into a parking orbit, but during my Cis-Eve Injection, as soon as my projected course exited Kerbin's Hill Sphere, the maneuver calculation was again thrown off (this time, much more severely).  The transport vessel does not contain any EL parts, and has only one KAS part: a connector port (previous missions to Duna and Ike that experienced this issue in KSP 1.2.1 lacked even this connector port).  At around the same time as my update to KSP 1.2.2, I updated KAS to 0.6.1, which was active when I attempted the Cis-Eve Injection.  As for the other two mods I am using, I have currently EL on 5.5.4, and MM on 2.7.5.  I currently suspect that this is a KSP issue, not a mod issue (particularly since it has affected craft that had no mod-based parts whatsoever).  

Has anyone else experienced a maneuver calculation glitch (perhaps serious enough to ruin your maneuver) when either your vessel or your projected path crosses a Hill Sphere Boundary (e.g., entering that of Mun or Minmus, or exiting that of Kerbin into interplanetary space)?

Edit: On closer inspection, I noticed that my trajectory was briefly passing through the Hill Sphere of one of Kerbin's moons without the glitch occurring at that point.  It is only occurring when I my trajectory goes interplanetary.  I have also now been able to extricate myself from this situation using similar techniques to how I kept my previous Trans-Duna Injections on target.  I am now in Gilly orbit preparing for my landing, and did not experience this issue during the Eve capture, Gilly intercept, or Gilly capture burns.  I suspect it may occur again in the future unless the underlying problem is found and patched, but for now, I have worked around it.

Edit #2: The issue has recurred for another mission of similar profile (another Gilly recrew).  Between this mission and the previous one, I sent another mission from Gilly to Duna, and like in 1.2.1, the issue occurred as it exited Gilly's Hill Sphere mid-burn.

Edit #3: In yet another Cis-Eve Injection (same mission profile), I have discovered that the glitch will not occur if I am in object view (instead of map view which I have been for previous instances).  If I am in object view when my trajectory exits Kerbin's Hill Sphere, I observe the "camera snap" where it pivots about my craft to view it from another angle, which I can use as a signal for when it is safe to switch back to map mode.  The issue is still occurring, however, if and at the point at which my trajectory re-intercepts Kerbin (i.e., my orbit goes out first due to needing Eve to gain on me, and ends up exactly 1 Kerbal year long), as well as for Trans-Duna Injections from Gilly when my vessel itself (not its trajectory) exits Gilly's Hill Sphere (One of the countermeasures I am using as a workaround requires me to be in object view so I can see my altimeter and know when to switch SAS modes).

Edited by cgwhite4
New information/workaround
Link to comment
Share on other sites

  • 3 weeks later...

I have encountered a similar problem, going Kerbin-Moho. Will try your workarounds. I use a host of mods, but not EL, so I do not think it is the issue.

I run KSP 64 bit on a win 7 enterprise. No specific information found in KSP.log, but I will try to keep exact time on when it happens.

Found the issue on the bug tracker and added a piece of information: What happens is that the maneuver node gets relocated to the next patched conic. If you move it in time, it gets located back.

Edited by Freshmeat
Link to comment
Share on other sites

  • 2 months later...

In addition to these issues still persisting for quite some time (mainly causing me problems when launching from Gilly), I am now experiencing another maneuver calculation issue while attempting to calculate a Cis-Moho Injection from Gilly.  This time, the problem is occurring during calculation, instead of during the resulting burn.  The intercept indicator keeps locking on to a "false intercept" shortly ahead of my position but nowhere near Moho's orbit, instead of the node (descending or ascending) near the intersection of the calculated orbit and Moho's orbit.  I may be arriving way early or way late, but I need to know which to know what adjustments I need to make to my orbit to get an encounter, and that can only happen if the intercept indicator tells me what is happening at the appropriate node instead of getting distracted by a "false intercept".  It would be very helpful if the intercept indicator could be adjusted so that "false intercepts" could be ignored.  My current mods are EL 5.7.1, MM 2.7.5, KAS 0.6.2, and KAS 0.7.3 (0.7.3 is a Beta of an eventual 1.0, and is non-conflicting with 0.6.2, according to IgorZ).  However, I do not believe any of these mods could be causing the problem.

Perhaps one way to eliminate/workaround this problem is allowing for orange and purple intercept indicators if the target is a celestial object (at this point, this only happens if the target is a vessel).  This way, even if the orange intercept indicator got distracted by the "false intercept", the purple intercept indicator would then appear on the correct node, allowing me to see what is really happening (whether I am early or late) and take the necessary corrective action.

Edit: I tried making an SFS-edit to move a piece of space junk into Moho's Hill Sphere to lock on to as an alternative target, but no intercept indicators appeared.  When positioning the junk just outside of Moho's Hill Sphere, I was able to get an intercept indicator, but it failed to provide me with sufficient accuracy due to deviations between its orbit and that of Moho (which become significant in the time it takes for Moho to move from its current position to the intercept position.

Edit #2: After double-checking with Alexmoon's calculator, it appears I have gotten very unlucky as to the time my vessel was completed (via Extraplanetary Launchpads) and launched from Gilly.  This suggests I will have to try a different, riskier, and more aggressive approach with my burn.

Edit #3: The strategy change enabled me to get a good intercept, and my vessel is now safely on the surface of Moho.

Edit #4: This bug has now also been observed while attempting to intercept Bop from Pol, occurring when my trajectory re-intercepted Pol.  Looks like it is not just interplanetary trajectories that are affected, but also interlunar trajectories at Jool.

Edited by cgwhite4
Bug occurred in new situation
Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...