StationCore undocking does not release attached item
Jimbodiah opened this issue · 19 comments
Many times trying to decouple SC parts will have the GUI button disappear like it undocked but the actual port will not let go. Reloading the craft will also no longer give the GUI option to undock the ports that have already been undocked (unsuccesfully).
logs + screenshot of GUI: http://kerbal.nl/sstu/sstu_undock.zip (github does not accept my jpg or zip fils while telling me it will only allow zip or jpg files,go figure).
The logs are from 1.2.1 but I have had the same issues in 1.2 but thought it was just a fluke thing. The GUI no longer shows the options to disconnect the Left and Right nodes where the COS habs are attached to. The top is still enabled as I have not undocked that yet, but the bottom one no longer has that option either and I did not try undocking that yet.
Preliminary investigation points towards this being the stock docking port bug:
MODULE
{
name = ModuleDockingNode
isEnabled = True
crossfeed = True
stagingEnabled = False
state = Ready
dockUId = 3320059107
dockNodeIdx = 20
EVENTS
{
}
ACTIONS
{
UndockAction
{
actionGroup = None
}
DecoupleAction
{
actionGroup = None
}
EnableXFeedAction
{
actionGroup = None
}
DisableXFeedAction
{
actionGroup = None
}
ToggleXFeedAction
{
actionGroup = None
}
}
DOCKEDVESSEL
{
vesselName = ISS Hab Station
vesselType = Station
rootUId = 2033588366
}
UPGRADESAPPLIED
{
}
}
Where it should not have a 'DOCKEDVESSEL' node or 'dockUId' when the docking port state is 'Ready'.
If in the 'Ready' state it should have none of that info (as those relate to what parts are docked to it), else if it is actually docked it should read 'Docked(Same Vessel)' or similar.
Not sure that there is anything that I'll be able to do to fix this. I'm not using custom docking code on those parts, it is all the stock docking port code (with all its quirks and bugs). The only SSTU code on there simply renames some of the UI labels, which has zero effect on the actual docking port code.
Going to do a bit more investigation to see if I can duplicate this problem in testing, what causes it, when it occurs, and if it is at all related to any of the SSTU code.
Any particular set of operations that trigger this problem? Does it only occur on the HUB parts, or have you seen it with other parts as well?
I've seen it on the hub and on DOS parts (LAB and PWR). It's not every time though. I undocked another vessel from the hub just before as I did not know which of the 4 nodes was what module. After that the two left/right nodes did not detach the vessel on them anymore. COuld it be that two ports on a single craft is an issue if one undocks and blocks the other somehow? Just guessing.
Hmm... will see if I can duplicate it using those parts / something similar to the station in the screenshot you posted. Hopefully I can at least get the problem to duplicate reliably.
Could be that multiple ports on parts confuses the stock docking port code; sadly that would mean there is nothing that I can do to fix the root of the problem. About the best we can hope for on this is that it is config related somehow. Had prior problems with the HUB ports with configs where it would cause them to not re-dock, but never had problems with refusing to undock during testing/fixing of those issues.
Even if it is a stock code problem I might be able to work around it by including a custom tailored version of Claw's stock-docking-port fix (would need to be adapted to support multiple ports on the same part, his code currently assumes only a single ModuleDockingNode is present on any given part)..
Will be investigating this for a bit tonight, will let you know what I come up with.
Any way I could have you upload the save file that is experiencing this problem?
Docking port state is saved out to the persistence file so there is likely some information in there that can help me track down what is up with these parts.
Also, have you tried it both with and without KJR? (had caused problems in the past with undocking)
Hopefully will get some time to investigate this in the next few days / over the weekend.
I can, but the station in question has several other mods on it, so if you open it the station will disappear. I'm running without KJR at the moment as I had earlier problems with things blowing up (not happened since I removed KJR). No rush on this issue for me, just FYI.
Was not able to duplicate the problem during the brief testing I did last night, but it was pretty limited -- used an existing test station and tried undocking some modules; worked fine there, but that could have been because it was launched as a single piece and cheated into orbit.
Will be doing more extensive testing tonight/this weekend including multiple separately launched craft and post-launch docking procedures.
The station was put together in orbit, so piece by piece. I've not tried stock ports as I only use the SSTU ones (look better). Right now I have hyper-edited a complete station into orbit and will see if that one has any issues. I've added stock ports to that as well and will check that.
Basically I will make a station that has the ports integrated into the part and a similar station with the station cores set to have no ports and add them manually. Maybe I can see a difference in behavior to pin down if it is stock/sstu or the multiple ports in 1 part. To be continued...
I've had it as well, and cannot duplicate reliably. It sort of happens, or doesn't. It's really frustrating for that reason (If I knew what did it, I'd stop doing that :) ).
Found a potentially related issue in the ST-HUB-COS config where the left and right attach node positions had been swapped, which may have well been playing hell with the docking ports themselves.
This fix will be available with the next release; until then I'll keep working on reproducing the problem so that I can test the force-undock fix....
Ugh. I had one, but as it was career, and I was trying to press on, I cheated a copy of the craft to rendezvous, then transferred crew via EVA, and derorbited it.
No worries; if you run into it again, please upload a persistence file if you can. You should be able to drag+drop right into the comment and GitHub will take care of the uploading (e.g. shoudn't need to use dropbox/etc).
Did your station by chance involve the COS-HUB, or has this problem manifest with other parts as well?
I was able to duplicate the problem before during testing, but only intermittently.
Now that I've sat down to write up a fix for it, I can't repro the problem at all; which is making it hard to test if the fix will work =\ (rather I know the fix will decouple things, but I'm unsure if the buttons will show up appropriately).
Do either of you have craft files that are currently experiencing the problem, preferably that only contain SSTU+stock parts (though needing one or two other mods might be doable if that is all that is available)?
Adding link to recent save/file data: http://jimbodiah.com/ksp/sstu/sstu_ports.zip
Interesting excerpt:
[LOG 21:29:03.926] at AT_Utils.FlightCameraOverride.Deactivate()
at AT_Utils.FlightCameraOverride.OnDestroy()
at UnityEngine.Object.DestroyImmediate(UnityEngine.Object , Boolean )
at UnityEngine.Object.DestroyImmediate(UnityEngine.Object obj)
at FlightCamera.Awake()
at UnityEngine.Object.INTERNAL_CALL_Internal_InstantiateSingle(UnityEngine.Object , Vector3 ByRef , Quaternion ByRef )
at UnityEngine.Object.Internal_InstantiateSingle(UnityEngine.Object data, Vector3 pos, Quaternion rot)
at UnityEngine.Object.Instantiate(UnityEngine.Object original, Vector3 position, Quaternion rotation)
at DragCubeSystem.RenderProceduralDragCube(.Part p)
at SSTUTools.SSTUStockInterop.updatePartDragCube(.Part part)
at SSTUTools.SSTUStockInterop.FixedUpdate()
Might be entirely unrelated (but a problem by itself).
I've seen something related with rendering procedural drag cubes. Is this by chance on the root part? KSP attaches a bunch of stuff to the root part's GameObject (vessel among other things), then when you render drag cubes for that part, all that stuff gets duplicated, since it's attached to that GameObject (and then it gets destroyed when drag cubes are done rendering). I've seen this lead to some other issues.
It could have been the root part, not entirely sure; was just browsing through the linked log file to see if anything stuck out at me. Also appeared to be out of an RO/RSS setup,
It does seem to be caused by some 'extra stuff' attached to the game-object that isn't initializing properly. I might have to find some work-arounds to root-part-drag-cube updating....