In my experience, characters are just a block; they all belong to the Player Collision Group which is set before runtime (i.e. in Studio). Parts in the Player Collision Group can only collide with the parts in the Default group.
Sometimes this is not what happens. Even though Player-Player collisions aren’t supposed to happen, under certain conditions they do happen. I haven’t found a deterministic way to reproduce the bug, but the following steps seem to reproduce the bug relatively reliably on this experience:
- Create a server with two players (you’ll notice they’ll spawn in the same place and that they’re ghosting through each other, as intended);
- One of the players stays at the finish line while the other completes a lap around the circuit;
- When going through the finish line, the first player should try to go through the second one, but they collide instead.
The output window on the side prints, from the client’s Point of View, the collision groups of both players (both set to Player on their primary part) and whether Player-Player collisions are enabled (they are not):
--!strict
local Players = game:GetService("Players")
local PhysicsService = game:GetService("PhysicsService")
while task.wait(2) do
warn("Player - Player Collisions: " .. tostring(PhysicsService:CollisionGroupsAreCollidable("Player", "Player")))
for _, p in pairs(Players:GetPlayers()) do
if p.Character then
print(p.Character:GetFullName(), p.Character.PrimaryPart.CollisionGroup)
end
end
end
Other remarks which may help in diagnosing the problem:
- The CollisionGroups of the characters’ parts are set in Studio (
StarterPlayer.StarterCharacteris overriden), however and for the avoidance of doubt, the collision groups are re-set toPlayerimmediately after spawned for the player; - Each player has network ownership of their own character;
- The character does not have an
Humanoidor aHumanoidRootPart; - Parts other than the PrimaryPart are for decoration only (they’re massless +
CanCollide/CanTouch/CanQueryis turned off for those parts);
