Climbing MOVING ladders, now that is revolutionary, we are in the future.
Trying to insert the ControllerManager to a Humanoid at runtime will not work as expected.
With respect to this, can we get more information about why / what’s happening in the background here? I have custom characters that I build at runtime and allow the player to choose them at will during gameplay. These are defined via a metadata folder that contains all of the setup information, models, etc. Can I define the controllers and set up the properties in Studio and then later at runtime, copy this tree of controller instances into the humanoid in the character before I assign Player.Character without any problems?
How does performance of these new controllers compare to current humanoid performance? Is it faster, slower and how come? Can we expect further performance improvements?
This is really cool, when I seen the climbing gif on the rotating object that honestly made me excited, that said I am not sure what itv was like before, but this will help a lot if before it was more rough. Definitely something my future game could benefit from… if I ever can start
Yes this particular workflow is more or less temporary while we are in a stage of carefully recreating the old controller with the new instances. It should only get more flexible from here.
If you define the Controllers with the same names/types as shown above and put them on the Humanoid as you insert it, things should still work out fine. You could also do this to initialize an NPC with the new controllers.
Wow, I am loving these rapid-fire announcements today lol
Many much-needed, much-appreciated features, especially THIS. Been waiting for the new humanoid physics controllers for a while now
TYSM roblox, I was planning on making a platformer soon
Today is an amazing day, Roblox is finally bringing so many wanted updates! I really love how it generally feels
Here’s some issues I’ve noticed:
Falling animation doesn’t exist, instead the last played animation is looped when falling
Walking up stairs is very bumpy
Landing sometimes has some janky physics, pushing the player in random directions/rotations at high speeds and the player is EXTREMELY fragile to the point that landing from a fall the size of 2 players puts you into that PlatformStand mode
Dying just PlatformStands you instead of making you fall into pieces/ragdoll (honestly hoping that there could be a basic Active Ragdoll type thing that blends in with various animations like flailing and staggering to increase immersion and to compete with AAA game ragdolls)
As said before, the player is extremely “fragile”; basic actions like jumping under a rotated part can PlatformStand you, sometimes even flinging you to the distortion point.
Jumping at a wall can make you “glued” to the wall in midair and fling you to the distortion point.
I love to see improvements made to core parts of the engine. I hope the testing stages go well and we can see this new tech live as soon as possible.
Conservation of momentum when jumping is probably my favourite thing added here! I can’t tell you how many times I’ve been on a moving object only to jump and be yeeted into the void.
One thing missing that I would like to tweak is the speed of the character rising/falling when swimming. I do not want the character to automatically swim upwards the majority of the time I have significant water areas.
Also if you toggle rigidity enabled on the swim controller, you break the character self-righting itself, but I guess this is the same reason why we shouldn’t modify the controller at runtime lol.
Another thing to note is that after inserting the controller manager and letting the defaults fill, jumping is broken, at least for my character. There does not seem to be enough force and I cannot find the setting for it.
In the video you can see that changing directions shifts the character slightly which doesn’t feel great. At the end it doesn’t shift the character, it seems to depend on the direction you are going.
It would be awesome if the new character controller supported a rotated HumanoidRootPart. It’s currently impossible to use an upright cylinder because it’s not the default rotation.
I love this update a lot and will definitely be experimenting with it. I only have one issue with it; you cannot use JumpHeight with the controllers when I tested it. That’s something I use on all humanoids
To clarify, modifying the Controller properties is totally ok and expected! I was referring to trying to insert/remove the instances themselves. It sounds like this may be a bug!
As per your request, are you saying you’d like to customize the swimming move speed for up/down separately from forward/back?
Thanks for the video of the movement shifting, I’ll look into it.
As for the cylinder rotation issue, this is definitely something we want to support. You should be able to customize what you want your up and forward axes are.
I forgot to mention this! Several Humanoid properties have moved over to specific controllers and currently we do not write one to the other.
Jumping is tuned by setting the VectorForce property on the JumpController. Yes this means you can also add an X and Z dimension to your jump! (note this is probably going to get renamed as well)
HipHeight is also now defined on the GroundControllers as a GroundOffset property.
WalkSpeed is split between the ControllerManager.BaseMoveSpeed, and the MoveSpeedFactor property found on each controller. (final speed is BaseMoveSpeed * MoveSpeedFactor)
These should be getting set correctly if you’re inserting a ControllerManager via the StarterHumaonoid workflow mentioned in the post. Otherwise, you’ll need to set these manually if you want to change them at runtime.
Extremely excited to see component humanoids are still happening, and even nicer to see it implemented in a seemingly more straightforward and understandable way compared to the old setup shown a couple years back!
However, I do have one concern. I don’t see any mention of fully scriptable custom base controllers. Without this, the dream of component humanoids simply does not exist. No matter how many base controllers get released, there will always be some idea that requires a controller that Roblox will not be able to anticipate. If developers were to have the ability to write up new controllers from scratch, then the possibilities would be endless. Being able to control when and how custom states occur happen would mean we can write out virtually any scenario we want for our players to go through. I think the customizable properties on the default controllers are beneficial and should be explored but if that’s the extent of our ability to customize the humanoid system then we’re not far enough from the current implementation, developers will continue scrapping humanoids in favor of their own systems (with potential clunky interfacing between the base controllers), and there would need to be a whole new revamp to fix that issue.
Since it’s only the first step I might be a bit paranoid and full customization is the intention for humanoid componentization, but I want to leave this here just so there’s a clear understanding of the problems these updates intend to solve.
my jump power is set to 13, by default the JumpController (auto created) is set to 50 and changing jump power does nothing unless you set it to 0. To somewhat match the jump power, I have to set the JumpController to 3
Specifically, when you do not touch the controls and you are underwater, the character will slowly swim back to the surface. I do not want this the majority of the time.
Is there a way to not use a VectorForce but use a height/offset like how JumpHeight uses? I never use forces for jumping because I like having jump height consistent with different gravity values. Will this be added as an option?
Yes this will be added. For now you should be able to still set your JumpHeight on the Humanoid, and obtain the computed JumpPower value. Then set this as the VectorForce.Y value.
