Could anybody confirm that this actually works? Last time I tired it (in two different games) it did not work at all. You drop to the floor as if you have no legs. Other people had the same issue!
1 Like
Works with r15 if i remember so far
So R6 was abandoned once more?
Will this support Root Motion?
1 Like
The character physics controller suite is released!!
It’s been a long journey, and it’s still only the beginning of our Avatar improvements. Thanks everyone for your testing and feedback, I’m glad we were able to collaborate so much.
As mentioned in a previous reply, remember that in our released version the “Parent ControllerManager to Humanoid” behavior is gone. All configuration and initialization needs to be done manually via Lua scripts. This was to ensure developers have as much control as possible and we avoid adding more hard-coded character logic.
The post linked above should provide enough info to get started with this new version! And of course we’ll continue to receive your feedback in that thread.
@AirtonGamer_Ytpro Will this support Root Motion?
yes, more info coming soon
11 Likes
for me the bug where the humanoid cant stand up still happens only in studio now and r15 also doesn’t work
1 Like
and im not even using the controler manager and this isn’t even a published place at the top left it says “baseplate” which isn’t a place
1 Like
its randomly back for some reason
dudes racing against the clock /j
what happens when you try -1 turn speed if you can?
For anyone wondering if their R6 rig is broken with new controller.
Found solution:
Make a script that will wait infinitely for ControllerManager.RootPart to not be Nil
then
ControllerManager.RootPart = nil
ControllerManager.RootPart = yourRig.PrimaryPart (yes setting it again)
this worked for me
2 Likes
Hope you are well. I’m currently facing some pretty noticeable issues with this humanoid controller when used for much more specialised purposes moving from my custom controller forked off @dthecoolest 's system to this new controller. The rig for my studio does not strictly obey the r15 schema and larger than the typical r15 rig (translates to around 6ft in the real world)
+ Whenever bumping hard into a surface it flings you out the map displacing you to a point of floating point errors as shown in the video. this is a major issue that has stalled my entire project, which as a solo developer is a critical setback. The main reason for moving was the very fact that I have to worry less on constant updates to the system. I would greatly appreciate any insights on how to resolve this issue.
To address this challenge, I’ve made the following attempts:
- Adjusted the root priority for the root part.
- Set relevant parts to be massless.
- Experimented with the parameters of BasePart.CustomPhysicalProperties for both the map and character. Unfortunately, these efforts have not yielded a solution, although there may be an error on my part.
- @dthecoolest 's implementation of the hip height offered a great approach to a ground offset equivalent that paved a way for seamless smooth walking in my game. The lack of discrete options for this controller however has hindered the migration, as increasing the hip height results in undesirable oscillations. I strongly believe that providing even more deeper granular control over this controller should be considered. The limited options have necessitated extensive adjustments so far to fundamental mechanics, such as dashing, vaulting, and sliding. This limitation appears to affect users with specific requirements, especially those working with large characters.
4 Likes
This Is pretty neat. Something I would really Love to see is a extension of the Rig builder in the Game settings with features similar to MakeHuman or other softwares that allow you to shape and customise your rigs without having to go into blender to achieve something like this. This would allow better looking avatars that people can change and warp to their liking. This feature would allow for a lot more control over the avatars which so far in my opinion is one of the biggest issues visually with roblox. I would have to say this is a pretty cool update.
When the ControllerManager starts with a BaseMoveSpeed of 0 and you change it to a number higher and then change it back to 0, it doesn’t stop. When you increase the number above the current speed, it speeds up but you can never stop it, even if you change the MovingDirection to (0, 0, 0). Has anyone else ran into this problem? I’m assuming it’s a bug unless I’m missing something. This seems to only occur when the BaseMoveSpeed starts at 0. Why wouldn’t you want it to start at 0 until the player uses inputs? This seems like the most used case.
Another player looks to have had problems with it also on June 3rd.
My entire game revolves around using this and it would be awesome to be able to start with a BaseMoveSpeed of 0.
Here’s a video
Here’s the place file
ControllerManagerPlace.rbxl (55.9 KB)
yes, i’ve been dealing with this issue too and i filed a bug report for it a few days ago
1 Like
Thanks, yea this looks like a bug and we can get it fixed. You should be able to work around by just preventing a non-zero MoveDirection at start instead?
2 Likes
Is there a way to accurately calculate JumpPower for the JumpImpulse attribute? Because currently, whenever the jumpimpulse is (for example) set to 100 on the average sized character, it jumps realistically (like 5 studs in the air), but if the character is small, it’ll jump higher like 20 studs in the air. Apply impulse doesnt seem to account mass.
1 Like
there is a robloxsecurity locked method for converting jump height to power and back in workspace, i would’ve created a feature request for it to be accessible to scripts but i don’t have permission to
Is there a way to accurately calculate JumpPower for the JumpImpulse attribute?
Here’s a fairly accurate way:
local METER_IN_STUDS = 1 / 0.28
local rootPart = controllerManager.RootPart
local jumpHeight = controllerManager:GetAttribute("JumpHeight")
local jumpPower = math.sqrt(2 * rootPart.AssemblyMass * workspace.Gravity * jumpHeight * METER_IN_STUDS)
rootPart:ApplyImpulse(rootPart.CFrame.UpVector * jumpPower)
1 Like
Has anyone found a good way of implementing autojump into this?