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
Is there an ETA for release? I’m heavily looking forward to this change.
It’s quite involved and would take a while to fully explain, essentially you use raycasts for collisions and gravity, lerping the CFrame of the entity forward towards wherever it’s going using distance = velocity (walk speed) * time. I’ll PM you a few helpful links I found when I researched it on the forums. If enough people are interested (PM me please and don’t clutter this thread) and I can find the time, I’ll make a tutorial.
Something to note: Custom humanoids are only useful when you need better performance and more control over your entities, as expensive states like swimming and climbing can be disabled. If humanoids continue to be better optimized for 100s of players per server and more, custom humanoid implementations may no longer be needed.
The intention is to eventually remove this setting after any issues are addressed and the default is set to Enabled. This will likely not be a quick process, but we will be watching to see if there are many games that intentionally disable this feature and try to address any concerns they may have to allow them to switch over to the new behavior. This will help keep the interface and code base cleaner.
The option to enable this feature should now appear in Studio for all developers.
For all existing and new places, the value will be set to default. Currently, default will leave the feature disabled, but in the future, we will be switching to enabled once we verify that there are no problems and that is will work for the majority of places.
Fantastic! This has been a bugbear of mine for a long while that made no sense to me.
Thanks for finally fixing this.
There is a warning relating to this that is plaguing our game’s server output.
What can we do about this?
Do you have a reproduce case that I can take a look at? Ideally a simple place file that causes this error?
What triggers that warning? Would be more than happy to create a simple repro if I knew more about what it’s trying to communicate. If the warning could be adjusted to show the instance path name and maybe a stack trace that would help significantly.
It appears that a modification to a Humanoid is being done to a Humanoid that is not parented to workspace. Possibly, this is something that is changing or removing parts to an R15.
I have a few ideas of what might be causing it and how to fix it, but I would love to verify it against your instance of this to ensure that the fix will solve the problem.
Issue a player of my game reported upon me enabling this setting. Player spawned in, new character created, teleported, fell into the smooth terrain and started moving around very quickly before being flung into the sky.
This has never happened before I enabled the setting. May be related to this setting, possibly not.
The reported warning should now be fixed for all servers that are newly started.
So is this still happening? And I have a question that is this improving the avatar collision?
This should be available currently. The default it still to use the old, every frame behavior, but hopefully that will be changing soon.
This change doesn’t modify the collision other than to help improve performance by not calling the code that sets the collision for the body party each frame. With this feature enabled, the Humanoid will only attempt to set the collision values of the body parts when the Humanoid changes state (ie for example, from Running to Jumping).
Thank you for this information
Sorry for the bump. But this was really helpful for my blood system having dismemberment I won’t have to finally rely on hacky stepped methods of turning the collisions back on just for the limb. And I won’t have to use collision groups.
Instantly set this to Enabled I called BreakJoints on my player’s left arm and boom! It collided with everything and doesn’t just fall into the void.
Thank you @CodeWriter for announcing this feature!
Hello,
The Default
behavior for this option has been equal to Enabled
since March of this year. Opt-in has been available since last August. Developers have had a year make any necessary fixes.
Next Thursday (8/3), we will remove the option, forcing all experiences to the Enabled
state.