Earlier I started messing around with CollisionGroupId as a workaround for a custom collision system I wish to implement as the client does not have the capability to set Collision Groups even on local parts. I was just about to test something when I noticed this pretty unusual bug which has 100% replication ability.
The platform seen has a CollisionGroupId of 1, while everything else has the default value of 0. I would expect the player to be able to jump up through the platform, but fall right back through it as they’re not in the same collision group. This is how it works right? But instead, what we see is that the top-side of the part still has collision, while the rest of the platform does not. To create this bug: open a new place in Studio, place a part in workspace, anchor it, and set it’s CollisionGroupId to 1 in the properties window. This issue is happening in the latest version of Roblox Studio, not sure if it happens in a live place yet.
I included the explorer window in the gif to show that there is in fact no code in the place file, merely a single part is all I added.
I’m testing to see how I can do custom collision on the client, I know it’s technically not the proper way but it’s still supported. And since I want to do it on the client I can’t use PhysicsService. Regardless, this isn’t behavior that should be happening.
What you can do is create and configure a collision group in Studio or the server, then set the CollisionGroupId property to the correct value locally.
I think the issue here is that there’s no collision group associated with that ID, so the engine doesn’t know if it should ignore the collisions or not.
Humanoid uses raycasts for it’s levitation forces. The avatar’s parts might not collide with it, but the Humanoid raycast is still hitting it so you can still walk on top of it.
I forget which was the case now, but the humanoid raycasts might use the same collision group as the HumanoidRootPart, or it might always use Default.
