Crash-to-Desktop on separating KCT-recovered craft

[liamdennehy]

Undocking the final stage of my craft - even on the pad - seems to kick out an integer overflow exception in RealAntennas.RealAntennaDigital.BestPeerModulator. Noticed I had v1.3 installed that CKAN never tried to upgrade. Using v2.1 I get the same behaviour, but no indication in the log of the crash so only included the v1.3 mod log.

Logs here.

Occurs consistently with this craft, though re-assembling it from scratch does not seem to cause the issue. Craft has previously been recovered with KCT/RO.

[DRVeyl]

The code reference in v1.3 no longer exists in 2.1. Those methods were completely refactored. I'll need logging from v2.1. I'm not sure what the same behaviour is. I assume "this craft should have link and doesn't after undocking." There is a debug GUI available to help show why any given antenna does or doesn't have a link. But I would not assume it is the same math error.

Recovering via RP-1's KCT stores things in strange places, tho I wouldn't expect the module data to have changed. However, what is then in KCT's data storage after recovery may not match the craft file. Can you duplicate it if you load the .craft file [not load something via KCT's storage] in the VAB, build, and launch that?

[liamdennehy]

I'm not sure what the same behaviour is. I assume "this craft should have link and doesn't after undocking." There is a debug GUI...

The behaviour is a complete crash-to-desktop of KSP, see screenshot in linked zip below. Unfortunately this makes the debug GUI unavailable, the crash is immediate. As mentioned, v1.3 presents a trace in the log implicating RA, v2.1 does not but the trigger is identical so bringing it here.

Can you duplicate it if you load the .craft file [not load something via KCT's storage] in the VAB, build, and launch that?

Yes, I loaded the craft file in a sandbox and both launching and simulating causes the crash in v1.3 and v2.1. Note the included craft is the KCT recovered one, not a clean build. As I said reconstructing the craft instead of using the recovered one seems to prevent this, so I can at least proceed in my game after some troubleshooting.

New zip with v2.1 log, affected craft and screenshots of pre- and post-separation. Interestingly the craft is ejected into space too.

[DRVeyl]

This has nothing at all to do with RealAntennas.

Your game died here:

[LOG 12:28:38.787] recalculating orbit for proceduralStackDecoupler: Earth ( Update mode TRACK_Phys )
rPos: [5269719.5892776, 3050611.26650074, 1874758.35791635]   rVel: [-136.748146566306, -0.0234780196483422, 384.259449521457] |407.866866375623|
[LOG 12:28:38.787] recalculated orbit for proceduralStackDecoupler: Sun ( UT: 4365068.83231384 )
rPos: [NaN, NaN, NaN]   rVel: [NaN, NaN, NaN] |NaN|
Delta: [NaN, NaN, NaN] / [NaN, NaN, NaN]

Probably because of this in the craft file for this part: part = proceduralStackDecoupler_4292569086 partName = PartTapIn:

    MODULE
    {
        name = DecouplerTweaker
        isEnabled = True
        isOmniDecoupler = False
        ejectionImpulse = Infinity
        mass = 0.00639213249
        stagingEnabled = True
    }

If you have access to the RO Discord, I have a test build for ProcParts that "should" fix related bugs with the ProcParts Decoupler, in the #testing-needed and/or #dev-feedback channel. Or you can wait for a release in the near future.

[liamdennehy]

Thanks for the analysis. About an hour after my last comment I started mulling over the significance of being decoupled into space and ejectionImpulse = Infinity seems like a culprit.

And I'm long over due for joining the RO Discord, thanks for the prod and your handling of my useless query :)