This would be handy, but also this would be quite easy to implement using your own VectorForce. Something like a drag force, for example.
I’m interested in trying to implement this now. Would it be like a force moving against the HRP’s lookVector with variable strength?
1 Like
There are lots of ways of doing it. You have the right idea, but using a force against the lookVector wouldn’t work since it only considers the direction the character is facing, not moving.
Instead, the drag force should be facing in the opposite direction of the character’s velocity. Here’s some code with the basic idea:
-- hrp is the character's humanoid root part.
-- dragForce is a VectorForce affecting the hrp.
-- humanoid is the humanoid of the character.
-- Adjust DRAG_COEFFICIENT for desired amount of drag.
-- 0 means no drag, -999 means LOTS of drag!
local DRAG_COEFFICIENT = -1
local function isCharacterInAir()
-- Assumes that the humanoid is acting with the default behaviour.
-- This may not work if the character is using custom physics.
return humanoid.FloorMaterial == Enum.Material.Air
end
RunService.Heartbeat:Connect(function()
-- Apply drag only when the character is in the air.
if isCharacterInAir() then
-- Applying force scaled by mass for consistent acceleration regardless of mass.
dragForce.Force = hrp.Velocity * hrp.AssemblyMass * DRAG_COEFFICIENT
else
dragForce.Force = Vector3.new(0, 0, 0) -- No drag when not in air.
end
end)
This is only a rough mock-up. If you’re using an entirely custom movement system (where you set humanoid.EvaluateStateMachine to false), you might have to make your own method of checking if the character is in the air or not. This will depend on your implementation.
This code scales drag linearly with velocity (Doubling the velocity will double double the drag force, etc.). A more realistic drag force would scale with the square of velocity. Something like:
dragForce.Force = hrp.Velocity * hrp.Velocity.Magnitude * hrp.AssemblyMass * DRAG_COEFFICIENT
Both of the above examples simply apply a drag force in the opposite direction to the movement of the character. This means that it will also slow a character’s fall. If you would only like the dragForce to push the character sideways (and not up and down), you could do the following:
local function getCharacterHorizontalVelocity()
-- Multiply the Y component of the velocity by 0 to ignore it.
return hrp.Velocity * Vector3.new(1, 0, 1)
end
RunService.Heartbeat:Connect(function()
if isCharacterInAir() then
local velocity = getCharacterHorizontalVelocity()
dragForce.Force = velocity * hrp.AssemblyMass * DRAG_COEFFICIENT
else
dragForce.Force = Vector3.new(0, 0, 0)
end
end)
6 Likes
How do I use the new controller on players?? i tried importing the lua scripts and that didn’t work at all it was super buggy and I don’t understand the documentation on how to set up
I think they might be broken, I’ve followed the tutorial on the docs exactly and it just drops to the ground.
1 Like
How to Actually Use Roblox's Physics Character Controllers - #2 by 04robot48 Hello! If anyone’s having trouble setting these up, I made a topic detailing how you can go about doing so. Check it out if you’re interested
1 Like
I find a bug.
When I frequently modify the EvaluateStateMachine property (True → False → True → False → True)in one or more frame(random time), there is a very small probability (one in ten thousand) that an issue occurs where the final state of EvaluateStateMachine remains as True, but the model automatically and indefinitely moves upwards (with Position.Y continuously increasing) without any external force applied.
Is there a way to do pathfinding with a controller manager? Theres no humanoid hooked up to mine, so I don’t know how it would be possible?
1 Like
I love using controller managers on the previous post I read something about UpDirection being added any news on when we will have access to this?
2 Likes
It’s been a year but they are still not fixed
Also, this might be a stupid question, but are these ever going to become the default controller in experiences? It would make physics-based games so much better, because the controller interacts with physics really nicely.
Bug report:
:GetPropertyChangedSignal isn’t firing at all for the “SensedPart” property of the GroundSensor.
The same thing is happening to me. The GroundSensor was working fine as long as the ControllerManager had the GroundController as the active controller, but the moment I manually set the active controller to the AirController, the GroundSensor stopped sensing entirely.
Even more strangely, it begins sensing again the moment I select it in the Explorer.
1 Like
What would achieve the same effect as platformstanding/physics for character controllers?
1 Like
I’m not sure what is happening, but it looks like my client is taking control of other players??
Is there a way to prevent this? Why is this happening? If it has to do with NetworkOwnership, shouldnt the other clients have control over their own client, and why does he keep snapping back?
My game utilizes ragdoll physics and it’s a major component of the game, so I’m not sure if whatever is causing this was causing my ragdolls to be extremely smooth… I’d really appreciate a response, as I’m pretty sure this is also linked to idle players sinking into the ground…
1 Like
hey roblox
any uh
updates on this?
2 Likes
How to fix immortality with this thing?
1 Like
The example scripts seem to be fighting between GroundSensor and the Swimming one. But it gives an interesting insight.
Initially I wanted to report this as a bug, but then I saw the note that it is not supposed to be a re-creation of the default Humanoid, nor maintained.
But I wanted to try some more things out related to Swimming, that I figured out that the default Roblox behavior actually changes the CanCollide Property without even triggering .Changed this similar behavior is found as well when the default character Jumps. 
The work-in-progress LuaCharacterController though is currently enabling the Collision on the Head. The default Humanoid doesn’t enable collisions on the head, not even while in water.
At least it doesn’t have the same issues as the example scripts mentioned here. Well… Unless you Jump. If you jump while in water it has similar issues.
2 Likes
It seems like the AccelerationTime and DecelerationTime properties of the GroundController instance (and likely any other controller instance with the same properties) are affected by your frame rate.
Video showcasing this:
The AccelerationTime and DecelerationTime properties are set to 0.25 and 0.125 respectively, the only thing that I’m doing to move the character is changing the ControllerManager’s MovingDirection property.
I noticed it while playing around with the maximum frame rate setting, which is discouraging to say the least.
Otherwise, I’ve been having a blast with these new physics controllers.
8 Likes
Wait, is ur character fully rigged animated with no humanoid thats welded to like a BEAN which is equipped with the controller
Just out of curiosity.
1 Like
It still has a humanoid for clothing (and animation) but yes it is just welded to a capsule for collisions.
1 Like