SpecialMesh under MeshPart behavior correction

Hello developers, we recently found SpecialMesh has broken behavior when it’s a child of MeshPart. So we decided to correct the behavior by making MeshPart ignore SpecialMesh. If your game relys on SpecialMesh/FileMesh, please make sure it’s not a child of MeshPart. This change will happen after next week.


Does that mean that we can no longer add a SpecialMesh in the MeshPart anymore?

Not like I put one in though.


Thanks for correcting it, and also thanks for the announcement! I appreciate it!


What was the broken behavior?

It seems more useful to make it so the SpecialMesh renders, but the collisions of the MeshPart are used. You could have less precise collisions for a more precise mesh for example.


You’re the kipper’s knickers, thanks!


Thank you so much for fixing it. Greatly appreciated!

1 Like

Is there a reason the behavior is considered “correct”? To me, it seems like adding a SpecialMesh should override any BasePart parent, not just Parts, Wedges, and CornerWedges. Maybe I used MeshParts for collisions with a different appearance (I don’t; just theoretical).


Is there still an option to make a mesh part not ignore a special mesh?

1 Like

Doesn’t seem like it, otherwise it’d probably be mentioned in the announcement. As a workaround, you could always just make the MeshPart transparent and weld a part with a SpecialMesh to it.


Okay, thank you very much for your help🙂

1 Like

Yeah I wouldn’t mind this being a feature too. Right now its impossible to switch the MeshId of a MeshPart at runtime. If we want to use the same geometry with different UV mapping, we have to use a separate MeshPart. Its very annoying at times.


Well, whenever you put a SpecialMesh inside a MeshPart with an already existing MeshId this would happen:

Normal MeshPart with no MeshId but with a SpecialMesh

Normal MeshPart with a MeshId:

Same mesh part but with a sphere SpecialMesh:

It not only distorts the SpecialMesh but it gets rid of the MeshPart’s mesh

Regardless of this, more people were having problems with SpecialMeshes and MeshParts with already existing id’s than people using it for the collisions of a MeshPart. Or at least I assume.


I think I like it better with the SpecialMesh overriding the MeshPart since you can use this behavior to add custom collision boxes to your meshes. Also, I believe this is more expected behavior since the SpecialMesh would be expected to override it’s parent, regardless of type. This ‘bug fix’ might introduce an ugly inconsistancy.


Oh darn, I kinda really needed this SpecialMesh-Override-MeshPart behavior for something, I want to keep the collission/hitbox the same
but use a slightly edited mesh with different UV-mapping, it’s like a important thing that I need.

I don’t want to rely on having to weld a part with mesh to the MeshPart, seems so hacky and unneeded, having to make a weld, weld new part with mesh to MeshPart, set MeshPart invisible, sounds like bad practice, more coding and memory use to me.

1 Like

This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.