Intersect markers disappearing

[bewing]

This issue has been pretty constant for me since 1.1.1, I think. When I'm creating a close approach between two ships in orbit, one of the "intersection markers" (I've seen them called "brown and orange chevrons") will vanish as I pass it -- usually the brown one, because that's the one I need the most. I just did a bugtracker search because I wanted to find out what the comments on it were, and maybe to give it an up vote. And I can't find a bug report on it! Was it in a dev note or something? Or has nobody actually reported it? Or did I miss it somehow?

This is not the "marker flickering all over the place" bug. Even though my orbit crosses the other, I'm only getting one intersect point most of the time. Sometimes, if I thrust, it comes back. Sometimes not.

(BTW: *I* think the one marker is hot pink, not "brown".)

Edited May 5, 2016 by bewing

[StyrofoamBoy]

I am having the same problem. It seems like it's almost always the markers for intersect 2 that blink in and out. Once I pass intersect 1, the intersect 2 markers come back, but that's often too late to discover that your trajectory "guess" was off.

[drapetomaniac]

Yes I am having the exact same problem.  I'm running up to date 64 bit on windows.  Just as I'm trying to set up my burn to rendezvous the marker disappears.  It only displays the orange marker and not the purple one.  Before this problem began when there was only one marker displayed it would be the pink one.  I never see this now.  The problem has persisted through a few reboots.  I am a bit worried that no one has commented on this for nearly a month!

[StyrofoamBoy]

I  also still having this problem. The only lyrics solution I've come up with,  at this point, is to try and meeting at the first intersect point (which requires more fuel, because of the extra speed) or "guess" on the separation for the second intersect and then adjust at the apoapsis. After you setup your initial maneuver, warp to the apoapsis. The second intersect point and separation will then show. Usually, I can turn prograde (orbit relative) at the apoapsis and use my RCS to burn a little faster or slower and get the separation to a reasonable distance. 

[Squelch]

Does anyone have a savegame that shows this problem please? Even a screenshot of the relative orbits would be useful in narrowing down under what circumstances this happens.

[bewing]

3 hours ago, Squelch said:

Does anyone have a savegame that shows this problem please? Even a screenshot of the relative orbits would be useful in narrowing down under what circumstances this happens.

Really? It happens 100% of the time. Sure, I can put two ships in orbit and have one target the other, and make a savegame out of it.

When you pass an intersect marker, it will go stale (it will completely unhelpfully show the positive time in the past when you already passed the marker, which you already know perfectly well). When you pass the Pe or the Ap, it will disappear completely. When you thrust, it may come back intermittently. But most of the time you will only have one intersect marker, even when the orbits cross.

From what I can tell as a programmer, there are two code paths that both attempt to show intersect markers. One of them works perfectly and the other has a big fat bug in it -- when the code for both should be indentical.

OK, I stuck it in the bugtracker with a savegame and screenshots: http://bugs.kerbalspaceprogram.com/issues/9802

Edited May 29, 2016 by bewing

[StyrofoamBoy]

On 5/29/2016 at 7:18 AM, Squelch said:

Does anyone have a savegame that shows this problem please? Even a screenshot of the relative orbits would be useful in narrowing down under what circumstances this happens.

I have taken a short video of the bug in action and uploaded it to YouTube:

This happens immediately after launch, on vanilla KSP 1.1.2 x64.  This machine is a quad-core i7, with an AMD graphics card (latest drivers, non-beta).

[Squelch]

On 29/05/2016 at 4:01 PM, bewing said:

OK, I stuck it in the bugtracker with a savegame and screenshots: http://bugs.kerbalspaceprogram.com/issues/9802

 

8 minutes ago, StyrofoamBoy said:

I have taken a short video of the bug in action and uploaded it to YouTube:

Thanks for the issue and the video. These really do help in identifying the behaviour you describe.

[Snark]

I've been experiencing this issue myself, too, a lot. The "intercept #2" marker seems to disappear very often.

I haven't been able to pin down exactly what the correlation is-- hard to do without having it side by side with 1.0.5. I kinda-sorta feel like it may involve a lower tolerance for inclination difference between the two orbits, but it's hard to say for sure.

Doesn't happen 100% of the time, but does happen very frequently, enough to be a major impact on gameplay.

[OHara]

I find that the two intercept markers mark the same intersection, with #1 hiding marker #2, about 50% of the time. 

Two lines in 3D space have only an infinitesimal chance of truly intersecting.  Of course we still want to mark near intersections, and see the corresponding target-vessel positions, and the new online-help does say the markers show the "intersection (closest approach)".

But finding a closest approach (minimization) is much harder to do robustly than finding a crossing (root-finding).   In general there are 1--3 minima in the distances between Kepler orbits, merging and splitting as we adjust our orbit.

Today KSP was usually putting both marks at the closest-approach at 140° (in my figure) and often marking the one at 230° (the * in my figure) -- a very shallow minimum in distance between orbits, but with a wide catch-basin for a minimization algorithm to find.

I wanted KSP to find the places where my orbit's altitude crossed that of the target (triangles in my figure).  In the presence of a relative inclination, that is not precisely the same as the minimum distance, but for the case of rendezvous it is the altitude-crossing that I want.  If I correct my orbital inclination with a burn at the AN/DN on the way to rendezvous, the altitude crossings will remain at the same heights and times.

When the relative inclination is 0° these altitude crossings are the true intersections.  In the case where our orbit is always above, or always below, the target we want the single point on our orbit with altitude closest to the corresponding (same phase-angle from AN) point on the target orbit, and that also nicely fits the description "intersection (closest approach)".

Edited July 4, 2016 by OHara
shorten

[Bomoo]

Similar problem here. My intersect markers are so spastic and glitchy as to be unusable. Yeah I can't rendez-vous like this. I don't think they've ever been this broken in all the years I've been playing KSP.

Edited July 4, 2016 by Bomoo

[OHara]

Cross-quoting from :

> Even if the game does find a second valley, when there are three or more, the question becomes which two did it find?

... and which do the players want to have marked?

I think, @taniwha, that we want the valleys nearest the points where our orbit's altitude crosses that of the target orbit.  (If our altitude never crosses that of the target, we want just the single global-minimum closest approach, which KSP 1.1.3 finds quite robustly already.)  In the presence of inclination, the crossing points are not precisely the same as those valleys, but I think the crossing points are what we want.   My instinct would be to replace minimization algorithms with root-finding to get the crossing points, if you have code-history or enough in the regression-test suite to tell you what behavior of the old algorithms users might depend on.

Alternative to radial altitude, the altitude projected into the plane of the target orbit is a nice criteria for near-intersections, because crossings of that projected altitude behave nicely when the relative inclination crosses 90°.

[taniwha]

On 30/05/2016 at 0:01 AM, bewing said:

From what I can tell as a programmer, there are two code paths that both attempt to show intersect markers. One of them works perfectly and the other has a big fat bug in it -- when the code for both should be indentical.

There is only the one path, executed twice with different starting conditions.  The problem is the second attempt does not always clear the intervening local maximum between the two local minima and thus slides back into the first local minimum.

On 01/06/2016 at 6:51 PM, Snark said:

I haven't been able to pin down exactly what the correlation is-- hard to do without having it side by side with 1.0.5. I kinda-sorta feel like it may involve a lower tolerance for inclination difference between the two orbits, but it's hard to say for sure.

While things may (or may not) have worsened since 1.0.5, I assure you this is nothing new: I've experienced it as early as 0.23.5 (if not earlier, but that sticks out in my mind as I was trying to intercept asteroids).

On 04/07/2016 at 9:54 AM, OHara said:

But finding a closest approach (minimization) is much harder to do robustly than finding a crossing (root-finding)

This is not true if you use the right algorithm. BSP is extremely good at finding local minima (or even roots: the ultimate local minimum) and is what KSP uses. More importantly, many root finding algorithms will be destabilized by local minima.

Even more importantly, local minima are critical for celestial body encounters, and KSP uses the same code for celestial bodies as it does for vessels, though for the initial guesses for the actual SoI transitions. Not only that, but local maxima may be useful for SoI encounter calculations: if the local maximum is still within SoI range of the celestial body's orbit, you can merge the zones of the two local minima into one zone for searching for an actual encounter.

However, using the radial distances (or worse, the projection of such) is not enough: you want the actual mutual closest points of the orbits. One of the conditions for mutually closest points is the tangents at the two points are both perpendicular to the line connecting the two points (the tangents do not need to be parallel, though, and generally won't be for inclined orbits).

BTW, it's not "hot pink", it's magenta Far too saturated to be any form of pink. Also, I seem to remember my Crayola fluorescent crayons having separate hot pink and magenta crayons (too many decades ago).

[bewing]

3 hours ago, taniwha said:

This is not true if you use the right algorithm. BSP is extremely good at finding local minima (or even roots: the ultimate local minimum) and is what KSP uses. More importantly, many root finding algorithms will be destabilized by local minima.

 

As a mathematician, I have to tell you that is totally the wrong algorithm for calculating intercept points. All you have to do is project one ellipse into the plane of the other. This gives a 100% exact (closed-form) solution in every case (where the ellipses actually intersect), and is millions of times easier than finding local minima. Since the game is only showing markers on one of the two ellipses at any time, obviously you project the ellipse of the target into the plane of the focused ship.

Once the two ellipses are coplanar, as @OHara said, the calculation to find the intersection points on the focused (non-projected) ellipse is trivial, because you just calculate the (possibly degenerate) root(s).

Obviously the ellipses are also parameterized in time, but once you have the two precise intercept points on the focused ellipse, then you do an inverse calculation to get the times of the intersection points. But you also have to force that the intercept time is in the future, which is another bug that KSP fails to sometimes do.

If there is no intersection between the two ellipses, then there is another simple closed-form solution to finding the nearest point, that still does not involve calculating local minima.

Of course, finding the "closest approach" time is a completely different calculation than solving for intersection points.

Edited July 13, 2016 by bewing

[OHara]

3 hours ago, taniwha said:

Even more importantly, local minima are critical for celestial body encounters, and KSP uses the same code for celestial bodies as it does for vessels, though for the initial guesses for the actual SoI transitions. Not only that, but local maxima may be useful for SoI encounter calculations: if the local maximum is still within SoI range of the celestial body's orbit, you can merge the zones of the two local minima into one zone for searching for an actual encounter.

That seems to be working nicely to create the cyan markers.  The marked encounters seem to be the first of local minimum in the 3D distance between bodies as a function of time on their orbits.  Finding the first minimum of a non-periodic scalar function of a single variable.

3 hours ago, taniwha said:

However, using the radial distances (or worse, the projection of such) is not enough: you want the actual mutual closest points of the orbits. One of the conditions for mutually closest points is the tangents at the two points are both perpendicular to the line connecting the two points (the tangents do not need to be parallel, though, and generally won't be for inclined orbits).

That approach for orbital intersection markers would require finding the minimum distances between the orbital paths, as opposed to the distance between the bodies following those paths.  Finding several minima of a scalar function of two variables, the two independent orbital phases.   From behavior of KSP, the code seems to find restricted minimum distances, between pairs of points on the two orbits that have the same phase angle, collapsing the independent variables into one.  

Then we have to pick the one or two minimum distances that are closest (in some sense) to potential intersections, after orbits are adjusted, based on some other criteria.  After trying it myself a bit, I find altitude-crossing a fine criterion among many choices, and can find altitude-crossings directly, skipping I the minimization step.

Maybe the encounter-finding code was re-used intersection-finding, but maybe it should not be re-used. The goals are different.   We want encounter marks at the first closest approach between two bodies as a function of time.  We want potential-intersection marks at both points on our path that potentially cross a target orbit (and potentially crossing is not the same as closest approach).

[taniwha]

Last I checked, the analytic solution for the intersection of two conic sections (remember, we're not limited to circles or even ellipses, but hyperbolas too) involves fourth powers and the solution to those things is a ghastly set of several kilobyte equations (according to my attempts with maxima). If that is not the case, then please post that analytic solution here.

BSP is actually very good at finding intercepts, and more importantly local minima, especially if you know which direction you should go, and for the case of conic sections, that is a small handful of trivial analytic solutions (nothing worse than the good old quadratic). Admittedly, it can get stuck searching for local minima if you don't know which direction the next guess should take and wind up with the solution being outside the search range, but...

As for what's wanted: the points on the vessel's orbit that are closest to the target's orbit. From those points, the position of the target when the vessel is at those points can be determined. If the target is another vessel, then we are done, just draw the markers. If the target is a celestial body, then we need to determine the region around the close approach point where the vessel is within SoI distance of the target's orbit (assuming it ever is, but that check is trivial). The target's position is then checked against that range and if within SoI distance, further refinements need to be made to determine if/when the vessel crosses the target's SoI. Celestial bodies is one reason why I want to get all the local minima: some may be within SoI distance, even if the crossings are not.

One very important thing to remember is the only difference between a vessel target and a celestial body target is the size of its SoI (0 for vessels, non-zero for bodies).

Another thing: the point of actual closest approach between the vessel and the target (as opposed to the target's orbit) is of no interest: it does not tell us how to get closer. Showing this closest approach is one mistake that KSP currently makes for celestial body targets, and it does cause a lot of confusion.

[edit]The reason BSP is very good is, despite possibly getting stuck to one side of a local minima, it is always stable.

Edited July 15, 2016 by taniwha

[bewing]

6 hours ago, taniwha said:

Last I checked, the analytic solution for the intersection of two conic sections (remember, we're not limited to circles or even ellipses, but hyperbolas too) involves fourth powers and the solution to those things is a ghastly set of several kilobyte equations (according to my attempts with maxima). If that is not the case, then please post that analytic solution here.

OK, I will do so. But the point is that even now in KSP, hyperbolic transits do not have intersect markers at all. So that is a non-issue. The only time the game currently shows intersect markers is for ellipses anyway, so that is the only analytic solution that is necessary. It is not necessary to do all combinations of all conic sections. It is also possible to simply fall back on BSP for the cases that are not easy to calculate in closed form.

I need some info about your internal format for storing orbital info, though. Are you using rectilinear coordinates internally? How are you doing your time paramaterization? I will look at the persistence file and any other documentation to try to see how the state vector of a ship or celestial body is encoded.

 

Quote

 

As for what's wanted: the points on the vessel's orbit that are closest to the target's orbit.

No. Intersection points and close approach points are two completely separate calculations. That is why they have completely separate markers on the display. Orange and magenta for intersect markers, and then bigger light blue markers for the close approach markers. If you are trying to merge it all together, that may be why it's turning into a mess.

Quote

Another thing: the point of actual closest approach between the vessel and the target (as opposed to the target's orbit) is of no interest: it does not tell us how to get closer. Showing this closest approach is one mistake that KSP currently makes for celestial body targets, and it does cause a lot of confusion.

I disagree. I use it constantly. The only problem is the calculation is unstable (the close approach marker tends to jump around a lot, and its value does not vary smoothly). The close approach marker tells me if my projected orbit is late or early to hit a celestial target, and by how much. This can help me adjust my maneuver node, or it tells me how long I have to wait until my window opens. If I know the SOI size, and it tells me that the close approach is a few hundred thousand km larger than the SOI, then I know that I'm very close. You are correct, of course, that it does not tell you exactly how to get closer, though.

 

Edited July 15, 2016 by bewing

[OHara]

9 hours ago, taniwha said:

the analytic solution for the intersection of two conic sections (remember, we're not limited to circles or even ellipses, but hyperbolas too) .

I used the polar-coordinate form, parametrized by the phase angle relative to the AN (that is, the 'true anamoly' minus the true anamoly at AN for each orbit.)  That way rotating orbits into the same plane is simply a matter of ignoring the relative inclination.

Spoiler

%!matlab

p1= 1.1; % the 'semi latus rectum'  p = a*(1-e*e)
e1 = 0.9; % eccentricity
d1 = -0.9; % AN relative to argument of perihelion
p2= 7;
e2 = 0.3;
d2 = -1.7;
incl = -0.2; % relative orbital inclination
ph = linspace(0,2*pi(),3600); % common phase angle relative to AN

r1 = p1 ./ (1 + e1*cos(ph-d1));
% x1 = r1.*cos(ph);
% y1 = cos(incl).* r1.*sin(ph);
% z1 = sin(incl).* r1.*sin(ph);

r2 = p2 ./ (1 + e2*cos(ph-d2));
% x2 = r2.*cos(ph);
% y2 = r2.*sin(ph);
% z2 = r2.*0;

% Phase ph at intersections
% 1/r1 - 1/r2 = 1/p1 - 1/p2 + e1/p1 cos(ph-d1) - e2/p2 cos(ph-d2)
%             = 1/p1 - 1/p2 + [(e1/p1)*cos(d1) - (e2/p2)*cos(d2)]*cos(ph)
%                           + [(e1/p1)*sin(d1) - (e2/p2)*sin(d2)]*sin(ph)
%             = 1/P + (E/P) cos(ph-D)
% with
P = p1*p2 / (p2 - p1);
E = P * hypot((e1/p1)*cos(d1) - (e2/p2)*cos(d2),...
              (e1/p1)*sin(d1) - (e2/p2)*sin(d2));
D = atan2((e1/p1)*sin(d1) - (e2/p2)*sin(d2),...
          (e1/p1)*cos(d1) - (e2/p2)*cos(d2));
phA = D - acos(-1/E);
phB = D + acos(-1/E);
phC = D; % the closest approach if E<1 and altitudes never cross

I'm still pondering the rest of what you wrote. Bewing seems obviously right about what we want KSP to show us, but you've seen the code that makes it work through all the case you have to cover.  

I remain confident that use of altitude-crossing intersections is good advice, at least for the issue of picking which of your minima to mark.

Edited July 15, 2016 by OHara
and somebody has to tell me what BSP stands for

[taniwha]

12 hours ago, bewing said:

But the point is that even now in KSP, hyperbolic transits do not have intersect markers at all. So that is a non-issue.

Flat out wrong While they don't seem to work for celestial bodies (they were supposed to, but...), they do work for vessels (there may be circumstances under which they do not): I made them work... for 1.1. Because I like to plan waaaaaaay ahead

Screen shot taken just now from 1.1.3 (click for larger image) Note how the vessels are not in the the same SoI, even }:>

Anyway, even if intercept markers didn't show (at all) for hyperbolic trajectories, you've forgotten to whom you are talking

12 hours ago, bewing said:

I need some info about your internal format for storing orbital info, though.

That which is necessary for the circumstances. So just post your analytic solution.

 

12 hours ago, bewing said:

I disagree. I use it constantly.

Actually, you do not, and that is the problem: you do not use close approach markers constantly, but you think you do because KSP tells you that you do even though they switch between close approach and intercept.

 

9 hours ago, OHara said:

That way rotating orbits into the same plane is simply a matter of ignoring the relative inclination.

This does not work because when you rotate an orbit into another plane, you change the location of its foci. Take the obvious example: rotate a circle: it's one focus (the center) splits in two and the diverge along the AN/DN axis.

I have, however, saved your matlab code as I am curious, though I have my doubts about its validity for relatively inclined orbits due to the focus shifting.

9 hours ago, OHara said:

I remain confident that use of altitude-crossing intersections is good advice, at least for the issue of picking which of your minima to mark.

Altitude-crossing would be ok if the orbits were always nearly co-coplanar, and if they actually cross.

My problem with your stances is the two of you want me to limit the cases in which the targeting code works, and that will not happen. You think you want altitude-crossing intersections, but I know that what you (and everybody else) really want is for the targeting code to "just work", every time, and under all circumstances.

 

9 hours ago, OHara said:

and somebody has to tell me what BSP stands for

Binary Space Partition. It is excellent for root finding, so-so for minima/maxima finding unless you can get some slope information for relatively free.

[OHara]

19 hours ago, taniwha said:

As for what's wanted: the points on the vessel's orbit that are closest to the target's orbit. From those points, the position of the target when the vessel is at those points can be determined. If the target is another vessel, then we are done, just draw the markers. If the target is a celestial body, then we need to determine the region around the close approach point where the vessel is within SoI distance of the target's orbit (assuming it ever is, but that check is trivial). The target's position is then checked against that range and if within SoI distance, further refinements need to be made to determine if/when the vessel crosses the target's SoI. Celestial bodies is one reason why I want to get all the local minima: some may be within SoI distance, even if the crossings are not.

After rereading, now I understand why you want to find closest-approaches between paths for finding SoI encounters.  I suppose you really need the to find the segments of the path that lies within one SoI radius of the target path, thus the talk of local maximum distances  I had imagined that KSP propagated the bodies on rails forward in time, watching for the minimum distance between bodies as a function of (future) time.

33 minutes ago, taniwha said:

My problem with your stances is the two of you want me to limit the cases in which the targeting code works, and that will not happen.

Take it as two users who noticed that the intercept-finding is very often failing to show the two crossings that we came to depend upon, and who gave some careful thought to what it means for the code to 'work' in cases where there is inclination.

My first suggestion was to mark the points that would become intersections, if I later match inclinations as I cross the AN/DN, and the analytic solution for that is posted above.  I've left the complete matlab that makes the figures above in the directory k-ohara.oco.net/KSP (alongside where the figures above are hosted).   

[bewing]

4 hours ago, taniwha said:

My problem with your stances is the two of you want me to limit the cases in which the targeting code works, and that will not happen.

Actually, I don't. I think my calculation will give you all the intercepts that you get now, and more. Hyperbolic and everything. I've been doing it by hand and verifying all my steps. Maybe I should put it in some math software instead, so it'll go faster.

I also think I want to say that an iterative approach would also work very well -- and a hell of a lot better than how it's working now. Project the target orbit into the plane of the focused vessel. Calculate the roots. Since the conic sections have the same focus, this is only a quadratic function -- not fourth powers of anything. This will give you a very close approximation in almost all cases to the nearest points between the conic sections. Put those values as a first guess into BSP. Then iterate. The best solution should narrow down from there extremely fast, since it will almost always be within a few meters or something right from the start.

Edited July 16, 2016 by bewing

[taniwha]

3 hours ago, bewing said:

That is not your closest approach to the body, but rather your closest approach to the body's orbit. ie, a local minimum of the sort I've about which I've been writing. Remember, the body is traveling faster than your vessel, otherwise the orbits would be reversed (vessel vs body).

When your apoapsis (or periapsis) is as close as you will get to the target's orbit, then of course the solution is a simple analytic one because you know exactly when you'll be there, but that will not always be the case (or even all that often, in practice). For one, your apsis being the closest point to the target's orbit is true only when either your apsis coincides with one of the target's apsises, the target's orbit is circular, or your orbits are suitably inclined and your apsis points directly at the tharget's orbit. If your orbit crosses the target's orbit and the target's orbit is circular, then the solution is still nicely analytic (that's how SoI exits are handled (a circle is just a sphere seen edge-on. Or was it the other way? Bah, go watch Interstellar)). However, if both orbits are non-circular, then figuring things out is far less trivial, especially when relative inclination is involved.

Now, while many like to arrange so all of their rendezvous and encounters are done with theirs orbits as coplanar as possible (understandable, it makes the math easier), but that is not always the most efficient, and not everybody operates that way, so inclined orbits must be handled properly. As must non-circular target orbits and other non-Hohmann transfers.

The basic problem we have here (in this thread in its current state) is that you have a solution looking for a problem. I have a problem with some pretty harsh requirements (number one being it must work (stable, accurate, and fast) in all circumstances, not just the ideal).

Anyway, rest assured that I do have things under control, as stated in my post in this week's devnotes thread, and I have progressed significantly since the time of posting.

[bewing]

57 minutes ago, taniwha said:

The basic problem we have here (in this thread in its current state) is that you have a solution looking for a problem. I have a problem with some pretty harsh requirements (number one being it must work (stable, accurate, and fast) in all circumstances, not just the ideal).

Anyway, rest assured that I do have things under control, as stated in my post in this week's devnotes thread, and I have progressed significantly since the time of posting.

Well, after I started this thread and verified that other people were seeing it, I figured you obviously would see the issue it and get on it, so I was perfectly happy to drop it then. I only filed the bug report after Squelch wanted documentation.

I was still willing to drop it until you pinged me by quoting me on Wednesday. But hey, whatever. I look forward to being pleasantly surprised by the quality of your solution.

[taniwha]

22 minutes ago, bewing said:

was still willing to drop it until you pinged me by quoting me on Wednesday. But hey, whatever. I look forward to being pleasantly surprised by the quality of your solution.

Well, I very much hope that I will not disappoint you.

[OHara]

20 hours ago, taniwha said:

That is not your closest approach to the body, but rather your closest approach to the body's orbit. ie, a local minimum of the sort I've about which I've been writing.

Oh! That is a very subtle point when looking at one image, but now that I know about it is obvious when I move orbits around in the game. KSP jumps between putting cyan markers at the closest approach between orbital paths, and closest approach of the bodies. But regardless of the criterion for 'closest', KSP shows in text the distance between the bodies. In the case you show, the craft was probably even closer to the Mün a bit earlier than the time corresponding to the cyan markers;. (I have to take back that nice thing I said earlier about the code placing the cyan markers.)

Somehow jumpy cyan near-encounter markers never bothered me before. Having a pair of markers showing the two bodies' locations at corresponding times was enough to make me happy.

I don't find the closest approach of the orbital paths to be a useful concept, but I've beaten that dead horse too much already.  I tried KSP 1.05 and now recognize the same behavior there, so I see you've inherited code that takes that approach.  Probably good that you embrace the approach in the code you are debugging.