Project

General

Profile

Feedback #6008

Docked secondary docking ports have increased drag and don't crossfeed fuel

Added by Kasuha over 8 years ago. Updated over 7 years ago.

Status:
Needs Clarification
Severity:
Low
Assignee:
-
Category:
Gameplay
Target version:
-
Version:
Platform:
Any
Expansion:
Language:
English (US)
Mod Related:
No
Votes:
Arrow u r green
Arrow d r red

Description

It is not uncommon in KSP that players attach large structures using multiple docking ports at once for greater stability. It is known fact that when multiple docking ports are used at once, only one is "primary" and becomes part of the ship's tree structure while the rest are "secondary" but if docked, they still provide structural support as if there was a strut tying them together.

There are two problems with such docking connections. I am reporting them as bugs since they affect gameplay in negative and unintuitive way.

Bug #1: Secondary docking ports have increased drag. Probable reason is that their docking surface does not count as occluded even though it is attached to the other docking port. This leads to aerodynamic unstability of the docked ship. Primary docked docking ports or docking ports attached in VAB/SPH don't have this problem.

Bug #2: Secondary docking ports don't provide fuel crossfeed through the connection. It is understandable that the standard fuel search does not scan this connection as if it is a normal connection within the ship's tree structure but since the game already draws a virtual strut between the two ports, it should be no problem to draw also two virtual fuel pipes, one in each direction. That would provide full fuel crossfeed capability and intuitive and logical behavior of such docking connections.

For reproduction of both bugs, please see the attached craft file. Attached images document the missing fuel crossfeed capability first, and unbalanced drag second.

I chose "Low" priority since it is gameplay affecting issue that occurs rarely, though in situation where it occurs the only way to avoid it is to use different design.

Clamp-o-tron test.craft (36 KB) Clamp-o-tron test.craft [email protected] Kasuha, 12/03/2015 08:34 PM
screenshot8.png (1.63 MB) screenshot8.png In VAB, disconnected Kasuha, 12/03/2015 08:35 PM
screenshot9.png (1.6 MB) screenshot9.png In VAB, connected Kasuha, 12/03/2015 08:36 PM
screenshot10.png (1.59 MB) screenshot10.png Proof the port is docked Kasuha, 12/03/2015 08:36 PM
screenshot11.png (1.58 MB) screenshot11.png LV-1R engines activated (tweaked to zero thrust), only one has access to fuel. Kasuha, 12/03/2015 08:36 PM
screenshot13.png (1.36 MB) screenshot13.png After launch, although the ship is symmetrical, it leans always to the side with secondary docking connection Kasuha, 12/03/2015 08:36 PM
8919
8920
8921
8922
8924

History

#1 Updated by sal_vager over 8 years ago

Hi Kasuha, thanks for the report, but I believe this may not actually be a bug.

You're right that the other port isn't occluded and that's why there's the drag, the faces of both ports on that side are effectively exposed to airflow.

But you're not quite correct when it comes to the connections, there is no connection of any kind between the second docking ports, not even a virtual strut, so there can be no fuel crossfeed or occlusion from airflow, this is a limitation of the tree method of vessel construction so no connection or crossfeed can be expected.

To join two pairs of docking ports you need to dock them simultaneously in the flight scene, this is not possible in the editor.

Knowing this, the above behaviour is expected, even though it is unintuitive as you say,but knowledge of how KSP works can help people avoid misconceptions.

#2 Updated by Kasuha over 8 years ago

sal_vager wrote:

there is no connection of any kind between the second docking ports, not even a virtual strut

There are moments when I look at what someone else wrote and I don't know what to say.

Did you notice the "Undock" option in the image? Did you even check the image, not mentioning actually testing the reported behavior? The port IS DOCKED! Or do you think there is no structural connection between docked ports? Many player designs would not work if any of that was true!

So I made this test rig to demonstrate you how KSP works when it actually works correctly. It is unrelated to the issue so I am placing my images just on Imgur and I believe you can reconstruct the rig easily in case you decide to test it yourself.

The left docking port is attached from SPH while on the right side the two ports were just installed facing each other and they docked together on deployment on runway. On the right is effectively a secondary connection because the "ship" is docking to itself:

http://imgur.com/ZYhIcB2

As you can see in the image, the structure neatly holds together, unlike when I click Undock.

http://imgur.com/Amw72ll

So let me conclude, facing docking ports DO dock when deployed, DO form secondary docking connections, and DO provide structural support, similar to if there was a strut.

Knowing this, the above behaviour is expected

Secondary docking connections (ship docking to itself) are implemented in game, provide structural support, and adding the rest of the functionality (fuel crossfeed and aerodynamic occlusion) was omitted. The behavior is UNEXPECTED, INCORRECT, and INDETERMINISTIC (since in docking you never know which connection will become primary). It should be fixed regardless whether you agree to call it a bug or not.

Just for your information, even the primary docking connection is different from direct attachment in VAB/SPH. Not only the commands to break that connection differ (decouple/undock), the part information in persistence is different from direct attachment, but even fuel crossfeed works differently. Primary docking connection does NOT behave like if the two parts are axially attached, it works as if there are two fuel pipes drawn between them. Yes, I tested it.

#3 Updated by Squelch over 8 years ago

  • Tracker changed from Bug to Feedback

Kasuha wrote:

There are moments when I look at what someone else wrote and I don't know what to say.

I respectfully direct you towards our guide. Please be courteous at all times on this tracker, and please only report one bug per issue.

Did you notice the "Undock" option in the image? Did you even check the image, not mentioning actually testing the reported behavior? The port IS DOCKED! Or do you think there is no structural connection between docked ports? Many player designs would not work if any of that was true!

So I made this test rig to demonstrate you how KSP works when it actually works correctly. It is unrelated to the issue so I am placing my images just on Imgur and I believe you can reconstruct the rig easily in case you decide to test it yourself.

The left docking port is attached from SPH while on the right side the two ports were just installed facing each other and they docked together on deployment on runway. On the right is effectively a secondary connection because the "ship" is docking to itself:

http://imgur.com/ZYhIcB2

As you can see in the image, the structure neatly holds together, unlike when I click Undock.

http://imgur.com/Amw72ll

So let me conclude, facing docking ports DO dock when deployed, DO form secondary docking connections, and DO provide structural support, similar to if there was a strut.

The notion here is that the docking ports that face each other in close proximity on vessel load, do in fact join together to form a joint. The two docking ports that are attached in the editor are coupled to also form a joint. These are the master or primary connection, with any other docking ports in close proximity to each other forming supplementary joints. The vessel hierarchy will only apply full functionality across the master pair including fuel crossflow and separation. Fuel crossflow across this pair is all that is required for the rest of the vessel, so other, same vessel joints with crossflow control, would be considered superfluous, and this part of the report could be considered moot.

Knowing this, the above behaviour is expected

Secondary docking connections (ship docking to itself) are implemented in game, provide structural support, and adding the rest of the functionality (fuel crossfeed and aerodynamic occlusion) was omitted. The behavior is UNEXPECTED, INCORRECT, and INDETERMINISTIC (since in docking you never know which connection will become primary). It should be fixed regardless whether you agree to call it a bug or not.

The pairing is determined from the order in which they are made in the editor. Supplemental joints are incidental.

Just for your information, even the primary docking connection is different from direct attachment in VAB/SPH. Not only the commands to break that connection differ (decouple/undock), the part information in persistence is different from direct attachment, but even fuel crossfeed works differently. Primary docking connection does NOT behave like if the two parts are axially attached, it works as if there are two fuel pipes drawn between them. Yes, I tested it.

The difference is, docking ports mated in the editor are considered coupled and can be considered as a joint in the whole vessel. They also have the ability to decouple and act as the master for all supplementary docking port pairs. A recreation of your craft with the master pair on the left, and the supplemental pair on the right, shows that decoupling the left pair will result in a total separation or undocking of the lower section, while undocking the right pair will only separate those as shown. Adding an engine to the lower right section allows for the joint to be remade and separated at will, and this does indeed serve the purpose for which many players use this situation for, and that is for rigidity.

There may be an issue with how the part's context menus behave in this context, but this is more of an ambiguity in the labeling if anything.

I'm afraid the closest thing to a bug in this report is the occlusion aspect. The way occlusion is determined relies on the stack nature of the vessel via the attachment nodes. Where there are two or more nodes per joint that are exposed to the airstream, only one pair is actually computed. This is true for both multiple docking ports as well as multicouplers (bi, tri, and quad couplers) I must admit to having overlooked this aspect due to how I have launched my multiport sections for a space station and deep space craft. I have been treating these sections as payloads only, and as such have been within a fairing or cargo bay where the whole assembly is occluded. This is noteworthy, and is acknowledged, so can only be classed as feedback.

#4 Updated by Kasuha over 8 years ago

Squelch wrote:

I respectfully direct you towards our guide.

Nowhere in the guide it says that when I make a report, it will be rejected for reasons unrelated to it or based on claims that are simply not true. I spent considerable time to report a bug, trying to make KSP a better game. This treatment tells me that I should move on with my life instead.

Bug: this issue type is for behaviour you encounter that appears to be unexpected or not intended by design.

Expected behavior: all docking connections behave the same way.

Observed behavior: some docking connections provide fuel crossfeed and have normal drag, other docking connections don't provide fuel crossfeed and have higher drag.

Observed behavior is not expected. There is no objective reason why some docking connections should be different. Internal game design is not objective reason, it is an excuse. And there is no reason why this behavior should be intended, unless developers intended to confuse and upset players.

#5 Updated by Squelch over 8 years ago

Kasuha wrote:

Nowhere in the guide it says that when I make a report, it will be rejected for reasons unrelated to it or based on claims that are simply not true. I spent considerable time to report a bug, trying to make KSP a better game. This treatment tells me that I should move on with my life instead.

Please be assured that your reports are both valued and welcome. I was alluding to one bug per report, policy discussion, and remaining courteous with regards to the guide

I have spent some time teasing out the issues involved here, and yes there are several. I am in the process of writing them up individually for internal consideration.

As was attempted to be explained, vessels work in a hierarchical manner. Starting at the root part, all further connections follow a branching, parent/child relationship. This is most obvious in the editor, and can be seen by mousing over a part to highlight it and all of it's children. This hierarchy drives the functionality of the connected parts, and works well generally. However, this parent/child relationship breaks down when a vessel branches and is then reconnected to itself, so effectively, loops cannot be made. There will always be a linear relationship between the connected parts, and this is not always obvious in the flight scene.

With regards to your example craft, There are several aspects that confuse the issue:
  1. Fuel flow, the multi-couplers (bicoupler in this case) do not crossfeed between the multinode section. The connected docking ports will not be receiving fuel from the coupler, so the crossfeed setting will have no effect. This is a separate issue.
  2. The rightmost docking port pair are joined in the orthodox sense, and this is the only join that can provide full functions. The leftmost pair are unjoined in the editor, and this can be seen by mousing over the assembly. The subsequent joint made by docking in the flightscene is mechanical only, and provides no other function. This means that fuel will not cross this joint, and because the lower port is effectively at the tail of the branch, is not occluded by the port above. Both of these are separate issues.
  3. The bicoupler follows the same parent/child relationship, so a split followed by a re-joining will be treated as a branch as above. Again, the tail of the chain will not be occluded nor provide occlusion.
  4. The order of connection (in the editor or subsequent docking) plays a significant role. The non occluded tail of the branch (top left) is facing towards the airflow, and will be subject to full face drag. Changing this in the editor so the tail is at the bottom left reduces it to tail drag.
  5. Fuel flow rules for rockets is that of fuel being drawn form furthest source first, with regards to the demand. In cases of branched or serpentine vessels, this may not be immediately obvious.
  6. The combination of the bicoupler behaviour, and the docking ports with the above in mind, only serve to confuse the issue. Additional non related parts further complicate a minimal reproduction.

As I said in my last response, the occlusion aspect is acknowledged and has been fed back to the developers. It happens for both coupler split/re-joins, and multiple docking ports separately. The other supplemental issues have also been noted and are being reported separately internally. Please do continue to report, but please also keep to one bug per issue, and also minimal reproductions and examples.

#6 Updated by Squelch over 8 years ago

Correction:

Couplers and adapters only feed fuel from the top node to the other nodes when considering the default orientation. ie, they do not work inverted nor are they able to feed fuel between lower nodes

#7 Updated by TriggerAu over 7 years ago

  • Status changed from New to Needs Clarification

Also available in: Atom PDF