I am making a game that is about two years old now, and in some of my older scripts, when I was still learning to code, I used the wait() to delay the script.
At that time I didn’t know that wait() could delay slightly, and task.wait() was a better alternative, however, over time I started to use the task.wait() in my newer scripts, but I still did not change it in the old ones, but as I added more things and more scripts, wait() in those old scripts started to delay a lot, and I mean reallllly a lot, for wait(0.8) sometimes the player had to wait for half a minute, which was really annoying.
I read that wait() can lag due to the performance of the game, so I decided to try to change all wait() to task.wait() in all the scripts it was in (I used changeall thingy roblox for this), so I did “wait( > task.wait(” and all the useless delays stopped, however the game now is crashing, jumping from 60 all the way down to 1 fps, so I reverted it, and the wait() lag still occurs.
My question is, what is going on and how can I fix it? Is it just the performance of the game and I gotta optimize it to make the problem go away?
They function relatively well because of the delay that wait() has. However when you replace it with task.wait(), the loops will work just like a heartbeat since task.wait() is supposed to wait for at least one heartbeat, so you might as well change all the loops to use RunService.Heartbeat.
This is probably an issue with your code. Once, I had code that would run for a part outline system (using meshes in the corners), and that code would run every time a part was selected or hovered even, but wouldn’t stop running. That issue caused the fps to drop as players were building. You might have a similar issue
wait() has been officially deprecated by Roblox (Literally, in documentation it is now marked as such.), so its suggested you use the task library for task.wait()'s functionality.
Considering that it has, you can only expect more issues to come it until its defunct.
wait() when used has two arguments that it returns when you run it, meaning you are able to tell the code to collect these arguments like this:
local a, b = wait();
a is the amount of time it took to run the function. b is the time since the application started running
task.wait() is the same thing, however it now only returns one argument, being the amount of time it took to run:
local a = task.wait();
The main thing you will notice between the two functions is that task.wait()'s yielding time is less than wait()'s yielding time by nearly half. This because task.wait() runs off of Hearbeat (, which is run based on FPS time This number can range from (60FPS or more), meanwhile wait() throttles it to around 30 FPS.
--[[ Difference between 60 Frames and 30 Frames ]]
local Frame60 = 1/60; -- .01666666666667
local Frame30 = 1/30; -- .33333333333334
-- This may not seem like a big difference, as 17 milliseconds is slightly
-- faster than 33 miliseconds, but these can make big differences
To throttle just means to limit in frequency, which for wait(), it is limited to a frequency of roughly 33 miliseconds (or around 30 FPS), while task.wait() is limited by your current FPS
It isnt something you cant fix unfortunately, its recommended you look into a different alternative.
One thing I noticed is that now wait() has become more innacurate. Before it stayed at around the same amount of time, now its going above 40 milliseconds.
Thats pretty weird then, because as i said the wait() can delay even up to 30 seconds, while im having stable 60 fps, which means its either a bug, or the “various throttling conditions” means something else than the framerate
That’s really odd. This probably won’t do much, but try to see if you have the Play Solo beta feature enabled, it has caused some weird issues. If it’s enabled, try turning it off and see if anything changes. You can also try to publish the game to the roblox servers and test it there in case it’s a studio bug. At this point you might as well try anything
