Currently the character instantly snaps to the new floor height. This is OK for regular roblox characters in most cases, but it’s not good enough for more realistic cases (i.e. skinned mesh quadruped characters). The issue is most noticeable when trying to climb slopes of terrain. Instant snapping just doesn’t look good.
From what I can see there’s no simple method to smoothen the floor height alignment of the character. Will this be added in the future?
In the docs there’s a ‘StandForce’: GroundController | Documentation - Roblox Creator Hub
Unfortunately it’s not accessible yet. If this is the max vertical force to be applied for floor alignment, then my issue would be fixed.
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:
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)
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
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.
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.
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.
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…
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.
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.
