Humanoid Part Collision Changing - 'Only On State Change'

Hi Developers,

We are going to be changing the way that Humanoid parts have their collisions values (CanCollide) set by the Humanoid that controls them.

Currently, the values of the CanCollide are set each frame based on the state of the Humanoid. For example, when the Humanoid is in a normal stating state ( Running ), the arms and legs are set to be CanCollide = false each frame.

In the future, they will still be set that way, but only when the Humanoid first enters a new state. This will improve Humanoid performance and allow developers more control over the collision state of the Humanoid, should they wish to modify it after the Humanoid has changed state. This change is not live yet, but will be in the near future.

Since this may break scripts that depend on the existing collision behavior, we will introduce a new property to Workspace called Workspace.HumanoidOnlySetCollisionsOnStateChange , as a way to opt-in to this new behavior.

Again, this is NOT live yet, but here’s what it will look like once it is enabled:


At release, the “Default” setting will have the same behavior as “Disabled”. At a later date, we will change this behavior so that it matches “Enabled”. This will allow games to opt-out if necessary to fix broken code (if they did not opt-in and fix that code previously).

We will update this thread once the migration occurs and this setting is available.

Thank you


Very nice optmization change.

Currently, the values of the CanCollide are set each frame based on the state of the Humanoid

I always wondered why I can’t set cancollide true on the bodyparts of characters. This is going to be very useful for ragdoll bodyparts clipping through parts.


Smaller announcement, but a great change! It’s always never made sense to me why Humanoid collision couldn’t be modified, and it’s great to see more optimizations made to humanoids and some of of their performance issues fixed. I switched to custom humanoids a while ago for NPCs so I can have hundreds moving around at once, but I’ll have to take a look again performance wise if these optimization continue!

Thanks for more control over humanoids! (Any chance for humanoid-less clothing in the future? Although it seems unlikely, it would be incredibly helpful.)


How immediately will collisions be set when states are changed and approximately which frequency does this occur (I’d assumed Stepped because physics simulation)? I think it sounds realistic to use task.defer here if we’re self-managing collisions on humanoid parts so that they can be updated to the values we want within relatively the same frame.


Thank you for this change! Always happy when humanoids get performance improvements.
Curious though, will HumanoidOnlySetCollisionsOnStateChange be deprecated once enough games use the new behavior (or at least don’t break with it)?


So is this gonna mean people can walk through each other without any problem from just this one thing no more scripts?..

1 Like

No, this simply changes humanoids so they don’t set the CanCollide property as often, for your issue use collision groups for that.

1 Like

Cancollide makes it where you can go through it though-

1 Like

From my experience outside of Roblox,
It’s because you generally want to minimize the unique physics interactions in actors/characters.

In roblox the case is generally: The Head and HRP are generally what detects collisions into walls

The Unity3D “CharacterController” uses a capsule hitbox for all of the basic physics as a means of stopping wonky behavior.


If they can go through each other without collision groups, then there’s nothing stopping them from falling through the earth into the void. Or nil, in Lua.

1 Like

I just quite don’t understand what exactly this update is supposed to bring.

This is just a small optimization to cut down on humanoid CanCollide settings per frame, such that they will only be changed when they need to be (i.e. when the humanoid’s state changes). Nothing very drastic, unless you depend on the current setting.


It changes all the parts. It may be represented like so:

Old behavior:

while task.wait() do
    if humanoidIsInState then -- Is humanoid in state
        -- Do stuff

It continuously polls the humanoid’s state, and sets the entire humanoid’s collisions accordingly. This runs every frame.

New behavior:

    if state == someState then
        -- do stuff

This runs only when the humanoid’s state changes, which is not every frame, therefore improving per-frame performance.


How did you go about making custom humanoids?

1 Like

Can we add a service for these new objects to prevent cluttering up workspace with loads of bloat. I’m sure these could be put under their own services, or for this one, simply PhysicsService.


These settings under workspace are starting to get a little messy, will these ever be moved to game settings instead?


The character wouldnt fall though the ground, because the Humanoid keeps the character ‘hip height’ above the ground even if there is no ‘cancollide’ set.

What this update does, is makes it easier for developers to turn collision on or off to character parts, if they need to. Without having to have a script manually set it each frame.

For instance, in my game, the mermaid crawling animation causes the lower torso, and upper torso to hit the ground. I have to make a script to set these parts to ‘cancollide = false’ each frame, so the crawling animation can play.

This ‘if I assume correctly’ will let developers check for a change in the collision state of the part and then set it how they need it.

Also, its an optimization, meaning less processing happening behind the scene because collision is not being set each frame anymore.


OHHHHH yeah when i make stuff like that it does hit the ground or float or like has a seizure and stuff now i understand thanks


oh, this is interesting considering all the ragdoll use that has been going on lately