[PartJoint]: None of the provided nodes was valid!

[problemecium]

I've been having docking port bugs off and on ever since unlocking docking ports in KSP 1.0, and today it got so severe a problem that my game progress is halted.

What's happened is that almost every docking port on my LKO station has become unable to undock. I tried the instructions detailed in a few other threads around here, and it helped the first time, but a few days later the bug came back with a vengeance.

One of the first things I tried was renaming the station. I'd previously noticed some Klaw bugs that seemed to go away as a result of renaming the vessel - perhaps KSP was confused when sorting out multiple "DOCKEDVESSEL"s of the same name. No luck.

Next I tried Claw's solution as detailed in FIX: Dock / Undocking Bug in 0.23.5. It helped at first - I was able to restore functionality to the two ports I needed to work; I didn't do an exhaustive analysis of the rest of the station though, so I can't say whether it did or would have helped.

What I do know is it isn't helping now. I have verified that every pair of connected docking ports is in the proper configuration, i.e. one says "Docked (same vessel)", the other says "Docked (dockee)", and they link to each other's uid correctly. As far as I can tell by reading it, the save file is flawless (but of course it can't be or I wouldn't have this whole problem).

As a last-ditch resort, I tried something else that occasionally helps with Klaw bugs, i.e. enabling the "Decouple Node" action on the docking ports. That did nothing to help and simply threw an unsurprising NullReferenceException.

Investigating further, I opened the error log and found a large block of warnings reading:

[PartJoint]: None of the provided nodes was valid!

The block was large (over a dozen), but not hundreds, nor did it repeat. I have a hunch that one warning was thrown by each docking port because something is wrong with the "PartJoint" connecting it to the other port; perhaps the save file is somehow causing the port to be given a reference to the wrong part or something.

I didn't want to post a new thread without being sure it was a new issue, so of course I checked Google and the forum's Search page.

I also tried to see if I could blame it on any of the three mods I have installed: HyperEdit, Kerbal Alarm Clock, and KER. No dice - none of those mods have anything about causing docking issues in their threads (not something I expected anyway given their nature), the station in question consists entirely of stock parts, and most importantly, digging through KSP.log and output_log.txt indicated that the error was apparently coming from the PartJoint class and being piped through Unity's built-in debug script.

So now I turn to the community seeking help. Is this related to a known issue? Have others been affected similarly? And might anyone have a solution?

Attached here are my KSP.log and output_log.txt: KSP.log | output_log.txt

And here is the save file experiencing the issue: persistent.sfs

The bug has attacked one of the last vessels in the list, "Station 1.0.2 Ring Station Edition". Apologies to anyone reading through it for the fact that I currently have a lot of stuff flying around and the station in question has around 400 parts. ^^;

In case it helps:

Windows 7 64-bit OS with KSP 1.0.2 32-bit, non-Steam, running on Intel HD Graphics 4000 with SM3 terrain shaders disabled.

I doubt any of that really affects this, but just in case xP

Edited June 2, 2015 by parameciumkid
persistent.sfs

[problemecium]

Update on my bug hunt: Using Claw's "in depth" solution was fruitless, but using a modification of the "quick and dirty" solution I was able to successfully restore functionality to at least one port (I have yet to check the rest). What I did specifically:

- Enable "Decouple Node" on all docking ports using a bulk search & replace function

- Assign all ports with the "Docked (dockee)" state an attachment to their "parent port" by changing the first "attN = None, -1" to "attN = top, [parent]" where "[parent]" is the port's parent index as recorded in its Part block.

PART{

name = dockingPort2

...

parent = 7

...

attN = top, 7

attN = bottom, 5

...

MODULE{

name = ModuleDockingNode

state = Docked (dockee)

...

}

...

}

- Resolve all conflicts wherein the newly assigned attN is the same as one of the other attached parts, e.g. the bottom attN or a surface attachment attN; for the time being I simply left these with "attN = None, -1" but the presence of a few of the aforementioned "None of the provided nodes was valid" messages suggests this isn't the "real" solution. I suspect that the bottom attNs have been assigned erroneously, perhaps due to the surface-attached ports' top and bottom nodes being very close together and KSP ending up thinking I'd docked onto the ports' bottom nodes.

- Attempt to decouple one of a pair of ports, and if a null reference occurs, reload the save file and instead decouple the other port.

I was thus able to at least get my crew ferry detached, which is a good sign, but I only treated the symptoms and have every reason to believe the bug can and will strike again and therefore still needs attention. Once again, if anyone has any answers, or even some useful information to help us all find the answer, please reply!

Edited June 3, 2015 by parameciumkid

[sal_vager]

I wish I had an answer for you but the only time I saw this was with one of Zekes tanks, it needed re-rooting in the editor to fix.