Seeing others having similar complaints regarding acceleration, it’s a hard thing to get right. Take your time and work out the issues while its still in beta, very excited to use this.
EDIT: Acceleration seems to be running the same de-acceleration without regard to the current velocity even when lightly tapping W, cancelling momentum in a way that feels awkward and rigid. This reply put it very well: New Humanoid Physics Controller - Beta - #82 by JoyfulFlowerMary
Is it possible to make quake or counter strike like bunnyhop movement?
This update sounds cool, however it will break obbies, which makes this update really terrible. That’s how I think about this update, because that is the main type of games that I make
Thank you everyone that’s provided feedback so far! It’s very important to us to fit everyone’s needs, and everything from tiny nit-picky tweaks to fundamental changes will be considered.
For those that are excited but haven’t given it a shot yet, I want to encourage you to do so! I believe that by spending some time you can really get a totally unique movement style that can be really satisfying to play with.
Remember, this will eventually replace the existing controller, so the more feedback we can get now to fix things the better.
I’m now going to reply to all the feedback, questions, and requests so far. Some questions were asked by several developers, so I paraphrased them and tagged those that asked. If it looks like I skipped your question, it may be because it’s already answered by someone else or in the main post! Or if it seems like I may have skipped it by mistake or misunderstood, feel free to ask again. I may also reach out to some of you directly to get more details on a specific bug.
The performance should be about the same.
Another key difference with the new controller is that the underlying systems are the same as our Constraint system. That means in our physics step, there’s no longer a separate “Humanoid simulation” and an “everything else simulation”. So, as we make general performance improvements to our physics simulation, they will also impact the controllers.
Yes we are looking into this. Due to what I mentioned above, any general solution we have to simulation security will also apply the the controllers.
Short answer: yes. More news on this coming very soon.
Our first goal is to get this new controller to fully recreate our existing movement behavior. Once that’s done, we absolutely will start adding to the Controller instances to enable additional movement options (and if needed, add entirely new types).
The best way to give feedback on this now, would be to try and achieve the movement you want with what’s available now, then request a particular thing you want to adjust once you get stuck. I totally expect that there are ways to tune the current controller suite to achieve various vehicle-like movement.
Hover: I expect you should be able to use the GroundController to configure this. You can adjust the “GroundOffset” property in real time to adjust how far off the ground you are. We also plan to have other properties that will allow you to adjust how fast/how much force is used to tune how quickly that changes. (StandForce/StandSpeed may do this now, but aren’t working how we want right now and thus are hidden in the Explorer)
Flying: Yes, I’m thinking we can get the AirController to a place where you can comfortably enable full 3D movement through air with it, like swimming.
Climbing side-to-side: Yes, will also be adding this
Yep also agreed, I have mostly the same answer to your post as I do for above. Fixing things like Spacebar not working, and orientation glitches, the diagonal movement are the first priority. Then, we can start exploring how this controller can be made more flexible (control up/down speed separately, etc)
This is also planned! The current thinking is to start, we will add an UpDirection property. Right now it’s always set to (0,1,0).
No, we are using the same floor/ladder detection as before. However, we are working on moving this to its own customizable system.
No, since moving parts this way has no velocity, there’s no momentum to conserve. There’s 2 ways to address this:
Agreed, I’m going to rethink how to handle jumping. Expect this API/Property to change.
Ah! That shouldn’t happen. Will fix.
I’m going to reach out about some of the bugs in your post. I want to explain this one here though:
This is happening because the MaxForce allowed for movement during FreeFall (AirController) is greater than gravity. So you can fix this by lowering the AirController.MoveMaxForce, and we probably want a lower default value for this.
Going to reach out for more info on the rest of your post, but wanted give some general tips on FallingDown and keeping upright
Right now, the FallingDown state is triggered when your character tilts past a certain angle (this will become customizable in the future)
With the new Controllers however, you can tune the “AlignTorque” and “AlignSpeed” on the GroundController that’s used to keep you upright. Right now, it’s a bit lower by default than before. This is so behaviors like getting smacked in the face with a beam look a bit more realistic. But you can adjust this so that you wobble around as much as you choose.
You can also use enable RigidityEnabled to really force you upright. The behavior of this should be identical to an AlignOrientation. You may notice that the “GettingUpController” (which is also a GroundController) has RigidityEnabled. This is so you always can get back up on your feet! But you can also disable this, forcing you to get up much slower if you choose.
Thanks for the feedback here. We will take the time to get it right, and I may reach out for more input later.
Feature request
We should be able to disable the “velocity inheritance” feature of avatars. Use case : we want to cancel all forward momentum if a player jumps while on a moving platform, since it “feels” better in the context of platformer games. This is pretty standard in a lot of platformer games, even mario games. Here’s an example of this in action in the game “a hat in time” :
While velocity inheritance may be desirable in some games, it is often not desirable in platformers, and as such, we need the ability to toggle this behavior (bonus points for letting us control this granularly).
I really like the new character controller.
It would be great to see a variable for the walk force of the player. Being able to choose if our characters can push heavy blocks or not without changing said parts weights would be amazing.
I would personally like to set this to a realistic value, and I think other developers will find this useful for pushing things that should have a ton of momentum or making it not possible to push their lightweight a-chassis cars.
Feature request
There should be an option to decouple lateral movement & rotational movement while in the air. Doing this would allow us to make lateral air movement keep the relative momentum of the moving platform we jumped off of! Right now, when a movement key is pressed while in the air, the player’s existing momentum is fully cancelled when they let go of the movement key, unless CancelAirMomentum is false on the AirController. However, setting it to false applies to both lateral & rotational movement! If I want to move forward then stop relative to the moving platform I jumped off of, my rotation isn’t cancelled either! I want to be able to have my rotation behave with its momentum being cancelled when I let go of a movement key (as if I were on the ground), while having my lateral movement keep its momentum relative to the platform I jumped off of, e.g. I press W, move forward a bit relative to platform, I let go of W, my original momentum before I pressed the movement key is restored (instead of zeroing out).
Here’s a demonstration of AirController having CancelAirMomentum set to true. Observe how all my existing momentum is cancelled as soon as I let go of a movement key:
Here’s a demonstration of AirController having CancelAirMomentum set to false. Observe how my lateral movement and rotational movement are coupled, preventing me from getting the relative lateral movement I want while making rotational momentum get cancelled when I let go of a movement key:
It looks like I’ll be spending a chunk of the weekend seeing how the update works with a fork of EgoMoose’s wallstick controller.
Any idea how soon this might happen? I use Wallstick because I have a game where gravity may be in an aribitrary direction, and I need moving inertial reference frames to be respected. I set workspace gravity to 0 and have a vector force on every assembly that is not anchored.
I have had to use the complex workarounds required by the Wallstick controller because I need
If I know UpDirection is coming soon, there isn’t much sense in updating WallStick right now because this new amazing wonderful update solves my first two problems.
So more flexible climb detection is exactly what I need to retire allmost all of what Wallstick needs to do now. I would only need it to fix the camera to work with a custom upvector, unless roblox is going to fix the camera controller and the relative movement input direction as well.
If you are unware, Wallstick works by running a script on the client physics update, making a clone of all blocks near the player, and re-orienting them to the local UpVector into an invisible “Physics World” with a copy of the player humanoid oriented foot-toward-down, so the built in blackbox character movement code responds to things like ladders oriented to the local UpVector and triggers the appropriate control and character state responses. That character model response is replicated back to the visible world the player sees. That’s all on the client. Optionally, that movement is also replicated to the server, then to all the other clients, so other players can see the correctly oriented character models.
I would love to do NONE of that.
Right now I can finally override the vector forces that go the wrong direction and drag forces that should not be happening in a vacuum. Setting the UpVector would mean so much.
Even if I need to adjust the character movement walking on moving surfaces somewhat, I can do that without the cloned Physics World concept.
I still need the character to respond correctly to stairs and ladders. Is that at all possible, or will I still be using WallStick for the foreseeable future?
It’s a beta, and won’t appear ingame until the update is fully released.
Will this make constraints on the character less broken? Trying to say, make a physics fishing rod has always lead to extreme instability.
When walking ontop of a unanchored car, (specifically the free police car by roblox in the toolbox), you can end up sliding off and not being able to move in the meantime, might be related to network ownership.
repro - press play and walk around on the front of the car.
b.rbxl (408.9 KB)
The player still clips on any slopes even at default speed or even higher.
(Happens on any material, not just ice which is slippery, this happens on older controller too, and new too.)
Place file if needed
ice phys.rbxl (42.9 KB)
R15 too.
There does seem to be a few replication bugs, but since this is an early beta i hope it’ll be fixed.
Refer to this post
https://devforum.roblox.com/t/new-buggy-roblox-walking-physics/2003213/3
Are you aware of the obby community, wall hops, ladder flicks, and long jumps? They have been patched by this beta. Could you please at least give us a script that is more efficient than current patches such as this?
Or will this be resolved in the customisation that you have mentioned?
We’re definitely aware that there’s obbies built around every bug and edge case in the legacy pid-based Humanoid controller. 
Part of our motivation of putting this out in Beta now, even with some known issues, is to start discovering all of these interesting edge cases. We really don’t want to break games if we can avoid it. We spend a lot of time thinking about compatibility. It’s something I and the rest of the team care a lot about. Screaming “don’t break games!” at people is one of my core job responsibilities.
Our goal is to make the behavior as close as possible to the legacy Humanoid by default, given some intentional changes like more linear acceleration curves and conserving momentum by default. We want to investigate and understand every single behavior change, understand in depth why it behaves differently, and make sure it’s not a regression.
Still the new controller can’t be expected to be perfectly bug-for-bug compatible. We might not want to reproduce all behaviors, like some cases of flinging, as built-in functionality at all depending on what exactly causes them.
We do plan to remove the legacy Humanoid controller eventually and replace it with this, but that’s at least months, or even a year out easily. It will take time to refine, polish, and gracefully voluntarily migrate as many games as possible.
Repros (automated if possible) will help us minimize the differences and provide better workarounds, but we do need help. Some of these obby tricks are insanely hard to reproduce consistently on our own.
Any chance of these physics being manually stepped forwards or backwards in the future and opening up that whole side of things to the player? It could help with implementing rollback networking solutions, without having to make your own deterministic physics.
Edit
I found the cause, which is still a bug. Basically, this made players way more fragile and they can fling very easily, but the major thing that causes this are constraints. Using forces or velocities on characters makes them way too likely to fling by even just jumping a little. Also, I found a few other bugs, like flinging if you glitch inside a part even a little, interacting with ragdolls owned by the server, and your character being treated like a part if you use a rope constraint.
I found a lot of bugs that basically render most of my code useless.
Ever since I enabled this feature, I was amazed at all of these changes, and I wanted to implement them into my game asap since I’m currently working on the movement controls. However, I started noticing a lot of bugs. For example, sometimes I get flung whenever I land from a tall height (the taller the more likely it happens) and go to the “breaking point” of Roblox. This also happens if I set my humanoid state type to physics after falling. This is game-breaking, because a lot of my features use the humanoid state types and the physics state in order to use ragdolls.
Example of a bug I get every single time:
With the character controller enabled
With the character controller disabled aka intended behavior
The only thing that I’m doing is anchoring the humanoid root part locally, and playing an animation.
Sorry for the inconvenience, if I did anything wrong please let me know.
When this first came out, I loved it. Was able to stand in the train in my game when there were no seats available without all the glitchy jumpy stuff. But now I get flung all over my map and/or knocked over trying to do anything. Wont even let me go up any stairs anymore. Had to remove it. Excited to see what becomes of this in the future, but for now I can no longer test my game in studio with it.
Flinging seems to be a big issue with this beta. Just walking over a few unanchored parts can send you absolutely flying…
yes it is, theres games like bhop and theres a open source bhopping script.