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.
Thanks for posting. I’ll try out the game to see if I find anything.
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.
It is something worth discussing, but we would like to avoid this route if possible.
I would be inclined to agree, fixed-axis force would be a huge benefit, so I’m glad you’re looking into it.
How much of an improvement does this see in physics performance? I’ve not had a chance to test adaptive yet. Sounds like it could be a significant improvement!
It’s quite the opposite actually. The setting is not to increase performance, but to decrease it for games that don’t need it. The spare CPU cycles could be used to power something else in the game for example, if you don’t need to simulate lots objects being flung around the players.
Thanks for the feedback. I’m interested in getting a repro with the issues you are seeing with your game. (DMd)
Hmm I will try to message bug reports asap, here’s what I had around 10 QA testers report when testing adaptive timestepping in short tho:
- When a player walks into another player they both get flung into air. This bug used to be in roblox many years ago but was patched in fixed.
- If there’s an unanchored object standing on an unanchored object the object on top will end up tripping
- Unanchored assets shake like crazy for no reason
- Purposely dragging the player makes the player fling in Adaptive only
- If you walk into a wall the camera starts shaking and so does the player
- If you hold the left/right arrow keys + w the camera starts stuttering
- If there’s too many parts (around 50) adaptive becomes really laggy and ends up just freezing most of the parts in air
Other bugs i’d like to report while i’m on it
-Strafing enabled toggle is broken
-Video looped/playing toggle is broken
Both reset to off when publishing/reopening studio and can only be enabled thru scripts.
Some of those bugs happen to the games in my profile. I am hosting another QA test tomorrow so Adaptive is on.
I would like an option in which it’s adaptive between 120Hz and 240Hz. I’d like to use this, but 60hz just too often breaks stuff, as others have reported as well. I do feel like 120Hz would be enough, but I can’t properly test this.
At least consider this, I have no idea how difficult this would be to implement.
Maybe it would be better if we saw a Dynamic option that allowed us to individually set the physics behavior of each BasePart/Assembly, as well as the ability to set what the default behavior for all BaseParts/Assemblies is. An extension of this for code, as MANY systems rely on RunService events would be .stepped type events for both physics behaviors that can be used interchangeably, i.e. RunService.AdaptiveRenderStepped and RunService.FixedRenderStepped, assuming that is possible of course. I’m pretty sure in Unity there is something similar, but don’t quote me on that.
Hey, thanks for the feedback. We have the ability to tune the aggressiveness of the system, so in the future we plan to provide the option to select between different modes
It depends on the game, but if your game doesn’t involve any hard-to-solve mechanisms (which will default to 240hz) you can expect ~2x perf boost for physics simulation time.
I just tested adaptive timestepping right now on my community fighting game (squid game chaos mode)
It’s a small game that really only has close quarters combat
Things I noticed immediately:
- Random flinging during combat (even though mostly everything is can collide false)
- Note that I’m not using any body movers or stuff for combat, just pure animations and tools. (The tools are can collide false, and using r6)
- The adonis fly command, has random glitchbacks and caused a massive FPS drop that didn’t subside even when I rejoined the game (very odd)
These are just 2 instances I found right now, so I’ll probably keep fixed on for most of my games, I will continue testing and reporting on other issues I find though!
We’ve been working on tuning humanoid simulation behavior a lot recently. I’m interested in knowing if the humanoid related issues still there.
Thanks for taking time to post the videos, these are super helpful.
I’ll try out your game to see if I can catch anything.
While you’re there fixing the missing vector3 maxforce issue, it’d probably be a good idea to wrapper or clean up the whole API for bodyAlignment…
For something that is meant to be the “core” of making things like baddies and elevators and doors in roblox, its API and workflow has a few problems. Especially now if you really are pushing hard to take away bodyPositions.
A very common experience is: " Add BodyAlignment to unanchored part. Add attachment to unanchored part. Put into single attachment mode. part still falls to the ground"
In general:
-
The default values are poor for the common use case. Most people just want to use a bodyAlignment to glue a part into a fixed position in the air, much like using a bodyPosition. Figuring out how to make this work via single attachment mode and the correct forces is actually fairly difficult.
-
It has a lot of properties. Many of which are contextual and don’t do anything, depending on what mode it is in. This is super confusing especially when you encounter issue 1
-
There is little to no feedback as to what goes wrong when your bodyAlignment doesn’t do the thing. Did I use the wrong setting? Are the attachments wrong? What’s going on?! Warnings or errors would be appreciated.
-
The way you’re meant to put the attachment somewhere else other than on the object is ultra confusing. Why the heck doesn’t this work, or at least give feedback why its not working.
Here’s a fun experiment: Try a blind test where you watch someone whos never used roblox before try and make an unanchored part stick in the air with a bodyAlignment. Just give them the rough outline of “Oh, you make parts fly with a bodyalignment” and watch them go…