Log spam when editing nodes

[HebaruSan]

Background

PlanningNode version: 0.1.2

KSP version: 1.11

Problem

LOTS of these messages (a user reported 1 MB/s; I saw a 13 MB total log after testing) are filed to the log by stock code some of the time while the node editor is active:

[LOG 19:17:05.807] dT is NaN! tA: NaN, E: NaN, M: NaN, T: NaN
  at System.Environment.get_StackTrace () [0x00000] in <ad04dee02e7e4a85a1299c7ee81c79f6>:0 
  at Orbit.GetDTforTrueAnomaly (System.Double tA, System.Double wrapAfterSeconds) [0x00000] in <2afc64dea36946459d4707808bdac511>:0 
  at Trajectory.UpdateFromOrbit (Orbit orbit, System.Int32 sampleCount) [0x00000] in <2afc64dea36946459d4707808bdac511>:0 
  at PatchRendering.UpdatePR () [0x00000] in <2afc64dea36946459d4707808bdac511>:0 
  at PatchedConicRenderer.LateUpdate () [0x00000] in <2afc64dea36946459d4707808bdac511>:0 

It isn't consistent from what I have been able to gather; sometimes it happens, sometimes not.

Cause

The message says that dT, tA, E, M, and T are all NaN, which suggests to me that those are orbital elements of an orbit that hasn't been initialized. Since the orbit is a parameter to Trajectory.UpdateFromOrbit, it must be originating somewhere in the PatchRendering.UpdatePR call. So maybe there's a render patch that doesn't have a valid orbit? If we could find that patch, maybe we could set activePatch = false to prevent it from being checked like this. Don't know when that should be done, though. Before PatchedConicRenderer.LateUpdate, I guess.

[HebaruSan]

If we could find that patch, maybe we could set activePatch = false to prevent it from being checked like this.

Tried this, didn't help at all. ☹️

[HebaruSan]

Inserting extra markers at Update and LateUpdate, I count 96 messages per frame. PatchedConicRenderer.patchSamples is 48, so this suggests there are two patches somewhere with NaN elements that the renderer is trying to process. (But the Orbit constructor I'm using fully initializes everything, so these mystery orbits are coming from somewhere else.)

The messages only seem to start up once you drag one of the handles; several seconds elapse in the log between the exception that marks the opening of the editor and the start of the log spam. So maybe they're generated when the solver updates its flight plan? But why only here and not when stock does it? To be continued...

Tried removing OrbitTargeter completely; no effect.

[HebaruSan]

I think this is related to the fix from 8669492; the flight plan ends up with a NaN orbit because the starting body gets in the way of the dummy vessel's maneuvers.

Tried looping over our solver's flight plan in OnGizmoUpdated, Update, LateUpdate, and FixedUpdate and disabling and/or removing NaN orbits. The log spam continued (at a reduced rate? hard to tell). It looks like the different stock components sometimes generate the bad data and then react to it with log spam without my code having a chance to step in and clean up. It's particularly tricky because the flight plan is regenerated from scratch every time, so fixing corrupted orbits only helps if you get to it early.

Tried using the celestial body's OrbitDriver instead of making our own (by generating all components with editingNode.origin.gameObject.AddComponent<>), since the solver skips the same orbit for purposes of finding encounters, and the game immediately froze up completely.

[HebaruSan]

Seems to mostly afflict newly created orbits with 0 dV, presumably since the post-maneuver patch then intersects the original orbit a whole lot. Editing my old saved nodes with real transfers doesn't produce spam (as much?).

Maybe we could create a "delta V dead zone," where if you get too close to 0, we automatically add some vector to avoid self-intersections? I could imagine defaulting a new node to 100 m/s prograde, and if you increase that, it would be fine; if you decrease it, then we jump you to -100 m/s prograde (=100 m/s retrograde), so you can still set up both inwards and outwards transfers, just nothing too close to your starting body's orbit.

Could even attempt to trigger that behavior by searching the flight plan for NaN orbits.

Or maybe we could increase and decrease the number of allowed flight node patches based on whether real encounters have been found? Start with 2 to account for the initial orbit and one maneuver, and then if we find the patch ending in an encounter, make sure it's real, and if so, increase the limit?

[HebaruSan]

Tried setting up a 100 m/s dead zone and then 500 m/s. Log still spammed.

[HebaruSan]

I guess as a last resort, I could try to write a replacement for PatchedConicsSolver that handles this scenario without creating NaN orbits. The PatchedConics class and its important functions are public. However, other objects reference the solver by type, such as the maneuver node gizmo, so it would have to inherit.

[HebaruSan]

Or, PatchedConics.CheckEncounter is a static delegate reference to the real implementation; maybe I can override that to avoid NaN orbits?

[HebaruSan]

Fixed in e9f6809.