Multi-connecting in editor (especially for multi-couplers)

[thox]

I came across the problem that an upside-down bi-/tri-/quad-coupler that is placed below a similar cluster of engines only connects to one of those, making the craft extremely unstable at this point and therefore making engine clusters in upper stages impossible (well, basically possible with lots of struts, but... you know, that might be very Kerbal but neither perfectly stable nor elegant).

So I am suggesting to make all the attachment points of the multi-coupler connect to the those above, which might be realizable by handling everything as it is (coupler connects to only one point at first), and then making those attachment points overlaying with other (free) attachment points (in this example the ones of the engines above) connect to those as well.

This might, as mentioned, especially be handy for engine clusters in upper stages and possibly also helpful in some other situations.

[dlmarti]

One part connects to one part, thats it. Its a limitation of the game engine.

[itsme86]

One part connects to one part, thats it. Its a limitation of the game engine.

That's a gross over-simplification. I mean, how do you explain struts or tri-couplers then? They obviously connect to more than one part.

[thox]

I know that in unity it is basically only possible have one new part connected to one other part standing above it in the hierachic structure, but what i was thinking about was just making the remaining free (and overlapping) attachment points automatically get physically attached to each other afterwards (kind of adding a strut connector between them that has zero weight and volume and the same stability as the normal connection).

[chaos_forge]

I don't know how this could be done, but it definitely needs to be done. It would really extend the types of rocket that you can build. And it is possible to auto-connect crafts, because the docking already do that.

[Kimberly]

Under the current system, attachment nodes follow a parent-child structure, and one part can only have one parent. This means multiple connections with multi-couplers are not possible. However, a ship is allowed to dock to itself, and it can do so multiple times...which is why it's possible to do this with docking ports. But docking ports only work if physics are turned on, which they aren't in the VAB.

[dlmarti]

That's a gross over-simplification. I mean, how do you explain struts or tri-couplers then? They obviously connect to more than one part.

You are assuming they are a real part, and not a kludge.

[toric5]

if you can do it with docking ports, it should be possible to make a workaround so the game sees attachment nodes as docking ports.

[chaos_forge]

^This. Is something like that possible?

[Eric S]

That's a gross over-simplification. I mean, how do you explain struts or tri-couplers then? They obviously connect to more than one part.

Actually, it's not, at least not by much. The tree structure that KSP uses to connect parts means that each part is connected to one other part (except the first part placed). The thing to keep in mind is that other parts can connect to that part, the limitation isn't symmetrical.

As for struts, they actually step outside the normal part tree for the connection at the second end. They're a connection point and a direction, there is no reference to the second part. In fact, if you move or even remove the part that the strut connects to, as long as there's still something for the strut to connect to in that direction, the strut will connect rather than retract.

[chaos_forge]

Actually, it's not, at least not by much. The tree structure that KSP uses to connect parts means that each part is connected to one other part (except the first part placed). The thing to keep in mind is that other parts can connect to that part, the limitation isn't symmetrical.

As for struts, they actually step outside the normal part tree for the connection at the second end. They're a connection point and a direction, there is no reference to the second part. In fact, if you move or even remove the part that the strut connects to, as long as there's still something for the strut to connect to in that direction, the strut will connect rather than retract.

This is what a data tree looks like. Note how many nodes are connected to more than one node. The limitation here it that to have a tri "re-coupler" would require arrows pointing up, which is not allowed. That means that any solution to this, like struts, would have to go outside the normal tree structure. Maybe have invisible struts pointing straight up and invisible fuel lines pointing straight down wherever there's an open node?

Edited July 29, 2013 by chaos_forge

[thox]

I don't even think invisible struts and fuel lines would be necessary, the connection might even be like a normal connection, just with the attachment logic bent around the tree structure like struts and fuel lines. And to achieve auto-connection for the free attachment points/nodes it might be best to have the nodes check whether there is another one in the exact same place and, if there is one, make a connection with it.

[itsme86]

You are assuming they are a real part, and not a kludge.

No I'm not, I'm saying that your comment was an over-simplification, which you just confirmed. It's not a simple as "one part connects to one part, that's it." You just said yourself that there are some parts that work around that limitation. And I'm not just talking about struts, but also multi-part couplers.

[itsme86]

Actually, it's not, at least not by much. The tree structure that KSP uses to connect parts means that each part is connected to one other part (except the first part placed). The thing to keep in mind is that other parts can connect to that part, the limitation isn't symmetrical.

As for struts, they actually step outside the normal part tree for the connection at the second end. They're a connection point and a direction, there is no reference to the second part. In fact, if you move or even remove the part that the strut connects to, as long as there's still something for the strut to connect to in that direction, the strut will connect rather than retract.

Yeah, but the question is, is that a limitation of the Unity engine that the game is built on, and therefore outside of the control of the KSP dev team, or is it a symptom of the structure that the KSP dev team has created?

[Eric S]

Yeah, but the question is, is that a limitation of the Unity engine that the game is built on, and therefore outside of the control of the KSP dev team, or is it a symptom of the structure that the KSP dev team has created?

That I can't answer. I've heard it claimed that it's a Unity limitation, but haven't heard of any independent confirmation.

[vexx32]

Here's how it works. Each part has to be attached somewhere. Now, that attachment point is either a surface or node attachment. The limitation of the game is that one part cannot be attached simultaneously to two other parts -- in other words, it can only have one "parent" part. That's what a tree structure is. To have a "reverse tricoupler" or to attach one part to three different nodes is impossible. Do you really think this has never come up before? It's come up at least fifty times in my own experience, and that's only back to 0.13.3. To alter the construction logic to such an extent to allow this would make it extremely complicated, and the craft files' structure would have to be reworked, because at present it is impossible to save a single part with two parent attachments, even if you attempted to force it by manually editing the file.

Unless you're a programmer, you understand tree structures and their limitations, and you have a workable solution and ideally some example code, please don't waste your time on this. This limitation exists for a good reason -- it's damned difficult to remove the damn limitation​.

[allmhuran]

it's damned difficult to remove the damn limitation.

Yep;

To the OP: the only solution is to make the additional attachments via docking ports, as mentioned by a previous responder.

This can be tricky to achieve though. In the VAB only one actual connection will be made. You then create additional "connections" by very carefully and precisely trying to line up docking ports between the sections. When the ship is launched the unattached docking ports that are facing each other will immediately dock when physics kicks in.

The nature of the construction cameras can make this really hard sometimes. The difficulty depends on the structure you're trying to complete. Sometimes it's trivial: If you...

attach a bicoupler (tricoiupler/quad coupler) to the bottom of a stack

attach two docking ports to the bicoupler facing down

Attach ("dock") another port facing up to ONE of those

attach an upwards facing bicoupler to the port that is facing up

Attach an upwards facing docking port to the empty face of the bicoupler

... then the "unattached" upwards facing docking port will be precisely aligned with the downwards facing port above it, and perfectly far away to immediately dock on launch.

However, if you are trying to do something where the geometry doesn't guarantee precision (which is usually the case when trying to make multiple *radial* attachments), you usually have to go into surface attachment mode and move the port pixel by pixel, hoping that you can get the planes perfectly aligned as well as getting zero distnace between the faces.

I'm also not sure if this accomplishes anything other than making this more aesthetically pleasing. Multiple-docking connections have been said to work "like struts". I don't know whether or not they are actually *stronger* than struts, though. So you might accomplish the same structural integrity simply by using a strut, which is way easier and doesn't need all the fiddling.

[chaos_forge]

Unless you're a programmer, you understand tree structures and their limitations, and you have a workable solution and ideally some example code, please don't waste your time on this. This limitation exists for a good reason -- it's damned difficult to remove the damn limitation​.

I understand the limitations of trees, but I don't know how struts work in KSP. If they are indeed directional, what's stopping us from just having invisible struts with a very short max length pointing straight up (or straight normal to the attachment plane, for radial attachment)?

[Eric S]

That's probably the easiest way to do it, but it still has a few issues that I can think of.

1) You have to detect when and where to put the invisible struts. Trivial for people, not so trivial for computers, because if it's not accurate, it can add struts that aren't actually needed, increasing the workload of the physics simulation. Just detecting unconnected nodes that are close together would work for some cases, but I can see cases where it wouldn't (extreme part clipping for example).

2) If any connection in the part graph between the two pieces breaks, the invisible strut will have to break as well.

[vexx32]

Also, you might have reasons not to want the part to attach to everything possible. As a result, it becomes a nightmare working out how to figure out exactly which things to attach where. Having users do it manually would be simplest, but then you need a whole new bunch of VAB commands and logic for them.

[thox]

It's come up at least fifty times in my own experience, and that's only back to 0.13.3.

Ok that is what actually convinced me that it's not going to happen (at least not soon), since it shows that the devs don't want to deal with that issue and I respect that. I still don't think it would be impossible, but they have things to work on that are more important.

[Teodzero]

I've seen almost all the same arguments about inability to delete or replace the first "parent" part. In the end, none of them matter. "That's just how the logic works" - you can say that about every bug, that doesn't justify it. And form the gamplay standpoint it is a bug and it has to be fixed before you can call the game finished.

And I think Squad can (and will) fix it... eventually.

It just became more irritating with all these new parts that can't be used to their full potential. I hope this situation at least pushed it higher in priority list.

[allmhuran]

No, it's *not* a bug, it is an inherent limitation of a deliberate choice. A bug is an effect that was not intended.

[LoneRider]

I think it should be possible while maintaining the only-one-parent rule (which is technically required) to add a field for cross-connecting. Like a part has only one parent (sure) but can have other connections to parts up the tree (just a data list with ids of parts). It is just needed to ensure that physics will apply from these cross-connected parts to the other parts as well. It would have to be a side-implementation (as breaking the only-one-parent rule is not possible) but should be possible. Even if you remove the real parent, one part from the cross-connection list could become parent. Which one shouldnt care, because physics are applied for the cross-connecting parts as well, so it just does not matter which one is the "real" parent on engine-side.

[itsme86]

Here's how it works. Each part has to be attached somewhere. Now, that attachment point is either a surface or node attachment. The limitation of the game is that one part cannot be attached simultaneously to two other parts -- in other words, it can only have one "parent" part. That's what a tree structure is. To have a "reverse tricoupler" or to attach one part to three different nodes is impossible. Do you really think this has never come up before? It's come up at least fifty times in my own experience, and that's only back to 0.13.3. To alter the construction logic to such an extent to allow this would make it extremely complicated, and the craft files' structure would have to be reworked, because at present it is impossible to save a single part with two parent attachments, even if you attempted to force it by manually editing the file.

Unless you're a programmer, you understand tree structures and their limitations, and you have a workable solution and ideally some example code, please don't waste your time on this. This limitation exists for a good reason -- it's damned difficult to remove the damn limitation​.

It just so happens that I am a programmer and I understand tree structures very well. What you're asking for as far as example code goes is impossible without having the existing code related to parts. Here, you want a fix?

Change:

class Part { Part parent; }

To:

class Part { Part[] parents; }

See? Useless. Your vague pseudo-intelligent answer isn't helpful either. How do you know how difficult it is to remove the limitation? There are existing, well-known structures for handling multi-parent nodes. They're called graphs. So, instead of using a tree structure, use a graph structure.

Any answer that simply boils down to "it's hard" is ridiculous. Really? It's hard? Now if the answer instead was "to keep calculations down for performance reasons" or some "game play design choice" or something, then that's totally reasonable. But "it's hard" is just a fail answer as to why something isn't done.