search

net-lisias-ksp / KSP-Recall

Recall for KSP blunders, screw ups and borks.
GNU General Public License v2.0
25 stars 2 forks source link

Consider a fix for the Docking Ports on KSP 1.12 - and a lot of similar issues since KSP 1.2 #27

Open Lisias opened 3 years ago

Lisias commented 3 years ago

On Forum, Fellow Kerbonaut Anth12 commented about how DockingPorts were handled on KSP < 1.12, and how they are done now:

1.11 and all previous versions crafts with docking ports and excluding robotics would snap back into position on timewarp/reloading scene.

This doesn't happen in 1.12, the video in my bug report shows the test craft (with 1 docking port) giving a little each time timewarp is disengaged.

In my opinion 1.12 is broken unless they give us at least a docking port variant that is using the old code.

Consider how KSP-Recall could help on this issue. KSP 1.12.2 is going to stay around for some time, as it appears.

Lisias commented 2 years ago

Nope, no need for chaining up AutoStruts. Each AutoStrut Grand Parent screws up his target independently - so more parts with AutoStruts, more targeted parts being screwed up and this fooled me on believing on a chaining only problem.

The following tests demonstrates that:

The "Alternating" craft have the Beams on the extreme of the segments (the one connected to the Girder and the one Connected to the Separator) set to AutoStrut Grand Parent. The "Just One" one have only the middle Beam set to AutoStrut Grand Parent.

savegame: [Uploading temp2.zip…]()

Lisias commented 2 years ago

Now I took the original "Bad" craft and changed the AutoStruts to Heaviest and to Root respectivelly:

screenshot8

screenshot9

savegame: temp2.zip

The problem is happening on every AutoStrut, it's not something related to Grand Parent only. And my diagnosis apparently is less than correct (or perhaps correct only for Grand Parent).

When using the heaviest auto-strut, the target part is the fuel tank that would be ejected by staging. When using Root, the target part is C7 Brand Adapter (I had to shove a lot of Launch Stability Enhancers to keep it on the place). In both cases, the deformed part was one of the docking ports. The Girder was affected only on the Heaviest one.

I probably will need some more tests to identify exactly how the AS Root and Heaviest are screwing these parts - perhaps the M.O. would be the same as Grand Parent, and the daisy chaining of the deformation would be a collateral effect of the problem, and not a direct result of the problem.

In a way or another, the conclusion is clear by now: somehow, the AutoStrut Module is screwing up part's positions and rotations when the craft changes somehow (staging for sure, perhaps any kind of part count change, or perhaps any craft change at all).

I don't think further testing is relevant from this point - since every AutoStrut is screwing up things, the fix or workaround will be (probably) the same for all of them anyway.