Saving & Loading Vessel "sinking" through ground when loading save/vessel [FIX/WORKAROUND]

[LowSnow]

(NOTE: I wrote this being really tired so don't mind the spelling/grammar chaos)
Dear Devs, dear community

I've seen countless of reports mentioning vessels dissapearing beneath the surface when loading in a save. I think I might have found a "cause" for why KPS2 is doing this, but even better, I have found a way to "fix" it for people really not wanting their vessel to dissapear and be unusable. I will use an example I experienced, with a rover that was landed on Duna but for one reason or the other dissapeared underneath the surface after loading in the vessel.

What happens:

1) You launch a spacecraft towards another planet, lands on it, go back to KSC and save the game.
2) When reloading the savegame, then going to tracking station, and eventually trying to "control" the craft [doesn't matter if you first click "focus" and then "control", or just "control" right away]... the vessels seems to have dissapeared under the surface and is now sinking towards the gravitational center of the celestial object. Do understand me correctly: it is NOT  when loading in the save that the problem will happen, it is ONLY when loading in the actual vessel, via the tracking station, after loading in a save that was focused on KSC itself!

What's causing it (according to my humble opinion and basic IT knowledge):

Before going into how you can "fix" (it's kind of more like a workaround without any chance of succes, but it worked for me), I will try and explain what I noticed in the save's JSON file and what is the probable cause of the issue.
This one is going to be quite tough, but try to stay with me :p

1) I have reason to believe that the problem only kick in when the vessel is actually loaded in. What do I mean? When you load the savefile, and you take a look at the vessel via the tracking station; you can clearly see in the parameters that the vessel is landed, current speed is 0, it is not debris nor destroyed, and it contains 1 or more (dependent on the situation) crew members that are alive and well

2) When you take a look at the JSON savefile (more explanation in the section on "How to fix it") there are some parameters of that vessel that state the following (will only copy and highlight the parameters of importance, separated with "..."):
...

          "referenceBodyGuid": "Duna",
...
          "localVelocity": {
            "x": 0.0,
            "y": 0.0,
            "z": 0.0
...
          "localPosition": {
            "x": -174018.95592732367,
            "y": 257847.53725303107,
            "z": -78006.057908550778
...
          "PhysicsMode": "AtRest"
Conclusion = The vessel is on Duna, having a certain velocity in XYZ, at a certain location in XYZ, being "AtRest".
At first sight, this seems logical. The vessel is not moving, so is at rest, and this makes the velocity being 0 on all 3 axes. However, if you take in the math and physics of spaceflight, being landed and not moving on the surface, makes it impossible for the speed to be 0, since the object you're on is turning around itself, but also moving around Kerbol, which in turn is moving around in a galaxy. Even if the game took that in account, not moving on Duna being 0 will be impossible to be the same on say Mun, since their size and rotation speed are completely different. The following point proves my reasoning (I think)

3) After implementing the fix (again, I will get into the fix itself later, I'm first trying to explain the cause), and driving back with my rover to roughly the same location as I was before, saving ON SITE (so not switching back to KSC and then saving), these paramaters where as follows:

"referenceTransformGuid": "Duna",
...
          "localVelocity": {
            "x": 0.0034261178225278854,
            "y": -0.0038649328052997589,
            "z": 0.00034581124782562256
...
          "localPosition": {
            "x": -174186.96236967808,
            "y": 258054.12362081016,
            "z": -78094.052239258686
...
          "PhysicsMode": "RigidBody"
Conclusion = The vessel is (still) on Duna, having a certain velocity in XYZ being NOT ZERO (yes, my vessle was stopped with handbrake on), at a certain location in XYZ, now being on a "RigidBody".
My reasoning in the earlier point 2 seems to add up, since - even being parked and not moving - my velocity is not at absolute zero. On the other hand, my position in ALL XYZ axes seem to be higher. Obviously since I'm not stuck in the ground anymore. Another thing that is noticeable is, even if I'm completely stationary, the "PhysicsMode" now states that I'm on a RigidBody, compared to "AtRest" in the previous save JSON file.

4) I have thus 3 possible hypotheses for the reason of this problem:

     a) The "AtRest" PhysicsMode needs to be "RigidBody" instead
     b) The localVelocity can NEVER be absolute 0, but somehow the savefile is causing it to be.
     c) A combination of the above 2 hypotheses.

How to fix it (more of a workaround, Windows 10 computer):

1) Start KSP2, go to tracking station, and look for the name of your vessel that is causing the issue, write down that exact name. In my case, it was "Default Name-50". DO NOT PRESS "CONTROL"!!!
2) Save the game with the same name but add something behind it like "modify test". Example: "OriginalSaveName Modify Test". Then exit the game.
3) (Please ask community for help on other systems) Go to "search" and type in "%appdata%". If you're in "local" or "roaming", go back to the "appdata" folder and go to
LocalLow\Intercept Games\Kerbal Space Program 2\Saves\SinglePlayer\Campaignname\"OriginalSaveName Modify Test.JSON

4) Press CTRL+F and type in "assemblyName": "Default Name-50" ("Default name-50" was my name of the vessel, so this should be replaced with your vessel name) and press "search"
5) Having "CTRL+F" still open, type in "referenceBodyGuid" and click "search". After pressing search the parameters just behind the referenceBodyGuid should be the celestial body your vessel was on at that moment. (In my case being Duna).
6) Scroll down just a little bit until you see the following:
localPosition": {
            "x": -174018.95592732367,
            "y": 257847.53725303107,
            "z": -78006.057908550778
7) Now it's time for trial and error, since you'll be changing the "y" coordinates with little increments, saving and exiting the JSON file, starting KSP2, loading the save, loading the vessel and then trying to manoeuvre into a crash landing just so it doesn't destroy the vessel. In my case, it was a rover with the medium wheels, so even if I loaded in from 1000m above the surface, I would just bounce off the ground a couple of times until I finally came to a stop and could use my vehicle again.
8) In case your vessel DOES get destroyed, repeat the above steps 3-7 until you have a vehicle that is landed and completely functional (AKA not destroyed). After this, you can choose to save the ORIGINAL save file, so it overwrites the broken one, but you can also just save the game in the current game.

Please let me know if this works out for you guys. I've spent over a week to trying to analyse this problem and creating a fix.

Devs: let me know if my reasoning was right

Cheers,

LowSnow

 

Edited June 1, 2023 by Anth12

[Filed.Teeth]

Great research, hope they take it and figure it out for a future patch. 

[herbal space program]

Studying the behavior of this bug on Mun, I'm finding that I don't actually start sinking If I just go back to the KSC,  save the game, quit,  reload it, and go back to my lander from the tracking station. Going to the VAB  or training center before reloading the lander doesn't seem to cause it either, even if I launch a training mission. Neither does it happen if I load a new vessel in the VAB, put it on the launch pad, and then recover it without launching. BUT, if I actually launch that vessel into orbit and then switch over to my lander through the map interface, then whoops! Where did the ground go? Same if I switch control from my lander to the Munar orbiter part of my mission and then go back, but interestingly in that case it only happens if I actually load the flight view for the orbiter before I switch back to the lander, and not if I stay only in the map view while controlling the other vessel. So the conclusion there seems to be that loading the flight interface for another vessel that is actually in flight and outside of the physics range of the lander is what is actually required to make it sink when you return to it. On a code level, that suggests to me that somehow the fact that the new current vessel is sitting on the ground is not among the parameters that is getting updated when you switch vessels. Perhaps that is the "rigid body" physics mode part. This in turn suggests to me that maybe if I launch another vessel and land it on the ground somewhere before switching back to my lander, it will no longer sink. Off to go do that experiment now...

Edited May 21, 2023 by herbal space program

[herbal space program]

...And the answer turns out to be that even if the vessel you switch to is on the ground, you start falling when you switch back. But on the plus side, I seem to have discovered a new form of Kraken drive! If you just let your vessel keep falling, it actually doesn't oscillate around the CoM of the parent body like you'd expect. Instead, it comes shooting out the other side at absurd velocity! I think I was going about 34km/sec when I came out the other side of Mun. Going to see what amusing things I can do with this!

[Mitokandria]

I wish I had seen this before I scrapped the save as "unrecoverable". I was so upset that such a long mission (and subsequent recovery mission) was so bugged by the time I got the designs for a rescue mission and launched that I deleted the whole save file.