This week, we are enabling fixes to the ClimbController, and enabling horizontal climbing capabilities.
This will work by having the ClimbController read localized X and Z dimensions on MovingDirection, and they will be projected onto the climbed surface - just like how the GroundController works now. Previously it only looked at Z. This means if you’re using the example scripts provided in this post (or otherwise copying Humanoid.MoveDirection properties onto the ControllerManager), then horizontal climbing will work automatically. You don’t need to change how input is handled for Climb vs Ground controllers.
If you don’t want horizontal climbing, you’ll need to set MovingDirections such that you move on one axis. One way to do this is to convert MovingDirectoin to the character’s local space, set X to 0, then convert back to world space. You could also take that X component and set on Z, so that left and right inputs still move the character up and down if you want that legacy behavior.
Today, we are releasing a new set of instances designed to make it easier to customize character physics and locomotion.
We have taken the piece of the Humanoid dedicated to physical locomotion (the forces that move your character around) and put it into an isolated set of instances. These instances can be used without a Humanoid, letting you build a custom physical movement system for players, NPCs, or anything else.
These Controller instances also give you more flexibility over the physics of a character than the Humanoid did, while ensuring the Parts in your character follow the same physics laws that every other Part does.
Here are some behaviors that will work with these controller instances that the Humanoid did not do:
- Customize friction with the ground.
- Customize max forces for keeping upright and moving around.
- Conserves momentum when leaving the ground by default.
- Climbing works on moving Parts.
- Customize how floors and ladders are detected.
Set up guide:
Getting Started with a Character Controller
We’re also providing the ability to disable the internal physics and state machine of the Humanoid, so you can implement your own version of them, using these new physics controller instances and your own scripts.
- No forces - The Humanoid will not apply any forces to any of its Parts. The Humanoid will not move the character in any way.
- No sensors - The Humanoid will not run any spatial queries to detect floors, ladders, or other obstacles (such as auto-jump)
- No collision changes - The Humanoid will not alter the collision state of any of the character Parts. By default only the torso and head have CanCollide enabled.
- No state transitions or replication - The Humanoid will not automatically update the Humanoid’s state. HumanoidState can still be set via script, but it will not automatically replicate.
- State events - If manually setting Humanoid States, the Changed and State events will still fire, which means the Animate script will still receive them and animate the character based on its current Humanoid State.
- Appearance - HumanoidDescription, clothes, accessories ad other Humanoid rendering behavior.
- Camera and player scripts - The Humanoid is still linked to Players and camera scripts which ensures the camera will continue to follow the HumanoidRootPart.
Player input handling - The
Humanoid.MoveDirectionproperty will still be updated via the
Movefunction and Player Scripts for input. The example scripts below demonstrate how this property can be used to simplify input handling.
You can add these scripts to you experience to try using an avatar with the new physics controllers
InitializeCharacters.lua (1.5 KB)
This server script should be placed in ServerScriptService.
For every player that joins, it will set
Humanoid.EvaluateStateMachine to false, and insert the necessary physics controller and sensor instances to the character model.
ControllerStateMachine.lua (4.3 KB)
This local script should be placed in StarterPlayer>StarterCharacterScripts.
This will manage swapping between basic Run, Jump, Climb, Freefall, and Swim states. It’s not intended to match exactly how the Humanoid handles these transitions, instead just covers basic input and movement.
These scripts are intended to be an example to work off of. You’re free to modify however you choose, and they will not be maintained or updated over time.
Later, we will have an official implementation in Lua using these instances that is intended to match exactly how the Humanoid handles states and movement today, as well as even more customization options. These example scripts will become obsolete once that’s released.
We also will continue to expand on the capabilities of the Controller instances, such as allowing you to configure the “Up Direction” of the character and horizontal climbing capabilities. We may also continue to tweak the controllers’ behavior as more of our next-generation avatar features are rolled out.
- The speeds from Humanoid state signals are incorrect if standing on moving Parts. This can lead to incorrect animation speeds. We will look into a fix for this, otherwise you are encouraged to also handle animates yourself instead of relying on setting the HumanoidState.
GroundController.AccelerationTime> 0 is can act inconsistently when a character is turning.
ControllerBase.Activewill still show
trueeven when the