New parameter “ignoreMassless” :
BasePart:GetMass(true) -- returns mass >0 for actively Massless BasePartCalling GetMass on a BasePart that is actively Massless returns 0.
I use mass to determine the “Health” of a block on a vehicle. But It remains massless to prevent it from affecting suspension. With this feature, I could avoid costily setting Massless after storing hefty readings for all parts in the initialization of our vehicles.
Mass (and the legacy GetMass) don’t always return 0 when the part is Massless; the property is ignored if the part is not in an assembly or is the the root of one. This is because Massless (and therefore Mass) are properties referring to the part’s contribution to the assembly’s mass.
Yes. Hence I only regarded ‘actively’ Massless parts in my post.
How are you using Mass as a measurement of “Health”? You can’t write to it, are you modifying Density instead?
Overall it sounds like you’d be much better off just using Attributes
Mass is used by getHealth(mass) to determine part Health
Current workaround:
Massless = false
– take reading
Massless = true
If thats efficient its ok
When a part (of some 300) on the car first takes damage, the mass is checked and now stored.
Ok I understand now. Assuming you’re just doing this once as an initialization, it should be fine.
In fact, if you perform this initialization before the car is in the World, the Mass will be shown even if the part is Massless. This is because all Welds are disabled while out of world, so that part can’t be Massless since it is its own root.
I don’t think you should be managing part health this way. This is extremely rigid and removes your ability to tune part health for game design purposes. You would be better off e.g. defining a table in a module somewhere that maps material to some kind of max health multiplier. You can use that number instead to multiply by the total volume of the part (width * height * depth), which gives you more control and doesn’t require weird API bloat.
