If people incist on using it, we can leave it as a legacy option. But when combined with the planned updates to our solver/physics system, running fixed 240hz will be overkill (unless you are making a racing-sim that requires ultra precise physics?) for most games.
To be clear, itâs the âFixedâ option that can go away in the future, not the high-res physics. For example maybe we will add a UltraPrecise
stepping mode that will run at 480~240hz.
Itâs more like, nobody really wants Adaptive to replace fixed as the default setting, and the average ROBLOX developer may or may not know why suddenly their game doesnât work the same as before. Even if all the physics messiness is hashed out, the reliability and relative consistency of Fixed timestep events in code is FAR superior to anything done with Adaptive. On the code side of things, physics is irrelevent when you have scripts that need to simply need update every frame with relative smoothness and you get really bad results and jitter due to inconsistent timestepping on Adaptive. Iâm pretty certain from testing that even the default camera is affected by this, though that was more towards when Adaptive first came out. But I personally think itâs not a good look to enforce new changes that jeopardizes the behavior of runtime events which make up a large portion of systems in almost every game on the platform.
Also, so far I havenât seen any advantages of using Adaptive over Fixed.
Iâve always been so disappointed that the higher the constraints in an assembly, the more bizarre itâs physics perform. Getting bridges, conveyor belts, etc, to work? Has always been near-impossible without a lot of careful tuning, so it does not surprise me at all that this is making it worse.
The only advantage is to Roblox itself. I can understand that a lot of games that arenât using heavy physics are getting over-kill CPU calculations run on the servers. Those CPU cycles cost money. For a single game instance, the benefits are too small to notice, but spread across millions of running servers, saving some CPU adds up to cost savings for Roblox. That part of business, I understand for Roblox. Having the default set to Adaptive for the bazillion simple obby games out there makes sense for cost savings. Not having the option to use Fixed mode (even in the near future) when it is really needed is where people are feeling the rub. I only speak for myself, but I have nothing against Roblox using a more CPU less intensive physics mode as the default for all the newbies making games out there to help keep server cost down. Itâs just forcing everyone to use adaptive will just break all the more advanced and developed games out there, including my own, and thatâs why we come here to speak up about it.
Yeah I feel like if adaptive behaved the exact same way as Fixed, with the only difference being stepped frequency, and somehow it was able to retain the normal runservice event consistency, itâd be fine, but right now all it does is break things and produce jittery runtime code
was Fixed
a default stepping method?
Adaptive is an absolute mess. I noticed characters who were holding weapons were jittering after standing still for too long and it turns out it was adaptive that was causing it. Way too many issue with this for it to be default.
While Adaptive does not affect my BodyPositionâs in my main experience, I canât convert to AlignPositions due to them not being a good replacement for BodyPositions. As soon as there is a good replacement, I will be able to convert them to AlignPositions.
Wouldnât it also just increase performance if they only allocate so much resources per server? If they limit the serverâs performance and the game requires more, that would cause problems. Probably an edge case, but might benefit some. Although that definitely was already possible without switching default to adaptive.
solution to the problem: Change Workspace.PhysicsSteppingMethod
from Adaptive
to Fixed
Yes, it was, I changed Flee The Mallâs PhysicsSteppingMethod
to Fixed
Would be interested in hearing more about these issues. DMd!
As of now it is currently the default stepping method.
Just to be clear, scripting frequencies provided by the current API are not related at all to adaptive timestepping.
The way to know if things are going not so well is to watch the âEngine Bugsâ forum and see if a bunch of âPlayer Physics broke canât figure out whyâ reports start flooding in.
OH, yeah youâre right I just realized I was thinking of SignalBehavior. Whoops. Although there are still very present issues with Adaptive physics
Fixed causes some strange behaviours in our game, even when not relying on deprecated body movers. Hereâs an example (albeit hard to see properly in the GIF as itâs not very high framerate)
Fixed: Jumping is smooth
https://gyazo.com/d284b138efa411948bc87bb6ff6164d9
Adaptive: Jumping is jittery, especially when taking off or landing.
https://gyazo.com/8e55cb9882d9ff5b9bf8c454c6b06e93
The Horse rig is separate from the Humanoid rig (Humanoid isnât physically attached, just visually following, separately.). If this is the intended behaviour of Adaptive, I would really appreciate a way to dictate the step-rate per simulated rig.
Just tested it, there are indeed these issues (camera stutters, flinging when walking into another humanoid, etc.)