Display basepart's collision group in Studio even when the legacy collisionGroupId is used

previous title: Parts reacting as if they’re in a different collision group

Edit: Read replies.

CollisionGroupBug.rbxl (50.0 KB)

Attached is a place file with two colored platforms; one green and one red.
Both platforms are supposedly in the “Default” collision group.
image

There is a server script in StarterPlayer.StarterPlayerScripts that sets the collision group of all of the parts in the player’s character to “Character”.

In the Collision Groups Editor observe that the “Character” group can collide with the “Default” group. Observe the presence of other numbered groups, all of which are set to collide with nothing else.

Enter play solo mode and try hopping onto the green platform. Observe that your character can stand on it. Now try hopping on the red platform. Observe that your character falls through it.

Again, the red platform claims to be in the “Default” collision group.

Exit play mode and set the “Character” collision group to be able to collide with the “2” collision group. Enter play mode again. Observe that your character is able to stand on the red platform now.

Expected behavior

The player’s character should be able to stand on both platforms because they are both supposedly in the “Default” collision group and the player is in the “Character” collision group and those two groups are set to be able to collide with eachother.

Instead, the player falls through the red platform but not the green.

Workaround

Set the red platform to a different collision group and then back to default again. It should behave normally.

3 Likes

Engine is working as intended, but we do have some usability issues here we need to fix…

Both of the parts do have CollisionGroup = "Default", but the red one with the weird behavior has CollisionGroupId = 3. It’s 0 for the green one, so that works as expected.

When CollisionGroup == "Default" we honor the legacy CollisionGroupId index. For compatibility, if the newer CollisionGroup property is not explicitly set to a non-default value the legacy index-based group lookup will be used. If CollisionGroup is non-default CollisionGroupId will be overwritten with the index of the named group.

We currently don’t auto-migrate old parts assigned to collision groups by ID to name based groups because that might not always work for groups that are created or remapped at runtime (which seemed to be common with the older less portable indexed lookup). If that migration didn’t work 100% correctly, it would be destructive and cause any scripts doing runtime ID remapping to break…

We either need to take that chance and force that ID-to-name migration anyway, or we need to fix the Studio UI to still display the ID when it is still used…

Until then, you can use the Lua console or a plugin to set CollisionGroupId = 0, then it should work as expected.

1 Like

This would be nice, or it would be even better for Studio to show the collision group name of the group the part is in if it has an index set to a group that isn’t “Default”.

For example, in my place file, it would show “2” for the collision group because that’s the name of the collision group the part has the ID for. If there are problems with having Studio automatically change the collisiongroup of a part to match the collisiongroupId then simply displaying it as “2” in Studio without actually changing the property of the basepart would at least make it clear to me because I had no idea why my player was falling through the floor of my map in random places.

Currently when I look in the properties window at the collisionGroup property, I (understandably) expect that to represent what collisiongroup the part is in so for the value there to not represent how the part will actually behave and the collision group it will act as if it’s in is not very intuitive and expecting a new user to figure that out isn’t reasonable.

1 Like

And of course a year later Roblox has decided to chose 0 of those two options which you stated. Trying to work with CollisionGroupId is the biggest pain for absolutely no reason. You spent more time working on the UI then fixing or atleast clarifying issues like this.

2 Likes

Yeah, Roblox works pretty slow and it can be very frustrating, especially when they leave important stuff broken for months or even years.

I always like to look back on how it took them at least 15 years to add a math.round function.

Hello, we’ve added a warning icon in case the collision group id doesn’t match with collision group. Please migrate collision group id to the new collision group. Thanks!

1 Like

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