Using tri- and quad-adapters both ways

[Tarheel1999]

2 minutes ago, Kerbal101 said:

@Tarheel1999 I don't think so

 

Multicoupling docking ports and having multicouplers connect to multiple nodes is not the same thing. My point re multicouplers stands. 

[Kerbal101]

@Tarheel1999 You said its engine limitation - its not. Its a bug.
 

All ports perfectly docked, all ports perfectly connected to each quadcouplers.

The front wheels of the vehicle are held by docks.

 

When I release two upper docks - no change. But when I release one bottom dock - connection breaks without part breakage.
Note: I set as target the upper dock on docking. Means - all four docks were indeed engaged and such vehicle configuration is very possible by engine.

 

Edited October 7, 2016 by Kerbal101

[Red Iron Crown]

6 minutes ago, Kerbal101 said:

All ports perfectly docked, all ports perfectly connected to each quadcouplers.

Only one of those is a "true" node connection, the other three are more akin to struts.

[Kerbal101]

Here, I switched to vehicle 2 (at slope), picked upper docking port as "Control From" and set another upper Port as "Set as Target".
Gave a bit of gas, and its redocked!

Afterwards I Shift-RightClicked all docking ports - and undocked the upper ones.

Here is the vehicle again being held by lower docking ports.
Notice the perfect connection through out the overstressed two lower docking ports. Wheels are in the air, prograde is at angle.

[Plusck]

4 minutes ago, Kerbal101 said:

[multi-docking-port connections]

Nobody is denying that you can connect multiple docking ports, and it provides a strong connection.

However, the game simply cannot close a circle because craft have a tree structure - and a tree cannot grow into a circle.

14 minutes ago, Red Iron Crown said:

Only one of those is a "true" node connection, the other three are more akin to struts.

Does this mean that multiple docking port connections also cannot occlude for drag? I forget...

[Red Iron Crown]

3 minutes ago, Plusck said:

Does this mean that multiple docking port connections also cannot occlude for drag? I forget...

Not sure about drag, but for resource flow one connection is considered the "master" connection.

[Kerbal101]

8 minutes ago, Red Iron Crown said:

Only one of those is a "true" node connection, the other three are more akin to struts.

Yes, I understand that node can be split - but can't be shrank.
But this is not about ability to sew nodes technically proper together, but about the connection function of the node once passed through the coupler.

Currently the functionality of bracketed** coupler junctions differs between generated from VAB/SPH  and connected "live".

It would be extremely cool if such "live" "autostrut" would be also generated after vehicle leaves the VAB/SPH - so its the same connection as when its redocked, not like its now (no connection at all).
I am sure that the couplers will also be used "bracketed", for very different goals.

Examples: multipart orbital-only spacecraft (fuel docking/staging), rocket payload or payload in cargo bays (swaying around when getting into orbit), multistage asporagus single-launch spacecraft going haywire if couplers used in bracketed mode anywhere.

 

Demonstration (download demo "craft") total links:20, capable links: 5 - valid links: 1, struts-only held links:4.  Only one link active in each quad on all sides, including middle.

 

 

Cutdown example - if bracketed above, the only connected joint is "liquid fuel". When closed over the top - all four side branches are essentially held only on struts.

 

** bracketed coupler configs affected:

basic bi coupler bracket: --(  2xpayload )---  profile cut view:   . .

tri coupler: --E  3xpayload Ǝ---  profile cut view:   ∵

quad coupler: --⋐4xpayload ⋑---     profile cut view: ∷

I am also using 6/1-multidock joint (click to view) for interstellar ship.
Appears that when connected in SPH/VAB - only 1 port functional; when connected "live" - all 7 functional.

[Tarheel1999]

Also not a bug. When you connect docking ports in the VAB, they are not docked but are connected by nodes, i.e., "coupled." Once you decouple the docking port in flight it can be "docked". That is how the game works and how it has always worked. 

[Kerbal101]

31 minutes ago, Tarheel1999 said:

Also not a bug. When you connect docking ports in the VAB, they are not docked but are connected by nodes, i.e., "coupled." Once you decouple the docking port in flight it can be "docked". That is how the game works and how it has always worked. 

Its a bug. A bug is anything that is working not as expected.
A quadcoupler is expected to connect to all nodes its touching - regardless how its coupled. Engine limitation does not remove "bug". The workaround in "live" mode fixes it - regardless how technically this is fixed, in SPH/VAB its not fixed.

Technical fact how it fixes it - by hidden struts or by making actual node - is of very little significance. Function is important.

"This is how game works and how it has always worked" - is invalid argument.

 

I can very easily prove you wrong - in existing VAB/SPH logic, all descending nodes of the coupler (two/three/four) become subnodes.
If your logic would be correct, then only single one would stay - others would not connect at all.

Thus if you see this as wrong and thus you want to make the couplers completely useless reasoning that from "engine supports only one node" argument - please fire a bug/thread and link to it.

[Red Iron Crown]

1 minute ago, Kerbal101 said:

Its a bug. A bug is anything that is working not as expected.
A quadcoupler is expected to connect to all nodes its touching - regardless how its coupled. Engine limitation does not remove "bug". The workaround in "live" mode fixes it - regardless how technically this is fixed, in SPH/VAB its not fixed.

A caveat here: "As expected" is shorthand for "as expected by the developers", not "as expected by the users". You can certainly make a case that it's not ideal behavior, but it is not a bug as this is how the game's design is made to work.

[Plusck]

Just now, Kerbal101 said:

Its a bug. A bug is anything that is working not as expected.
A quadcoupler is expected to connect to all nodes its touching - regardless how its coupled. Engine limitation does not remove "bug". The workaround in "live" mode fixes it - regardless how technically this is fixed, in SPH/VAB its not fixed.

Technical fact how it fixes it - by hidden struts or by making actual node - is of very little significance. Function is important.

"This is how game works and how it has always worked" - is invalid argument.

 

I can very easily prove you wrong - in existing VAB/SPH logic, all descending nodes of the coupler (two/three/four) become subnodes.
If your logic would be correct, then only single one would stay - others would not connect at all.

Thus if you see this as wrong and thus you want to make the couplers completely useless reasoning that from "engine supports only one node" argument - please fire a bug/thread and link to it.

It is working as expected. It is a tree structure, and so grows as you build it. But you cannot simultaneously attach one item to two pre-existing items, therefore you cannot close a circle in the VAB. An item could have a hundred nodes on it - it would still be perfectly workable. But you could only ever attach one of those nodes to one other part at a time - or several nodes to several separate parts using symmetry. Attaching one part to several nodes is an impossibility.

If you have docking ports facing one another, they will snap to when you load a craft. Therefore you can strengthen loads in cargo bays and suchlike by adding docking ports: they don't connect in the VAB, but they'll snap to when the craft loads.

This is not a bug, it is a limitation of the tree structure of craft. It is how the game works and how it has always worked. The only way to change this woud be to completely redesign the whole building process. It is annoying, perhaps, but as soon as you understand that you can only ever connect one item to one item in the VAB (or with symmetry, several items to one item) you'll understand it is not a bug.

 

[Kerbal101]

1 minute ago, Red Iron Crown said:

A caveat here: "As expected" is shorthand for "as expected by the developers", not "as expected by the users". You can certainly make a case that it's not ideal behavior, but it is not a bug as this is how the game's design is made to work.

Old Volkswagen cars used compressed air from emergency tire, to blow glass cleaner. Completely weird developer-side bandaid, that worked to make an expected function - which contributed to selling value.
Later, it was redesigned with dedicated electronic pump - proper developer-side way. But users were already given the expected functionality, it was just internally re-architectured.

 

Another live example, deacceleration engines.
This bug is currently destabilizing aerodynamics of the rocket. Any added weight on top of the upper decoupler will decenter the rocket on launch:

Only the part with mouseover highlights in VAB, thus the whole top of the rocket is held by single piece (1/4) that is in addition - de-centralized.
Shrouds are off on this image.

Launch example (half initial thrust to not overheat SRB):

[Red Iron Crown]

1 minute ago, Kerbal101 said:

Old Volkswagen cars used compressed air from emergency tire, to blow glass cleaner. Completely weird developer-side bandaid, that worked to make an expected function - which contributed to selling value.
Later, it was redesigned with dedicated electronic pump - proper developer-side way. But users were already given the expected functionality, it was just internally re-architectured.

Not sure what your point is with this anecdote. You keep showing examples of the intended behavior (i.e. single - multiple - single node connections are not directly supported), and I gather that you consider this undesirable, but undesirable is not the same as a bug. 

[Kerbal101]

24 minutes ago, Plusck said:

This is not a bug, it is a limitation of the tree structure of craft. It is how the game works and how it has always worked. The only way to change this woud be to completely redesign the whole building process. It is annoying, perhaps, but as soon as you understand that you can only ever connect one item to one item in the VAB (or with symmetry, several items to one item) you'll understand it is not a bug.

 

Please do not use an invalid argument. "Used" aka "normal" is not a synonym with "proper", "correct".

The autostrut logic already fixes issue in "live" mode on docking. Applying this in VAB will solve the bug.

[Red Iron Crown]

6 minutes ago, Kerbal101 said:

The autostrut logic already fixes issue in "live" mode on docking. Applying this in VAB will solve the bug.

It really wouldn't. A strut is not the same as a true primary node connection for things like drag and resource flow.

[Kerbal101]

3 minutes ago, Red Iron Crown said:

Not sure what your point is with this anecdote. You keep showing examples of the intended behavior (i.e. single - multiple - single node connections are not directly supported), and I gather that you consider this undesirable, but undesirable is not the same as a bug. 

Breaking things because it does not work as expected - is not "undesirable". A coupler is supposed to couple.

I understand that there is an engine limitation ("single - multiple - single node connections are not directly supported") which exactly leads to "not working as expected" aka "bug".
Yet the expected behavior is present  in "live" mode (again, I understand that its achieved via a workaround), but regardless how its realized, from rocket designer perspective "workaround" > "absent feature/limit/bug".

Another way to fix this, is to remove the bracketing functionality by setting a maximum of 1 coupler in a row for the whole craft.
But this will be called feature regression. :/

[Tarheel1999]

In 1.1.3 docking ports are not autostrutted. They are connected in flight with a connection appromixating struts. 1.2 introduces the ability to autostrut parts which if used properly will likely address the issues you find in your designs. It will also reduce or eliminate the need to use multiple docking ports for structural purposes.  It is highly unlikely that there will ever be an option to "dock" docking ports in the VAB. 

Edited October 7, 2016 by Tarheel1999

[Red Iron Crown]

7 minutes ago, Kerbal101 said:

Breaking things because it does not work as expected - is not "undesirable". A coupler is supposed to couple.

I understand that there is an engine limitation ("single - multiple - single node connections are not directly supported") which exactly leads to "not working as expected" aka "bug".

"Expected" again. It is the developer's expectation that makes things expected or unexpected when reporting bugs. This is feedback, because some users consider the intended behavior undesirable.

7 minutes ago, Kerbal101 said:

Yet the expected behavior is present  in "live" mode (again, I understand that its achieved via a workaround), but regardless how its realized, from rocket designer perspective "workaround" > "absent feature/limit/bug".

It is not. True nodal multiconnection don't work in any mode. Additional docking ports create structural links similar to struts but they do not make true nodal connections.

 

[Kerbal101]

1 minute ago, Red Iron Crown said:

It really wouldn't. A strut is not the same as a true primary node connection for things like drag and resource flow.

The listed features of primary node are not applicable to the problem. Let me explain:

1) Drag - yes, I already saw any strut to increase drag. But consider that an extra drag from the hidden strut is better than a "banana" rocket due to random shift of aerodynamic center due of eccentricity of the load caused by the problem in this particular case.
2) Resource flow - completely agree, but this seem to be already solved in 1.1.3. I observed for example, that stock KSP distributes/consumes all fuel equally, regardless of the connection hierarchy. If I remember correctly, 1.0.5 did not do that.
Absent element 3) Physical connection between joints. This causes only 1/of N docking ports holding, fuel tanks/weight swinging/ lift imbalance.

The (3) is not exclusive part of "true primary node", but also present in "strut" which I assume is used hidden in "live" simulation (see initial roller images).
It can be omitted in VAB/SPH with whole existing node hierarchy - the problem only happens in live simulation.
I see no reasons not to apply this when vehicle is in the whole simulation, not only when docking.

TL/DR logic (I don't know c#, sorry):
If the node is a splitting coupler node(not main big node) AND there is a open node in its direct(aka "exactly below") proximity AND if its simulation THEN apply hidden struts with same physics force as typical for size of this node.
This fixes all coupler issues.

8 minutes ago, Red Iron Crown said:

"Expected" again. It is the developer's expectation that makes things expected or unexpected when reporting bugs. This is feedback, because some users consider the intended behavior undesirable.

Okay, I remember one recent case:

Case: exploding lander legs by walking kerbal.
Developer: expected.
User: O_o (which I understand)

Fix: remove physical occlusion, Kerbals can walk through the legs - but its lesser evil than exploding legs.
Developer: O_o (I suppose, aka "bandaid" hate - which I understand)
User:

I strongly think that exploding legs was one of the issues that directly hindered "that version" KSP sales via reviews and word of mouth.

As a buyer, I expect coupler to work.

20 minutes ago, Tarheel1999 said:

In 1.1.3 docking ports are not autostrutted. They are connected in flight with a connection appromixating struts. 1.2 introduces the ability to autostrut parts which if used properly will likely address the issues you find in your designs. It will also reduce or eliminate the need to use multiple docking ports for structural purposes.  It is highly unlikely that there will ever be an option to "dock" docking ports in the VAB. 

1.2 is currently unavailable in my distribution channel (GOG), so I hope its fixed.
I never asked fro option to dock docking ports in VAB. I asked for couplers to couple - in simulation, not VAB/SPH - regardless which side they are facing.

[Harry Rhodan]

I expect all chess pieces o move exactly the same - chess is a buggy mess.

[Red Iron Crown]

1 minute ago, Kerbal101 said:

The listed features of primary node are not applicable to the problem. Let me explain:

1) Drag - yes, I already saw any strut to increase drag. But consider that an extra drag from the hidden strut is better than a "banana" rocket due to random shift of aerodynamic center due of eccentricity of the load caused by the problem in this particular case.

Consider that one of the nodes is properly occluded while the others are likely not (haven't tested so not 100% sure).

1 minute ago, Kerbal101 said:

2) Resource flow - completely agree, but this seem to be already solved in 1.1.3. I observed for example, that stock KSP distributes/consumes all fuel equally, regardless of the connection hierarchy. If I remember correctly, 1.0.5 did not do that.

That flow mode is not a 1.1.3 feature aside from jets and the rapier. Are you thinking of 1.2?

1 minute ago, Kerbal101 said:

Absent element 3) Physical connection between joints. This causes only 1/of N docking ports holding, fuel tanks/weight swinging/ lift imbalance.

I don't know what you mean by this.

1 minute ago, Kerbal101 said:

The (3) is not exclusive part of "true primary node", but also present in "strut" which I assume is used hidden in "live" simulation (see initial roller images).
It can be omitted in VAB/SPH with whole existing node hierarchy - the problem only happens in live simulation.
I see no reasons not to apply this when vehicle is in the whole simulation, not only when docking.

TL/DR logic (I don't know c#, sorry):
If the node is a splitting coupler node(not main big node) AND there is a open node in its direct(aka "exactly below") proximity AND if its simulation THEN apply hidden struts with same physics force as typical for size of this node.
This fixes all coupler issues.

Forgive me, but this is trivializing a problem that is more complex than it appears at first glance. 

[Kerbal101]

28 minutes ago, Red Iron Crown said:

Consider that one of the nodes is properly occluded while the others are likely not (haven't tested so not 100% sure).

That flow mode is not a 1.1.3 feature aside from jets and the rapier. Are you thinking of 1.2?

I don't know what you mean by this.

Forgive me, but this is trivializing a problem that is more complex than it appears at first glance. 

Re: Flow mode: Yes, whiplash and rapier.

Re: Problem
Okay, let me throw the quint-essence of the problem in (1-2-3):

1) Design:

2) Expectations (that either - all four bend, or none of them):

3) Reality:

 

Now: If I split the thing in two halves in the middle, place pair of docking ports in each of four columns AND CONNECT whole vehicle LIVE together - issue is not reproducible (fixed by "hidden struts", but - fixed). This behavior in simulation is the problem.
 

@Tarheel1999 or anyone interested: actually the docking port pairs do connect properly in VAB/SPH. All four(two, three, six, twenty). What breaks them - is the "both ways" coupler/adapter attachment (see thread title). If I use my own "coupler", I already encounter the problem in VAB/SPH, as I am unable to "sew" the split hierarchy back. Its okay that its unfixable there, manual struts will do.

Edited October 7, 2016 by Kerbal101

[Red Iron Crown]

1 minute ago, Kerbal101 said:

Expectations (that either - all four bend, or none of them

Again, your expectation, not that of the developers. One-to-many-to-one nodal connections don't work, by design limitation. I don't really know what else to say here.

[Kerbal101]

10 minutes ago, Red Iron Crown said:

Again, your expectation, not that of the developers. One-to-many-to-one nodal connections don't work, by design limitation. I don't really know what else to say here.

Means all in-game duo/tri/quad couplers are useless and dangerous (unpredictable behavior), because only manually struted/designed couplers will work as expected.

I'll report back if 1.2 release addresses this issue.

Edited October 7, 2016 by Kerbal101

[Red Iron Crown]

3 minutes ago, Kerbal101 said:

Means all in-game duo/tri/quad couplers are useless and dangerous (unpredictable behavior), because only manually struted/designed couplers will work as expected.

I'll report back if 1.2 release addresses this issue.

Their intended use is to split the stack but not recombine it. They work fine for this, generally speaking. Nice hyperbole though, "One unintended possible use case doesn't work so the parts are useless and dangerous." 

I can tell you now that 1.2 does not change this behavior.