Using tri- and quad-adapters both ways

[Kosmic Debris]

I was pretty excited about the new stack adapters, but I've run into a weird glitch. I basically need to put one on both ends of a set of engines, as I'm trying to change engines in space with docking adapters. But...I can't get the stack adapters to line up on either end. I've tried rotating the adapters and everything else I can think of - is there a trick to this, or am I just trying to do the impossible?

[capi3101]

You mean an adapter engine sandwich? I've gotten them to work with some success (the decouplers have a tendency to explode when they're activated but so far all that's done as been to blow up fairings, leaving engines intact.

Here's what you do:

1) Stick the adapter on the bottom of the stack.

2) Set your symmetry to match the adapter type and make sure snap-to is on. For example, if you're using a quad adapter, use 4x symmetry.

3) Attach your engines. Use shift-Q and shift-E if they don't want to snap on until all engines turn green.

4) Slap the decouplers/seperators/docking ports on the bottom of your engines. (Use struts later if you go with ports).

5) Flip the other adapter upside down (WASD, twice on the same key you pick)

6) Attach it to the decouplers.

I'm actually using this at the moment on my Apollo-style Duna mission; I haven't taken screenshots yet but I can take some later tonight and post them if it'd be at all helpful to you.

[M4ck]

Actually, that way will only get one of the 4 parts connected to the next. You could make it work if the stack under the coupler goes like this: engine/decoupler/docking port facing down(with 4x symmetry). Then, build down on one of them a structure of docking port up(so they are connected), quadcoupler(QEd so it lies properly under the previous one). Now add 3 more, separate docking ports under the other three engines. It's important to make sure that they are connected to the quadcoupler, not the other ports.(you can check that by trying to place some other part with a docking node; you will then see green nodes in your connection in places where the docks are NOT attached to parts; you want these nodes between the docks, not between the docks and the coupler) At the moment, the upper and lower part is connected by the one docking port pair you've assembled at first, but at the launch, the other three should click into place(at least that's what people say happens). Using docking ports is the only way to have "times X" connection in a vessel, due to each part having a single other part set as its parent, in other words when building from the core part, you can only spread the "lines", you cannot merge them back.

Edited August 28, 2013 by M4ck

[capi3101]

Beg to differ with you on that - You can put a docking port below a decoupler or seperator and it will attach...

Wait, that not what I said in my original post, was it? My apologies. If you're using docking ports to hold the ship together, you will need to put something above them like a decoupler or seperator; it will give something for the docking port to couple to and generate a fairing for the engine. Time comes to cut it lose, you can just right click and "decouple node" and off it will go. You can later right click to remove the decouplers/seperators and the fairings they generated manually. I mainly just mentioned docking ports as an option; they will attach to other bits without a docking port above them - they just won't reattach if they get cut loose.

I get the impression I'm not explaining that well...look at this. And know that yes, you can get that narrowed back down to a single stack. I've done it myself, but as they say, pics or it didn't happen, and I don't have any at the moment...

[PetWolverine]

Beg to differ with you on that - You can put a docking port below a decoupler or seperator and it will attach...

The issue isn't getting the docking port to attach to something other than a docking port; it's having a rocket design that splits and then comes back together. You can't. You can place a quadcoupler so that it appears to be connected to four points, but it is in fact only connected to one of them. You can tell this by selecting another part to place, which will cause the connection nodes to show, or simply by taking the vehicle to the launchpad, where only one of the four nodes will remain stable while the others slide around and the rocket likely falls apart.

Possible designs have a tree shape, in the sense that if you diagram a design as a graph, labeling the points on the graph as parts and connecting them with lines where they are connected in the VAB, there will be no loops or "cycles" in the graph.

Rather than trying to connect a quadcoupler to four existing attachment nodes, the solution is to connect it to one attachment node in the VAB, and then arrange docking ports such that they will dock as soon as you take it to the launchpad.

Not allowed:

       Bicoupler
        /     \
      Part   Part
        \     /
       Bicoupler

Notice that there is a cycle: You can go down one side and come back up the other, returning to where you started from without traversing the same edge twice.

Allowed:

       Bicoupler
        /     \
      Part   Part
       |       |
      Dock   Dock
               |
      Dock   Dock
        \     /
       Bicoupler

There are no cycles in this design. The missing connection between the two docking ports on the left will become connected once physics takes effect, because the ports are positioned perfectly for docking. Cycles are allowed at that point, just not in the VAB.

[capi3101]

Well, I'll check my designs again, because I have done this. Twice.

Is there no difference between an n-coupler and a n-adapter? I'm talking about using adapters...

Edited August 29, 2013 by capi3101

[sojourner]

Nope, there is no difference. to see the problem better, try just using engines between adapters. Adding the decouplers is creating farings on all the engines, but not actually creating solid connections. if you take the decouples out of the equation and attach the decoupler directly you'll see that only one engine gets fairinged, indicating a solid connection. Even with this single connection you can make a rocket work, just use lots of struts.

[Dispatcher]

I agree with sojourner, having run into the situation while making 2 stage landers. The craft will look like its all snugged together, but there is only one connection point. I think that's just the way that the editor is right now. The craft will still work, and it was a good idea about the struts.

[Sirine]

I'm looking forward for the solution.

[Sirine]

And here is my solution...

The main problem = The Bi-Tri-Qu-coupler-adapter, they only go in 1 direction. Put something in between them which support bi-direction, like fuel tank. and make the fuel flow "down" by connecting the "fuel pipe" downward, and problem solve.

Edited August 29, 2013 by Sirine
Adding more image

[Sirine]

Farings? Here are the 3 LV-N Farings.

[allmhuran]

The fairings are there because you have added a decoupler below each engine. But as everyone has said, only one of those decouplers is actually connected to the bottom tricoupler. What sojourner is helpfully suggesting is that for the purpose of self-enlightenment, *remove the decouplers entirely* in the VAB and attach the lower tricoupler directly to the engines. Only one of the engines (the one that is actually attached to the lower tricoupler) will get a fairing.

And, as has been said by others already but still seems to need repeating, the only solution to this is to use docking ports. A detailed description of the technique can be found here:

http://forum.kerbalspaceprogram.com/showthread.php/43621-How-to-have-engine-clusters-in-upper-stages

[Sirine]

Yes, I cheated...I change the .craft file.

part = liquidEngineMini_4294107242

partName = Part

pos = 0.625,15.13789,-0.3624999

rot = 0,0.8660254,0,-0.5000001

attRot = 0,0,0,1

mir = 1,1,1

istg = 0

dstg = 0

sidx = 0

sqor = 0

attm = 0

link = adapterLargeSmallTri_4294104406 <----***********["I added this link"]*************

sym = liquidEngineMini_4294107606

sym = liquidEngineMini_4294107316

attN = top,adapterLargeSmallTri_4294115512

attN = bottom,adapterLargeSmallTri_4294104406

[Sirine]

Another cheat...

Warning: Current version are really NOT supported the tri-to tri both ways. Do this and you will damage your craft file, and make it unusable.

[allmhuran]

I don't know the format of craft files. Does "mir = 1,1,1" indicate that this one part entry applies to all three of the parts in the model? If not then this is just the part entry for one of the three engines, and one of the three engines will indeed be connected at both top and bottom.

What's the distinction between "link" and "attN"? Assuming that attN = attachment node, is "link" used by things like struts, fuel lines and docking ports? If so, have you simply turned the engine itself into a kind of docking port? In which case the statement "the only solution is to use docking ports" is still true.

What happens when you subject it to physics (ie, take it to the launch pad)?

[Sirine]

Tested to the physic...at launch pad...seems..ok.

Warning: Current version are really NOT supported the tri-to tri both ways. Do this and you "will" damage your craft file, and make it unusable.

Unless are for Fun or Debugging purposes.

[sojourner]

And here is my solution...

The main problem = The Bi-Tri-Qu-coupler-adapter, they only go in 1 direction. Put something in between them which support bi-direction, like fuel tank. and make the fuel flow "down" by connecting the "fuel pipe" downward, and problem solve.

Fuel flow is not the issue being discussed.

[Sirine]

well, for all the "viewer" & "poster" I hereby apologies for my mistake and misleading. Regarding the Bi-Tri-Qu-coupler-adapter connected both ways.

They are NOT supported at current version 0-21-1. (unless using the docking port solution).

(Even the Fuel tank are only connected to only one of them, "already check the .craft file".)

So, I'm sorry.

[Galane]

Seems like a possible solution would be a special multi-node decoupler for each model of 1-to-n adapter for use on top of them when flipped upside down. But could it be shoehorned into the current KSP version?

Then there's the issue of if it'd be simpler to allow such "doughnut rockets" (they're loops, topologically equivalent to a torus, as are humans and all animals with a digestive tract with two open ends) in a future version, using stock parts or to make a specific allowance for special multi-decouplers.

Oooorrrr, instead of multi-decouplers, integrate that function into upside down versions of the 1-to-n adapters - making them n-to-1 adapters. That would open the way to N-to-n and n-to-N adapters, where the upper and lower case N represents a larger or smaller number of attachments.

[capi3101]

Built a couple of test rockets last night; tests showed y'all were right. Certainly explains why the decouplers were exploding...

My apolgies, y'all. I wouldn't have argued the point if I hadn't thought I was right.

PetWolverine's solution is probably the correct one...I didn't test it out last night. Probably what you could do is go ahead and build the bottom part first - the adapter with the ports - then take it off your stack, flip it over and set it aside. Go ahead then and build the upper part - adapter, engine, decoupler, port - then grab the bottom part and stick it on. The ports give you the connection; the decouplers let you slough the whole thing off as normal. Like I said, I haven't tested this configuration out and I've already proven myself wrong in this conversation, so take this advice with a big grain of salt.

Edited August 29, 2013 by capi3101

[sojourner]

Seems like a possible solution would be a special multi-node decoupler for each model of 1-to-n adapter for use on top of them when flipped upside down. But could it be shoehorned into the current KSP version?

Then there's the issue of if it'd be simpler to allow such "doughnut rockets" (they're loops, topologically equivalent to a torus, as are humans and all animals with a digestive tract with two open ends) in a future version, using stock parts or to make a specific allowance for special multi-decouplers.

Oooorrrr, instead of multi-decouplers, integrate that function into upside down versions of the 1-to-n adapters - making them n-to-1 adapters. That would open the way to N-to-n and n-to-N adapters, where the upper and lower case N represents a larger or smaller number of attachments.

It's not the parts that are the issue. It's the way the game engine handles ship construction. Squad would have to re-write ship construction to allow for multiple connections that form loops. Not sure how difficult that would be.

[allmhuran]

The difficulty probably lies somewhere in the physics handling. I'm just using 20 odd years of programming to arrive at a guess for the implementation, but it seems like right now forces could be pushed down through the hierarchy using basic BFS or DFS methods, but if you introduce graphs then you introduce the problem of having forces cycle through the graph, you'd have to write in some form of attenuation, you could get crazy shennanigans with different overlapping cycles of forces converging and diverging, etc.

[sojourner]

^Not sure it's a physics handling issue. Other wise the docking port method of creating loops mentioned earlier would come with caveats from the people using it about "crazy shenanigans" occurring.

[allmhuran]

True, but given the way long ships tend to "wag" their tail (for example) if the tail is connected via docking, it seems like docking ports transfer forces in a slightly unusual way (that isn't fully explained by simply calling it a "weaker" connection).

[sojourner]

^But multiple docking ports are often the method used to strengthen a ship against wobble. Further evidence against shenanigans caused by loops.