You should be able to accomplish this by using Collision Groups.
Sorry, I should clarify in the original post, this feature (and the future features listed) is only meant for R15 characters.
6 Likes
That’s what I was thinking as well, but ROBLOX probably won’t do that as it would be more stuff that they would have to look after and it could eventually get to the point where they just can’t maintain it anymore.
3 Likes
I agree, I think this is the best solution (Your solution), there is a minority of games still loved by the community, I hope they won’t be broken due to this future update.
2 Likes
I have thought of using Collision Groups and looked into it and tried out out but this is not a fruitful solution
2 Likes
Hearing the mention of facial animation confuses me, especially when this seems to be implying that heads from bundles currently on the catalog would somehow be changed to support facial animations.
Is this something we should actually expect to happen? Even the bundles being released as part of this current event have head models like that look like this:
This mesh could never support facial animations without being completely remodeled and retextured. I am very excited to see how Roblox rolls out these new features that leverage mesh deformation, but the task to make legacy catalog items cooperate with these changes seems impossible.
6 Likes
I’ve just tested out this feature and I’ve noticed the Classic Fedora hat doesn’t appear as it should.
Aside from that, excited for this change to be fully rolled out!
4 Likes
So I’ve found a rather unique issue related to this change. It completely breaks Rbadam’s Smokestack Top Hat
The first (and most obvious) issue is that the MeshPart is bigger than the old handle, leading to the particles being generated outside of the hat, rather than inside. At first glance, this seems like it would be the only issue, but this hat is unique because it actually has a script that retextures it for certain holidays.
As seen in the image above, this change actually causes the retexture function of the script to break (specifically the mapping of the texture seems to be off). I haven’t looked into exactly what’s causing this to happen, but it happens for most of the hat’s themes.
I hope this can be resolved before this fully rolls out!
12 Likes
Looking into both of these issues. Thanks for reporting them.
12 Likes
Why isn’t this enabled for R6?
Edit: NVM, that’s why you always scroll up…
3 Likes
After enabling this, I have seen that the Headless Horseman costume, the head has a large collision field, will these costumes be optimized to avoid this?
Edit: I read the part about this problem, but what can be done to mitigate it while it is being fixed?
11 Likes
Great optimization update. Looking forward to it!!
1 Like
Time to block off doors as a sentient toilet with no head
4 Likes
In fact, you don’t even need pivots, this already works the way you want!
Try changing the size of a character’s head and then dragging it. If you drag it by the head, it will be “off”, but if you drag it by clicking on any of the parts which are aligned, then the whole model will stay aligned the way you want as it is dragged.
The way the draggers handle alignment is to align the vertex of the dragged content closest to where you clicked on it with the surface that you drag onto, so which part on the model you drag it by will let you disambiguate how you want it to align.
2 Likes
Is it possible in the future that we will get support for R6 characters? I mainly ask because for a very specific use case, I am trying to make the head and accessories of a R6 character neon, but I am unable to accomplish this due to SpecialMesh’s lack of support for the neon material.
Currently the hack I use to get “glowing” meshes is setting the SpecialMesh’s texture to a pure white decal and then setting the VertexColor to a extremely high number. This accomplishes an effect similar to neon, but has a few caveats making it difficult to use.
Here is a comparison image of a Neon part and SpecialMesh part for reference.
- VertexColor does not become as bright as neon, which is especially more noticeable at certain colors (for example, see the orange mesh part). You can also notice there is still a shine on both mesh parts while Neon does not have any of this.
- It’s harder to get the color I want when I set VertexColor past it’s normal limits, especially when I’m trying to get it to match up with normal neon parts.
- Setting properties like VertexColor past their normal limits do not work if the part is a descendant of a object that has a humanoid, which forced me to write clientside code specifically to get around this.
The result of all my very hacky code is this:
However, as stated before, at certain colors, it will look very off.
I simply ask and hope that in the future, R6 will get the same support for this new feature as R15 did. It would also be very nice if the FileMeshes got support for the neon property or if we could set the property of MeshId for MeshParts, but that’s getting off topic.
19 Likes
Huh, never knew that. Well then that part is settled.
1 Like
Will having this enabled improve performance for characters due to it being a MeshPart rather then a SpecialMesh?
3 Likes
This update is great, finally I don’t have to weld fake heads on my characters, but when will Mesh Part packages be a thing 
1 Like
This should be fixed now. Let us know if anything else looks wrong.
3 Likes
This looks promising as MeshParts are more useful than SpecialMesh
However I like this change since it’s a way to work with new features which require MeshParts for example.
Also this may be offtopic but is SpecialMesh instance going to be phased out?
Same with CylinderMesh, BlockMesh, etc
1 Like
I have a question.
I have a custom rig (wich uses a part + mesh as head)
I need to do something? @Osyris