[1.7.x] ReCoupler - Monocouple your bicouplers!

[Booots]

Fixed it! I'll have the fix up shortly. Right now, docking and undocking works just fine, but weirdness happens if the virtual joint is across the docking port itself.

Fortunately, that should be a rare case as the virtual joint is usually at a multicoupler (although one of the "stoopid" configurations I'm testing has it elsewhere).

Regardless, it should be functional for you guys now!

[ZobrAA]

@Booots, thx for your great work!

I wanna ask, did you know about Connected Living Space mod? CLS identifies areas within a vessel that can be crewed by Kerbals and through which kerbals can pass internally to reach other parts that can be crewed... So is it possible to simulate not only physical links with recoupled parts but also a CLS connections?

I'll duplicate this suggestion in CLS thread, so may be this can be done from that end.

[diomedea]

Must say I'm really impressed about the ingenuity with Recoupler.

Probably many know, still I'd show a few considerations about the Vessel's tree structure in KSP and topology. As it was started since when KSP first allowed to put parts together, it never changed significantly. KSP stores one single "Part.parent" attribute with all parts, so branching is strictly one-way (from one to one or many, never from many to one). IN KSP stock code, there are (that I could find) 68 routines using Part.parent, all assuming the value to be unique for each part.
Of course, the resulting structure is very easy to navigate, efficient, and allows recursivity without constraints. All good reasons to wish to only deal with one-way trees of parts, instead of dealing with all kinds of more complex structures (to include loops of all kinds, see graph theory) and would require specific code to deal with path duplications (to the effect of pruning any path already travelled), which unfortunately makes for more complexity (= more bugs!) and time to compute those routines.
Still, tree structures aren't fit to deal with all requirements: in KSP, the rigid one-way branching has caused many issues, e.g. no multiple docking among two vessels, non-functional claw grabbers; plus the intrinsic weakness of a structure held together from only one node with each part (very correctly highlighted by the author).

Now, to me the cleanest solution would still be if KSP code was changed to allow (at least in those cases with multicouplers or other parts conceived to allow reversed branching) a part to have multiple parent attributes, all correctly managed (so adding a lot more complexity in all those routines). But I have no confidence this will ever happen.

Having now, thanks to Recoupler, a working alternative, is a blessing! Sure enough, I've built a number of closed space stations that never could be correctly seen as "closed" lacking one or more joints till now (even worse since I'm also using Connected Living Space), this is something I'm expecting this add-on to improve greatly.

Hope the above can bring to some more ideas on how to improve with a vessel structure, perhaps about what other features this add-on could implement.

[dtrauma]

41 minutes ago, diomedea said:

Now, to me the cleanest solution would still be if KSP code was changed to allow (at least in those cases with multicouplers or other parts conceived to allow reversed branching) a part to have multiple parent attributes, all correctly managed (so adding a lot more complexity in all those routines). But I have no confidence this will ever happen.

Didn't it, in a way, already happen when struts and fuel lines where introduced? As discussed here, they and multiple docking ports connecting at the same time all already break the model of a tree of parts. This is why this mod works (if it does, waiting on the docking fix to test it), as all the code is already there, there simply isn't a GUI to make the nodes connect in the VAB.

So code wise I imagine (got no clue really besides reading the dev blog posts) we have a spanning tree of parts built as they are clicked together in the VAB, and it is used for all kinds of things like proposing staging (and getting it wrong ), re-rooting and just generally making editing easier for the user: it's easy to understand that you have a tree of parts that you influence directly, and stuff like struts and docking ports facing each other are second class citizens, so parts strutted together just break the struts if you move one of them around, and if you copy a part tree, the struts won't necessarily work as expected if you aren't doing something symmetric. If you exposed the full multigraph of parts to the user they'd likely just be confused if not already at expert ship builder level. And then we have the real multigraph mess where parts are connected in all kinds of ways for physics (struts, autostruts) and fuel flow (fuel line) and aerodynamics (cargo bays sheltering other parts), with docking ports affecting all three.

It would be really nice (and sufficient, I think), to be able to say "these two aligned and very close together attachment nodes shall be pseudo-connected!" in the VAB - it would require manual fixing of multicouplers when building as opposed to this mod, but you'd always be aware where the connections were and there was no potential for unwanted links in cramped situations. You can get the same effect when using docking ports right now, but that has it's own kind of problems.

[Booots]

4 hours ago, ZobrAA said:

I wanna ask, did you know about Connected Living Space mod? CLS identifies areas within a vessel that can be crewed by Kerbals and through which kerbals can pass internally to reach other parts that can be crewed... So is it possible to simulate not only physical links with recoupled parts but also a CLS connections?

That's a good idea! I'll see what I can do about making it happen. I think they have an API of sorts so it should be doable. I'll add it to the to-do list.

 

3 hours ago, diomedea said:

[Snip] Brilliant explanation of why ReCoupler is necessary.

Great explanation! I might make some tree diagrams showing how the back end of ReCoupler does its thing to augment your explanation.

 

1 hour ago, dtrauma said:

Didn't it, in a way, already happen when struts and fuel lines where introduced? As discussed here, they and multiple docking ports connecting at the same time all already break the model of a tree of parts. This is why this mod works (if it does, waiting on the docking fix to test it), as all the code is already there, there simply isn't a GUI to make the nodes connect in the VAB.

So code wise I imagine (got no clue really besides reading the dev blog posts) we have a spanning tree of parts built as they are clicked together in the VAB, and it is used for all kinds of things like proposing staging (and getting it wrong ), re-rooting and just generally making editing easier for the user: it's easy to understand that you have a tree of parts that you influence directly, and stuff like struts and docking ports facing each other are second class citizens, so parts strutted together just break the struts if you move one of them around, and if you copy a part tree, the struts won't necessarily work as expected if you aren't doing something symmetric. If you exposed the full multigraph of parts to the user they'd likely just be confused if not already at expert ship builder level. And then we have the real multigraph mess where parts are connected in all kinds of ways for physics (struts, autostruts) and fuel flow (fuel line) and aerodynamics (cargo bays sheltering other parts), with docking ports affecting all three.

It would be really nice (and sufficient, I think), to be able to say "these two aligned and very close together attachment nodes shall be pseudo-connected!" in the VAB - it would require manual fixing of multicouplers when building as opposed to this mod, but you'd always be aware where the connections were and there was no potential for unwanted links in cramped situations. You can get the same effect when using docking ports right now, but that has it's own kind of problems.

The docking fix is up, btw. Or rather, for *most* situations. I've identified two problem configurations that will take more work, but casual play and/or testing shouldn't encounter them (I hope).

Struts, fuel lines, and multi-docking don't actually change the tree structure. The strut's parent is only the first part you place it on, and it has no children. It just creates a physical connection to the part on the other end. This is why, when the tree breaks between the two strut points, the strut also disappears. Multi-docking does essentially what this mod does. The docking ports trigger their DockToSameVessel() instead of DockToVessel() and create a physical/crossfeed link without a parent/child relationship. Then if the "real" docking connection breaks, I think they shuffle the tree a bit to one of the other connected docking nodes - exactly what I'm doing here. So there is no multigraph at any level, but I think that's a good thing because it makes dealing with the vessel's parts faster, more efficient, and, more importantly, extremely robust.

[ZobrAA]

@Booots, serious bug: game crashes on attempt to load craft with double cargo bay. No crash log, even ksp.log have no strings at crash moment...

Edited March 10, 2017 by ZobrAA

[Booots]

2 hours ago, ZobrAA said:

serious bug: game crashes on attempt to load craft with double cargo bay. No crash log, even ksp.log have no strings at crash moment...

Woops! Infinite loop leading to a stack overflow! Because the inner nodes are making a ReCoupler connection, the one cargo bay checks for connected cargo bays and the double link makes it loop infinitely.

I'm fixing this by making ReCoupler ignore all of the attachNodes specified as inner by the ModuleCargoBay. I can't think of any situations where fake joints would be needed across an internal cargo bay node (are there any modded cargo bays with multiple inner nodes on the same end?), but I'm noting for posterity that this may not be the optimal solution.

In other interestingness: clipping two service bays into each other hides the nodes (since they don't specify a inner node in their config so my method can't detect it), but for some reason it doesn't crash. I'll take it however I can get it, though!

Updated SpaceDock and GitHub with the new fix. Thanks for pointing it out!

[FizzerUK]

omg!!!

 

Thank you!

[CarnageINC]

Kottabos brought me here, I just gotta say....

AMAZING MOD!  THANK YOU!  BRAVO! BRAVO!

[Thor Wotansen]

This mod shows much promise and I really like the direction you are going with it.  Bravo.  I do however have a question about further implementation of the concept.  I have recently been building some rather large creations using the structural panels to create a hull, in which I put the bit that makes the ship go.  With the way the KSP building mechanic works this obviously leads to a hull that relies on it's inner bits an extensive use of rigid attachment and autostrut to maintain even a semblance of structural integrity.  Could the concept of this mod be expanded to parts that are touching in the editor but don't have nodes?  Perhaps a tool that draws a line across the joint in question to inform the recoupler mod of which connections are desired could work?

For clarification, this is one of the projects that would be greatly improved by the above.

[Booots]

5 hours ago, CarnageINC said:

Kottabos brought me here, I just gotta say....

AMAZING MOD!  THANK YOU!  BRAVO! BRAVO!

What???!!! @Kottabos picked this up?! Whoa!!! My hero! This made my day.

Thanks for all the encouragement everyone!

So to address the requests for custom and arbitrary part connections, I'm going to add a to-do item to implement a UI of sorts that will visualize all the virtual joint pairs and allow them to be ignored and for new ones to be specified. Note that I'm a behind-the-scenes coder primarily, so since I'll have to learn GUIs and stuff this will probably take me a while to implement. Also, since I'd like to keep the "acting as stock" style of this mod, the GUI and any associated buttons will probably be hidden by default (shown only if a settings file flag is set to true) so that it can be like this mod is almost not even there for most users.

[ThePsion5]

Great mod! I'm planning on using it for an upcoming mothership I'm designing. However, one issue I have run into, however.

I'm a big fan of using fairings to connect larger lower stages to upper stages. For example: 3.75m Fairing -> 2.5m Separator -> 2.5m Engine -> 3.75m Tank, with the fairing attached to the 3.75m tank. Normally this all works out fine normally, but after installing Recoupler, they suddenly wouldn't separate. I confirmed the decoupler was triggered by staging, and the decoupler no longer had the "decouple" option. After removing your mod, I reloaded the vessel and re-launched it and the decoupler separation worked fine.

If I had to guess, I suspect your code is treating the connection between the fairing shell and it's attached part as a regular attachment between parts, so even after the fairing deploys and the decoupler is separated, there's an invisible connection between the deployed fairing and the attached node.

[Dr. Jet]

 This should be a stock mechanic.

[Booots]

@ThePsion5, can you send me a screenshot of the vessel in the VAB? I suspect it's one of the extra nodes that fairings have that is overlapping somewhere with another free node. Unfortunately, I'm away from my development computer for a bit, but if that is the case, it should be a fairly straightforward fix when I get the chance.

[Papa_Joe]

@ZobrAA and @Booots, thanks for pinging me over on the CLS thread.  I've been slammed at work lately so I didn't pick up on this sooner, but yes, there will be implications for CLS when using this mod.

 

@Booots, I'll pull the latest and peruse the code to see what trickery you are managing, so I can make CLS "aware" of it and account for this.  Great idea.  I ran into the circular coupling and docking issue a long time ago when I was building space stations that could connect to themselves.  

Best of luck with this, and If I find any gotchas I'll be sure to reach out and see what we can do to make it a winner.

[DigitalProeliator]

Question on how this works. Is this done when launching from the VAB, reloading from someplace or on the fly? I'm curious if this would work with say bases made with docking stuff together or ones build piece by piece with KAS on site.

[Booots]

On 2017-03-11 at 3:38 PM, Papa_Joe said:

@ZobrAA and @Booots, thanks for pinging me over on the CLS thread.  I've been slammed at work lately so I didn't pick up on this sooner, but yes, there will be implications for CLS when using this mod.

@Booots, I'll pull the latest and peruse the code to see what trickery you are managing, so I can make CLS "aware" of it and account for this.  Great idea.  I ran into the circular coupling and docking issue a long time ago when I was building space stations that could connect to themselves.  

Best of luck with this, and If I find any gotchas I'll be sure to reach out and see what we can do to make it a winner.

@Papa_Joe, I think this is something that might be best done through an API hook from my end rather than from your end. I track all the fake joints in a vesselModule and the only externally-detectable data is that the Part's crossfeedPartSets now interconnect and that the AttachNode's attachedPart is set to the part I'm joining it to. While you could look through all AttachNode connections on the vessel instead of looking through the parent-child tree, that way leads to circular paths (which, TBH, I'm honestly surprised I haven't broken anything on. Thank goodness everyone uses the tree!). If you added a method in the ICLSVessel class that takes two ICLSSpaces as input and merges them (or two Parts and then looks up the corresponding Spaces), I could just call that whenever I make a link.

I'm visiting my parents for the week, but if I have some time, I might mock something up and send you a pull request.

 

15 hours ago, DigitalProeliator said:

Question on how this works. Is this done when launching from the VAB, reloading from someplace or on the fly? I'm curious if this would work with say bases made with docking stuff together or ones build piece by piece with KAS on site.

I'm still new-ish to Unity and coding for KSP, so short answer: yes. All of those. It rebuilds the connections when loading the scene, but re-checks them whenever the vessel is modified in some way. I think, though I haven't tested with KAS or KIS, that because those mods trigger the onVesselModified event this mod should detect that and try out the new tree. Hopefully removing parts with KIS doesn't cause nullrefs now that I think about it. If anyone runs into bugs, please let me know!

 

Speaking of bugs, I think I have a fix for the fairing issue reported earlier. I'm just going to have it ignore all nodes that begin with "interstage" and that should have it exclude all the floating nodes that fairings have. Hopefully nobody has named any nodes that that I shouldn't blacklist. I'll have the new update on SpaceDock and GitHub shortly.

[Viscosity]

so im not sure f its just my lack of knowledge on how to build a ring (actually im almost positive thats what it is...) the first craft is testing and showing the mod is working, the 2nd is showing the nodes not connecting on a fuel ring, is there anyone that would be able to help me understand either A) how to fix it or B) how to build a ring that does work?

the 3rd vessel is demonstrating another method i tried where the nodes should be touching but that i couldn't get to connect

http://imgur.com/a/X0lAk

 

Edited March 13, 2017 by Viscosity
to change embed to a link

[Viscosity]

On 3/10/2017 at 9:26 PM, ThePsion5 said:

Great mod! I'm planning on using it for an upcoming mothership I'm designing. However, one issue I have run into, however.

I'm a big fan of using fairings to connect larger lower stages to upper stages. For example: 3.75m Fairing -> 2.5m Separator -> 2.5m Engine -> 3.75m Tank, with the fairing attached to the 3.75m tank. Normally this all works out fine normally, but after installing Recoupler, they suddenly wouldn't separate. I confirmed the decoupler was triggered by staging, and the decoupler no longer had the "decouple" option. After removing your mod, I reloaded the vessel and re-launched it and the decoupler separation worked fine.

If I had to guess, I suspect your code is treating the connection between the fairing shell and it's attached part as a regular attachment between parts, so even after the fairing deploys and the decoupler is separated, there's an invisible connection between the deployed fairing and the attached node.

i have notice that the kerbodine adtp 2-3 adaptor has this issue but that is the only one that seems to give me issues

[Booots]

1 hour ago, Viscosity said:

so im not sure f its just my lack of knowledge on how to build a ring (actually im almost positive thats what it is...) the first craft is testing and showing the mod is working, the 2nd is showing the nodes not connecting on a fuel ring, is there anyone that would be able to help me understand either A) how to fix it or B) how to build a ring that does work?

the 3rd vessel is demonstrating another method i tried where the nodes should be touching but that i couldn't get to connect

<blockquote class="imgur-embed-pub" lang="en" data-id="a/X0lAk"><a href="//imgur.com/X0lAk"></a></blockquote><script async src="//s.imgur.com/min/embed.js" charset="utf-8"></script>\

Your imgur album isn't working for me, sorry. I don't think embedding is working on the forum these days. Maybe just post a link to the album? Kottabos' review showed how it would be done in essence. ReCouple only works with stack nodes, which might also be contributing to your problem?

8 minutes ago, Viscosity said:

i have notice that the kerbodine adtp 2-3 adaptor has this issue but that is the only one that seems to give me issues

Is that with the latest version (today's)? If it's still not working properly, can you post a picture of your craft and maybe the log file? Thanks!

[Viscosity]

3 hours ago, Booots said:

Is that with the latest version (today's)? If it's still not working properly, can you post a picture of your craft and maybe the log file? Thanks!

i will update (didn't know it was updated today) and retest, i will send log file and image if i see it again, it only happens sometimes.

 

i also updated the original post with the link

http://imgur.com/a/X0lAk

here it is aswell

Edited March 13, 2017 by Viscosity

[Booots]

@Viscosity: Hmm, you are doing it right, as far as I can tell. It might be that the nodes are just a tiny bit misaligned or out of range. Try increasing the range limit in the settings file. Unfortunately, until such time as I implement a GUI, changing settings will require a restart of KSP. Keep in mind that the settings apply to all vessels, so don't go too overboard. If that doesn't work, I'll try downloading the part mods you're using and try to replicate it myself.

[Viscosity]

i changed the node catcher to 0.3 but still didnt catch on that particular craft, that being said im pretty sure its my incompatance as a builder because i was soon after able to come up with a new ring design that worked flawlessly, thank you for your help and i cant wait to see this mod as it continues!

[Kombat engineer]

On 3/1/2017 at 9:12 PM, martinezfg11 said:

This is the best thing since sliced MechJeb.

Make that sliced MM.

[Booots]

Hi everyone! Sorry I've been away for a bit. It was March break here so I went home to visit my parents and help with some renovations.

Now that I'm back, though, have I got progress to share! ConnectedLivingSpace compatibility is most definitely doable. I've sent a pull request to @Papa_Joe with the changes I need on their end so it shouldn't be too long. If anyone wants, you can get the test builds on my GitHub for ReCoupler Dev and CLS Dev (experimental). Please let me know if anything breaks or you see errors in your logs.

I've also gotten permission from IgorZ to use some of the docking port code from KIS so that should help me sort out the last of the problems on that end.