`PartStartStability` patch can cause "kraken shake" events on scene load

[gotmachine]

Bug report originally submitted on the forum by user @kerb8345

Provided save reproducing the issue :
kerb8345_sample.zip

In the provided save, on loading the quicksave numbered "2", the vessel quickly enter a self-reinforcing physics instability leading to a kraken event, but only when the PartStartStability patch is enabled. I've verified this reproduce in a stock install with just KSPCF installed.

I haven't investigated much, but something interesting to note is that the craft is clawed to a large mass asteroid, with four radial orange tanks docked to the main hull through small docking ports, and their autostrut mode set to heaviest part, and consequently being autostrutted to the asteroid.

Interestingly, when the PartStartStability patch is enabled, the issue can be reproduced during play and not just at the scene load, by taking those steps :

• Load the quicksave dubbed "1", where the craft is not yet clawed to the asteroid
• Set the radial tanks autostrut mode to "none"
• Approach and claw with the asteroid
• Quicksave / quickload
• Set the radial tanks autostrut mode to "heaviest part"

2025-06-21.00-01-43-619.mp4

This reproduce the physics instability, despite the Part.Start() method the PartStartStability patch is altering not being involved when the autostrut mode is changed.

This however doesn't reproduce in the following case :

• Load the quicksave dubbed "1", where the craft is not yet clawed to the asteroid
• Don't change the radial tanks autostrut mode (let it be "heaviest part")
• Approach and claw with the asteroid

This seems to indicate our modification is causing a change in the parts state, leading to the shaking behavior, a state change that is somehow reset when clawing with the asteroid (which internally involve a partial reset of the parts/vessel state).

[gotmachine]

So, there is definitely something about autostruts causing this, but I'm frankly a bit lost as to what is actually happening there...

I couldn't find any meaningful difference when comparing state dumps after loading when the patch is enabled or disabled, but this is a difficult exercise and I might have missed something.

Looking at the sequence in which stuff happens, I also cannot find anything either. Joint creation is happening seemingly in the same order and while other relevant subsystems are in the same state, at the expected exception of the last stage of Part.Start() happening before the third visual frame. The klaw active joint is created in a slightly different order, but fixing that doesn't change anything.

Something to note is that this reproduce consistently not matter the physics delta time setting.

I managed to reproduce the issue with another simpler craft that share broadly the same design :

• A Klaw attached to a central core
• 4 radial tanks attached to the central core with a coupled-in-VAB docking port in between (doesn't seem to work if directly attached through a radial attachment)
• Each radial tank must have another stack attached part
• Each radial tank must be set to the heaviest part autostrut mode.
• Keeping the symmetry link doesn't seem to matter.

Craft file : ShakeShake.zip

The issue seem to only reproduce when klawed to an asteroid. I didn't manage to reproduce it when klawing to a free floating fuel tank. When klawing to something else than an asteroid, the heaviest part autostruts strangely don't update themselves, I have to cycle them manually.

The only weird thing I'm noticing is that on Part.Start(), before the vessel is unpacked, the game create a bunch of nonsensical autostruts between parts that shouldn't have them at all. Upon unpacking, those autostruts are destroyed and the real ones are created. The behavior is a bit weird, and I'm wondering if maybe KSP might be loosing track of some of those (useless) autostrut joints due to our changes.