You could just use collision groups
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.
You can achieve this exact behavior by doing exactly what CodeWriter describes in their first reply to you. Did you actually try it?
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.
You can instead change the CanCollide property on the client on RunService.Stepped to get the same effect.
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.
You can just make the floor a collideable object in the collision group
Won’t work. Some things that need to act as a floor should also be able to clipped through depending on where the player is (For instance, the second floor of a house).
Also, adding collision groups to all the parts in the Workspace would be a pain.
That wouldn’t work for me, in my case, my game is incapable of knowing what the “floor” may be because it is a sandbox building game where the players can create their own worlds, which others may then explore. This would probably be possible if the game’s world weren’t so dynamic but it is in no way a solution, whereas the first solution showed was already proven to have the effects I desired and I plan to try it out.
Yeah, agreed! This is what I was wanting to see with my code. Thanks for the help!
You could probably get around this issue by raycasting to find the current floor
Why go to this length when there is already a far simpler solution? besides, that doesn’t sound very performant (not the raycast part, but the part where it would have to be constantly changing the collision groups of parts).