Hi
Any update on fixes or the lua release?
Would like to use this, but in it’s current state it’s not really usable…
yup this is pretty much unusable in most of my cases
i’m trying to make an obby but having yourself get flung for absolutely no reason when going up trusses is annoying
NOTICE
This week we will be releasing fixes and stability improvements to the ControllerManager.
One in particular is a fix for GroundController turning. This prevents it from overshooting the FacingDirection at high speeds. In fact, the actual angular velocity was often higher than was defined by ControllerManager.BaseTurnSpeed * GroundController.TurnSpeedFactor defaults. This lead to turning faster with a GroundController as opposed to the AirController despite the same settings. Now, turn speeds should be consistent for both.
As a result, the GroundController turn speeds may appear slower than before. You can compensate for this by increasing the TurnSpeedFactor on the Controller or BaseTurnSpeed.
4 Likes
very cool roblox
(character limit)
Is there a way to keep the RootPart from rotating indefinity without needing to use AlignOrientation? Currently when the offset is high and the object is floating, the part basically rotates left and right many times, and doesn’t get to face the right direction. Why is this? It should automatically just face the direction properly. (Not sure if this fix getting released fixes this)
I am using ControllerManager, GroundSensor, and GroundPartController with their default properties, except that the RootPart is just by itself, is big 200 each axis, and has an offset that creates this levitating effect that I need, and the SearchDistance is high as well to account for the GroundOffset.
If is to be expected that it will never get to face the direction fast enough and properly without going forward and then back again, should I just use the AlignOrientation?
1 Like
So, I’ve been messing around with this for a long time. I like my current result but am sort of at a stopping point as I prefer Gravity being lower for more real-world-like physics. However, it seems that messing with gravity messes with the friction or something so my character slides around and rotation overshoots even more than before. In a way, it makes sense but it’s annoying.
Is this intentional? If so, how can I avoid this sliding?
Increase the Friction and FrictionWeight properties on the GroundController
Thanks!
It seems to work, but it comes with the quirk of moving unanchored parts under the character. I guess that’s because it’s all physics-based, but I think I can come up with a solution for that.
Make the unanchored parts on the floor heavier!
2 Likes
will this feature ever be decoupled from the humanoid? so we don’t have to have a disabled humanoid all the time to render clothing etc?
Added near full support for capsule physics controllers!
Climbing & proper camera offsetting for R15 is still in the works.
Was a little finicky to implement my own root part while maintaining most dependencies of the character. I wonder if there will be easier methods soon to do this.
NOTICE 2
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.
*The default OnRead ControllerPartSensor Ladder behavior may not be ideal for horizontal climbing with cetain ladder types. You may be better off setting up a Manual sensor, maybe via a single Blockcast that matches the height and width of the character model.
10 Likes
Hey there! I’ve been working on my game and I’m interested in creating my own humanoids. But you mention an official Lua implementation coming some time. Any chance you could give an ETA on when that might drop? I’m debating whether to make my own now or hold off for the official release. Thanks
Setting up manual sensors and checking for geometry ourselves by casting shapes brings some limitations because we can only perform these checks once every rendered frame. In contrast, the native Humanoid code under the hood runs in sync with the physics simulation, if I’m not mistaken. This means at 60 FPS Humanoids internally are performing these checks 4 times as fast as we’re able to perform them ourselves manually, since 4 worldsteps are advanced per frame in order for the simulation to maintain its target rate of 240 Hz.
Is there any plan to allow us to tap into the physics simulation update event in the future? This would be really useful for cases where we would want to develop character controllers with a higher degree of fidelity. It would also be useful for a bunch of other cases, like custom physics stuff.
2 Likes
While the Humanoid/ControllerManager physics calculations doe run at a higher frequency, the sensors have never run at that rate. The Humanoid has always been updating physics based on sensor data updating at only 60hz. So you shouldn’t be actually loosing anything under this new system.
However, we do understand there’s a need to run lua code at the simulation frequency for various controller systems. I don’t have anything to share right now but it is something we are aware of and talking about.
4 Likes
I don’t have an ETA on the lua implementation right now, sorry.
I’ve noticed that when using an FPS unlocker with the physics controllers (in a non-humanoid character, what I have tested), that the sent KB/s go up by a lot, as opposed to humanoids. Is there a way to rate-limit this? Would I have to rate-limit it from the client? Any chance we will be seeing bigger performance increases when using the controllers solely, without humanoids? Thanks!
2 Likes
I hope this is a bug.
Depending on how close your Rig is to the ground via animations; setting Motor6D Cframes in a run service loop will cause the character physics to spaz out.
Edit:
Any Motor6D attached to the Character, having its CFrame Properties set consistently, causes the Character to spaz/fling.
finally, i was trying to implement this myself but my character kept getting positioned to NaN when going up a right angle which softlocks the controller manager for some reason