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 f590b7f

[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.

[Lisias]

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

Unfortunately, you are also the person that can't tell cause from effect.

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.

So please explain why the test crafts are having the parts deformed even after uninstalling TweakScale on KSP 1.8.1, but not on KSP 1.7.3.

Without any hint about how and why this is happening, there's no other line of investigation other than considering KSP doing itself the trouble.

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.

Exactly. And since the TweakScale's code is exactly the same for KSP 1.7.3 and KSP 1.8.1, the only variable now is the KSP itself - what, again, suggests I'm right on this line of investigation.

For you being right, KSP 1.8.1 should had stopped doing something it was doing in the past and that was beneficing TweakScale somehow - what's, again, a change on KSP. It may be something like checking for Zero Mass as KSP start do on 1.5 or 1.6, and that was suddenly removed. It's a possibility, but then we would need to explain why the very same parts are working on a craft file and not on another. Same Parts, same TweakScale code, same TweakScale Exponents.

The only variable is KSP - one craft file borks on KSP 1.8.1 but not on KSP 1.7.3. And on the bottom line, it's that simple.

But frankly, you won't be able to fix that one by punching at random things in the dark like you usually do.

Your lack of communication and social skills are notorious, and already had caused triggered (*EDIT: THIS WAS UNFAIR. See this post for my apologies) a lot or trouble for everybody in the recent past. But since you also have skills that are damned good, usually the net result is positive.

However, "punching random things" are definitively a huge misjudgment of yours - a misjudgment that tends to erodes any chance of successful collaboration since you consistently insists on a line of arguing when every presented evidence suggests you are wrong - or at least, not entirely right.

Had we at least one example on this misbehaviour under KSP 1.7.x or earlier, I would be spending more time on your line of investigation - but the evidences I have suggest exactly the opposite, and I'm investing my time on the evidences I have at hands now. Remember: unscalled parts are being deformed too, and I'm damned sure TweakScale can't be doing anything on them because the Module is disabled when not needed. It's just that simple.

Even by reading the source code, I need to know first where to read. This is a misbehaviour on KSP (being it induced by 3rd parties or not), and you will not find a code calling applyMisbehaviour while doing the reverse engineering. I need to zero in on the trigger so it could be possible to focus on the code affected by it.

[vghfr]

Am I missing something, or does tweakscale keep causing issues?
why not test without tweakscale installed?

[Lisias]

Am I missing something, or does tweakscale keep causing issues?

You are missing the whole thread. TweakScale is, at best, the screaming victim and, at worst, the trigger for a problem that, until the moment, everything pinpoints to be something that changed on KSP on Release 1.8.x, as the problem just doesn't happens on 1.7.3 and before.

why not test without tweakscale installed?

Already done it. See above. The problem was reproduced the same.

The thing is that I have ONE test craft where the problem happens, and another one where it doesn't. And since I was testing TweakScale when I triggered the problem, both test crafts have Tweakscale.

I didn't managed to create a new craft, with or without TweakScale, where the problem happens. So I'm trying to mangle one of the test crafts to match the borking one, and since the borking one uses TweakScale, I'm using it too on the new one.

The only way to definitively rule out TweakScale (or realise exactly what's borking on it, in the case I'm wrong) is to reproduce the problem deterministically with or without TweakScale.

My current task is to take the working craft and somehow induce it to break. Until the moment, mangling with TweakScale module's data DID NOT reproduced the problem. The "version 3" of the working craft has now exactly the same parts the borking one uses, using exactly the same data from the respective TweakScale Modules. And yet, the "new craft" doesn't borks.

[Lisias]

Well… Just realised that the Version 3 was not exactly equal - I was using the TS-12 Stack separator instead of the (used on the borking craft) TD-12 Decoupler. Version 4 of the subject craft now uses the TD-12 - but the (good) behaviour didn't changed.

Still Work In Progress.

[Lisias]

And just for the peace of mind, I just reproduced the problem using the original borking craft file.

I had to reboot the computer today, and suddenly I remembered a terribly weird issue a fellow Kerbonaut had with Module Manager that I reproduced and documented, just to have the misbehaviour vanished from the surface of Kerbin after rebooting the machine (an obviously uninitialised memory somewhere, I'm guessing on the Mono runtime).

So I thought it could be a good idea to check that craft again, just in case.

Well, at least the thing misbehave the same - so it's still something that we can, eventually, try to fix once we figure out the damned problem.

[vghfr]

You are missing the whole thread. TweakScale is, at best, the screaming victim and, at worst, the trigger for a problem that, until the moment, everything pinpoints to be something that changed on KSP on Release 1.8.x, as the problem just doesn't happens on 1.7.3 and before.

Ohhh ok.

[Lisias]

ERRATA

The following statement of mine, quoted from a post of mine above, is UNFAIR. GotMachine was the trigger of the problems, the cause was some "Lead Engineer" that was unable to cope with criticism and probably jealously.

Your lack of communication and social skills are notorious, and already had caused a lot or trouble for everybody in the recent past. But since you also have skills that are damned good, usually the net result is positive.

He, indeed, has some problems on his communication skills that ended up triggering a situation - but as can be easily noted, so do I.

My apologies, I will try to control my verbiage and avoid such mistake again.

[gotmachine]

However, "punching random things" are definitively a huge misjudgment of yours - a misjudgment that tends to erodes any chance of successful collaboration since you consistently insists on a line of arguing when every presented evidence suggests you are wrong - or at least, not entirely right.

I have no intent of collaborating. I stumbled upon your forum post, and decided to test your "borking" craft file myself. Mainly because I did a fair bit of research on the whole part position drift issue, and because you were making a link between your tweakscale issue and the drift issue, and I wanted to see for myself.

I could have let you alone with your mess, but I figured I should at least warn you that some of your hypothesis were wrong, and give you my opinion on what the actual issue is.

So please explain why the test crafts are having the parts deformed even after uninstalling TweakScale on KSP 1.8.1, but not on KSP 1.7.3.

Even if it feels pointless, I will repeat a third time : because TweakScale alter the stock data in the editor. Resulting in that data being incorrect when the stock KSP code parse it in the flight scene. Yes, something probably changed between 1.7 and 1.8. I can only guess, my my take on this is that TweakScale always did something vaguely wrong/unsupported, but it didn't affect a critical stock code path until 1.8. And unless you're able to reproduce that issue with a craft that was designed in the editor with a 100% stock install, that's the only possible explanation.

Now, I will see myself out to stop annoying you with my terrible social skills.

[Lisias]

JESUS <insert your favorite non github aproved expletive here> CHRIST. It's the AUTO-STRUTS. I was so focused on the TweakScale and PartModule data in order to get gotmachine's hypothesis out of my way, that I forgot to look on the other Modules!!!

The diference between the working craft and the broking craft is that the Truss and the 3 M-Beams are using AutoStrut to Grand-Parent on the borking craft, and no Auto-Struts at all on the working one!

I managed to induce the Version 4 of the (good) test subject craft to bork by applying Auto-Strut to GrandParent on these 4 parts!! The Version 5 of the subject now borks the same!!!!

V4 (good boy): Untitled Space Craft 2-d.craft.zip

V5 (corrupted, ex-good boy): Untitled Space Craft 2-e.craft.zip

And now, for the counter-proof: I uninstalled both TweakScale AND KSP-Recall from the test bed, and created the following (new) misbehaving craft:

Good Boy: Untitled Space Craft - good.craft.zip

Corrupted, ex-good Boy: Untitled Space Craft - bad.craft.zip

Both crafts were created from scratch on a new SandBox savegame on KSP 1.9.1 installment WITHOUT KSP-Recall neither TweakScale (neither anything else). The Bad craft leaded to this result:

It was not determined, yet, if the misbehaviour is triggered by the Grand-Parent Autostrut, if by any AutoStrut neither if every part is affected or just some (hey, I'm on working hours - the coffee break is over!).

I will further investigate this by night.

[Lisias]

I have no intent of collaborating.

This is more than clear by now.

Even if it feels pointless, I will repeat a third time : because TweakScale alter the stock data in the editor. Resulting in that data being incorrect when the stock KSP code parse it in the flight scene. Yes, something probably changed between 1.7 and 1.8. I can only guess, my my take on this is that TweakScale always did something vaguely wrong/unsupported, but it didn't affect a critical stock code path until 1.8. And unless you're able to reproduce that issue with a craft that was designed in the editor with a 100% stock install, that's the only possible explanation.

And, again, you are wrong. See my post above.

EVERY Add'On on KSP does something unsupported. The most interesting ones ends up doing things "vaguely wrong" in order to achieve the feature. Every Single One Of Them. It's the very nature off the Add'On coding.

My last post above DEFINITIVELY proves that:

1. I was right, it's something on KSP since the beginning.
2. You are utterly and completely wrong, what's not a surprise since you had failed since the beginning to properly interpret the evidences that yourself had provided - what ended up being useful nevertheless, as it reinforced my own hypothesis (besides luring me out of the right path - but it just wasted about a couple of hours of my time)
3. TweakScale (neither Recall) isn't even remotely involved on the mess.

There're problems on TweakScale, it's the reason I maintain a bug track for it. But nearly 80% of the support tickets I had and have are due KSP bugs, or 3rd Parties borking themselves in a way that affects TweakScale. KSP-Recall was born due this crap.

You could be right? OF COURSE YOU COULD BE RIGHT. Something changes enough inside KSP and the technics used to scale things will bork for sure, as they are tied to the current way KSP does things - but such event will be catastrophic for everybody and TweakScale will complain on the KSP.log anyway, because it has a very big mouth and yells on anything that smells funny. So in order to promote TweakScale as prime suspect, proper evidence is needed - evidence that most of the time TweakScale will provide itself.

Evidence that you consistently failed to provide, while consistently failing to interpret the ones you provided.

Your insistence on pinpointing TweakScale as a source of KSP or 3rd parties problems is, from now on, being considered FUD and misinformation. And it will be handled as such - I'm just fed up of idiots slandering TweakScale to try to promote themselves or to cover up theirs or KSP's flaws and you appears to be one of them.

The alternative being you are not up to the task you are carrying on KSPModdingLibs by lack of judgment and analysis skills (at least, by now). You just can't tell cause from effect, your own evidences were supporting my hypothesis - but you, apparently, was unable to interpret even the data provided by yourself!

Besides being able to read the source code you (or someone else) reverse engineered, you failed to understand the relationship between the craft's mass and size on the Camera movements, something that it should be obvious to any KSP heavy player by now. Had you ever crashed a very heavy craft?

Of course I can't tell which of the hypotheses above is right, but since both leads to the same logical consequence, one doesn't need to know it anyway. The simple and sad consequence is that you are not trustworthy and that it's very hard to tell information from noise from your contributions to the discussions at hand.

And if I can't trust you, I can't trust your code. In the end, it's simple like that.

[Lisias]

These are the WHOLE savegame directory with a "good" craft and a "bad" craft for this problem for the following KSP versions:

• KSP 1.8.1 : temp2.zip
• KSP 1.12.3: temp2.zip

On every one of them, no TweakScale or Recall (or anything else) were available on the GameData. The savegame was created from scratch, and the craft files were remade on each savegame to rule out any influence from the UpgradePipeline.

The misbehaviour was, obviously, reproduced on all mentioned KSP versions above (see the "bad" craft). The only diference between the "good" and the "bad" crafts are the use of Grand Parent AutoStrut.

And now, A COMPLETE SURPRISE!!!! :) I Reproduced the problem on KSP 1.7.3 !!!!!

temp2.zip

I wrongly pinpointed KSP 1.8.x series as where the problem happened because I didn't properly tested for the problem on KSP 1.7.3 - not a surprise, as I didn't really knew what the problem was at first place. NOW I know better, and I will pursue the KSP release where this started to happen - assuming it's not something that it was there since the beginning of times, of course.

[Lisias]

The problem was reproduced on KSP 1.4.1 (same scheme: clean GameData, new savegame, crafts made from scratch).

The craft is not exactly the same, since KSP 1.4.1 doesn't have Mission History parts available - but this helped to rule out ModulePartVariants influence on the matter anyway.

temp2.zip

[Lisias]

And the problem was also reproduced on KSP 1.3.1 !!!

Same scheme: clean GameData, new savegame, crafts made from scratch. Since KSP 1.3.1 has a smaller palette of parts available, some different parts were used. But the misbehaviour happened the same.

temp2.zip

[Lisias]

Misbehaviour reproduced on KSP 1.2.2 .

As usual, clean GameData, new savegame, crafts made from scratch.
temp2.zip

it appears to be something happening since the inception of the AutoStrut feature, as it appears… When this feature was introduced?

[Lisias]

Unsurprisingly, KSP 1.1.3 DOES NOT presents the misbehaviour - as it doesn't have the AutoStrut feature yet. :)

You know the drill - clean GameData, new savegame, craft made from scratch. Since KSp 1.1.3 doesn't have AutoStruts, I didn't made a craft with them and, so, didn't reproduced the problem.

temp2.zip

KSP 1.1.3 was tested anyway to mark a point on time where the problem probably started to happen.

I will dig out a KSP 1.2.0 and 1.2.1 installment just for completude, as for all practical purposes this bug is with us since the first implementation of the AutoStrut feature.

[Lisias]

Reproduced on KSP 1.2.0 . I will not test 1.2.1 (as 1.2.2. also presents it).

Yada yada yada, clean GameData, new savegame, craft made from scratch.

temp2.zip

[Lisias]

I made a quick search on the bugtrack to try to find something that could be related , but on a superficial eyeballing, I didn't. There're a lot of mentions on AutoStrut, and even some bugs directly related to it - but none of them mentions deformations.

It's extremely unlikely that I'm the first to experiment this misbehaviour, so I'm guessing that this was recorded on the bugtrack without mentioning AutoStruts, as nobody had pinpointed the root cause of the deformation to it.

https://bugs.kerbalspaceprogram.com/projects/ksp/search?page=1&q=autostrut&scope=subprojects&utf8=✓

[Lisias]

Found some issues on the KSP's bug track that may (or may not) be related, I'm registering them here so I can resume the research later.

"Breaking ground parts deformation not recoverable"

https://bugs.kerbalspaceprogram.com/issues/22928

the nodes between parts is deformed due to forces ( gravity and centrifugal force etc), when you launch it and then return to space center, the deformation is saved, next time when you reload, the all parts are initialized on the deformed Position. even if the force is gone, the parts will not return to its original position. This issue can be seen if the parts (no matter stock or DLC parts) are connected through Breaking ground DLC parts.

[Lisias]

I made a Test 2 craft fuel tanks instead of trusses and Docking Ports to check if every part would be being affected by the AutoStrut problem, of if only some ones (like the physicsless parts).

Well, the problem is consistent - every part appears to be affected by it.

This is a screen shot of a test session made on KSP 1.2.2:

And this is the respective savegame (check the Test 2 and Test 2 AS crafts):
temp2.zip

[Lisias]

This is very interesting,

I retook the tests with the Untitled Space Craft Bad thingy, and removed the AutoStruts from some of the parts. This is what I got:

I removed the AutoStruts from all non M-Beam parts, and also from the Beam attached to the Girder:

However, aparently having ONE targetting a part is not enough - the first Beam to have the AutoStrut Grand Parent set is targetting the Girder, but the Girder "survived" the process unaffected!

I'm guessing that you must have two AutoStruts chained up in order to trigger the problem...

It appears that the AutoStrut (at least the Grand Parent one) is messing up with the positions/rotations of the target part, and not exactly the part in which it's set.

Savegame: temp2.zip (see the Untitled Space Craft Bad Partial).

[Lisias]

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:

• Alternating
  

• Just One
  

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]

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

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.