Being specific, everything on GameData/Squad/Parts/Structural/mk1Parts are screwed, using 0 when they should be using 1 on the _top and _bottom nodes.

_top2, _bottom2 and _direct should be 1 point smaller than the the former.

See https://forum.kerbalspaceprogram.com/topic/140262-14x-18x-airplane-plus-r264-fixed-issuesgithub-is-up-to-date-dec-21-2019/?do=findComment&comment=4319552 for details.

I missed what I had seen, and hit what I hadn't. There're conceptual problems on Making History parts.

See this post for details.

There's 4 possible solutions for this mess:

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.
   • 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.
   • Obviously, user should be able to activate or not the option.
4. 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.
     • And I would need to patch everybody else too, not only Stock.

I'm going for 3.

Tasks to get this done:

• Write patches to rebalance Making History
• Create a Support entry on Discussions about this
• Write code to warn the user the first time it fire ups KSP with the rebalance active, asking the user to go to the page if he wants more details.
• Write code to "forget" the warning when the rebalance is deactivated, so it will be issued again when the thing is reactivated.

Crap, dude… Lots of add'ons were being screwed by this, taking the blame with trying to cope with the stock screwed parts, and then taking the blame because the stock right ones get drag.

WHAT A FSCKING MESS, SQUAD… BY GOD'S SAKE!!

I may had lost my temper too soon.

A more careful inspection of the Stock parts mentioned revealed that they are unusual, but not necessarily wrong.

For example, MK2 parts are able to carry Size1 partes inside, so the _top2 and _bottom2 nodes have the same size as the external ones.

Additionally, some parts doesn't have the 7h parameter of the Node (the node size), and so a default value is used. Obviously, such default value must be 1 - but I will double check this just in case.

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.

Visually explaining the problem:

1

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

2

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?):

So, this will cause no drag:

But this one will!!

3

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

Well, if I'm going to bring hell on me, I want to do it doing the Right Thing™ - I'm no masochist, I don't want to have a hell of a work and then realise I just moved the problem to another place.

Am undesirable collateral effect of this stunt is that I'm bringing into KSP-Recall (again) the responsibility to patch 3rd parties.

DAMN, I don't want to make this a habit. :(

Oh, well… Making History (as 1.12.5) have the following size1p5 parts:

• Decoupler_1p5
• EnginePlate1p5
• EquiTriangle1p5
• HeatShield1p5
• LiquidEngineKE-1
• LiquidEngineLV-T91
• LiquidEngineLV-TX87
• LiquidEngineRK-7
• MEMLander
• Mk2Pod
• Panel1p5
• Pollux
• Separator_1p5
• ServiceModule18
• Size1p5_Monoprop
• Size1p5_Size0_Adapter_01
• Size1p5_Size1_Adapter_01
• Size1p5_Size1_Adapter_02
• Size1p5_Size2_Adapter_01
• Size1p5_Strut_Decoupler
• Size1p5_Tank_01
• Size1p5_Tank_02
• Size1p5_Tank_03
• Size1p5_Tank_04
• Size1p5_Tank_05
• Size_1_5_Cone
• Triangle1p5
• Tube1p5
• fairingSize1p5
• flagPartSize1p5

From these, the following are already using Size 1 nodes!!:

• LiquidEngineRK-7
• Pollux
• ServiceModule18
• EquiTriangle1p5
• Panel1p5
• Triangle1p5
• flagPartSize1p5

And the following ones have all their attachment nodes set to ZERO:

• EquiTriangle1p5
• Panel1p5
• Triangle1p5

Unless I'm missing something, this is a hell of a mess, damn it! If the damned thing is defined as size1p5 on the bulkheadProfiles, I expect the damned thing to be attachable to a respective node on the target part and do not have drag, krap.

This is the "SP-T18 Structural Panel", EquiTriangle1p5.

It have 4 attachment nodes, all Size 0.

I think the central one should be Size 1, because by attaching this part into a Size0 part, I intuitively expect to have huge amounts of drag, but once I attach it to a Size 1 part, we would have way less drag.

However, I may be missing something on these ones, so I'm choosing to ignore these 3 parts with 0 sized attachment nodes for now - I can always add them later.

I will try to avoid adding 3rd parties support on Recall, unless I absolutely have no other viable alternative.

Ideally, 3rd parties should have these patches on their own distribution - there's no hard dependencies anyway, all it's needed is a Module Manager symbol called KSPRECALL-REBALANCE-AN to be defined somewhere (or a directory with this name created on the GameData) and this can be accomplished without installing KSP-Recall.

I'm wondering if I should create equivalent support for the 3rd parties sizes size0p5, size2p5 and size3p5. There're no Stock (or DLC) parts with these sizes, but they are used on the field, and it would be nice to have a centralised interface to work with them.

Reworked the solution. The feature is implemented on commit bcd480a .

I decided to fix the mk2CargoBayS idiosyncrasy mentioned above on comment #70 (comment) .

Implemented on commit 9c86192

I jumped the bullet and "implemented" the Rebalance on Airplane+ on commit net-lisias-ksp/AirplanePlus@f0fbfb4

Now, that's interesting. On KSP 1.12.5, I build this contraption:

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.

Perhaps this is what the original problem is about?

edit: On KSP 1.3.1 this misbehaviour doesn't happen.

Added question tag, as I now have conflicting reports about the whole ordeal.

Well, we have some artefactos to work with, thanks to our fellow Kerbonaut Krazy1:

I have a ship from yesterday with a CRG-15 that does not block drag: has drag

I built and tested several more versions today and they ALL WORKED. No drag with doors closed. This one appears the same as the first... but the bay blocks drag correctly. drag is good

I went back and forth testing these two several times and it is repeatable... one works, one broken. Same KSP session.

But wait, there's more. I made an "extended" version of the broken ship, adding another bay at the bottom and... yep... top one broken, bottom one works.... same ship! extended, 1 good, 1 bad

I can't tell you what I did different. Maybe I translated the SEQ parts and then picked them up and dropped them on the node? Maybe I re-rooted it? But I tried those things on another ship today and it worked correctly.

Just launch them, cheat to 20 km and watch aero data in PAWs. No need to use the chute. Krazyness.

Confirmed. After installing the needed dependencies:

• Trajectories
  • ClickThroughBlocker
  • ToolbarControl
• Sigma/TweakChutes

I easily reproduced the problem using the "has drag" craft, and I confirm that the rebuilt "drag is good" craft has no misbehaviour at all under the same circumstances, on the same savegame, on the very same session.

Didn't did any further tests or analysis, will do later.

Oukey, shooting in the dark time.

It may be something wrong with the AirPlane+'s config files, so I eyeballed the CRG-15 part config, comparing it with the Mk3 Short Cargo Bay from Stock. Other than a missing:

		partTypeName = Cargo bay

on the ModuleCargoBay config section, they are similar or plain identical. DaMichel's CargoBay add'on was also mentioned on another report with similar results, and the DaMichel's parts matches the Stock even better - so this is hardly the issue.

Shoving the thing on the part didn't changed anything anyway, so it's not it for sure.

Maybe the order in which things are declared on the Part Config?

Nope. reordering the Part Config values didn't changed anything. (Thanks Kraken!)

Party time again.

I removed all non essential Add'Ons from the rig and tried again. Exactly the same results, this is not something induced or triggered by 3rd Parties, except maybe AirPlane plus (the owner of CRG-15 Cargo Bay).

Out of pure curiosity, I imported both the CRG-15 and the "reference" stock Mk3 Short Cargo Bay on Blender (using the io_import_mu). I don't know what I was looking for, but I didn't found it. :P

The mesh structure is pretty different, but both mu files appear to work fine as they are - and the ModuleGenericAnimare would hardly cause collateral effects on the ModuleCargoBay, right? hum… RIGHT???

Well, I'm on an inflection point. I need to pinpoint either the CRG-15 part as the source of the problem, or I will need to pinpoint KSP itself by exclusion (because there's nothing left to screw me up on this).

I.e., I need to study how the sample crafts (the "good" and the "bad") were created and try to replicate the issue using stock only parts on a vanilla installation.

"E lavamos nozes!!"

So, I cleanup my 1.12.5 test bed, load and save the test crafts (the GOOD and the BAD - I owe you the UGLY, but this will be left to another (gun)fight).

DragIssue.zip

From now on, all the tests will be used using these two crafts.

Well… Here is the UGLY. :)

I opened both GOOD and BAD crafts on a text editor, and then rearranged the BAD so the order of the PARTs inside the craft file would be identical.

It didn't fixed, the order of the parts on the craft file is not an issue.

UGLY FROM BAD.craft.zip

So, the only option left is the order in which you attach the parts.

So I opened the BAD, dismantled it (but saved the parts to be reused, instead of taking new parts) and reattached them in the order I found in the GOOD craft:

• Cupola (rool)
• parachuteDrogue
• smallwingConnector1 (x 4 in radial symmetry) into the Cupola
• s2cargobayS into the Cupola
• Large.Crewed.Lab into the s2cargobayS
• cargoContainer into the bottom2 node of the s2cargobay2
• cargoContainer into the top of the previous cargoContainer.

and…

The problem is not the order of the parts, but how they were attached:

Problem: it's plain impossible to the user pull this one at first place. And where are the attachment nodes of the Lab and the SEQ containers?

Well… The one KSP feature I know is known to ruin attachment nodes is… #66 (Editor's ReRoot is screwed from KSP >= 1.8.0)

TADAAAAAAH

It's our old friend, KSP Editor, fscking our lives again. Well done, Squad. :/

I'm closing this one as duplicate for #66