[1.4.x-1.8.x] Airplane Plus - R26.4 (Fixed issues/Github is up to date) (Dec 21, 2019)

[linuxgurugamer]

There are multiple fields for the resale, depends on hiw the part is configured

[Kerbal410]

19 minutes ago, linuxgurugamer said:

There are multiple fields for the resale, depends on hiw the part is configured

oh.

[linuxgurugamer]

3 hours ago, Kerbal410 said:

oh.

Specifically which part, and I'll see if I can give you an example

[Kerbal410]

the part I'm trying to rescale is the KS-130-S2 low landing gear. I'm trying to increase it from a size 2 radial attachment to a mk3/size 3 radial attachment.

[linuxgurugamer]

On 6/28/2023 at 2:36 AM, Kerbal410 said:

the part I'm trying to rescale is the KS-130-S2 low landing gear. I'm trying to increase it from a size 2 radial attachment to a mk3/size 3 radial attachment.

Here you go.  Put this into a cfg file:

Quote

+PART[herculesgear]
{
    %name = herculesgear-3
    @MODEL
    {
        scale = 1.5, 1.5, 1.5
    }
    %title = KS-130-S2 Low Landing Gear - Size 3
}

+PART[herculesfrontgear]
{
    %name = herculesfrontgear-3
    @MODEL
    {
        scale = 1.5, 1.5, 1.5
    }
    %title = KS-130 Low Landing Gear - Size 3

This doesn't address the strength of the wheels, I suspect that the values are already pretty high

Edited September 5, 2023 by James Kerman
Fixed formatting

[Kerbal410]

1 hour ago, linuxgurugamer said:

Here you go.  Put this into a cfg file:

+PART[herculesgear]
{
	%name = herculesgear-3
	@MODEL
	{
		scale = 1.5, 1.5, 1.5
	}
	%title = KS-130-S2 Low Landing Gear - Size 3
}


+PART[herculesfrontgear]
{
	%name = herculesfrontgear-3
	@MODEL
	{
		scale = 1.5, 1.5, 1.5
	}
	%title = KS-130 Low Landing Gear - Size 3
}

 

This doesn't address the strength of the wheels, I suspect that the values are already pretty high

got it. so two .cfg files? thanks!

Edited June 27, 2023 by Kerbal410

[linuxgurugamer]

2 hours ago, Kerbal410 said:

got it. so two .cfg files? thanks!

One file

[Kerbal410]

2 hours ago, linuxgurugamer said:

One file

ah.

[Kerbal410]

how would I make a part that is just a Mk0/Mk3s0 version of the J-119? would I need to change anything else aside from the rescale factor, name, and title?

also, the anti-roll landing skids don't appear to properly line up when placed.

Edited August 27, 2023 by Kerbal410

[Krazy1]

Having trouble with cargo bays not occluding drag for parts inside.  Tested 2.5m CRG-15 and Mk1 Sliding Door. Stock bays work as expected. 

KSP log

player log

Spoiler

left, in stock bay, right in AP+ bays

Same problem for DaMichel's Cargo Bays.

https://forum.kerbalspaceprogram.com/topic/207351-112x-damichels-cargobays-dcb-version-11990-prerelease-27-jul-2022/?do=findComment&comment=4311592

 

[Lisias]

2 hours ago, Krazy1 said:

Having trouble with cargo bays not occluding drag for parts inside.  Tested 2.5m CRG-15 and Mk1 Sliding Door. Stock bays work as expected. 

KSP log

player log

  Hide contents

left, in stock bay, right in AP+ bays

Same problem for DaMichel's Cargo Bays.

https://forum.kerbalspaceprogram.com/topic/207351-112x-damichels-cargobays-dcb-version-11990-prerelease-27-jul-2022/?do=findComment&comment=4311592

 

Oh, well… It's diagnosing fest again.

First let's see when the problem started. I made a quick & dirty (but still fun) aircraft using the Mk1 "Sliding Door" Cargo Bay (one of my favorites), shoved a small ore tank ("Radial Holding Tank") inside and kicked the thing into the air, using "Display Aero Data em Action Menus" from the Alt+F12's "cheat" Physics entry.

The M.O. was:

1. Fire the craft into the runway;
   1. (I bluntly copied the craft file between KSP versions and save it again on the target's Editor, but the savegame was a new one created on the target)
2. Move the camera into the Cargo Bay exposing the ore tank (do not touch the cargo bay itself) by using the Zoom (mouse's roll wheel) and mouse movement;
3. Right click on the ore tank, then click on the attach icon on the top left so the PAW would be persistent;
4. Alt+F12, Physics, tick the "Display Aero Data in Action Menus";
5. Note the drag values on the PAW;
6. Fire up the engines, take off;
   1. Note the Drag values on the ore tank's PAW stable on 0.0.
7. Once you reach about 100 m/s, open the cargo bay;
   1. Note the Drag values on the ore tank's PAW coming to life.
8. Close the cargo bay;
   1. Note the Drag values on the ore tank's PAW getting back to zero.

Listing of my GameData:

drwxr-xr-x 13 lisias staff    416 Mar 16 18:55 000_KSPe
-rw-r--r--  1 lisias staff  29184 Jul  4 19:10 000_KSPe.dll
-rw-r--r--  1 lisias staff 170496 Jul  4 19:10 001_KSPe.dll
lrwxr-xr-x  1 lisias staff     72 Sep  4 20:37 666_ModuleManagerWatchDog.dll -> /Users/lisias/Workspaces/KSP/runtime/_pool/666_ModuleManagerWatchDog.dll
lrwxr-xr-x  1 lisias staff     57 Sep  4 20:36 999_KSP-Recall -> /Users/lisias/Workspaces/KSP/runtime/_pool/999_KSP-Recall
lrwxr-xr-x  1 lisias staff     63 Sep  4 20:37 999_Scale_Redist.dll -> /Users/lisias/Workspaces/KSP/runtime/_pool/999_Scale_Redist.dll
lrwxr-xr-x  1 lisias staff     83 Sep  4 20:36 AirplanePlus -> /Users/lisias/Workspaces/KSP/GIT/net-lisias/ksp/AirplanePlus/GameData/AirplanePlus/
lrwxr-xr-x  1 lisias staff     60 Sep  4 20:36 Firespitter -> /Users/lisias/Workspaces/KSP/runtime/_pool/Firespitter.u2019
lrwxr-xr-x  1 lisias staff     64 Sep  4 20:36 KAX -> /Users/lisias/Workspaces/KSP/GIT/net-lisias/ksp/KAX/GameData/KAX
drwxr-xr-x  5 lisias staff    160 Sep  2 02:55 L-Aerospace
drwxr-xr-x  8 lisias staff    256 Jul 19  2022 ModuleManager
-rw-r--r--  1 lisias staff 129024 Jan 24  2023 ModuleManager.dll
lrwxr-xr-x  1 lisias staff     64 Sep  4 20:36 ModuleManagerWatchDog -> /Users/lisias/Workspaces/KSP/runtime/_pool/ModuleManagerWatchDog
drwxr-xr-x 28 lisias staff    896 Jan 15  2023 Squad
drwxr-xr-x  4 lisias staff    128 Aug  4  2021 SquadExpansion
drwxr-xr-x  4 lisias staff    128 Oct  9  2021 __LOCAL
drwxr-xr-x  7 lisias staff    224 Sep  4 19:37 net.lisias.ksp

./__LOCAL:
total 4
-rw-r--r-- 1 lisias staff 111 Oct  9  2021 JetEngine.cfg
drwxr-xr-x 6 lisias staff 192 Oct  9  2021 TweakScale

./__LOCAL/TweakScale:
total 0
drwxr-xr-x 3 lisias staff 96 Oct  9  2021 BreakingParts
drwxr-xr-x 3 lisias staff 96 Oct  9  2021 HotFixes
drwxr-xr-x 3 lisias staff 96 Oct 25  2019 Tests
drwxr-xr-x 3 lisias staff 96 Oct  9  2021 Workarounds

./net.lisias.ksp:
total 0
lrwxr-xr-x 1 lisias staff 67 Sep  4 20:36 CrewLight -> /Users/lisias/Workspaces/KSP/runtime/_pool/net.lisias.ksp/CrewLight
lrwxr-xr-x 1 lisias staff 79 Sep  4 20:36 KerbalObjectInspector -> /Users/lisias/Workspaces/KSP/runtime/_pool/net.lisias.ksp/KerbalObjectInspector
lrwxr-xr-x 1 lisias staff 66 Sep  4 20:36 PartInfo -> /Users/lisias/Workspaces/KSP/runtime/_pool/net.lisias.ksp/PartInfo
lrwxr-xr-x 1 lisias staff 69 Sep  4 20:36 VesselMover -> /Users/lisias/Workspaces/KSP/runtime/_pool/net.lisias.ksp/VesselMover
lrwxr-xr-x 1 lisias staff 53 Sep  4 20:36 mkext -> /Users/lisias/Workspaces/KSP/GIT/net-lisias/ksp/mkext

My results:

• On KSP 1.3.1, the ore tank's drag was zero as long the Cargo Bay is closed (you open the cargo bay, you got the drag back)
• On KSP 1.4.3, same thing. Everything works as expected.
• On KSP 1.7.3, same thing. Everything works as expected.

This settle the case for the Old School® guys.

Now let's inspect the New Kids™ on Unity 2019 (unfortunately, the migration from Unity 2017 to Unity 2019 broke a lot of things, perhaps this would be one of them).

• On KSP 1.8.1, surprisingly - same thing. Everything works as expected.
• On KSP 1.12.5, same thing. Everything works as expected.

Caveats:

I can't call this a clean, pristine Test Session because I used my in house or development versions of everything (but Squad and SquadExpansion, of course), and not any Official Releases you probably used youself. So there's a chance that I had "fixed" the problem by accident somewhere on my code or assets. (I did this way because my test beds were already configured with them, so I could get results quicker.)

However, it's also pretty possible that whatever is screwing with you, are installed on your rig and not on mine.

In a way or another, I need to redo these tests on a clean, official release only installation to see what I get. At least I can get directly into the point, 1.12.5, as it's already known that whatever is happening, is not exactly on KSP this time.

Edited September 5, 2023 by Lisias
Pics or didn't happened!

[Manul]

2 hours ago, Lisias said:

Oh, well… It's diagnosing fest again.

Some of my airplanes suffered from broken dragshielding and I found that the wrong node size was causing this. If any of two parts attached to cargobay's outer nodes has a smaller attachment node than the bay's outer nodes, the dragshielding doesn't work. Here comes the most interesting part of the story:  all Mk1 cargobays from A+ have size 1 nodes  while  Mk1 half length fuel tank has  size0 nodes.  The same with s1.5Mk3 cargobays and fuselage parts.

After I had adjusted the node sizes to match each other I got a working dragshielding for already launched crafts that didn't have it before.

[Lisias]

On 9/4/2023 at 11:55 PM, Manul said:

Some of my airplanes suffered from broken dragshielding and I found that the wrong node size was causing this. If any of two parts attached to cargobay's outer nodes has a smaller attachment node than the bay's outer nodes, the dragshielding doesn't work. Here comes the most interesting part of the story:  all Mk1 cargobays from A+ have size 1 nodes  while  Mk1 half length fuel tank has  size0 nodes.  The same with s1.5Mk3 cargobays and fuselage parts.

After I had adjusted the node sizes to match each other I got a working dragshielding for already launched crafts that didn't have it before.

Interesting. I did a peek on the configs, including stock, and this is what I got:

1. Nodes from MK1 parts ending up with _top and _bottom have a node size 1 (the default by absence).
2. Stock cargo bays have two addition sets of such nodes, _top2 and _bottom2 , slightly inside the mesh. These are the attachment nodes for cargo, inside the bay. For MK3 parts, they have a size 1 point smaller than the outer nodes.
3. The A+ Sliding Door Mk1 cargo bay have the _top2 and _bottom2 nodes one point higher than the outer nodes!
   1. So we found the problem, my tests were made by surface attaching the ore tank inside the Cargo Bay!

Oukey, we found the problem. And the fix is simple, as well the workaround:

@PART[mk1cargodoor]
{
	%node_stack_top2 = 0.0, 0.9175, 0.0, 0.0, -1.0, 0.0, 0
	%node_stack_bottom2 = 0.0, -0.9175, 0.0, 0.0, 1.0, 0.0, 0
}

Shove this patch somewhere in your GameData (I suggest Gamedata/__LOCAL/AirplanePlus/mk1cargodoor-drag-fix.cfg), and you are set.

NEWS FROM THE FRONT

I inspected some Stock parts from KSP 1.12.5 and… DAMN, what a mess.

The mk1pod_v2 has a bulkheadsize as size1, and the node_stack_bottom has a node with size 1. Same for Mark1Cockpit and landerCabinSmall.

This contradicts the other mk1 parts I found, as the following parts have a top and bottom node with size ZERO:

• Mk1FuselageStructural
• MK1IntakeFuselage
• MK1Fuselage
• nacelleBody
• radialEngineBody
• Mark2Cockpit

So we have a problem! Some STOCK parts for parts with size1 (1.25m) have a _bottom and/or _top nodes set as 0, but other as 1! 

It's not a surprise so many people are complaining about drag!! #facePalm

— — POST EDIT — — 

Found a pattern: everything on GameData/Squad/Parts/Structural/mk1Parts are setting the attachment nodes size to 0, while everything else is using 1 . KRAP, man… This is a freaking mess! Stock parts are screwed up!!!

— — POST POST EDIT — — 

This krap was detected downto KSP 1.2.2 (don't have anything older installed to keep digging).

Damn, this explains why people blamed TweakScale for problems related to drag in the part - GARBAGE IN, GARBAGE OUT. If the source part is already messed up, the resulting one will be too!

— — POST POST POST EDIT — — 

It's not certain that having "weird" values on the cargo bay attachment nodes will cause negative impact on drag - at least, no test corroborated this thesis yet.

It may cause other issues (or not), but it's out of the scope of the present study.

Edited September 6, 2023 by Lisias
post post edit.

[Krazy1]

55 minutes ago, Lisias said:

Oukey, we found the problem. And the fix is simple, as well the workaround:

Thanks for all the testing. Wow. The sliding door Mk1 bay is great and unique... but this time I want to use the 2.5m CRG-15. So, hopefully that fix is very similar? 

[Lisias]

On 9/5/2023 at 1:26 AM, Krazy1 said:

Thanks for all the testing. Wow. The sliding door Mk1 bay is great and unique... but this time I want to use the 2.5m CRG-15. So, hopefully that fix is very similar? 

No. The CRG-15 is defined right, it's something else now.

I want to bring to your attention that we just diagnosed STOCK PARTS with the wrong node settings - a complete mess. <Nope!! That part's settings were unusual, but not necessarily wrong. I will further investigate them, though>. This is probably the reason add'ons are taking the blame for the drag problem, because if you "fix" for some parts, you break them for the others and vice versa.

DAMN.

—— POST EDIT — — 

Ha! I was right, I found a problem inconsistency on the node's definition on Stock!! See below!!!

Edited September 6, 2023 by Lisias
it's not certain it's a problem.

[Krazy1]

1 hour ago, Lisias said:

STOCK PARTS with the wrong node settings - a complete mess

Oh. Well, I'm sure they'll fix it in 1.13. 

Spoiler

[Lisias]

36 minutes ago, Krazy1 said:

Oh. Well, I'm sure they'll fix it in 1.13. 

  Reveal hidden contents

Is there anyone left over there?

Speaking frankly, since every new release lately is breaking more things than they are fixing, I fear it's best just to leave things as they are - or just Open the damned Source for once!

Edited September 5, 2023 by Lisias
Whoops… Stock appears to be innocent for now...

[Lisias]

And… I found a problem inconsistency on Stock!!!  

It's not a "bug" on the Part Config, it's more a conceptual problem.

That's the history: Making History introduced the size1p5, or 1.5 the size 1, or 1.875 meters. However, someone had the extremely unhappy idea of giving these parts a Node Size of 2!

Problem: Size 2 Cargo Bays are 2.5 meters wide, and mechanically can hold Size 1.5 parts inside. However, since the Size2 Cargo Bays sets the internal attachment node to 1 (one point less than their bulkheadProfile), by attaching a Making History 1.5 size part inside such cargo bay, you will get drag!!

Visually and mechanically (a.k.a colliders) a size1p5 part will fit inside a size2 cargo bay, but since the size1p5 was defined as a Node Size2, the physics engine will inject drag on it because the cargo bay's node is smaller than that.

Defining the size1p5 atttachment nodes to 2 was a huge mistake. We need to rebalance the Making History parts' nodes, but by doing that we will "breaking legacy" - and anyone that followed suit to Stock will need to rebalance their parts too, on a cascading update fest.

Request For Comments!

Edited September 6, 2023 by Lisias
It's not certain it's a problem. It may cause issues, but I didn't managed to link them to drag.

[linuxgurugamer]

5 hours ago, Lisias said:

And… I found a problem on Stock!!!  

It's not a "bug" on the Part Config, it's more a conceptual problem.

That's the history: Making History introduced the size1p5, or 1.5 the size 1, or 1.875 meters. However, someone had the extremely unhappy idea of giving these parts a Node Size of 2!

Problem: Size 2 Cargo Bays are 2.5 meters wide, and mechanically can hold Size 1.5 parts inside. However, since the Size2 Cargo Bays sets the internal attachment node to 1 (one point less than their bulkheadProfile), by attaching a Making History 1.5 size part inside such cargo bay, you will get drag!!

Visually and mechanically (a.k.a colliders) a size1p5 part will fit inside a size2 cargo bay, but since the size1p5 was defined as a Node Size2, the physics engine will inject drag on it because the cargo bay's node is smaller than that.

Defining the size1p5 atttachment nodes to 2 was a huge mistake. We need to rebalance the Making History parts' nodes, but by doing that we will "breaking legacy" - and anyone that followed suit to Stock will need to rebalance their parts too, on a cascading update fest.

Request For Comments!

So, the fix is to change the nodes inside the cargo bays to be the size size as the outside node (at least until some code is fixed)?

Edit:  I should saw, the fix is to change the nodes from size 2 to size 1?  Should be possible to write a MM patch for this.  Not sure how difficult it would be to write a generic patch, but there are only a limited number of parts with this problem, should be easy enough to just write a brute-force patch:

All parts in Making History with bulkhead profiles of sizep5:

Quote

Aero/protectiveRocketNoseMk5A/Size_1_5_Cone.cfg:        bulkheadProfiles = size1p5
Coupling/Decoupler_1p5.cfg:     bulkheadProfiles = size1p5
Coupling/EnginePlate_1p5.cfg:   bulkheadProfiles = size1p5
Coupling/Separator_1p5.cfg:     bulkheadProfiles = size1p5
Coupling/Size1p5_Strut_Decoupler.cfg:   bulkheadProfiles = size1p5, srf
Engine/LiquidEngineKE-1.cfg:    bulkheadProfiles = size1, size1p5, size2, srf
Engine/LiquidEngineLV-T91.cfg:  bulkheadProfiles = size1p5, srf
Engine/LiquidEngineLV-TX87.cfg: bulkheadProfiles = size1p5, srf
Engine/LiquidEngineRK-7.cfg:    bulkheadProfiles = size1p5, srf
Engine/solidBoosterTHK/solidBoosterTHK.cfg:     bulkheadProfiles = size1p5, srf
FuelTank/Size1p5_Monoprop.cfg:  bulkheadProfiles = size1p5
FuelTank/Size1p5_Size0_Adapter_01.cfg:  bulkheadProfiles = size0, size1p5, srf
FuelTank/Size1p5_Size1_Adapter_01.cfg:  bulkheadProfiles = size1p5, size1, srf
FuelTank/Size1p5_Size1_Adapter_02.cfg:  bulkheadProfiles = size1, size1p5, srf
FuelTank/Size1p5_Size2_Adapter_01.cfg:  bulkheadProfiles = size1p5, size2, srf
FuelTank/Size1p5_Tank_01.cfg:   bulkheadProfiles = size1p5, srf
FuelTank/Size1p5_Tank_02.cfg:   bulkheadProfiles = size1p5, srf
FuelTank/Size1p5_Tank_03.cfg:   bulkheadProfiles = size1p5, srf
FuelTank/Size1p5_Tank_04.cfg:   bulkheadProfiles = size1p5, srf
FuelTank/Size1p5_Tank_05.cfg:   bulkheadProfiles = size1p5, srf
Payload/fairingSize1p5.cfg:     bulkheadProfiles = size1p5
Payload/SM18.cfg:       bulkheadProfiles = size1p5
Pods/Mk2Pod.cfg:        bulkheadProfiles = size1p5
Pods/Size1_5_Lander.cfg:        bulkheadProfiles = size0, size1, size1p5
Structural/EquiTriangle1p5.cfg: bulkheadProfiles = size1p5, srf
Structural/Panel1p5.cfg:        bulkheadProfiles = size1p5, srf
Structural/Triangle1p5.cfg:     bulkheadProfiles = size1p5, srf
Structural/Tube1p5.cfg: bulkheadProfiles = size1p5
Thermal/HeatShield1p5.cfg:      bulkheadProfiles = size1p5
Utility/flags/flagSize1p5/flagSize1p5.cfg:      bulkheadProfiles = srf,size1p5

 

Edited September 5, 2023 by James Kerman
Fixed formatting

[Lisias]

3 hours ago, linuxgurugamer said:

Edit:  I should saw, the fix is to change the nodes from size 2 to size 1?  Should be possible to write a MM patch for this.  Not sure how difficult it would be to write a generic patch, but there are only a limited number of parts with this problem, should be easy enough to just write a brute-force patch

Technically, yes. The problem is the consequences - because we would need to patch every single part under the Kerbol to follow suit, or we will have what around here it's know as a "short blanket problem" - if you cover your chest, your feet gets cold and vice versa.

I'm inspecting some other 3rd parties, and until the moment everybody is following suit with Making History - rounding the "point 5" sizes to the ceiling, and not to the floor as I'm proposing. So, by patching MH parts now, everybody else will start to have problems.

There's also the stablished standard: add'ons with custom sizes, like size0p5, size1p5, etc, are also rounding the Node Sizes to the ceiling, adding yet another layer of complications to our already complicated problem.

AFAIK, we have three options:

1. Get consensus on the Scene, where everybody would agree to round the point 5 sizes to the floor, and so we would rush on an update fest for the entire Universe
2. We pull up something from our hats to do it programatically on the user's machine, automatically switching the Node sizes for parts with point 5 sizings.
   1. A bit hairy as there're a lot of part with multi bulkhead support, and we need to patch only the respective nodes, and not all of them.
3. We selectively patch parts from the most used add'ons, and hope people will get into the wagon as time goes by adding "support" to it.
   1. Obviously, user should be able to activate or not the option.

I think the option 3 is the less worst way to go. Everybody still follow suit with Making History on Releases, as we have about 6 years of a standard (being it crappy or not) to cope, and this change will break crafts relying on the older behaviour for sure.

Edited September 5, 2023 by Lisias
Kinda of tyops.

[linuxgurugamer]

1 minute ago, Lisias said:

A bit hairy as there're a lot of part with multi bulkhead support, and we need to patch only the respective nodes, and not all of them

Correct me if I'm wrong, but aren't the important parts the top and bottom nodes?  Can't we ignore the interior and side nodes?

[Manul]

10 hours ago, Lisias said:

Problem: Size 2 Cargo Bays are 2.5 meters wide, and mechanically can hold Size 1.5 parts inside. However, since the Size2 Cargo Bays sets the internal attachment node to 1 (one point less than their bulkheadProfile), by attaching a Making History 1.5 size part inside such cargo bay, you will get drag!!

Does the internal attachment node size matter? Every stock and most modded cargobays have inner nodes one size smaller than outer ones and it doesn't cause any problems. But when you attach a cockpit with size 2 node in front of the Mk3 cargobay with size3 outer node the dragshielding is gone.

For example Raksha Corvette Bridge from Prakasa Aeroworks mod has a Mk3 bullhead profile but it had a size 2 attachment node and it used to brake dragshielding for any stock Mk3 cargobay that was attached behind it. After changing it's rear node size to 3 this cockpit doesn't break dragshielding no matter what is attached to inner nodes of Mk3 cargobay that comes behind it.

Edited September 5, 2023 by Manul

[Lisias]

20 hours ago, linuxgurugamer said:

Correct me if I'm wrong, but aren't the important parts the top and bottom nodes?  Can't we ignore the interior and side nodes?

If we could ignore them, we would not have the problem at first place!

Everytime you attach two parts those node's size are different, you get drag. [not reproduced inside cargo bays!]

Now, on Cargo Bays, you have two sets of nodes: a set for external attachments, and sets for internal attachments. By definition (the whole Stock and StockExpansion abide to this), the internal set of nodes are 1 point smaller than the external ones - what makes sense, you can't carry parts inside a cargo bay that are on the same size, only smaller!

However, when Making History was released, a new bulkheadProfile was created, the size1p5 - but KSP has only 5 Node Sizes coded (from 0 to 4). So the dude/gal/person that was creating these new parts had to make a hard choice (don't blame them by the mistake - my chances of doing exactly the same are about 50%, depending on how much time I was already playing with cargo bays at the time), and by bad luck, they did the worst choice - rounding to the ceiling.

For external attachments, as long everybody agrees that size1p5 is a Node Size 2, everything will work just fine.

It's on internal attachments that you will get screwed by this decision (I know I'm being repetitive, but I want to make this clear to people dropping on the conversation out of the blue too), because besides visually and mechanically (i.e., colliders) a size1p5 is able to fit inside a Size2 cargo bay, you will get drag no matter what because (by definition since the beginning of time), cargo bays have the internal nodes one point smaller than the external and, so a Node Size 1 internal node for a Size 2 Cargo Bay - but the part you are attaching inside it have a Node Size 2 (besides being smaller, 1.5).

I don't see a way to fix this without breaking something. What's clear is that giving size1p5 parts a Node Size 2 is causing a lot of confusion for people willing to use cargo bays - and there're a lot of them,  by the temperature of my ears.

"Fixing" all size1p5 MH parts to Node Size 1 appears to be the logical solution, but we will break a long standing standard, what are followed by lots and lots of 3rd parties (including A+), and they will need to be updated too or you will get new complains from the same people by similar reasons.

I just though on a forth alternative (adding to that 3 I posted above): rising the Cargo Bays internal node sizes 1 point, making them the same size of the external ones. This is the easiest route, no doubt - but it will allow people to attach Size 2 parts "inside" Size 2 Cargo Bays without penalty, and this is something that would open a ticket on the bug track for sure, because it breaks a specification (a long standing one).

But even by going the krap way, we will still need to patch everybody's else Cargo Bays too, so again a update fest on the Universe… (sigh)

From my personal point of view, if I'm going to get screwed no matter what, I would like to do the Right Thing™ and maximize the gains on the long run (as on the short term, I'm screwed no matter what). But I want to be sure about what is the Right Thing™ at first place, because I don't find productive having a hell of a work just to have a the same set of problems happening in other place: if I'm going to get hurt, I want to get hurt only once.

 

20 hours ago, Manul said:

Does the internal attachment node size matter? Every stock and most modded cargobays have inner nodes one size smaller than outer ones and it doesn't cause any problems. But when you attach a cockpit with size 2 node in front of the Mk3 cargobay with size3 outer node the dragshielding is gone.

Yes, we would not have problems if not!

Let me explain this to you graphically (on the using graphics sense, not the other meaning!! ).

This is a good setup: A Size2 Part with a Size 1 Part inside, this will cause no drag:

 

For the sake of curiosity, the Mark 2 Cargo bays are the only ones I'm aware those internal Nodes have the same size of the external ones - for a good reason, as besides having 2.5 meters wide, they choose to give them a Size 1 external node (by mistake, perhaps?):

Interesting enough, the Short Mk2 Cargo bay have internal nodes set to 0, while the Long have the nodes set to 1. I think this is a mistake, the Short one should have Size 1 too!!! The following setup will generate drag, completely counter-intuitive!

 

Now things start to go South: a size1p5 Part inside a Size 2 Cargo Bay:

 

And this M.O. is replicated everywhere, virtually every 3rd party I inspected until the moment followed suit with giving the internal node a point smaller than then external, while rounding the p5 parts to the ceiling. So Size0p5 uses Node Size 1, not 0; Size3p5 uses Node Size 4, not 3.

And then we have this very same situation scattered over the Scene, with people attaching visibly fitting parts inside the cargo bay but getting unexpected drag!!

 

— — POST EDIT — — 

Until this moment, I didn't managed to induce drag misbehaviours due internal attachment nodes. I think I got some issues on resistance, but I don't think they would worth a large scale intervention.

Still studying the issue - there are reports of differences on attachment nodes causing issues on cargo bays, but they weren't specific enough.

Edited September 6, 2023 by Lisias
POST EDIT.

[Krazy1]

11 hours ago, Lisias said:

15 hours ago, linuxgurugamer said:

Correct me if I'm wrong, but aren't the important parts the top and bottom nodes?  Can't we ignore the interior and side nodes?

If we could ignore them, we would not have the problem at first place!

Everytime you attach two parts those node's size are different, you get drag.

I'm not sure Lisias... I'm just a student here but this Kerbal University video doesn't mention internal node size. External node matching it does mention. What about radially attached internal parts?
I did a quick test of the CRG-15 with ideal conditions... external and internal nodes size matched, one internal part node attached... and it does work correctly. Now I need to experiment to see why my actual bay packed full of parts doesn't work.

Update: So I did more drop testing and... it's insane. The first couple tests worked. Then it stopped working and could not be fixed. I completely rebuilt the test craft and it still had drag with the doors closed. Same ship, different result. So maybe something on this install is a problem? Some silent exception that breaks only only drag on this part? Maybe reverting to VAB and/or crashing. I don't know. I can't take it... I'm going to bed.

Edited September 6, 2023 by Krazy1
update

[Lisias]

5 hours ago, Krazy1 said:

I'm not sure Lisias... I'm just a student here but this Kerbal University video doesn't mention internal node size. External node matching it does mention. 

Fair question. Let's check it with moar testings  .

And you appears to be right, but on the other hand this contradicts reports from other people. So I concluded we don't have enough information yet.

Digging around, I found that matching external attachment nodes sizes it's important for structural integrity.

But I also found reports correlating attachment nodes to drag. 

In a way or another, being due drag or not, ideally we should match attachment nodes.

 

5 hours ago, Krazy1 said:

What about radially attached internal parts?

This we already have proved it works. How it works, and under what circumstances I don't know, and I will not pursue this one until I have nailed the problem under our noses first - unless we realise it's all the same thing.

 

5 hours ago, Krazy1 said:

Update: So I did more drop testing and... it's insane. The first couple tests worked. Then it stopped working and could not be fixed. I completely rebuilt the test craft and it still had drag with the doors closed. Same ship, different result. So maybe something on this install is a problem? Some silent exception that breaks only only drag on this part? Maybe reverting to VAB and/or crashing. I don't know. I can't take it... I'm going to bed.

Humm… Write down carefully every single step you took on every single attempt. Sometimes, one small little detail is the trigger for the problem!

In a way or another, I made another one trying to figure out why you would be having problems on reproduce the mishap deterministically. Pehaps something like this?

Quote

The interesting part is using two Mk2 Short Cargo Bay, attaching a Mk1 Crew Cabin on the top inner node of the top cargo bay, and then translate it to the Cabin stays half on the upper bay, half of the lower.

By launching the thing, if I open the upper bay I will have drag on the Crew Cabin as expected, and when I close the upper bay, the drag ceases. As expected.

But if I open the lower bay, even by closing it after I have drag on the Crew Cabin for ages! It slowly goes to zero, but by the time things get into normal, we are near outside the atmosphere.

https://github.com/net-lisias-ksp/KSP-Recall/issues/70#issuecomment-1708083306

 

19 hours ago, linuxgurugamer said:

Correct me if I'm wrong, but aren't the important parts the top and bottom nodes?  Can't we ignore the interior and side nodes?

I have conflicting reports about this matter, more studies are on the way - I found one anomaly, but appears to be unrelated to attachment nodes.

On the bright side, I had already wrote the patches and they are easily editable to suit our test cases, so we have some tools to play "what if".

Worst case scenario, I ditch the patches and call it day, no harm no foul. At very worst, I now have new toys to document and audit parts - hardly a bad outcome.

 

On 9/4/2023 at 11:55 PM, Manul said:

Some of my airplanes suffered from broken dragshielding and I found that the wrong node size was causing this. If any of two parts attached to cargobay's outer nodes has a smaller attachment node than the bay's outer nodes, the dragshielding doesn't work. <…>

I forgot to mention, but I'm auditing every single part from A+ using the tools I created to check the problem above, and I'm fixing them. Lots of nodes on A+ were defined… creatively.  

This is material enough to worth a full release, so I expect to kick one through the doors for this weekend.

Edited September 6, 2023 by Lisias
Brute force post merge.