Flight Docking Ports Not Docking [Possibly Happens When Trying To Re-Dock After Undocking]

[Stenner]

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes 
OS: Windows 11 Pro 64-bit (10.0, Build 22631) | CPU: 13th Gen Intel (R) Core (TM) i7-13700KF | GPU: NVIDIA GeForce RTX 4080 | RAM: 32366 MB

 

I accidentally submitted this somewhere else so here it is, here.    You can load the save and they're touching but will not connect, nothing seems to be occluded, each part was previously attached to something and they've been docked since, but not when they meed after rendezvous from the mun.  any help is welcome, thanks.

 

Included Attachments:

OsirisMKIV.json

ksp2save.zip

Edited January 2 by The Space Peacock

[antra]

The problem is `PartComponentModule_DockingNode` module state of the `dockinport_vX_inline` part has ModuleData.DataObject.CurrentState incorrectly set to "Docked" when it should be "Ready". The exact cause for this is unclear, but in my testing it involved previous docking and undocking with a separately launched craft. In some circumstances undocking does not cleanly reset the CurrentState to "Ready". 

The immediate workaround involves editing the save file manually. Its fairly tedious, but not hard if you are comfortable with JSON. It can probably be automated in a community fix mod. The steps would be as follows:

1. Identify the two craft with difficulty docking. Note their craft names
2. Locate the JSON dicts corresponding to the craft names. Search for `"assemblyName": "your_craft_name"`. Optionally note the Guid.Guid in the beginning on the dict containing the AssemblyDefinition found. The guids make the dicts easier to find if you need to look them up again. 
3. Copy the entire craft dict to separate file. It is easier if you use something like VSCode to enable folding of JSON dicts and lists.
4. In the craft dict search for `dockingport_v`. This may produce multiple matches if there is more than one docking port.
5. For each docking port dict search for `"CurrentState":`. If this dock port is showing `Docked` when it shouldn't, change it to `Ready`. You can examine the attach points to see if there is anything attached to the 'top'. If there is a null part with 0000 guid, that means that there is nothing attached, otherwise you will see a proper part link.

For resolution it would be very helpful to test various docking and undocking scenarios. One interesting case to test is the following:

1. Launch 2 crafts, craft A and craft B. Craft A should have a pair of docking ports in pre-docked configuration.
2. Separate the pre-docked dock ports in craft A after launch.
3. Bring in craft A and craft B to immediate vicinity and dock. Optionally conduct resource transfer, but not likely to matter.
4. Undock craft A without switching control to craft B
5. Leave the vicinity in craft A (so that craft B is no longer rendered or shown as a marker on HUD).
6. Check the save-file state for the CurrentState of docking port of craft B and craft A. 

It is possible that the issue is related to incorrect state initialization after the craft is loaded from save file and then undocked.

Edited January 4 by antra

[jclovis3]

I just had an occasion where the docking port "CurrentState" was "Acquire_Docker" rather than Docked or Ready. Replacing it with Ready worked, just the same.

[Ezekiel]

I have the same problem with the medium size docking port not pairing with another. I would like to upload my save file but the forum is not letting me at the moment. 

[Elnod]

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes 
OS: Windows 10 | CPU: AMD Threadripper 1920X | GPU: RTX 2060 and GTX 1070 Ti | RAM: 32 GB

I've just encountered a situation where I docked via medium docking ports a crewed hydrogen ship with a double-2XL hydrogen fuel station around Jool, and after exploring some more of its moons (Bop and Pol) with the orbital survey, returned to the hydrogen fuel station to refuel for the trip back to Kerbin. I intercepted it successfully and pointed both docking ports at each other with SAS, they meet up perfectly at 0.5 - 1 m/s but the ships just bounce off each other. I've tried accelerating again and trying to dock several more times, but it does not resolve. 

I just tried reloading a save and unfortunately that doesn't fix it either.

Included Attachments:

[The Aziz]

This is important as plenty of people faced that: 

 

[The Space Peacock]

@Elnod merged your report

also changed the title to be a bit more clear and include a mention of undocking then trying to redock as a possible cause for this

[jclovis3]

I found this online JSON editor handy for branching down the nodes in a collapsible node tree.
https://jsonviewer.stack.hu/

In my instance, I did dock with another ship to get fuel, and they use the medium size docking node, both inline. Later, I used to newly refueled ship to dock with a newly launched ship. They wouldn't dock. I checked their states in the save file and found the refueled ship to have the bad state. The online tool doesn't make editing easy so I had to go back into Wordpad and make my way down with the Find tool using the node tree as a guide for what to search for. Multiple searches brought me along the stack to the right part on the right ship.

Some thing I think we might want to test is weather this bug occurs from using the docking port on the affected ship to undock in the previous instance, or use the docking port from the ship we previously docked with to undock and see if this decision can reliable trigger the bug. In old KSP1, you could not choose either docking port. Only one would have the undock action available.

[Ezekiel]

@antra Thanks for the write up. Editing the save file fixed the issue for me. Seems like the state is sometimes not getting set to "Ready" after things have decoupled/undocked from the node.

[The Aziz]

I tried replicating this on Kerbin. Had two rovers docked together, undocked, drove around a bit, but had no issues docking back. (However, it caused some symmetry control issues, to be reported) There must be something else that triggers the port state switch. A situation of one, perhaps?

[rnt_hank]

15 hours ago, jclovis3 said:

I just had an occasion where the docking port "CurrentState" was "Acquire_Docker" rather than Docked or Ready. Replacing it with Ready worked, just the same.

My ship is saved!  You guys are my heroes, thank you all!  (Acquire_Docker on the refuel ship's port was the culprit)

For posterity, on this mission (refuel #6), while in the editor, I used a docking port from a sub-assembly to attach a heat-shield instead of grabbing a new one out of the menu bar.  It was attached *to* the port that failed.   Not sure if that could be related but it's the only significant change I made for this mission.

[jclovis3]

22 hours ago, The Aziz said:

I tried replicating this on Kerbin. Had two rovers docked together, undocked, drove around a bit, but had no issues docking back. (However, it caused some symmetry control issues, to be reported) There must be something else that triggers the port state switch. A situation of one, perhaps?

You tested this by docking the same rovers twice? There is a line item in the save files for last docked part. Maybe repeating the same connection isn't going to reproduce the bug. Try docking rover A with rover B, then undock using the docking port on rover A while in control of rover A. Then dock rover A to rover C. Now repeat test by undocking A/B using the docking port on Rover B while the controlling part is still on rover A. Then Dock each with rover C one at a time and see what happens. I've been meaning to get around to this but been busy with another mission.

It seems to me, the culprit could be related to which part has control and which docking port is closest or farthest from that controlling part at the time of separation, or which part is used to cause the separation. There are at least six different combinations of this to run through.

Edit: I just ran some tests with three rovers and verified the smaller docking ports as well as the Docking Port Sr, which is what I most commonly see this bug with. In my tests between three different rovers and all combinations of controlling parts and which part was used to decouple, I could not replicate. I know this bug happens though, so we might need someone with access to the code to drill down and find it.

Edited January 8 by jclovis3
Added results of further testing.

[The Aziz]

6 hours ago, jclovis3 said:

You tested this by docking the same rovers twice? There is a line item in the save files for last docked part. Maybe repeating the same connection isn't going to reproduce the bug. Try docking rover A with rover B, then undock using the docking port on rover A while in control of rover A. Then dock rover A to rover C. Now repeat test by undocking A/B using the docking port on Rover B while the controlling part is still on rover A. Then Dock each with rover C one at a time and see what happens. I've been meaning to get around to this but been busy with another mission.

The initial bug occured to me with Apollo style vehicle. Lander below the transfer stage, docked together in orbit, undocked above the Mun, landed, returned, unable to dock back. But since I couldn't replicate "dock then undock then fail to dock again", there must be more to it.

[TygeR]

On 1/4/2024 at 10:13 PM, antra said:

The problem is `PartComponentModule_DockingNode` module state of the `dockinport_vX_inline` part has ModuleData.DataObject.CurrentState incorrectly set to "Docked" when it should be "Ready". The exact cause for this is unclear, but in my testing it involved previous docking and undocking with a separately launched craft. In some circumstances undocking does not cleanly reset the CurrentState to "Ready". 

The immediate workaround involves editing the save file manually. Its fairly tedious, but not hard if you are comfortable with JSON. It can probably be automated in a community fix mod. The steps would be as follows:

1. Identify the two craft with difficulty docking. Note their craft names
2. Locate the JSON dicts corresponding to the craft names. Search for `"assemblyName": "your_craft_name"`. Optionally note the Guid.Guid in the beginning on the dict containing the AssemblyDefinition found. The guids make the dicts easier to find if you need to look them up again. 
3. Copy the entire craft dict to separate file. It is easier if you use something like VSCode to enable folding of JSON dicts and lists.
4. In the craft dict search for `dockingport_v`. This may produce multiple matches if there is more than one docking port.
5. For each docking port dict search for `"CurrentState":`. If this dock port is showing `Docked` when it shouldn't, change it to `Ready`. You can examine the attach points to see if there is anything attached to the 'top'. If there is a null part with 0000 guid, that means that there is nothing attached, otherwise you will see a proper part link.

For resolution it would be very helpful to test various docking and undocking scenarios. One interesting case to test is the following:

1. Launch 2 crafts, craft A and craft B. Craft A should have a pair of docking ports in pre-docked configuration.
2. Separate the pre-docked dock ports in craft A after launch.
3. Bring in craft A and craft B to immediate vicinity and dock. Optionally conduct resource transfer, but not likely to matter.
4. Undock craft A without switching control to craft B
5. Leave the vicinity in craft A (so that craft B is no longer rendered or shown as a marker on HUD).
6. Check the save-file state for the CurrentState of docking port of craft B and craft A. 

It is possible that the issue is related to incorrect state initialization after the craft is loaded from save file and then undocked.

This seems to be the case in my save file as well. One of the two docking ports CurrentState lists Docked. My normal way of undocking is to right click the dock port and then select undock from the component manager. It seems that the bug causes only the state of the selected dock port to change to undocked/ready. The other docking port still remains "docked".  Basically the origin of this bug is redundancy in the craft data. As the dock state is appearent in multiple locations. This is considered bad practice and bug prone. It's sad to see that even though they restarted programming KSP2 from scratch they still have got many core failures in the way it is (sloppily) programmed.

I'm glad this is another bug we can work around now and hope the redundancy issue (which occurs on more than the dock port part) can be fixed.

Thanks to antra for pointing us to this issue and workaround,

[The Aziz]

I have done a very similar mission like the one where I encountered the bug - but it worked (almost) flawlessly. On approach it bounced off a little but docked a second later. So not very reliable, I hope the team can get to it regardless.

[tweaked9107]

Reported Version: v0.2.0 (latest) | Mods: none | Can replicate without mods? Yes 
OS: Windows 11 | CPU: Intel i9-9900k | GPU: NVIDIA RTX 2080 Ti | RAM: 32GB

With the docking clamp-senior I undock the "command" module with my pilot in. The part of the rocket behind is controlled by a probe module and has a docking port both ends with the opposite end being attached to a science lab. I spin the rocket and dock back with the command module so that my kerbals in the science lab can jump out. All of this works absolutely fine.

I then undock my command module and flip the rocket back around so that it can re-dock the opposite end with the command module. The idea being that I can then eject the science lab behind me leaving my command module attached to the return stage of my rocket. HOWEVER, when I attempt that final dock, going back to what is effectively the original position, it won't re-dock. They just bump up against each other doing a whole lot of nothing. I can change the docking force, where I'm controlling from, re-load. Nothing works. Mission abort, wasted 3 hours of  my time.

Included Attachments:

OrbitalLabPrototype.json

[DibzNr]

@tweaked9107 Merged your report with this post

[Schtoopid]

I'm going to throw in a "Me too" here.
Lander and orbiter. Dock fine initially, but once the lander returns to the orbiter, it won't dock.
I'll try the json.

[HammerTyme]

I stopped playing this game a few months ago because of this one specific issue. It was unbelievably frustrating when I can’t dock due to whatever bug this is.    I just tried playing again today thinking surely this has been fixed after 4-5 months. And it’s not…  This is a huge bummer.   I really hope the devs are aware of this issue.  I really don’t understand why this hasn’t been fixed yet.    I love this game and I thank the devs for creating this, but my god… it’s such a downer when a bug like this hasn’t been fixed yet.    I guess I’ll check back again in a couple months.   Sorry if I sound rude, I’m just really upset and frustrated. 

[EngineeringWaffle]

Also having this issue, the JSON fix worked. Had a big mission to Jool and have had to do a lot of save file editing to make it work. Between trajectories disappearing and docking ports locking up I've had to keep the saves folder open next to KSP because I'm in there so much fixing stuff.

 

To be clear about what I was doing, I have a descent stage and a transit stage and was visiting all the moons of Jool. My descent stage would undock, go down to the moon surface, run experiments, take off, and then redock to the same docking port. I had this bug every time. One time both docking ports were bugged, the other time just one docking port was bugged. But the dock never worked without editing the save file.

Edited March 5 by EngineeringWaffle

[Doyouknowkimble]

Seems this is still bugged as of writing this. I have a fix, without editing game files. Go to your action groups and group the undock command on the docking collar to a number key. Press number in game, you are now undocked........ again.