I would really like to understand what the Rate (/s) value in for scripts when viewed in the Developer Console. What does this value represent and how is it helpful? Why is it displayed in the Dev Console?
Any information is appreciated.
Wym rate for script? Scripts run instantly (unless yielded)
for a while true do wait() end loop, the rate is approximately 60/s IIRC as each wait is 1/60 if no parameter is passed into wait (this is also the minimum).
You can run faster with RunService heartbeat and renderstepped
Last I heard this value is wildly inaccurate and is not to be understood at the moment. If Iâm wrong then someone please correct me.
I heard something like that too; RunService Heartbeat is apparently the most reliable way to yield (though I still use wait, it works, never really gave me an issue.)
You havenât had an issue with wait? Wait until your game gets more intensive then. Itâs not whether it works or not, itâs the underlying problems behind it.
The issue with wait is that the actual time it spends waiting is indeterminate because it waits the amount of seconds you specify and then an additional few to find an open spot on the task scheduler. If your scheduler is busy running intensive functions, this delay can go from a few miliseconds to several seconds and delay your code from running for an unexpectedly long amount of time.
Heartbeat runs according to frames not the scheduler. You can check how much time has elapsed between frames and use this to create a custom waiting system with a higher degree of accuracy and less behavioural unpredictability.
2 Likes
Hereâs the âratesâ of all things in Roblox.
Server Scripts (without wait() functions) - Instantly, as soon as the server is booted.
Local Scripts (without wait() functions) - Instantly, as soon as the client connects.
wait() functions - Itâs quickest is 0.03 repeating, so wait() waits 0.03 repeating seconds. Anything lower than 0.03 repeating ends up going 0.03 repeating.
RunService.RenderStepped - This runs before the clientâs frame is rendered. At maximum, this is 60 FPS, however some people exploit using FPS unlockers, so this can theoretically be any number. Complex calculations will delay the frameâs rendering, so be careful using this one.
RunService.Heartbeat - This runs after the clientâs frame is rendered. Same limitations as above, except complex calculations wonât delay rendering.
spawn() - Once spawn() is called, the game will pass an arbitrary time of length (most of the time very short, however some report seconds, even up to a minute of wait), then run the function in the parentheses.
Coroutines - Coroutines do not have the arbitrary wait time, and run as soon as they are called. This is why you should use them instead of spawn().
Hope this helped you!
3 Likes
No, Iâve never noticed an issue with wait(). Is there any drawbacks to heartbeat? Edit: Why would they make wait unreliable lol they should fix it
I am not talking about âwaitâ or how soon a script runs.
When you are in the Developer Console, you click the âscriptâ tab, and the graphs show 2 values, frequency and rate.
I was just wanting to understand what those meant and how to use them to determine if there are issues with my scripts.
So, Whatâs your problem again? I donât understand it clearly
P.S. This is the last post for this topic. You should DM me if you want to discuss further since I do believe this is off-topic and doesnât have much, if anything at all, to do with the OP.
In a moderately sized game or one that isnât that intensive, you arenât going to see many issues with wait. When your game starts adding more expensive or involved functions, you will start to notice that wait starts expanding how long you need to wait for. You can check how much time wait actually waited for using the first return value.
Heartbeat does not have any drawbacks, unless you consider not being able to get exactly a sum of 1 when adding delta time up a drawback. Itâs as precise as you can get. The engine doesnât have any functions, to my knowledge, with higher accuracy.
Wait isnât made unintentionally reliable and itâs not broken either. Lua is single-threaded. Every single piece of code in your game runs sequentially and this is facilitated by the task scheduler. When you call wait in your thread, it yields and gives up its running spot to other threads. When it finishes yielding, it then needs to wait in line for a slot to resume. Unreliability mostly comes down to your own code and what itâs doing, not the scheduler itself.
2 Likes