Kerbal Space Program

From the screenshot posted, seems the piston is surface-attached to the hinge instead of stack-attached. Stack nodes have a fixed position, so can reliably be taken as a reference to compute the relative position of attached parts from the root part. Surface attachment doesn't involve nodes, the relative position is held in a craft file, or the section describing a vessel in game; but then, relative positions are also continuously recomputed to apply forces to parts; each time a vessel goes "on-rails" the last positions reached are saved; when goes "off-rails" the vessel is spawned using those relative positions again. Is then clear how deformations caused by a force applied to a child part and not its parent can get progressively worse. This is possibly at the root of issue #22928 too.

Please check if changing autostrutting with the piston helps (though I would certainly use the stack nodes in the case shown). If not, need the craft file and savegame where the issue shows to at least be able to verify what is happening, and hopefully test when a fix is ready. Thanks.

Hi, Thanks for the quick reply,
I have uploaded all the files i can (it wont let me upload my quicksave file), i have included a rebuilt version of the mobile base (it was changed when i discovered the bug) but it was using nodes to connect the hinges to the pistons, if you load the PNF Mobile base 2.craft file and press '1' it should open the solar panels/radiators and move the pistons and hinges to see what kind of movement they were experiencing, (i have only rebuilt the front pistons on this model for testing). Hope this helps!

PS is there any way to reset the part 'drift' with the craft files in flight (or is it hideously complicated?)

Many thanks for those craft files (impressive rover/base BTW). Yep you're right, those between hinges and pistons are stack node joints. Don't have any explanation why such joints could "drift" away and would certainly be useful to fix.
Unfortunately I couldn't reproduce the issue even with the rebuilt version of your craft. Using Timewarp when those masts are deployed, got them oscillating a lot, but nothing was displaced.
With the original craft a few modules are not recognized in a pure stock install, perhaps you had add-ons? If so, I have to trust you checked the issue happens also without any add-ons (but if not, please verify and let us know).

About "resetting" the part drift in flight. Yes, it is complicated, an operation not for the faint-hearted. WOuld do that only as a last resort; so, try first if anything like folding the masts again helps.
There is no known mechanic for "displacing" a part in flight from its current position. It takes to edit the savegame. As editing may bring to consequences, please do a backup copy first (or, take a quicksave and only edit that).
With the savegame open for editing, need to use the search feature to find what needed.
First, search for a vessel by the name of your base. Unless you renamed it, would be matching a line "name = PNF Mobile Base 2" within a "VESSEL" section.
Then, have to look for the pistons. The problem here is, there are 4 of those, what needed are the two above the hinges. So, look for those hinges first. Use the search feature with "hinge" as keyword on the VESSEL section by the name of your base. A number of matches will be found, what is of interest are only those in a "PART" subsection with "name = hinge.01.s". What we need is their ID, which isn't shown (is the number of "PART" subsections above this in the "VESSEL" section) but we have a trick: the hinges were placed in symmetry, and going down in the PART subsection will find a line named "sym =". The ID numbers show there for the other symmetry parts. For those two hinges, the IDs (Using your craft file in game) are 29 and 82.
Now back looking for pistons. Search PARTs by "name = piston.04" and watch the line below "parent =". When the ID shown with "parent" = 29 or 82, we have got our displaced parts.
Within those PART subsections matching the pistons, find the lines "position = " and "rotation = ". With the issue, some of those would be abnormal, but unless we can compute 3D axial displacements and quaternions against the root part frame of reference there's little hope of success by editing numbers. So, what I can propose is to look at a "sane" (without displaced pistons) identical vessel, obvioulsly with the masts raised. The vessel I landed on Laythe shows what follows:
piston ID = 30 (parent = 29): position = -3.0248227119445801,-0.87666702270507813,-4.6899933815002441 rotation = 0.509643376,-0.481519192,0.518668771,-0.489270777
piston ID = 83 (parent = 82): position = 3.1020503044128418,-0.87466919422149658,-4.6807441711425781 rotation = 0.519145012,0.491970301,-0.507046461,-0.480996609
(please note all those are floats in double precision, with the game running those are recomputed continuously and when the game is saved, their last values go in the save. Just a next frame and those values will have changed a bit; however what's important are the most significant digits which should not change).
The problem with this method is that it is iterative. All parts next in the tree have to be edited too. Which means, next find any part where the line "parent = " reads the ID of the previous part (in the case of pistons, 30 and 83). Again find their own ID (sym helps mightly). Again edit position and rotation lines to match a save vessel. Until no more child parts are found in the tree structure, according to the sequence of ID found.

In theory, you could simply copypaste the whole VESSEL from a sane game instance to replace the distorted one, however you would lose the states with all single part modules, resources. And you have to avoid changing anything withing the VESSEL heading (before the first PART subsection) and the VESSEL footer (after the last PART subsection).

Hi,
I have another example of part drift one another ship (mun resource ferry lander) using nodes which has drifted, i unfortunately have altered the file since but i have attached the screenshot, (The crocodile hinge was node connected to the radial surface mount and strutted for good measure) the hinge has drifted far from the radial surface mount,
Hope this helps,
Cheers!

Believe it helps too! and comes at a proper time for work on these robotic joints issues.