To quote clonetrooper when this feature came out:
If you give Terrain a collision group, then give a Humanoid’s parts a collision group, and set it so the two collision groups can’t collide, Humanoids can still stand on Terrain, though they can walk through it if the slope is steep enough.
Example repro code:
local PhysicsService = game:GetService'PhysicsService'
local TerrainGroup = 'TerrainGroup'
PhysicsService:CreateCollisionGroup(TerrainGroup)
local CharacterGroup = 'CharacterGroup'
PhysicsService:CreateCollisionGroup(CharacterGroup)
PhysicsService:SetPartCollisionGroup(workspace.Terrain, TerrainGroup)
PhysicsService:CollisionGroupSetCollidable(TerrainGroup, CharacterGroup, false)
game.Players.PlayerAdded:connect(function(p)
p.CharacterAdded:connect(function(c)
for _,v in next, c:GetChildren() do
if v:IsA'BasePart' then
print('set group',v)
PhysicsService:SetPartCollisionGroup(v, CharacterGroup)
end
end
end)
end)
But FYI if you’re wearing a package, you need to add a p.CharacterAppearanceLoaded:wait() inside CharacterAdded. Otherwise you’re setting the collision group of the block package that gets destroyed and replaced with the package you’re wearing.
So, this is a known issue, and it’s a consequence of the fact that Roblox characters are not colliding with anything they are walking on. As I’m sure you’ve noticed, a character’s limbs are CanCollide false (and forced to be so on every frame), except when you manually put the character in Physics state using Humanoid:ChangeState(). Collision groups only work with CanCollide=true parts the physics simulation is handling the collisions for. When the character is walking on the terrain, it’s just doing downward raycasts to figure out what height to float at. This is why there is a HipHeight property on Humanoid, to make the offset correct so that the feet appear planted on the ground at the right height. The rays detect and respect the collision groups of parts they hit, but apparently smooth terrain is an exception to this.
If you try to make a character walk with collidable parts, you’ll quickly see why this is how video game characters are often implemented; it turns out that legs that scissor back and forth like R6 characters is not a viable bipedal locomotion strategy. Even in games where the character is physically colliding with the ground, it’s usually not with the character’s visual geometry, the character’s “feet” are often just a sphere sliding on the ground (or hemispherical bottom of a collision capsule).
So is the issue just that the HumanoidStage isn’t acknowledging the collision group of the Terrain? Maybe it should be based on the HumanoidRootPart’s CollisionGroup?
The issue is that the Humanoid’s raycasting-based system has no use of Terrain CollisionGroups. And yes, if we were to add a special case for the Humanoid it to blacklist Terrain from it’s downward raycasts based on CollisionGroup, the character as a whole would need to pick one group for the purpose of the comparison.
EDIT: I made the clarification that this is only affecting Terrain. The Humanoid already does make this exception for parts, of course, so I think it’s reasonable to consider this a bug. That said, wanting player characters to fall through all smooth terrain is not a common request, and the view from inside terrain isn’t nice. Is there an actual use case where this is desired, or was this just an observation? I’ll have to ask around, as there is some change this behavior was a deliberate choice because of how all smooth terrain is basically one part, and the value of being able to fall through it is limited.
For what it’s worth, if you really want your players falling through Terrain, I can confirm having tested it just now that humanoid:ChangeState(Enum.HumanoidStateType.Physics) will allow it to happen. In this state, the player character is just regular physics simulation parts.
I brought this up because when I was doing this x.com
the smoothterrain was causing my character to stand on it and constantly get pushed up into the sky, even though they shouldn’t have been colliding
My workaround to offset everything by 1024 studs (camera, terrain generation) from where my character was
Oh I see. Yeah, I just had my invisible character on an invisible baseplate below the normal one, and was setting camera.Focus and camera.CameraSubject manually to STM’s location part.
