Im pretty sure you’re able to change the update frequency by changing the Workspace.PhysicsSteppingMethod to Fixed. It defaults to an adaptive timestepping but if you want super accurate physics calculations all the time, you can set it in the workspace property in studio.
1 Like
I know I am late, but if it is lower than 1/60 it will run based on client framerate
That used to be the case with wait() I believe but task.wait() was reported (on release) that it will wait EXACTLY the amount of time you specify it to wait.
The reason I don’t think it runs at the client’s framerate is because the Lua VM can easily execute many millions of instructions per second.
So telling it to wait 1/1000th of a second is practically just “skipping” a bunch of instructions so to speak.
I don’t think the Lua VM is “synced” to the framerate, otherwise a single instruction (like adding 1 + 1) would take a single game frame to complete.
Might test it in studio soon but you can try this code.
local start_time = tick()
task.wait( 1 / 1000 ) -- 1 / 1000th of a second.
local estimated_time = tick() - start_time
print("This code took " .. estimated_time .. " to complete.")
task.wait() is tied to the task scheduler. It will resume after a variable amount of frames, depending on the wait time, until the desired wait time has elapsed. An empty task.wait() or a task.wait() with a very small wait time will wait for a minimum of 1 frame, which is 1/60 of a second, if the fps is not unlocked and the player isn’t lagging
Well, you can try your code and see it for yourself 
(Though, you should put a task.wait() at the start of the script to make sure the code start and ends at the same point in the frame, making the results a lot more consistent, especially if you do it from the command bar)
1 Like
Bump, please can we get any word on if this is being at all considered??
3 Likes
I think this is mostly for the new “pause with rendering” feature, not something designed for us to bind to.
We are never getting this feature 
2 Likes