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

[Teodzero]

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

Can you explain from the gameplay standpoint why this ability should be limited? Because the fact that current system just works like that does not mean that it's inherent. Otherwise you could say that about old crazy ASAS, Space Kraken, and the current aerodynamics too.

[chaos_forge]

Can you explain from the gameplay standpoint why this ability should be limited? Because the fact that current system just works like that does not mean that it's inherent. Otherwise you could say that about old crazy ASAS, Space Kraken, and the current aerodynamics too.

You can say that it's a limitation that should be removed, but a bug is very precisely defined as an unintended or unforeseen behavior of a program. The inability to have multi re-couplers is neither.

To use your example: the current aerodynamics are broken, yes, but they are not a bug because they work exactly as they were implemented to work.

[KASASpace]

Well, how about another connection point below where the engines go? Like on the fairings in KW rocketry, just going down? And then when a part such as a decoupler was placed underneath, then a fairing would swallow the whole thing including the stack coupler.

[Ernest3.14]

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.

^This. There was a very well thought-out thread on this a while ago, idk what happened to it though. Whenever the devs get around to implementing it they should take a look at that.

[RadHazard]

^This. There was a very well thought-out thread on this a while ago, idk what happened to it though. Whenever the devs get around to implementing it they should take a look at that.

I've taken courses on graphs and other data structures. I don't know how intertwined trees are to Unity's physics engine, but since things like struts which allow cyclical physics connections work, I assume it's not too deep. Swapping from a tree to a graph structure would involve a major re-write of a lot of game logic, but it shouldn't be too difficult to do, just tedious. You'd have to replace a whole bunch of game logic with algorithms designed to handle graphs. There are plenty of already-made algorithms out there to determine things like connectivity, bridges and articulation points (to determine if an exploding part splits your vessel into two or not), and there are search algorithms that could easily handle things like fuel flow (breadth-first search is one simple example, but there are other, better ways), so it'd just be a matter of actually implementing them in KSP

The hardest part would likely be adding editor tools to make handling multi-connections for vessels. A simple (though not very efficient) way to do it would be to simply connect any parts that intersect with each other and aren't already connected, but letting the user handle connections manually would make them much smarter.

Of course, this would mean a large amount of developer time, and I don't know how big of a benefit it would provide. It may not be worth doing at this point because of how much work it would take, versus the rather marginal benefit it would provide, given we already have struts and multi-docking-port connections to handle most cases.

[edwardc]

Here's an idea. Simplistic maybe, but possible and hopefully not too hard to implement.

As Vexx mentioned, you might NOT want these items to connect, so why not make it the builders choice?

Have a button that creates these connections only if the user wants it.

How do you work out if there should BE a connection?

Easy enough (I think), the nodes should have the EXACT same co-ords in the VAB. Let's face it, if you've used the correct parts these nodes WILL have the same co-ords. So the function runs, checks for unconnected nodes, does a check for duplicate co-ords and finds the 2 overlapping spots on part A and part B. It then creates a 0.0001 length invisible, zero weight, zero drag strut joining the two. Strength the usual between regular joins.

If the user disconnects/moves ANYTHING in the VAB, destroy ALL these connection types. Make him do it as the final step to creating a stable structure. This avoids needing to check them all every time parts are shifted.

[Edit] These invisible struts should transfer fuel power obviously

Yes, doing this the proper way with parent arrays might be hard, take longer, but this is my 2c to try get a quick work-around to make us all happy.

[sharpspoonful]

As I've said before, I'm no programmer. But rather than all all of the previous mental exercises what if there was a part that would bind all attached parts below it as a single entity? The obvious limitation would be that they all act as a single part, and nodes would have to automatically be placed under said parts, but it would be a workaround for things such as engine clusters, and objects without dynamic meshes.

[Jim DiGriz]

Thing to do would be to have a tri-coupler that was both a top and a bottom of a stack, which had three connectors 'inside' it where you could hang engines and fuel tanks, and make the length procedural.

That way the tri-coupler has one parent above it, it has four children (the three stacks below it, and whatever connected to its base). Probably need to have different versions for solid bases and bases without any collision mesh so that engines could fire 'through' it.

There's a few parts in one of the big packs -- NovaPunch or KW Rocketry -- which are kind of like this.

[vexx32]

I've taken courses on graphs and other data structures. I don't know how intertwined trees are to Unity's physics engine, but since things like struts which allow cyclical physics connections work, I assume it's not too deep. Swapping from a tree to a graph structure would involve a major re-write of a lot of game logic, but it shouldn't be too difficult to do, just tedious. You'd have to replace a whole bunch of game logic with algorithms designed to handle graphs. There are plenty of already-made algorithms out there to determine things like connectivity, bridges and articulation points (to determine if an exploding part splits your vessel into two or not), and there are search algorithms that could easily handle things like fuel flow (breadth-first search is one simple example, but there are other, better ways), so it'd just be a matter of actually implementing them in KSP

The hardest part would likely be adding editor tools to make handling multi-connections for vessels. A simple (though not very efficient) way to do it would be to simply connect any parts that intersect with each other and aren't already connected, but letting the user handle connections manually would make them much smarter.

Of course, this would mean a large amount of developer time, and I don't know how big of a benefit it would provide. It may not be worth doing at this point because of how much work it would take, versus the rather marginal benefit it would provide, given we already have struts and multi-docking-port connections to handle most cases.

As complicated as this kind of thing would be, it would be a really brilliant addition, in my opinion. But... it'd probably take a ridiculously long time and I can just see the sheer number of bugs arising from it. Perhaps later on down the road.

[Minarkhaios]

Do we care that the nodes are not connected in the vab ?

Don't using the docking port mechanisms on empty node be enough ?

Something around the lines of :

- Nodes (on problematic parts) behave like dock port (a new object called nodedock).

- The first one is linked in the vab (no change here)

- The other ones are linked on the launchpad

- If the link is created, it can't be removed manually (but still destroyed of course)

- If there is no nodedock facing a nodedock then the nodedock became undockable (to avoid using then as real dock)

- Then controls are given to the user (all steps above are done during the launchpad loading)

Mainly it's just recycling the docking port mechanism.

[Ernest3.14]

As complicated as this kind of thing would be, it would be a really brilliant addition, in my opinion. But... it'd probably take a ridiculously long time and I can just see the sheer number of bugs arising from it. Perhaps later on down the road.

But then there's the argument of the later saves are broken, the more people that are unhappy.

[Kasuha]

I think I'll leave it here, too.

Javascript is disabled. View full album

[federicoaa]

I think I'll leave it here, too.

http://imgur.com/a/x6CZZ

Brilliant!