DragCubeGeneration patch interaction with B9PS causes vessel to not show in map view

[NathanKell]

The Mercury capsule from ROCapsules (v2.0 and before, I'm releasing a hotfix to disable KSPCF drag cube patching in 2.1) will not show in map view. Not merely is no icon shown, but the entire vessel is simply not created AFAICT, with no orbital track and the planetarium camera focused on Kerbin.

Reproduction:
Download ROCapsules from Github. Install Textures Unlimited (probably not necessary, but it shouldn't matter), B9PS, and CRP. And KSPCF and Harmony, of course. Go to editor, place Mercury Capsule, load to flight, go to map view.

If I disable the patch, or I remove B9PS, the issue goes away.

KSP.log

[NathanKell]

Update: TU not needed. I included CRP only because of the resources used by the capsule, it's not otherwise germane.

[NathanKell]

Disabling by default until @gotmachine has a change to look at this, since per forum reports it also breaks stockproc fairing drag cubes.

[NathanKell]

Forum link: https://forum.kerbalspaceprogram.com/topic/204002-18-112-kspcommunityfixes-bugfixes-and-qol-tweaks/?do=findComment&comment=4301554

[gotmachine]

Gave a quick look at this, and I'm able to reproduce. The issue reported on the forum with stock fairings is likely separate, see #162

This seems indeed to involve a misconfigured B9PS mesh switcher somehow, specifically for the ROC-MercuryCMBDB part,
B9PS is configured to use procedural drag cubes (affectDragCubes), which is incompatible with the presence of a IMultipleDragCube module (in this case, ModuleAnimateGeneric, having the useMultipleDragCubes field implicitly left to true by default).

KSP is yelling about the situation (which isn't uncommon, there plenty of such misconfiguration in various mods), but I have no idea how the end result can be what we are seeing when the KSPCF drag cube generation patch is added to the mix. The behavior doesn't seem to be entirely deterministic, I've had cases where this doesn't happen, and cases where the map view doesn't load at all. But from a few tests, fixing the drag cube misconfiguration seems to fix the whole thing.

Will try to find some time to investigate further, in the meantime, the patch is better left disabled.

[NathanKell]

Thank you! <3

[gotmachine]

Managed to isolate this to the following conditions :

• StartCoroutine(DragCubeSystem.Instance.SetupDragCubeCoroutine(part, null)); called from PartModule.OnStartFinished()
• The part must have multiple drag cubes (a module implementing IMultipleDragCube)
• The part must be the root part

It sounds like the issue stems from copying the part, which in the case of the root part incurs copying a lot of additional components : Vessel, VesselModule and various other stuff living on the root part in flight. This mean all code in the Awake() for those component will run, and I guess the issue is coming from that.
But... the stock code does this as well, and I've been quite careful at replicating everything the stock code does... I guess I missed something ?

EDIT : ok... found it... sigh
When copying the part, the copy is renamed with :

partObject.name += " Drag Rendering Clone";

And guess what... Here is a piece of code from Vessel.OnDestroy() :

if (base.gameObject.name.Contains("Drag Rendering Clone"))
{
	DestroyVesselComponents();
	return;
}

[gotmachine]

Should be fixed as of 1.31.0