As part of our ongoing efforts to improve Humanoid performance, we are deprecating the HumanoidStateType.RunningNoPhysics state in a few weeks:
The Humanoid will not change to this state automatically
Any attempt to set the Humanoid to this state will result in it being in the Running state instead
This is necessary as part of the effort to allow Humanoid updates to be processed in parallel using the multiple cores and threads of modern computer hardware.
RunningNoPhysics vs Running States
Currently, the RunningNoPhysics state is intended to be equivalent to the Running state and is used when the character is on the ground (either running or standing). The Humanoid automatically switches between these two states while on the ground based on proximity of other physically simulated objects to the character.
When the character is near other objects or when it has recently entered the grounded state, like landing after a fall or a jump, the Humanoid will start in the Running state. If the Humanoid then detects that there are no nearby physical objects after a few seconds, it will switch over to the RunningNoPhysics state. Then, when the Humanoid detects an object nearby, it will automatically switch back to Running state to use the more accurate collision detection to handle any possible collisions with these objects.
The RunningNoPhysics is a simplified collision model used to improve performance by not having to perform more expensive collision tests if there are no nearby physical objects. With the addition of our parallel update, though, the improvements in performance due to the use of multiple threads is larger than the savings granted by the RunningNoPhysics state. As a result, when running in the new parallel mode, the Humanoid will not switch into the old RunningNoPhysics state and will remain in the Running state.
Deprecation of RunningNoPhysics
The Enum.HumanoidStateType.RunningNoPhysics enum will remain to prevent scripts and other references from breaking. But if you have scripts that depend on particular RunningNoPhysic state, as opposed to (Running or RunningNoPhysics) , this may cause issues. Please review your scripts if you feel this may be an issue for you.
The switch to change this behavior will not be made immediately, and we will follow up with another post on this thread when this change goes live. The change is likely to take place in the second week of October, pending the results of our final tests.
Will there be any alternative to this? I found the behaviour of it incredibly useful in that it allowed for a noclipping admin command to be made. It’d be very disappointing if there wasn’t.
If you are looking to place your character into a state where it won’t collide with anything, you can enable the Workspace.HumanoidOnlySetCollisionsOnStateChange by setting it to true. Then when the character enters HumanoidStateType.Running, you can set the collide state of all the body to CanCollide to false. I believe this behavior will be close to what you are describing.
Considering this topic is talking about one of the humanoid state types, will there by any chance have a state type for idle humanoids? It would be good to have that since it can simplify animation management for example.
Humanoid states typically are used to differentiate between different controls for the character. While on the ground, the controls and physics behaviors are the same. The Running state really is used to indicate that the character is on the ground. Idle, walking and running are simply variations of this standard grounded state. The controls and physical forces remain the same despite how fast the character may be moving.
Good change, Humanoid performance boost is a big deal with large server games. I’m glad to see how far 100 player servers have come performance wise and I hope to see more updates like this in the future.
I’ve looked at what you mentioned and sadly it doesn’t look like an alternative for me, the game I have a noclip admin command in uses CreatePlaceAsync in order to allow players to create their own worlds that they can build in, and others can then explore, which save and are not limited to a small amount of data. It’s unfortunate that this fact has resulted in me being unable to make use of many of the cool new features that have come out recently which are locked behind non-scriptable properties.
Personally, I’ve always wanted some sort of way to be able to simply set these properties and have them apply across the entirety of my game at once, and I would make a feature request for that myself but devforum members haven’t had any means to do so for quite some time now.
What ever happened to Avatar Components phasing out the humanoid over time? It’s frustrating when you have so much core functionality tied to what’s essentially a black box. We are stuck working around Humanoid default features, such as the loss of momentum midair when keys are released, because unlike the camera component none of this is exposed in Lua. Are there still plans to move towards a Lua based controller/component system as described in the original plan for Avatar Evolution? (Avatar Evolution | Building the future of Roblox avatars and more!) (https://roblox.github.io/avatar-evolution/files/AvatarComponents.pdf)
If you meant animation priority management, there is an announcement for that here:
It says blending fix, but they said there may be custom animation priorities.
By the way, I never understood RunningNoPhysics because my dashing system would not continue the dash all the way when the player presses a key to trigger it. Certainly glad that RunningNoPhysics is deprecated, finally removing it from my code.
Without understanding what your script does, it is hard to suggest alternatives. If you could share how it’s using RunningNoPhysics, it might help better discover what other options might exist.
All my script does is, when a player uses the command to activate noclip, their client will be told by the server to disable every state except for RunningNoPhysics and set the state to it, with this being undone when they deactivate noclip. All I really need is some way to have the humanoid be able to walk through walls whilst still keeping itself on the ground, which is exactly what RunningNoPhysics allowed me to achieve.
As I explained in my original response to what he said, I can’t do that because the property he mentions of workspace is not scriptable, and since it’s a property, I can’t toggle a game-wide setting to enable it. The issue here is that my game is a sandbox building game where players can create their own worlds, to achieve this, I make use of CreatePlaceAsync and SavePlaceAsync because they have no limits to the amount of data that can be saved.
We are still working on a number of features that were present in that original Evolution Plan. We’ve shipped the skinned meshes, the PBR shading, and improved mesh importing tools described there. And we are continuing work on other features as well that we hope to announce in the future.
Our goal is to make Roblox a feature rich and powerful tool that allows developers to create the many varied experiences that they imagine. As part of the evolution towards that goal, we’ve performed many experiments to see what’s possible. And from this particular exploration, we discovered that performance would be very important to the success and growth of our character systems. This change is one part of a set of changes that we are releasing to help everyone have more characters in their games and to make room for new, amazing features.
If I understand correctly, you are saying that you cannot modify the property in places which players have already saved. Is that right?
If so, @PeZsmistic’s second solution should work, which, is an older way of achieving noclip iirc. Additionally, @Elocore suggested using collision groups, which, you should definitely be able to achieve.
I plan on trying pezmistic’s solution, but I am almost certain that elocore’s wouldn’t work because the humanoid still needs to be able to collide with the ground, and using collision groups to prevent the limbs from colliding with everything else in the workspace would very likely cause it to fall through the ground and die upon activation, which is not ideal.
