In the coming weeks, the Default mode on PhysicsSteppingMethod property on Workspace will be set to Adaptive.
Adaptive Timestepping allows better physics performance by stepping using larger timesteps when possible. For more information, visit our documentation.
With this change, physics simulations may behave differently in some cases, so we encourage everyone to test their experiences with PhysicsSteppingMethod.Adaptive first.
If you wish to opt-out, you can always use the Fixed option to keep everything the way it was. However, as we continue to update this feature and other components within our engine, the âFixedâ option is subject to being removed in the future. We recommend moving away from deprecated APIs that may not work well with Adaptive Timestepping.
Please note, if your experience heavily relies on legacy BodyPosition instances, the system will default those bodies into 240hz mode. This is an unfortunate decision we had to make since legacy BodyMovers are generally unstable under lower frequencies. It is strongly encouraged that you migrate these Instances to the new AlignPosition constraints to benefit from Adaptive Timestepping.
Please let us know if you have any questions or concerns.
Maybe now would be a good time to consider giving AlignPosition control over independent axis like BodyPosition has? using MaxForce with 0 on one axis for example made it unable to push in that direction and let other physics constraints act on it, AlignPosition has no such feature even after years of its release and BodyPositions deprecation.
Constraints seem powerful by the ones who have existing physics knowledge already, but for someone who doesnât have prior knowledge itâs very hard to make the switch.
Would appreciate it if VectorVelocity didnt cause the physics replication to go to sleep. Itâs been very annoying to have to build all kinds of manual replication methods and hacks to force the physics engine to stay awake when dealing with vector velocity related issues. VectorForce does not have issues relating to this, neither do a lot of the other constraints. Would appear VectorVelocity is one of the only ones facing this issue.
While I appreciate the option to offer up a more limited version of the Physics Stepping Method, using the Adaptive mode in physics heavy games simply wonât work.
The first issue is speed. If you have a lot of objects moving around (say more than +100 for example), the physics engine basically seizes up and all objects are just stuck floating in the air.
The second issue is the player physics. Any player that runs into another object ends up getting flung off in some weird bug that sends the player tumbling sideways for a few seconds until the game engine finally catches up and fixes it. Players canât push open a door for example because if they run into it, they might be sent high in the air or crashed into the ground like they just fell 10,000 studs with Jupiter gravity.
So if the default is Adaptive and it works for your game, then more power to you. But the fixed mode needs to stay forever for those of us using very heavy physics games that depend on the precision and speed of the server to avoid physics seizes or player movement bugs.
Iâve never submitted any bug reports about the Adaptive mode because I just chalked to âlimited by designâ for those games that donât depend heavily on this. It makes sense. But the rest of us, the âFixedâ mode needs to stay and talks about removing it are just silly as it would break a lot of games. Actually, it will break a lot of games when it becomes the default because most donât even know they need until it stops working.
I cant use this. Some Airport People Movers has been tested under adaptive timestepping and it cant handle it due to its interesting behaviour of root priority abuse.
It flings whenever it tries to change physics setting. This will probably break a lot of other of my CFrame based mover systems which rely on a deterministic root part, Iâve noticed under adaptive, the root part mysteriously changes for no reason
Please stop trying to push one system over the other, this is an approach Iâve seen Roblox take with quite a few features and its detremental to game development. Is âwhy not bothâ too difficult of a workflow for you guys?
Or just⌠not change it? Adaptive is a pain for most of my games and it literally has broken a lot of them. It is nowhere close to good enough to even be usable in the cases I have. The character has a lot of problems just existing with this mode on.
I have tried to use adaptive, but it just ends out horribly every single time. Please, have fixed still be available for games that canât use adaptive
Best news iâve received today. Impressive, very nice.
By the way I already use the new constraints (mostly AlignPosition/Orientation and LinearVelocity) but iâm limited to what I can do with them because of this issue.
Found a major issue with this as well; using an FPS unlocker makes the stepping visible to your characterâs physics. I think that character physics stepping should automatically adjust to your framerate. This just looks ugly with FPS unlockers set higher than 60. I have to use an FPS unlocker due to Roblox eating my very fast inputs. My PC uses a 120Hz monitor, so itâs really needed for this.
Iâm unsure of the exact cause, from my own testing it looks like the root part gets changed when the assembly gets anchored (which is fine, i expect this to happen), its when the model gets unanchored, it doesnât respect the fact that the root part needs to move back to where i want it
This works fine in 240hz fixed physics, so its an issue with adaptive timestepping.
I donât think this change is a good idea. the Adaptive mode is still extremely broken. When 2 players walk into eachother they get flung, when you walk into a wall the whole camera and player shake like crazy, assets fling around like crazy, it breaks when thereâs too many assets, players get flung like crazy. The Fixed mode must stay permamently especially for games that heavily rely on the physics.
That is true along with other major issues. Roblox should really just keep both if they admit that there are differences in how physics is going to react. Just keep the option as something optional.
There is no bug being fixed with this, so itâs no big issue to allow developers to keep the option. Having it as default is one thing, but removing fixed is a no go.
Hey realOmlet, thanks for the feedback. We wonât be getting rid of the capability to simulate everything at âhigh-resâ physics. If we decide to remove the âFixedâ option, we will make sure whatever it gets replaced with can provide similar simulation quality to âFixedâ.
Iâm also interested in the issues you mentioned; it would be great to get a repro so we can make the system more reliable.
That is a good thing that you are considering keeping something similar to the quality of fixed. I do hope that the character physics get fixed as the characters I use always start freaking out when there is a slight angle when moving at a wall. I use custom characters for my game, but this still happens with R6 and R15.
