Booots

@linuxgurugamer, how would I go about fixing this? I ask because you merged the first CKAN pull request and I'm not familiar at all with CKAN. What happened is I updated it with a v1.0.0 version number, realized I had broken my numbering convention, updated it again without sending the notifications to followers, and deleted the v one.

It's done! I added a GUI, added compatibility for CLS, and fixed the last of the annoying bugs. Soo... It's time for a release! I made a thread over in the Release forums, so feel free to check it out over there!

Ever want to use bi- or tri-couplers but want to recombine the stacks before the next stage? Ever wish you could make circular stations in the VAB without having to spam struts to keep the open end closed? Here's the answer you've been looking for! ReCoupler works around the Vessel tree by identifying attach nodes that would have been connected but can't without a part having multiple parents or creating a circular structure. Once those nodes are identified, it hides them in the editor so that you don't accidentally connect anything else to that node. Then, in flight, it creates a structural link identical to the ones that normally hold parts together. But wait! There's more! When decoupling (or explosions) happens, it detects if one of the virtual connections would continue holding the vessel together and magically makes that the real connection point as if no funny business had been happening! Check out the rest of the album! And some new building styles you can use with ReCoupler: Interested? Get it from SpaceDock or GitHub now! Known bugs: Not a bug, necessarily, but it only works for stack attach nodes. Future plans: Make a decoupler that connects to 2-, 3-, or 4-engine clusters and makes their fairings work with it. Thanks Making History! Considered complete at this point. Please feel free to raise any suggestions!

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.

@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.

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? 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!

@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. 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.

@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.

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.

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!

Just from what I've seen poking around the CLS source and API, it looks like a new method would have to be added to the API to allow the creation of arbitrary connections. Something like CLS.ConnectSpaces(Part fromPart, Part toPart) (or using their attachNodes) that would essentially link the spaces of the two parts. A corresponding way to unlink them would also probably be required. Because it looks like CLS checks all the parent->child connections and ReCoupler doesn't make parent->child relationships (because you can't), without an explicit "these two are connected" method, I don't know what I could do on my end. @Papa_Joe, am I understanding your mod and its API capabilities correctly?

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. Great explanation! I might make some tree diagrams showing how the back end of ReCoupler does its thing to augment your explanation. 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.

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!

Thanks! Thanks for the bug report. I hadn't tested docking/undocking with this. I'll do that when I get home from work. When you say decouple, do you mean undock, or are you using the 'Decouple' option on the docking port? Were the vessels docked when you installed it, or does it also do this when you dock and then try to undock? I have some ideas on why it might be doing this, and it *should* be a relatively easy fix. Hopefully!

Yeah, if someone does weird clipping with surface attached things that also have stack nodes such that their stack node overlaps with another one, unintended joints may be created. I did limit the relative angles between attach node orientations that it will accept, though. I mostly did that so that it could handle cargo bays, but it should help with this. If you find anything in your trials, let me know! Thanks!

Development for today: Fixed the staging issue! I've taken the coupling method that the new KASv1 uses. (@IgorZ, it's public domain so that's cool, right?) Fixed the previous bug in loading that my fix for aero introduced. Now both aero and persistence works. Released a pre-release (pending only any new bug reports and maybe hacking the fuel flow overlay in the editor before becoming a full-on release). Check out the release on SpaceDock (here)! Any feedback is appreciated as always. Cheers!

I am excited to see what stoopid ways you can come up with! Hopefully it can be made to work for the most fun ones. Development for today: Reverting flights no longer breaks. Aero seems to be fooled into believing my connections are real. Hopefully if my connections break or are removed it doesn't break. Undoing in the editor seems to work. I don't know what I did to fix it. Maybe it worked all along? I haven't tested redoing in a while. The only critical bug before I'm willing to do a pre-release on SpaceDock is the whole staging breaking thing when the switching to being a real attachment node gets triggered. I'm having no luck figuring that one out, though. Any tips will be greatly appreciated. As always, newest beta and code are on GitHub. Cheers!

Trickery indeed! When I saw that the multi-docking port thing worked, I realized similar trickery of having physical joints where no tree connection existed must be possible. Thanks for your encouragement so far! Development for today: Fuel crossfeed nominally works across the trickery joints. Better handling of all things in the editor (except the crossfeed display) Nodes reliably disappear and reappear when they're supposed to, even after reverting. (But not undoing, for some reason...) Downside is that it saves my helper PartModule to the .craft file and then throws up warnings in the log on launch because that module isn't in the prefab. I need to figure out how to intercept the save and remove the PartModule in time. Discovered new things to fix (like aero being unaffected by all this) New beta is on GitHub for anyone interested.

Ever want to use bi- or tri-couplers but want to recombine the stacks before the next stage? Ever wish you could make circular stations in the VAB without having to spam struts to keep the open end closed? Here's the answer you've been looking for! ReCoupler works around the Vessel tree by identifying attach nodes that would have been connected but can't without a part having multiple parents or creating a circular structure. Once those nodes are identified, it hides them in the editor so that you don't accidentally connect anything else to that node. Then, in flight, it creates a structural link identical to the ones that normally hold parts together. But wait! There's more! When decoupling (or explosions) happens, it detects if one of the virtual connections would continue holding the vessel together and magically makes that the real connection point as if no funny business had been happening! They say a picture is worth a thousand words, so here's what it does: http://imgur.com/a/LoTfh (Posting pictures isn't working for me. Just go to the album. It's worth it.) Interested? It's in release! Get it from SpaceDock or GitHub if you want to try it out! Or head over to the release thread: Bugs? Did I say bugs? I meant, er... Known bugs: Not a bug, necessarily, but it only works for stack attach nodes. Future plans: Make a decoupler that connects to 2-, 3-, or 4-engine clusters and makes their fairings work with it. Thanks Making History! Possibly working magic to make surface attach nodes work in some circumstances. My bug list is short enough for a release!

Okay, new question: How do I create a physics connection akin to those made by attachment nodes? Note that I'm not trying to attach the two parts in the parts tree sense, I just want a physics joint between them with the same properties as an attachment node would have. I went through the Kerbal Joint Reinforcement code and implemented their StrutConnectParts() method from KJRDecouplerReinforcementModule.cs, but it seems to have no effect. I see something that looks close-ish to what I want in KJRManager.cs in UpdatePartJoint(), but it looks like it goes above and beyond what I need and I can't quite figure out which parts I need or don't need. Anyone have some insight they can share? Maybe @ferram4?

I'm playing around with VesselModules for the first time and I have some questions about how they work in the editor and in flight. I see in the API that you can set Activation.NonFlightScenes, this would make it run in the editor, right? Is there any way I can then save information in the craft file to be loaded when the vessel gets sent to the flight scene? Does VesselModule.OnSave() work like that in the editor? Thanks!

For some reason, the carbon extractor, water purifier, small greenhouse, and algae farm all seem to be limiting themselves to 65% regardless of where I have the slider. (I'm running TAC LS) I noticed someone had a similar problem a few pages back, but it's still persisting for me. I am running the latest version of both TAC and KPBS. EDIT: A timely fix would be nice so my Kerbals en route to the Laythe colony don't die in flight. EDIT2: Weird, when on an unmanned vessel with one of each, just to test, they only run at 5%... EDIT3: I found the root cause: UseSpecialistBonus = true SpecialistEfficiencyFactor = 0.2 SpecialistBonusBase = 0.05 ExperienceEffect = ConverterSkill EfficiencyBonus = 1 This somehow makes those converters sensitive to personnel. Is this intended behaviour?

The stock asteroids actually have a density of 0.03 to start with, so they have a density of 1.0 after the asteroid.cfg patch is applied. Regardless, the pull request I sent will make it work for any density 'roid.

I sent you a pull request on GitHub because the calculation of excavated volume was wrong. It was just a multiplication sign where it should have been division. Not a big deal since your MM patch sets the density to 1, but I prefer a slightly lower density and my asteroids weren't letting me put in the volume they should have. Also, is it possible to mine out only the rock and leave the ore for later, or do all asteroid resources get mined simultaneously and the excess dumped?

Wow! +1 to you for writing this out. This is exactly it. If you're curious to visualize what effect any changes in those variables will have on a given trip cost, I have a MATLAB script that does exactly that in the spoiler below.