Autostrut functionality disabled on craft with probe cores and an active comms connection.

[Sujimichi]

OS: Windows 10 Pro 64-bit (10.0, Build 18363) (18362.19h1_release.190318-1202) KSP: 1.9.1 (build id = 02788) Installed Mods (optional): - installed via CKAN Module Manager (ModuleManager 4.1.3) RemoteTech (RemoteTech v1.9.6)

Problem:

• short description: Having a probe core with a connection to network causes autostruts to become disabled IF there is another craft present.

• longer description: If you have a craft which has autostruts enabled on some parts, and the craft has a probe core (ie OKTO2) and an antenna (ie Communotron 16-S) with connection to the comms network AND there is another craft nearby then autostruts will be disabled on all the parts which had autostrut enabled in the editor. If you look at the context menu for those parts the autostrut option is set to disabled and clicking on the button to change it does nothing, however you can still enable autostruts on parts which previously did not have them enabled.

Reproduction steps:

• install a fresh copy of KSP 1.9.1 (no DLCs, although their presence doesn't change anything)
• install Remote Tech and Module Manager via CKAN
• launch game, create and load a new sandbox save (all default options)
• when save loads dismiss the initial Remote Tech dialog (so all settings as left as default)
• go to SPH and load a stock rover (ie the Crater Crawler), launch it and drive it just off the runway and leave it there, return to space center.
• return to SPH and create a new simple craft. Just a command pod and a couple of fuel tanks (ie Mk1 Command pod + FL-T400 fuel tank + FL-T400 fuel tank). (I used that pod and tanks in testing, but I think it will work with anything).
• set autostrut to Heaviest Part on both fuel tanks
• launch the craft and right click on either tank and note that the autostrut setting is correct.
• revert back to SPH and now add an OKTO2 probe core (I think any probe core will do), and a Communotron 16-S (again, I think any activated omni antenna will do).
• launch the craft again and right click on the fuel tanks and note that now the autostruts have been disabled *1*. Also that you can't change them from disabled by clicking the button. 2**
• quicksave and reload and note that autostruts are still disabled.
• right click on the omni antenna and deactivate it
• quicksave and reload again and now autostruts will be working correctly (and you could now re-activate the antenna).

*1 While the autotruts are disabled at this point, and you can't cycle their state by clicking the button, note that if you do click the autostrut button in the context menu, when you get to the final step and they're working again, the effect of pressing the button will have been registered. ie if autostruts where set to Heaviest Part, and you clicked the context menu button once while they were not working, when you reach the final step it'll now be set to Root part instead of heaviest.

*2 If at this point you hit escape and revert to launch, then the autostruts will be working again. however if you then quicksave and reload they will no longer be working.

Logs: KSP.log Log created while going through the above reproduction steps.

Thoughts This is a really odd issue. I can't think of a reason why RT would have any impact on autotruts at all. I did wonder if it was module manager causing it, but discounted that because if you remove the RemoteTech.dll plugin (but leave MM and all RTs MM patches present) then it's not possible to recreate this issue.

In the above steps it is essential to have that other craft (the rover) present to get this issue to occur reliably. If you repeat the above steps without the rover present the issue doesn't occur. However I have had the issue happening on craft which are out of the physics range of any other craft (but other craft are present in the save).

There are other consequences which are harder to replicate. Craft which have parts which are clipped and autostrutted can end up becoming deformed (ie the clipped parts are pushed out of their position). But by removing RT (or just deleting the plugin .dll) and then reloading the save then they are returned to normal.

Possible Workaround (not ideal, but at least enables continuing without removing RT) When launching a new craft, always revert to launch first as that fixes the issue. When switching to an in-flight craft, as soon as the craft loads, disable all antenna, quicksave and reload (issue fixed) and then re-enable all antenna. (requires having the option in RT to enable/disabled antenna without connection).

Suggestion: Would it be possible to delay RT functionality when loading a craft in the flight scene? ie when launching a craft or switching to an existing craft or loading a quicksave, force all antennas to be in a deactivated state and then re-activate them once physics loading has completed. That might work around the problem without having to track down the root cause of it.

Persistent save (optional):
save_folder.zip Save folder with fresh sandbox save, just with the crater crawler rover already in position and a pre-made test craft (RT-IssueTest) in the SPH.

settings.txt Also include my main KSP settings file (just had to change the extension from cfg to txt to be able to upload it here).

Screenshot (optional): not applicable.

[KSP-TaxiService]

Hi, many thanks for your detailed reproduction steps on this odd problem.

At the step launch the craft again and right click on the fuel tanks and note that now the autostruts have been disabled ..., NullReferenceException is immediately raised on each auto-structed tank, as shown below. This side effect is simply non-functionality of auto-structing of each affected part.

Strangely, like you said, it requires another vessel within 2km physical range to trigger in the otherwise normal RT environment.

I am looking into what is triggering this error in RT codebase.

Edit: Activated antenna is required to trigger the error. Probe code connected or deactivated antenna does not trigger it alone.

[Sujimichi]

Thanks for looking into this. Remote Tech is an absolutely brilliant mod, it's really an essential part of KSP imo.

[KSP-TaxiService]

The root cause is ModuleRTAntenna.cs notifying KSP on a vessel added with RT antenna module during loading, triggering the event chain in other places included autostruct function.

// Trigger onVesselWasModified after adding a new transmitter
GameEvents.onVesselWasModified.Fire(this.part.vessel);

Particularly, the autostruc function only crashes in presence of nearby vessel and activated antenna.

I don't see any good or easy solution for this situation of an unrelated action triggering this problem, unless this notification is not sent. This notification avoidance isn't good idea if KSP and other mods need to know when vessel is modified by RemoteTech.

Like you said, the workarounds are

1. Launch with antennas deactivated
2. Launch or switch without any nearby vessel within 2km range
3. If nearby vessel within 2km range has working autostruct (under 1 or 2 above), then problem does not occur when launching or switching

[KSP-TaxiService]

Closed due to difficult fixing and rare reproduction conditions.