The BasePart.CollisionGroup property does not do anything in the Roblox physics engine. All setting this property does is trigger an internal callback to set the BasePart.CollisionGroupId, which was deprecated in favor of BasePart.CollisionGroup. The deprecated BasePart.CollisionGroupId is the property that is actually used for collision detection, and it is extremely easy to desync these two values. To desync the two values, set the CollisionGroupId of a BasePart to a collision group ID that does not match the CollisionGroup set to the BasePart. Once desynced, the properties can be re-synced by either setting BasePart.CollisionGroupId to match the BasePart.CollisionGroup’s ID, or by setting BasePart.CollisionGroup to a different value. Setting BasePart.CollisionGroup to its current value without changing it will not reset the BasePart.CollisionGroupId and thus will not do anything to remedy desynced collision behavior. Attached is a reproduction file with a part and GUI buttons to change the part’s collision behavior with the player character.
The behavior should be reversed. Changing BasePart.CollisionGroupId should do nothing but update the BasePart.CollisionGroup, and BasePart.CollisionGroup should be the property used for collisions. Normally, this would not be a worthwhile bug to fix because it only appears to trigger when modifying deprecated properties, but importing models from other places will use the original place’s BasePart.CollisionGroup and BasePart.CollisionGroupId values, resulting in desyncs between places with the same collision group names and different IDs, with no deprecated properties updated by the developer. This is how I discovered this bug in the first place.
@Andy_Wirus Sorry this seemed to be missed! I am trying to reproduce the behavior now. Do you recall how you were importing models when you found this bug? As in copy-and-pasting, dragging, etc?
I don’t know for sure since it’s been almost a year, but I did some testing and noticed that the desync does not occur with copying and pasting, nor does it occur with importing an rbxm, which I imagine is the same conclusion you arrived at in order to ask me that question. Knowing this, I think I most likely discovered it by exporting as rbxm and using that rbxm file in a Rojo project that I had hacked collision group data into (by exporting a place file as rbxlx and copying the collision group data’s BinaryString and pasting it into the project.json, since Rojo does not have collision group support). Perhaps the bug is more niche than I initially believed it to be for this reason, but I still think we can agree that physics simulation shouldn’t be relying on deprecated properties. The repro file in the original post still demonstrates this behavior: CollisionGroup is only a mostly-functional alias instead of an authoritative property.
Thanks for the info! Given that we can’t currently reproduce the error in export/import, I am closing this ticket. I agree with you, though, that having the group ID floating around seems a little odd. The reason for this is backward compatibility. We designed the new system such that it wouldn’t break older games that may contain scripts from before the change, but this meant that we had to keep the group ID exposed to users, thus allowing the desync you showed in your repro (which was super nice, by the way!)
We do want to fix any import/export inconsistencies though, so if you find it again, please let us know!