This issue was reported multiple times in the past. It was fixed for a short time, but then started to happen again:
- Tool parts have collision when equipped for a short amount of time although CanCollide is false
- Tool parts have collision when equipped for a short amount of time although CanCollide is false (continued)
- CanCollide false, can still collide right after the Part is brought into the DataModel Workspace, e.g. through Tool Instance
I observe today that when a tool is unequipped, the tool handle’s “CanCollide” property is set to true on the server (because there is a delay between the moment the tool is unequipped and the moment the property changes). When the tool is equipped, the CanCollide property is set to false on the client (because the property change applies immediately), however, this causes an issue being that if you have a tool equipped and quickly unequip and re-equip it, the tool’s handle gets collision while it’s equipped for a short amount of time because the server made the change while the tool was unequipped on the server. Players are able to abuse this to clip through walls which are thin enough.
I demonstrate the bug in the video below in a fresh baseplate where a tool’s Handle CanCollide property is set to false on Studio, and exploit the bug to clip through a 0.6 studs-thin wall. I put a 0.3 seconds network delay.
One workaround is to listen to the CanCollide property change on the client and set the property back to false every time, but that is annoying to set up and we should not have to do this. Another workaround is to put the tool’s Handle in a collision group that does not collide with anything, but it has the side effect of making spacial queries (RayCast, ShapeCast, etc…) impossible to detect the tool’s Handle.
Expected behavior
I expect the tool Handle’s CanCollide property to be false at all times, like set in Roblox Studio.