[1.4.*] [2.5.3] (2018-04-06) UbioZur Welding Ltd. Continued

[Fwiffo]

Minor bug, multiple ModuleDataTransmitter's in a weldment are not consolidated correctly.  e.g. The packetInterval fields are added, which makes the resultant antenna worse (longer delay between sending packets of data).  It also adds packetResourceCost, which shouldn't be done (AFAIK transmission cost per data is normalized at 12 throughout the game).

I believe a more reasonable formula should be:

packetInterval = (minimum interval)
packetSize = sum(each antenna's [packetSize / packetInterval] * minimumInterval)
antennaPower = sum(each antenna's antennaPower)

I'm not as sure about optimumRange, packetFloor and packetCeiling.

Alternatively you could just pick the best antenna (e.g. one with highest antennaPower) and go with that, discarding the others.

Edited October 25, 2016 by Fwiffo

[Alewx]

3 hours ago, Fwiffo said:

Minor bug, multiple ModuleDataTransmitter's in a weldment are not consolidated correctly.  e.g. The packetInterval fields are added, which makes the resultant antenna worse (longer delay between sending packets of data).  It also adds packetResourceCost, which shouldn't be done (AFAIK transmission cost per data is normalized at 12 throughout the game).

I believe a more reasonable formula should be:

packetInterval = (minimum interval)
packetSize = sum(each antenna's [packetSize / packetInterval] * minimumInterval)
antennaPower = sum(each antenna's antennaPower)

I'm not as sure about optimumRange, packetFloor and packetCeiling.

Alternatively you could just pick the best antenna (e.g. one with highest antennaPower) and go with that, discarding the others.

Why do you weld Antennas, normally they contain animations, which just get broken.
OH I see the new big dishes.

That is still not the way the processing of the values work.
It works on a per value base, so nothing like formulas or such for the modules.

A value can be maximized, minimized, averaged, or summed, that are all the options possible.

A new calculation option would be suitable if it is used in multiple cases. But specialized code for certain modules is nothing I will bring back; that was a horrible mess.

[Fwiffo]

1 hour ago, Alewx said:

Why do you weld Antennas, normally they contain animations, which just get broken.

I fix the animations in post-weld.  It's actually not hard, your mod could handle this fairly trivially (at least in some cases) and users would have a much better time with such components.

1 hour ago, Alewx said:

It works on a per value base, so nothing like formulas or such for the modules.

Thanks for clarifying.  I'm not intimately familiar with how the mod works internally and am still learning.

1 hour ago, Alewx said:

A new calculation option would be suitable if it is used in multiple cases. But specialized code for certain modules is nothing I will bring back; that was a horrible mess.

I completely understand your reluctance to maintaining a lot of specialized code.

I need to play a little more with the existing capabilities provided, although I do wish they were a little less constrained.  I've found a lot of cases where the welder gets things wrong and manual fix-up is required post-weld.  Granted I'm doing more advanced welds than most people venture into.  I'm just reporting issues as found, you can take or leave them as you see fit.  I recognize you volunteer your time (which I'm enormously grateful for) I certainly won't feel insulted if you don't want to work them. :-)

[Alewx]

18 minutes ago, Fwiffo said:

I fix the animations in post-weld.  It's actually not hard, your mod could handle this fairly trivially (at least in some cases) and users would have a much better time with such components.

Which parts, and how do you fix it exactly? If it is just the GernicanimationModule to put in the first place, this will already get into problems with the datastorage module, which is required to be the first one.

20 minutes ago, Fwiffo said:

I completely understand your reluctance to maintaining a lot of specialized code.

I need to play a little more with the existing capabilities provided, although I do wish they were a little less constrained.  I've found a lot of cases where the welder gets things wrong and manual fix-up is required post-weld.  Granted I'm doing more advanced welds than most people venture into.  I'm just reporting issues as found, you can take or leave them as you see fit.  I recognize you volunteer your time (which I'm enormously grateful for) I certainly won't feel insulted if you don't want to work them. :-)

If it is something I can find a solution for it is welcome.

About the internal handling, the mod gets the type of each value a module has, and then processes it based on its config; no real magic. But it is really designed to work in general on all modules, no matter what happened to their own source.
It goes through all parts, and looks for modules, if there is one that is already known, it tries to find any values that are already known to it, or that might break the process. this works well for numbers, or vectors, but when it comes to text, it just takes the last one.

[Fwiffo]

5 minutes ago, Alewx said:

Which parts, and how do you fix it exactly? If it is just the GernicanimationModule to put in the first place, this will already get into problems with the datastorage module, which is required to be the first one.

I will update the GitHub issue I have in place for this.  I've learned a lot more since I first opened it and I think there's a better approach that will hopefully fit in more cleanly with the mod's approach to things.

[Alewx]

Just now, Fwiffo said:

I will update the GitHub issue I have in place for this.  I've learned a lot more since I first opened it and I think there's a better approach that will hopefully fit in more cleanly with the mod's approach to things.

Ok I will watch it.

[Fwiffo]

Updated.  Let me know if you have questions.

By the way out of curiosity:

28 minutes ago, Alewx said:

...the datastorage module, which is required to be the first one.

Are you talking about ModuleScienceContainer or something else?

[Alewx]

20 minutes ago, Fwiffo said:

Are you talking about ModuleScienceContainer or something else?

Yes that should be the one I meant.

20 minutes ago, Fwiffo said:

Updated.  Let me know if you have questions.

I will look it up, once I'm home.

[Fwiffo]

8 minutes ago, Alewx said:

29 minutes ago, Fwiffo said:

Are you talking about ModuleScienceContainer or something else?

Yes that should be the one I meant.

I wonder if that requirement you mentioned for it to be first still exists.  I did some weldments and the mod was not placing it first.  I haven't noticed any trouble with the science container yet but have not completed field testing missions.  Do you recall exactly what the symptoms were?

[cy-one]

I'm a bit confused about solar panels.

If using non-animated panels like the stock ones to build a huge "pane" of static panels (for a planetary base, for example) ... That wouldn't work, would it?

[Alewx]

8 hours ago, cy-one said:

I'm a bit confused about solar panels.

If using non-animated panels like the stock ones to build a huge "pane" of static panels (for a planetary base, for example) ... That wouldn't work, would it?

Only if they are all facing the same direction, and even then, I have doubts.

9 hours ago, Fwiffo said:

I wonder if that requirement you mentioned for it to be first still exists.  I did some weldments and the mod was not placing it first.  I haven't noticed any trouble with the science container yet but have not completed field testing missions.  Do you recall exactly what the symptoms were?

The science parts were throwing exceptions in the log, that the storage module was not found. It is very possible that it got updated, which would be great^^

Could be that I just made a testing area for such an improvement, that never made it live.

[Fwiffo]

Any idea what would cause the offsets I'm seeing to these meshes?  Preweld on the left, postweld on the right.  The displaced items are meshes that were originally patched into the science parts via MM.

The postweld meshes are the correct size and in the correct orientation, just not in the correct location.  It's almost as if they're being adjusted in X and Z without taking into account the rotation they had in the original part.

EDIT: I've done some drawings on a piece of paper to check calculations, and confirmed.  The mod has a bug in that it is just blindly adding the x, y, z offsets of the mesh without taking into account the orientation of the part it came from.  Once you get your head around the coordinate system, it's correctable with some simple trigonometry.  More info in the spoiler:

Spoiler

I'm in a bit of a rush, but hopefully this is enough information to work this problem.

To reproduce, put this MM patch for the indicator light in a file named accelerometer.cfg and add it to your GameData directory.  You will also need IndicatorLights/Meshes/nubbinLamp which you can grab from here.  Note the Z position coordinate -0.08097 specified here (which is a Z offset from the origin of the accelerometer part):

@PART[sensorAccelerometer]
{
    // We have to re-specify the model for the stock part, because this is
    // an older part that uses the "mesh =" syntax in its .cfg file instead
    // of the newer "MODEL" syntax. The "mesh =" syntax doesn't allow having
    // multiple models as part of the same part, which would prevent this mod
    // from adding meshes for the indicator lights.
    MODEL
    {
        model = Squad/Parts/Science/sensorAccelerometer/model
    }
    
    //-------------------------------------------------------------------------
    // INDICATOR MESHES
    //-------------------------------------------------------------------------
    MODEL
    {
        model = IndicatorLights/Meshes/nubbinLamp
        scale = 1, 1, 0.3
        position = 0, 0.11417, -0.08097
        rotation = -90, 0, 0
    }
}

Then place an accelerometer at an angle on something, and weld.  You'll see the mesh in the weldment is slightly in the wrong place, like my original screenshot above.

These are notes I've been including in my weldment to help me remember how to fix this during manual postweld work, and may help explain things:

    ....
    MODEL
    {
        model = Squad/Parts/Science/sensorAccelerometer/model
        position = 0.55771, 0.047, -0.46326
        scale = 1, 1, 1
        rotation = 0, 315.6288, 0
    }
    MODEL // IndicatorLight for Accelerometer (nubbinLamp index 2)
    {
        model = IndicatorLights/Meshes/nubbinLamp
        // Fixing offsets of Indicator Lights in weldment:
        // 1) The accelerometer on the original craft was at:
        //      pos = -1.50217199,14.4811096,-0.697227895
        //      rot = 0,-0.377607763,0,0.925965846 // quaternion vector [x, y, z, w]
        //    Using http://quaternions.online/, we see that converts to a euler angle of:
        //      [x, y, z] = [0, -44.371, 0] = [0, 315.629, 0]
        //    which corresponds to the rotation of the accelerometer part (45deg around Y).
        //    So far so good.
        // 2) The MM patch accelorometer.cfg which Indicator Lights applies to the stock
        //    accelerometer part contains:
        //      model = IndicatorLights/Meshes/nubbinLamp
        //      scale = 1, 1, 0.3
        //      position = 0, 0.11417, -0.08097 // <-- LET'S CALL THAT 3RD VALUE "Z0"
        //      rotation = -90, 0, 0
        //    Recall +X axis is toward hangar doors, so the rotation flips the nubbin from
        //    facing ~forward (like a gong) to to facing ~down (i.e. like a pancake).
        // 3) In the weldment, the accelerometer was correctly placed at:
        //      position = 0.55771, 0.047, -0.46326
        //    but mod incorrectly placed the nubbinLamp mesh at:
        //      position = 0.55771, 0.16117, -0.54423
        //    i.e. The welder added the Z0 value of -0.08097 to the accelerometer position.
        //    It forgot to take into account rotation of the original part, and should have
        //    instead added -Z0*sin(45deg) to X, and Z0*cos(45deg) to Z.  This yields the
        //    correct coordinates of:
        //      position = 0.61496, 0.16117, -0.52051
        position = 0.61496, 0.16117, -0.52051
        scale = 1, 1, 0.3
        rotation = 270, 315.6288, 0
    }
    ....

Here is a top-down hangar view of what is going on:

I know that image might be a little confusing; let me know if you need any more help understanding what I'm trying to get across.

 

Edited October 31, 2016 by Fwiffo

[Alewx]

47 minutes ago, Fwiffo said:

Once you get your head around the coordinate system, it's correctable with some simple trigonometry

And that is the point of ugh.^^

By the way, what are these plates on top of the sensors? Are they welded in the sensors?

[Fwiffo]

7 minutes ago, Alewx said:

And that is the point of ugh.^^

By the way, what are these plates on top of the sensors? Are they welded in the sensors?

LOL sorry I should not have said "simple".  The trig itself is straightforward, but everything you need to actually get to the point of being able to apply the trig is a bit mind-bender :-).  At least for simple folk like me.  Since the sensors themselves come out correct, I'm kind of hoping you already have the code to fix this but something in the mod just overlooks applying it to these meshes.

The "plates" (little light emissives) are meshes that are added into the stock sensor parts (by an MM patch).  They just happen to be the parts that were triggering it for me; I'm fairly confident the issue is not specific to anything about that mod.  If it's easier to set up, you can just install IndicatorLights (also available on CKAN) and it will patch in the meshes for you.  Let me know if you need me to provide anything else to make this easier to repro / troubleshoot.

Edited October 31, 2016 by Fwiffo

[Fwiffo]

On 10/25/2016 at 1:36 PM, Alewx said:

On 10/25/2016 at 4:51 AM, cy-one said:

I'm a bit confused about solar panels.

If using non-animated panels like the stock ones to build a huge "pane" of static panels (for a planetary base, for example) ... That wouldn't work, would it?

Only if they are all facing the same direction, and even then, I have doubts.

Hi @cy-one, I *think* (if I remember correctly) including a fixed solar panel in a weldment causes the entire part to become sensitive to light (i.e. as long a sunray hits any part of the weldment, it will charge).  You could try using the welder to make a part that includes all those solar panel meshes, then manually edit the part modules to specify values that would be equivalent to all those panels.  (Obviously this is unsupported and kind of venturing out on a limb.  I do a lot of that with this mod :-) ).

Edited October 31, 2016 by Fwiffo

[Alewx]

9 minutes ago, Fwiffo said:

LOL sorry I should not have said "simple".  The trig itself is straightforward, but everything you need to actually get to the point of being able to apply the trig is a bit mind-bender :-).  At least for simple folk like me.  Since the sensors themselves come out correct, I'm kind of hoping you already have the code to fix this but something in the mod just overlooks applying it to these meshes.

The "plates" (little light emissives) are meshes that are added into the stock sensor parts (by an MM patch).  Let me know if you need me to provide anything else to make this easier to repro / troubleshoot.

That might already be the thing. as they are applied via a MM patch, they are vritualized. and not in the original config that is on the HDD.
Reading the virtual config in the memory of KSP could solve the problem, but that is really just a simple thought.

[Fwiffo]

24 minutes ago, Alewx said:

That might already be the thing. as they are applied via a MM patch, they are vritualized. and not in the original config that is on the HDD.
Reading the virtual config in the memory of KSP could solve the problem, but that is really just a simple thought.

Interesting, though starting to get over my head :-).  I think the welding process does seem to know about them at some level, since they make their way into the weldment?  In any case I was able to reproduce without any MM patching (but still using MODEL syntax, I'm not sure if that still counts as "virtualized"):

Spoiler

Files

Preweld:

Postweld:

I'm starting to wonder if this happens for any MODEL mesh which is not at the origin in the original cfg and is rotated in the preweld.

Also wonder if this is the same reason weldments of weldments come out fuzzled.

Edited October 31, 2016 by Fwiffo

[Alewx]

2 hours ago, Fwiffo said:

Interesting, though starting to get over my head :-).  I think the welding process does seem to know about them at some level, since they make their way into the weldment?  In any case I was able to reproduce without any MM patching (but still using MODEL syntax, I'm not sure if that still counts as "virtualized"):

  Hide contents

Files

Preweld:

Postweld:

I'm starting to wonder if this happens for any MODEL mesh which is not at the origin in the original cfg and is rotated in the preweld.

Also wonder if this is the same reason weldments of weldments come out fuzzled.

No if you put them into the config manually with the model, than it is not virtualized.

I'm pretty sure that you are up to something, that is causing this trouble. But that is Math I really hate.

[RightInfinity]

Hey, I'm having issues with weldments and rescaled parts, as a lot of my weldments made in this version are turning out with changed scales compared to unwelded assemblies. it's mainly happening to structural panels, i-beams, and a few fuel tanks (Oscar-b in particular), Although for wing parts it's working just dandy. I'm running a nearly stock setup with only additional parts coming from KER, Infernal Robotics, Editor extensions and Snacks   Pic in spolier

Spoiler

Is there any reason why this is occuring? I'm having to go back to 1.1 a version to make my assemblies, that doesn't suffer from this bug.

 

Edited November 4, 2016 by RightInfinity
Added in my mods

[Alewx]

37 minutes ago, RightInfinity said:

Hey, I'm having issues with weldments and rescaled parts, as a lot of my weldments made in this version are turning out with changed scales compared to unwelded assemblies. it's mainly happening to structural panels, i-beams, and a few fuel tanks (Oscar-b in particular), Although for wing parts it's working just dandy. I'm running a nearly stock setup with only additional parts coming from KER, Infernal Robotics, Editor extensions and Snacks   Pic in spolier

  Reveal hidden contents

Is there any reason why this is occuring? I'm having to go back to 1.1 a version to make my assemblies, that doesn't suffer from this bug.

Scaling is something that changed quite a lot in the way it gets handled through out the different KSP versions. It is a thing that @Fwiffo also pointed me at; and it is on the agenda.

Edited November 4, 2016 by Alewx

[Alewx]

Update to UbioWeld Continued 2.4.0 - Weldception

• Recompile for KSP 1.2.1
• Fixed welding of weldments
• Fixed Position
• Fixed Rotation
• Fixed Scaling

Download version 2.4.0 for KSP 1.2.1

[COL.R.Neville]

it goes all the way back to the rescale on the original model. once you weld it you lose the cfg that was associated with it for the most part. 

so go back to the original part and add scale = 1.0, 1.0, 1.0 under the model = 

and that will get carried forward IF its there.

or just wait until you are done and rescale with the same under the model entries in weld file. but remember when you rescale you need to move all the nodes along with it.

everything is working fine in 1.2.1 so far.  

Edited November 6, 2016 by COL.R.Neville

[Alewx]

9 minutes ago, COL.R.Neville said:

it goes all the way back to the rescale on the original model. once you weld it you lose the cfg that was associated with it for the most part. 

so go back to the original part and add scale = 1.0, 1.0, 1.0 under the model = 

and that will get carried forward IF its there.

or just wait until you are done and rescale with the same under the model entries in weld file. but remember when you rescale you need to move all the nodes along with it.

everything is working fine in 1.2.1 so far.  

Do you have an specific example?

[COL.R.Neville]

Spoiler

PART
{
    name = LSScrubber
    module = Part
    author = UbioZurWeldingLtd
    scale = 1
    rescaleFactor = 1
    node_stack_bottommepsdock0 = -0.003923, -0.48193, -0.352817, 0, -1, 0, 0
    node_attach = -0.003923, -0.48193, -0.352817, 0, -1, 0, 0
    CrewCapacity = 0
    TechRequired = electronics
    entryCost = 34900
    cost = 10320
    category = Utility
    subcategory = 0
    title = Life Support Recycler
    manufacturer = UbioZur Welding Ltd
    description = Life Support Recycler, conditioner
    attachRules = 1,1,1,1,0,0,0
    mass = 0.44000006
    dragModelType = default
    maximum_drag = 0.0878299996
    minimum_drag = 0.0792360008
    angularDrag = 0.350890994
    crashTolerance = 8.8081398
    breakingForce = 197.373184
    breakingTorque = 197.373184
    maxTemp = 3200
    fuelCrossFeed = True
    explosionPotential = 0.472015381
    thermalMassModifier = 1
    heatConductivity = 0.12
    emissiveConstant = 0.40000000000000002
    radiatorHeadroom = 0.25
    bulkheadProfiles = size1,srf
    MODEL
    {
        model = MEPS/Parts/mepsdock
        position = -0.003923, -0.371929, -0.352817
        scale = 1,1,1
    }
    MODEL
    {
        model = UmbraSpaceIndustries/Konstruction/Assets/PAL_Truss
        position = -0.003923, -0.206928, -0.352817
        rotation = 270, 0, 0
        scale = 1,1,1
    }
    MODEL
    {
        model = LLL/Models/Science/Generator
        position = -0.028628, 0.218071, 0.90372
        rotation = 0, 270, 0
        scale = 0.75 , 0.75 , 0.72
    }
    MODEL
    {
        model = LLL/Parts/Utility/RadialPipes/model
        position = -0.454214, 0.713584, 0.292651
        scale = 0.6125, 0.6125, 0.6125
        rotation = 5.1E-05, 179.9999, 0
    }
    MODEL
    {
        model = LLL/Parts/Utility/RadialPipes/model
        position = 0.013347, 0.711263, 0.292653
        scale = 0.6125, 0.6125, 0.6125
        rotation = 5.1E-05, 179.9999, 0
    }
    MODEL
    {
        model = UmbraSpaceIndustries/LifeSupport/Assets/MiniPak
        texture = miniPak, UmbraSpaceIndustries/LifeSupport/Assets/miniPak_01
        position = 0.850067, 0.469288, 0.142655
        scale = 1,1,1
    }
    MODEL
    {
        model = UmbraSpaceIndustries/LifeSupport/Assets/MiniPak
        texture = miniPak, UmbraSpaceIndustries/LifeSupport/Assets/miniPak_03
        position = 0.021753, 1.150903, 0.651992
        rotation = 90, 0, 0
        scale = 1,1,1
    }
    MODEL
    {
        model = UmbraSpaceIndustries/LifeSupport/Assets/MiniPak
        texture = miniPak, UmbraSpaceIndustries/LifeSupport/Assets/miniPak_02
        position = -0.453321, 1.150903, 0.649325
        rotation = 90, 0, 0
        scale = 1,1,1
    }
    MODEL
    {
        model = UmbraSpaceIndustries/Kontainers/Assets/RoundTank
        texture = Tank_00, UmbraSpaceIndustries/Kontainers/Assets/Tank_01
        position = 1.454577, -0.006929, -0.352817
        rotation = 0, 0, 270
        scale = 0.5,0.5,0.5
    }
    MODEL
    {
        model = UmbraSpaceIndustries/Kontainers/Assets/RoundTank
        texture = Tank_00, UmbraSpaceIndustries/Kontainers/Assets/Tank_01
        position = -1.462423, -0.006929, -0.352817
        rotation = 0, 0, 270
        scale = 0.5,0.5,0.5
    }
    MODEL
    {
        model = LLL/Models/Utility/2x1Greenhouse/model
        texture = model000 , LLL/Models/Propulsion/LLL2x1/model000
        texture = model000334_NRM , LLL/Models/Propulsion/LLL2x1/model001_NRM
        position = -0.014327, 0.155571, -0.258505
        scale = 0.5, 0.5, 0.5
        rotation = 90, 90.00003, 0
    }
    MODEL
    {
        model = LLL/Models/Science/Circuit1
        position = -0.785106, 0.143072, -0.328318
        rotation = 0, 270, 0
        scale = 1,1,1
    }
    MODEL
    {
        model = LLL/Models/Science/Circuit1
        position = 0.784762, 0.143072, -0.331931
        rotation = 0, 270, 0
        scale = 1,1,1
    }
    MODULE
    {
        name = ModuleAnimateGeneric
        animationName = shutter
        isOneShot = false
        startEventGUIName = Extend Shutters
        endEventGUIName = Retract Shutters
        actionGUIName = Toggle Shutters
    }

    RESOURCE
    {
        name = ElectricCharge
        amount = 4000
        maxAmount = 4000
    }

    RESOURCE
    {
        name = Supplies
        amount = 400
        maxAmount = 400
    }
    RESOURCE
    {
        name = Fertilizer
        amount = 400
        maxAmount = 400
    }
    RESOURCE
    {
        name = Mulch
        amount = 0
        maxAmount = 400
    }
    RESOURCE
    {
        name = Water
        amount = 0
        maxAmount = 3600
    }
    MODULE
    {
        name = USI_ModuleRecycleablePart
        Menu = Disassemble Part
        ResourceName = MaterialKits
        Efficiency = 7
    }

    MODULE
    {
        name = USI_ModuleResourceWarehouse
    }

    MODULE
    {
        name = ModuleAnimateGeneric
        animationName = shutter
        isOneShot = false
        startEventGUIName = Extend Shutters
        endEventGUIName = Retract Shutters
        actionGUIName = Toggle Shutters
    }

    MODULE
    {
        name = ModuleKISInventory
        maxVolume = 500
        externalAccess = true
        internalAccess = true
        slotsX = 8
        slotsY = 5
        slotSize = 50
        itemIconResolution = 128
        selfIconResolution = 128
        openSndPath = KIS/Sounds/containerOpen
        closeSndPath = KIS/Sounds/containerClose
        defaultMoveSndPath = KIS/Sounds/itemMove
    }
MODULE
{
name = TweakScale
type = free
}
}
 

yeah i created this life support scrubber. outta USI ,LLL and MEPS parts. 

had a problem with the radial pipes since they are rescaled to 1.25 in the cfg file. it just ignored that and ran to 1. 

but the lll generator is specifically attributed at the model with a scale of 0.75,0.75,0.72 and it carried that forward. 

i added in the scale under all of these since i subsquently welded it again after i tweakscale everything down another 50 percent. and added in a KIS container for the final one.  

because i had all of these with the scale data attributed under the model i zero problems with the final one. but it took a better part of the day to figure out what it was doing. 

[Fwiffo]

That latest build of the mod is a huge improvement - thanks Alewx!

Perhaps now we could make the "Ignore massless parts" work as advertised.  i.e. When unchecked, it would take into account the masses of physicsless parts and adjust CoM accordingly (i.e. make use of all the latest changes you incorporated).  When checkmarked, it would ignore physicsless parts altogether for purposes of CoM (and maybe just add their mass to the final weldment).  The latter is still useful in some scenarios - I'm running into edge cases where the balance of welded parts is not quite as expected and I used to use that option as a workaround.  Also suggest renaming it to "Ignore physicsless parts for CoM" for greater accuracy/clarity (since they still do have mass, and the modules etc. provided by the physicsless parts are still included).