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

[Lisias]

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]

First attempt on commit https://github.com/net-lisias-ksp/KSP-Recall/commit/f590b7fc7185da579d0c0a702b05ccb11a77390f

[Lisias]

Moar data:

Unfixed bug on bugtraker: https://bugs.kerbalspaceprogram.com/issues/28311 Video with the problem: https://www.youtube.com/watch?v=Ah0ZY6Xpux4

Sample craft: DriftTimeWarpBug.zip

[Lisias]

I completely misunderstood the problem (as usual). The problem happens under stress, not at rest.

[Lisias]

I have something that slightly minimise the effects of the problem.

I took the craft from the previous post, launched it on the KSP airstrip and cheated the Gravity to 3.0X - this way things are way easier to reproduce:

Then I hit ">" to accelerate the time to 5, and once the timewarp reached 5 I hit "<" to go back to normal time. Once the Easying Physics stopped and the craft stopped bouncing, I took a screenshot.

Then I repeated this 9 times.

This is the final result of the process WITHOUT the new prototype for the LetsStayTogether:

And this is the final result of the process WITH the LetsStayTogether:

I managed to mitigate a bit the problem on the DockingPort itself (i.e., the craft is not sinking into the structure too much), but now the Girder are prominently being screwed up by the TimeWarp.

This hints me that the problem is on the physicsless parts, and the DockingPort are just the trigger for thus root problem.

[Lisias]

I do not aim to fix the thing, I'm focused only on undo the bad deeds. So apparently I'm not too far from the right direction.

I need to understand where is the point in which things goes down to the tubes. Once I detect this sweet spot, I can undo it later once the TimeWarp is unapplied.

Let's see what I get later once I get some sleep. :)

[Lisias]

Oh, well… Apparently I was ran over by a KSP Dev. :)

https://github.com/JPLRepo/FixDockingNodes/blob/master/FixDockingNodes.cs

However...

Inheritance in KSP is terribly flawed, not only a lot of critical code is using the class name (instead of checking inheritance), but also the way things are loaded and saved gets messed up, completely screwing up the savegame.

[Lisias]

So I did this test:

1. Installed FixDockingNodes
2. Loaded the Craft file from Anth12
3. Edited the DockingPort
4. Launched the craft
5. Created a savegame

** Figure for item 3**

** Figure for item 4 **

This is the Module section of one of the parts:

				MODULE
				{
					name = ModuleDockingNodeFixed
					isEnabled = True
					acquireForceTweak = 200
					crossfeed = False
					nodeIsLocked = True
					targetAngle = 0
					inverted = False
					stagingEnabled = True
					state = Ready
					dockUId = 0
					dockNodeIdx = 0
					EVENTS
					{
					}
					ACTIONS
					{
						ToggleLockedAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						ServoEngageLockAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						ServoDisgageLockAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						UndockAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						DecoupleAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						MakeReferenceToggle
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						EnableXFeedAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						DisableXFeedAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						ToggleXFeedAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
					}
					AXISGROUPS
					{
						targetAngle
						{
							axisGroup = None
							axisIncremental = Pitch, Yaw, Roll, TranslateX, TranslateY, TranslateZ, WheelSteer, WheelThrottle, Custom01, Custom02, Custom03, Custom04
							axisSpeedMultiplier = 0
							axisInverted = None
							overrideIncremental0 = Pitch, Yaw, Roll, TranslateX, TranslateY, TranslateZ, WheelSteer, WheelThrottle, Custom01, Custom02, Custom03, Custom04
							overrideIncremental1 = Pitch, Yaw, Roll, TranslateX, TranslateY, TranslateZ, WheelSteer, WheelThrottle, Custom01, Custom02, Custom03, Custom04
							overrideIncremental2 = Pitch, Yaw, Roll, TranslateX, TranslateY, TranslateZ, WheelSteer, WheelThrottle, Custom01, Custom02, Custom03, Custom04
							overrideIncremental3 = Pitch, Yaw, Roll, TranslateX, TranslateY, TranslateZ, WheelSteer, WheelThrottle, Custom01, Custom02, Custom03, Custom04
						}
					}
					UPGRADESAPPLIED
					{
					}
				}

Note the acquireForceTweak = 200 as this is a easy pick.

QuickSave: quicksave.zip Craft file: craftfile.zip

[Lisias]

Second test.

1. After quicksaving the previous test, quit KSP (with the craft on the runway)
2. Remove FixDockingNodes from GameData
3. Restart KSP
4. Reload the savegame
5. Select DriftTomeWarpBug with fix craft on the runway and fly it.
6. So another quicksave
7. Notre how the DockingPort was reset!!!

** Figure for item 7**

quicksave: quicksave.zip

The is the respective module section:

				MODULE
				{
					name = ModuleDockingNode
					isEnabled = True
					acquireForceTweak = 100
					crossfeed = True
					nodeIsLocked = True
					targetAngle = 0
					inverted = False
					stagingEnabled = False
					state = Ready
					dockUId = 0
					dockNodeIdx = 0
					EVENTS
					{
					}
					ACTIONS
					{
						ToggleLockedAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						ServoEngageLockAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						ServoDisgageLockAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						UndockAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						DecoupleAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						MakeReferenceToggle
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						EnableXFeedAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						DisableXFeedAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
						ToggleXFeedAction
						{
							actionGroup = None
							wasActiveBeforePartWasAdjusted = False
						}
					}
					AXISGROUPS
					{
						targetAngle
						{
							axisGroup = None
							axisIncremental = Pitch, Yaw, Roll, TranslateX, TranslateY, TranslateZ, WheelSteer, WheelThrottle, Custom01, Custom02, Custom03, Custom04
							axisSpeedMultiplier = 0
							axisInverted = None
							overrideIncremental0 = Pitch, Yaw, Roll, TranslateX, TranslateY, TranslateZ, WheelSteer, WheelThrottle, Custom01, Custom02, Custom03, Custom04
							overrideIncremental1 = Pitch, Yaw, Roll, TranslateX, TranslateY, TranslateZ, WheelSteer, WheelThrottle, Custom01, Custom02, Custom03, Custom04
							overrideIncremental2 = Pitch, Yaw, Roll, TranslateX, TranslateY, TranslateZ, WheelSteer, WheelThrottle, Custom01, Custom02, Custom03, Custom04
							overrideIncremental3 = Pitch, Yaw, Roll, TranslateX, TranslateY, TranslateZ, WheelSteer, WheelThrottle, Custom01, Custom02, Custom03, Custom04
						}
					}
					UPGRADESAPPLIED
					{
					}
				}

Note the acquireForceTweak = 100 - the valule is back to the default!

Everything on this module section was recreated from scratch, as the entire section is ripped off and a new one is injected. On every part on every craft on the savegame.

[Lisias]

TL;DR : Using https://github.com/JPLRepo/FixDockingNodes is destructive.

All your savegames wil have the ModuleDockingNodes reset to the default, you will lose all settings (include keybindings) once you install it.

And all your savegames will have it reset again if the FixDockingNodes is not installed (or the DLL does not loads by any reason).

Technically, FixDockingNodes does the right thing - but KSP guts are poorly written, hindering the solution and potentially screwing up savegames.

I will not use it, and I'll probably have to write a note about it on KSP-Recall thread.

[Lisias]

There's something else I didn't considered (but someone else did)

https://github.com/search?q=HAS%5B%40MODULE%5BModuleDockingNode%5D%5D&type=code

Every legacy add'on that supports ModuleDockingNode is going to need to be reworked to cope with the FixDockingNodes thingy.

It's one more problem to be worried about.

[Lisias]

On the bright side, migrating savegames from KSP 1.11 didn't added any new considerations. Neither from 1.10. I will skip 1.9 and 1.8 by lack of time, but there's a pretty good chance that they will work fine.

I think that migrating savegames from 1.7 may be problematic (it was for people extending the ModuleControlSurface), but at this point I don't thing there's too many people like me still using it - so I will skip it too.

[Lisias]

I found this (KSPCommunityFixes, also on Forum).

This one is promising, it does not present any of the problems I described here. And it plays nicely with KSP-Recall, so in essence I have absolutely no reason to pursue this problem on Recall.

I'm considering pinpoint it on a Warning on startup. I will think on it for a couple days and then I will take a decision and implement it.

EDIT: it was pinpointed on Forum that KSPCommunityFixes may violate the KSP EULA. Besides being very unlikely this would be pursued on Real Life (tons and tons of games are modded this way, it would be a terrible P/R for TTI not to mention being a lost cause), the KSP EULA is enforceable on Forum. (sigh) Let's see what happens - the fact is that it is the best solution at hands by now.

[Lisias]

Oukey. Found something pretty serious now.

This problem was misdiagnosed! It's not enough that the "fix" from the Developers created lot of collateral effects, and ended up in drama! The whole premisse is at fault!!! #facePalm

The root problem is not related to the ModuleDockingNode, it's something that changed on KSP guts while dealing with part's deformation, and it affects everything - the PartModule itself, and not only the ModuleDockingNode or even the Robotics!

This changed happened on KSP 1.8.0 probably (I tested it down to 1.8.1, as I don't have a 1.8.0 test bed available anymore. The following posts will demonstrate the problem.

[Lisias]

So, this is the test craft:

And this is the craft file: Untitled Space Craft.craft.zip

Once launched, the fuels tanks will bounce crazily, deforming the craft:

By hitting Stage, the fuel tanks will be ejected, and we will have a deformed craft!!

Note how the docking ports were affected (and this is 1.8.1, way before the Rotating Docking Node on KSP 1.12!!).

[Lisias]

This is the same test craft on KSP 1.12.3, where allegedly the ModuleDockingNode was "fixed":

And on launch:

And after staging:

Same thing - even worse…. :(

Test Craft: Untitled Space Craft.craft.zip

[Lisias]

And, finally, the same test on KSP 1.7.3, the last version where things worked fine:

After Staging:

And everything is fine:

Test Craft: Untitled Space Craft.craft.zip

[gotmachine]

There is something in TweakScale or another plugin you are doing that is borking that craft file.

If I rebuild the exact same craft from scratch in stock, I'm unable to reproduce your issue, and neither can I with many test design I tested.

Additionally, in 1.12.3 at least, doing the test with your craft file, then engaging timewarp or doing a F5/F9 cycle restore the non-deformed part positions, which indicate that orgPos/orgRot are actually unchanged, and only the joint positions are affected.

And final nail in the coffin, if I just remove the docking port from you craft file, I can reproduce your issue :

Said otherwise, whatever issue this is, it has nothing to do with docking ports, and doesn't relate in any way to orgPos/orgRot stock borking. It's your code inducing a bug in the editor that propagate to the craft file.

[Lisias]

There is something in TweakScale or another plugin you are doing that is borking that craft file.

~~It's something on TweakScale, no doubt.~~ [EDIT: Nope. See this comment.] Problem: that code is needed to make things work, scaled parts need to have these points replaced, the stock size points doesn't fits anymore.

If I rebuild the exact same craft from scratch in stock, I'm unable to reproduce your issue, and neither can I with many test design I tested.ing. It's your code inducing a bug in the editor that propagate to the craft file.

Nope. If you launch the craft using the launchpad, without using the editor to load it, the craft is launched all right. Whatever is happening, happens only on Editor. But the scaling code is the same for both scenarios.

~~And the damned thing works fine before KSP 1.9.0. So it's hard to conclude without further information that TweakScale suddenly resolved to misbehave just because.~~ [EDIT: nope, there's a place where this can happen].

What I think it's happening is the Editor, when merging a craft or subassembly, is shoving back prefab data on the craft being loaded instead of trusting the values on the craft file. And since TweakScale's code was made relying on the data of the craft file, the code ends up recalculating the positions wrongly, because the data it relies is not reliable anymore.

And final nail in the coffin, if I just remove the docking port from you craft file, I can reproduce your issue :

If you had spent some time reading things here, you would had found that I already had stablished that.

EDIT: yes, I'm cranky about this issue. you are clearly spending time trying to help, but sometimes you jump into conclusions in a way that it's not productive, and simetimes this affects my temper.

Said otherwise, whatever issue this is, it has nothing to do with docking ports, and doesn't relate in any way to orgPos/orgRot stock borking. It's your code inducing a bug in the editor that propagate to the craft file.

~~Please read the issue before commenting, you are injecting noise on the diagnosing.~~ EDIT: unnecessary, but kinda called for. There's better ways to say that, however. From this comment:

The root problem is not related to the ModuleDockingNode, it's something that changed on KSP guts while dealing with part's deformation, and it affects everything - the PartModule itself, and not only the ModuleDockingNode or even the Robotics!

On the other hand, in order to this be an TweakScale issue we would need to explain why it was working until KSP 1.7.3 - and what changed on KSP on 1.9.0 in order to induce TweskScale to misbehave.

It's interesting to note that TweakScale DID NOT misbehaved on KSP 1.8.1. Things started to happen on 1.9.0. Again, hardly to just rule TweakScale is at fault, as the same code works fine even on 1.8.1.

EDIT: Found a place where this can happen, and it targets KSP 1.9 specifically. EDIT2: Lines got crossed here. This paragraph talks about another problem, the SubAssembly one

Without understanding EXACTLY what changed on 1.9.0 to induce the problem, there's no ground to pinpoint TweakScale as the source of the problem. Granted, doesn't rules it out neighter.

[Lisias]

Lines are being crossed here, and I think this is start to create confusion.

We have the TweakScale problem, that I think it's not TweakScale and something that was unduly changed on KSP 1.9.0, probably to patch up some other unduly change.

And we have this another troublemaker, the parts being unduly deformed.

The problem on TweakScale happens only on Editor. The problem with the parts being unduly deformed happens, obviously, only on Flight Scene.

There can or cannot be some relation between them, but since TweakScale started to misbehave on 1.9.0, when a lot of changes happened on KSP due the changes on KSP 1.8.x, I'm working with the theory these misbehaviours can be related.

If I'm right, I need t be careful about what I do on TweakScale, otherwise I will screw up living crafts once the savegame is loaded. The problem on Editor is a pain in the ass, but it's not a savegame corrupter - I do the wrong thing here, I will corrupt savegames.

And THIS is the reason I'm terribly cranky about this issue.

[Lisias]

And final nail in the coffin, if I just remove the docking port from you craft file, I can reproduce your issue :

About this specific detail, you are completely wrong on your analysis.

TweakScale doesn't merely scales the size of a part. It scales all the part's properties (being size and attachment points some of them). So a scaled down part will suffer stress more severely than the original unscaled part.

By removing TweakScale from that part, you made the connections stronger than on the original craft file - and, so, they would deform less severely than when scaling down.

What you had shown is that TweakScale is working as intended, and since the remaining unscaled parts were deformed somehow, you just had proved exactly the opposite you are claiming!!! :)

Deformations are happening besides TweakScale.

[gotmachine]

The point I was making is that this has nothing to do with docking ports or the kind of deformation issues that you can see with 1.12 docking ports or BG robotics (since the deformation is actually purely in-physics, and not propagated to orgPos/orgRot).

And I was pointing the fact that since your craft file show this issue in a stock install, this mean TweakScale is borking some of the stock data at the VesselConstruct level. Said otherwise, TweakScale is altering some stock data in an unsupported way.

Also, when loading that craft in a stock install, I get very strange and unstable behaviors, like the camera target being offset, or the craft shifting positions when engaging non-phys timewarp. All this point to the some of the persisted craft data being in an unsupported state, due to some plugin altering it in an unsupported way.

[Lisias]

The point I was making is that this has nothing to do with docking ports or the kind of deformation issues that you can see with 1.12 docking ports or BG robotics (since the deformation is actually purely in-physics, and not propagated to orgPos/orgRot).

Again, NOT. You are misunderstanding cause and effect. There's not a PartModule for deformation, if you load a craft and the parts are incorrectly placed, you have someone mangling with the positions.

~~TweakScale DOES NOT change them~~. TweakScale updates the attachment points, and it's plain impossible for TweakScale to screw up unscaled parts. EDIT Surface attached parts needs to have these values changed, so there's a situation where TweakScale effectively changes that values. But the sample crafts don't have scaled parts attached on surfaces, so this code is not involved.

And I was pointing the fact that since your craft file show this issue in a stock install, this mean TweakScale is borking some of the stock data at the VesselConstruct level. Said otherwise, TweakScale is altering some stock data in an unsupported way.

~~What's evidence that TweakScale is not involved. Had you tried to counterproof your evidence creating a new, similar craft from scratch to see how it would behave you would had reached the same conclusions as mine.~~ EDIT Humm… Belay that, I should had tried some things first. Doing now.

As I said, you are jumping into conclusions. EDIT: and there's a chance I'm too

Also, when loading that craft in a stock install, I get very strange and unstable behaviors, like the camera target being offset, or the craft shifting positions when engaging non-phys timewarp. All this point to the some of the persisted craft data being in an unsupported state, due to some plugin altering it in an unsupported way.

The Camera Target is offset because it was calculated based on the size of the craft while saving the file. Once you remove TweakScale, the total size (and mass) of the craft will obviously change, so obviously any data that relies on this size need to be recalculated. What's not happening.

Again, not a TweakScale issue - TweakScale can't be responsible for what happens when it's unduly uninstalled!

[Lisias]

DAMN. I managed to create a situation where the deformation is not happening after staging even with TweakScaled parts.

ON THE SAME FREAKING INSTALMENT, ON THE SAME FREAKING SAVEGAME.

BOTH OF US are wrong. Or, at least, not that right.

This is the craft file that behave as expected: Untitled Space Craft 2.craft.zip

What I can be sure I know by this point:

1. The thing happens only from KSP 1.8.x and above (presumably 1.8.0, but tested only from 1.8.1 and above).
   • ~~On KSP 1.7.3, the problem just doesn't happens.~~ [EDIT: nope. The problem happens since 1.2.0 - I had borked the 1.7.3 test]
2. We have a test craft were the problem happens, and a similar craft where it doesn't. On the same savegame, using the same KSP testbed.
3. Whatever is happening, affects the craft (when it affects) when the craft is changed (perhaps part count, perhaps something more generic).
   • Quick Save/Load doesn't affects the craft as long it's done before staging. Not OnLoad/OnSave related so.
   • This tends to clear out TweakScale, as these are the handlers that could be the source of a hypothetical TweakScale bug. TweakScale doesn't acts at Flight except by these two triggers.

Since this testbed doesn't have anything installed by KSP-Recall and TweakScale (besides the usual scaffold: KSPe, MM e PartInfo), this still suggests KSP as the probable cause of the problem, as I still can't reproduce the issue on KSP 1.7.3 (and I'm trying).

[vghfr]

So what changed between 1.7 and 1.8?

[Lisias]

@staticalliam7

So what changed between 1.7 and 1.8?

For starters, they changed from Unity 2017 to 2019. A lot of changes on the physics engine's behaviour is due that. But this is not what's affecting us right now - at least not directly, we may be facing a bug introduced while writing the new support on some key handlers.

Right now, we are dealing with a change somewhere on the KSP's guts that under certain circumstances is deforming the craft. My previous guess was an intentional change on something that runs when you change the craft part count or something like that (let's call this, for while, as "onVesselStandardModification handler" as apparently the problem is happening somewhere around it), but my last post suggests I was wrong on the intentional part!

Right now, my current working theory is an unintended change somewhere else that may be exploding an exception on the mentioned code (or perhaps someone that calls it). So the exception handler is missing something, or the exception handler itself is missing, leading to the premature closure of the thread.

I suspect that such premature closure or missing exception handling can be happening also on KSP 1.7.3, but since pre-1.8.x KSP apparently does not changes the parts' position at Flight Scene, whatever was happening was not immediately visible. From KSP 1.8.x, some code is changing the parts' position at Flight Scene and so from 1.8.x the missing/borking handler is starting to bite!

It was by plain luck, but right now we are in a INFINITELY better position than before: we have two test crafts, one that borks and another that doesn't on the very same savegame on the same KSP installment. And the crafts are pretty similar, using almost the same parts, so it's feasible to eyeball them looking for differences while trying to break the good one and to fix the broken one. Once we manage to do that, we will know exactly what is the trigger of the problem, and knowing exactly what this trigger are, we can try to zero in on the perpetrator.

[anth1256]

1.8 was a pretty bad version update. my bug reports for it totalled over 30 (or 40) over the space of 1.8.0 and 1.8.1

I wouldn't be surprised if was the cause of a lot of unexpected things. (encounters was one of them. went from working ok to being much worse, even to this day)

Here's a few more bug reports relating to crafts being deformed.

https://bugs.kerbalspaceprogram.com/issues/28159 (Docking crafts on the ground can be displaced/twisted permanently) https://bugs.kerbalspaceprogram.com/issues/28160 (If a craft ends up slightly into the ground on loading a scene it will warp the craft)

The deforming recovers in 1.11.2 but doesnt recover in pre 1.12.3

[Lisias]

The deforming recovers in 1.11.2 but doesnt recover in pre 1.12.3

The deformings on this issue are not recovering on 1.12.3.

Whatever the problem is, Squad work around it by shoving a call that "undo" the deforming everywhere they found this is happening, instead of fixing the source of the problem. The aftermath is that they didn't found every possible place where the deforming is "leaking" - they just patched the most obvious places, and left the rest as is.

We manage to find the source of the deformations, we fix the problem for good.

[anth1256]

This is an older version of my truck. Its design had the following happen: It looks broken.

The following is the same truck when the game is in timewarp under 1.12.3: It fixes the broken aspect but also the wheel on the left side of the picture is submerged into the terrain slightly

KSP on coming out of timewarp will push the wheels and other parts up into the parts that are above the ground twisting them. In 1.12.0, 1.12.1, 1.12.2 sometimes I would see some sort of very vague recovery sometimes but for the most part the craft would stay completely broken.

1.12.3 all I need to do is keep timewarping off and on until the submerged wheel raises higher and higher until the truck is fully repaired (or close enough)

This isn't quite the same problem as you have been talking about above. This one is primarily caused by a craft that is submerged into the surface of the planet and then the parts below the surface are forced (swashed?) into the parts above the surface instead of moving the entire craft up.

This was the first indicator to me that docking port drift existed. When I timewarped the truck didnt snap back to its original positions.

The snapping back is happening again now which shows to me that 1.12.3 did fix a major problem.

The craft which slowly deformed further and further each timewarp was turned off and on, is that still happening? Because now that the docking port drift is gone (crosses fingers) that shouldn't be happening anymore unless its a robotic branch

[Lisias]

The following is the same truck when the game is in timewarp under 1.12.3: It fixes the broken aspect but also the wheel on the left side of the picture is submerged into the terrain slightly

The wheels appears to be unrelated. While toying with TweakScaling the wheels, I realised that the wheels's collider mesh is slightly smaller then the meshes used for drawing it. Additionally, the new terrain code is somewhat different from the KSP 1.7.x era, so we can expect some differences between how the ground colliders are made too.

I think that the wheels "submerging" are more as a effect than a cause of the problem. I think you detected a collateral effect, not the bug.

The snapping back is happening again now which shows to me that 1.12.3 did fix a major problem.

That's the point: they didn't fixed the problem, they worked around it. It's not necessarily a bad thing, but it's not so good as fixing the root problem neither - and since this bug is affecting a lot of different situations, the workaround needs to be applied on each one of them. There's a point in which it's better to just find the root cause and fix it, and so you don't have to waste time and uncountable releases until you find all the situations where the misbehaviour is bitting!

The warping you are seeing on the truck is due deformation due weight - and this is good, because we want things to bend due weight, it's what makes KSP interesting to toy with. When you time warp, the physics engine is forced to take "shortcuts" on the physics calculations, omitting some steps on the simulation to save time - let's pretend the physics engine would be dropping 2 frames each 5 in order to save some time and allow the time warping. Problem: you have weight and gravity pulling things down, and you have the materials' resistance to counter-act such force, and once you start to jump frames, the numbers stops to match the ones you get with all the frames being calculated, and so the parts drifts a bit from what you was getting without time warping.

HOWEVER, and this is where the bug relies, since KSP 1.8.x the original positions of the part are being mangled by the engine in some still undetermined situations, and so Squad had to write something to unmangle them. I don't know exactly when the mangling happens, I only detected one situation where the mangling is happening deterministically (including on KSP 1.12.3, what suggests the bug is not being fixed, but a workaround is being patched whatever they find it happening).

Until recently, entering timewarp was another deterministic situation where this happens. What Squad did was to call that workaround once you enter timewarp. Analising the FixDockingNodes stunt, I think that this workaround is the RecurseCoordUpdate(part.vessel.rootPart, part.vessel.rootPart); code. One not caring about Forum rules or risking being called out for License Violations by a member of the development team could search for every ocurrence of RecurseCoordUpdate in order to check where it's called - this would help to check how much I'm right (or wrong) about my current working theory.

[gotmachine]

One not caring about Forum rules or risking being called out for License Violations by a member of the development team could search for every ocurrence of RecurseCoordUpdate in order to check where it's called - this would help to check how much I'm right (or wrong) about my current working theory.

I am such person and almost everything you said is wrong. Especially that :

since KSP 1.8.x the original positions of the part are being mangled by the engine in some still undetermined situations

Original positions are only being updated by robotics partmodules, by 1.12.0 to 1.12.2 docking ports partmodules, and by 1.12.3 unlocked docking ports, but that's it. Again, whatever issue that craft file is causing, it is entirely unrelated to orgPos/orgRot updates.

And again, the bug you encounter is caused by a plugin messing around. Yes, something changed between 1.7 and 1.8, causing your 1.7 code to be incompatible with 1.8+. I won't spend any time investigating it, since I don't really care, but I've seen enough to be certain that the actual issue is this :

• In the editor, Tweakscale is messing around with the part positions and node positions
• While doing so, it fails at properly updating something, leaving some stock data in an incorrect state (ie, in a state that is unexpected/unsupported from the KSP code PoV)
• That incorrect data is propagated to the craft file
• In flight, when reading the craft file for launching the vessel, that incorrect data lead to an unexpected state, causing KSP to behave erratically.

Since you have two crafts, one that work and one that doesn't, I would suggest to closely compare the craft file persistent data. There has to be something different here, that will maybe point you at what that incorrect data/state is more precisely. But frankly, you won't be able to fix that one by punching at random things in the dark like you usually do. Give yourself the psychological freedom to analyze the KSP source code. Nobody cares.