Parts' drag calculation inside cargo bays

[atomontage]

KSP Version: 1.3.1.1891 (Windows 7 x64), fresh install, fresh sandbox savegame. I keep this particular KSP install for such testing only.
Mods / Add-Ons: All Stock
 

Description: if there is a long enough part inside a cargohold that consists of two shorter ones, then drag is applied to the payload. (I think its because the game thinks that payload part is clipping through the cargobay. Although visually it is only clipping through its front or its back as it is longer than the cargobay.)

I also think the problem is known. But I'm not sure. Also I'd like to know if it's gonna be fixed or not.

The reason I'm reporting this is because there are many modded parts that are longer than the longest cargobay available. Fuel tanks for example.

It also limits how one should attach their payload inside cargobays. 

UPD: not every part bugs. Incomplete list of parts which I've tested (yes = causes the bug):
- FL-T800 Fuel Tank: yes
- Modular Girder Segment XL: no
- M-Beam 200 I-Beam: no
- Mk1 Cockpit: yes
- Orange Tank: yes
- RT-10 Hammer Solid Fuel Booster: yes (omg i've ignited it inside my cargobay.. omg.. oh nevermind it didnt explode)

As a lil' bonus I've also tested the situation when a small part is placed between two cargobays. It didn't bug at all (tested with 2x FL-T200 Fuel Tank).

Steps to Replicate:

1) Create a plane with two connected short cargobays so they make a longer one together.
2) Put a long enough part inside - its length must be longer than one of the short cargobays. Example: two connected Mk3 Cargo Bays CRG-50 and an Orange Tank inside.
3) Attach additional parts like a Cockpit, landing gears and an engine (if the payload isnt a fuel tank - then attach a fuel tank too of course).
4) Launch the craft.
5) Make aero forces visible in parts' gui menu through the debug menu.
6) Open the payload right-click menu.
7) Accelerate and watch its drag.

Result: The payload's drag isn't zero although it must be as it is fully enclosed.

Fixes/Workarounds:

- attach the payload differently (if there are multiple crafts or parts as a payload);
- use different nodes;
- use the largest cargobay available;
- don't put larger parts inside

Other Notes/Pictures/Log Files:

Both Mk3 and Mk2 cargobays have this problem. I believe its an internal technical logic problem, not a bug. Its just how the game calculates drag. But still it is a problem.

Craft files:
Mk2: https://www.dropbox.com/s/kk4h6y8h4alamx0/Bugged Mk2.craft?dl=0
Mk3: https://www.dropbox.com/s/fe4zaluf436nniq/Bugged Mk3.craft?dl=0

Screenshots (the right part-menu reflects the payload on both screenshots):

Spoiler

Thank you Squad for making one of the best games! No sarcasm involved. Bugs happen.

(I believe there is no need to include logfiles. Will attach if Im wrong.)

Edited December 30, 2017 by atomontage
added list of parts

[OHara]

Good news, I think : I failed to reproduce the bug when I put a long girder into a cargo bay made of two short pieces. I put the craft here.  For me, everything inside the combined cargo area is shielded, including things attached to the walls, but a part shifted beyond the combined bay, clipping into a fuel tank, gets drag.

I will try to download and look at the craft you linked sometime this weekend, to see what the difference might be.  

There is a bug on the tracker about failure to shield from drag if the cargo bay is the root part.

Edit: It seems that the girder is the largest part that can be shielded by the short mk2 bay.  A nuclear engine cannot be shielded; but if I stack a small part onto the end  of the un-shielded nuclear engine, that small part is shielded.

If I replace your FLT800 tank with to FLT400s joined together and then mounted to they bay, the two tanks are shielded.

It seems that any part deemed too large to fit in a short bay, cannot be shielded by a stack of short bays.  Otherwise, the current implementation is reasonably sophisticated -- better than what older posts on this forum described.

@bewing might notice this and put it into the QA system, otherwise any of us users can make ourselves a login to enter it into the bug tracker (and I will if no-one beats me to it).

Edited December 30, 2017 by OHara

[atomontage]

@OHara thanks for your help. I've also tested a few parts - added my conclusion to the original post.

Btw, in both cases of testing (Mk3 and Mk2 variants) cockpits were root parts.

[bewing]

There are two or three known issues with MK2 bays. Nobody knows when the devs will fix a particular bug -- they just grab one randomly out of the list when they are not adding new features.

But I think what you are asking for here is extremely difficult. If a part extends past a first cargo bay, how is the game supposed to tell that there is a second cargo bay after it, and its doors are closed?

The logic currently does not simply trace the tree of parts and mark them all as "shielded" automatically. The way it works is: each part has a known CoM. Even if that part is attached to the shielded node in a cargo bay, if its CoM is outside the parent cargo bay, then it's marked as "unshielded".

It sounds like what you want is for the game to model the craft each time it is saved. Take each cargo bay and fairing and calculate what 3-D volumes they enclose. Then any part CoMs inside each of those volumes are marked as shielded if the doors are closed/fairings are undeployed. In general, that sounds like a decent system, but it means that each part needs to reference which cargo bay/fairing shields which part. Which would be a big change to the craft file system.

 

[OHara]

On 12/30/2017 at 9:01 AM, bewing said:

The way it works is: each part has a known CoM. ... if its CoM is outside the  cargo bay, then it's marked as "unshielded".

We each checked small parts that were attached to a parent attached to one short bay, but which small part was enclosed in the second bay, and found them shielded from drag.  So it seems "if its CoM is outside any cargo bay, large enough hold it, then it is unshielded".

The original developer article on the topic still seems to describe the current situation, except for the 'large enough to hold it' test (and maybe some updates about activating things like parachutes on the walls of a bay).

I can see how the 'large enough to hold it' test is needed so we're not tempted to put a fat draggy part, into a cargo bay where it obviously will not fit.  Maybe we are asking for the 'large enough' test to consider only dimensions transverse to the attachment node, or something.  

Of course we shouldn't ask for an implementation, but pick a use-case that shows where users are likely to want different, or tweaked behavior.

Now in bug-tracker entry 16993. 

Edited January 7, 2018 by OHara
entered in bug tracker