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
I would like to bump just because I have my own reasons for running specific server sided content at greater than 60 fps, and the main one is both networking and tickRate
I have been working on some projects recently and the servers running at a maximum of 60 frames per second is a barrier for certain things that I wanted to develop, such as a competitive shooter or racing title. Often times, these games run high tick rate servers, normally ~120 ticks per second or higher, which enables for more frequent and more accurate game updates. I believe remotes are also throttled so doing some sort of busy-wait on the server to “double” the tick rate will not really improve the networking at all and will only serve to create unnecessary load on the server. The majority of the reasoning for requiring the higher tick rate in the first place is to allow for more frequent and accurate communication of game state with the client, which helps better optimize latency, as well as make server-authoritative networking solutions make better decisions through more frequent data input, resulting in less rubber-banding overall, and a better quality gameplay experience
I would much rather be able to modify the tick rate myself and handle my networking, interpolation, snapshots, and calculations that way as opposed to alternative methods, as 240hz is unnecessary for my use case (though may be useful for manual/native physics simulations), but both options would be suitable in this scenario
The only two ways I can currently ‘do’ this are both not great:
(deferred version to make busy-waiting less intensive on server and allow other scripts to execute)
