really? Well okay then. But they functional completely normally?
wait() is being deprecated in the terms that Roblox don’t want you to use it. But actually removing support for it will break way too many games on the platform, so it will keep existing & functioning. The problem is wait() throttles a lot & isn’t very accurate. task.wait() is essentially basing directly on the heartbeat which is ran each frame. So you should safely expect it to be done waiting on the exact frame it’s due, which wait() often doesn’t.
It’s just much more reliable.
1 Like
For this case no, but for longer waits (i.e., 1 second+)
task.wait() is what you want to use. It’s a lot more accurate than just using wait()
The main reason for task.wait (and its deprecated friend, wait) is to pause your up for a short period of time.
The time, with no argument defined is 1 resumption cycle (generally 1 frame since Roblox cycles are 60hz). It can, however be modified to wait as long as you want it to.
You should be using it in an infinite loop (such as while true do) to ensure your game doesn’t freeze. Roblox needs to know it can pass onto the next frame of operations knowing your code has completed, creating an infinite loop with no pauses basically means Roblox will never be able to proceed since it thinks your code is still running.
I can give you a more technical rundown but you’re a beginner so I dont really want to give you too many technical terms.
1 Like
There is one down-side about task.wait(), it continues the loop even though you either disabled or destroy the script.
Although wait() is not encouraged to be use, wait() corrects this flaw.
oooo okay got it! thank you for the explanation!
“creating an infinite loop with no pauses basically means Roblox will never be able to proceed since it thinks your code is still running.”
but, can’t we have if statement that checks and breaks accordingly?
“it continues the loop even though you either disabled or destroy the script.”
So basically it will continue the loop even though you can’t see changes, which takes up memory?
It should be
Yes. It takes up untracked memory.
wait so if it still replicates the changes after the script is destroyed, how do we stop it?
Both wait at the same time.
The difference between using while true do wait() end and while wait() do end is that while true do is optimized and doesn’t actually check the condition, it just repeats until a break happens. Internally, Luau won’t check if true is a truthful value, it gets “compiled” to bytecode which doesn’t take that into account since true is always true. It’s not that big of a deal though. Using RunService to handle things that “always happen” is a much better option, readability (to me), perfomance, and memory wise.
(This optimization above is true on Lua, therefore it should be valid in Luau as well.)
Source: luaK_goiftrue under lcode.c on Lua source code. (Got that source from While-Wait-Idiom)
A while true loop with a reachable break or return is not an infinite loop
Infinite loops are where the code never escapes the loop
1 Like
ya I know.
That’s what I was tryna say lol
Please don’t ever use this, you’re relying on the fact that wait is going to return a truthy value, in this case, it’s the time it waited for. If roblox ever changes this, this will break.
while true do is more optimised than while wait() do.Why is wait() important? - #22 by LucasMZ_RBX
I doubt Roblox would remove the return from wait given how its useful to developers who want to make time-based animation code etc.
2 Likes
I can see why while true would be more optimized than while wait(). I am an expert a java programming as I literally take 5 hour long classes on saving memory and runtime lol. So, using my experience from that, I would kind of be able to tell why while true is more optimized than while wait()
Just going to leave this here… Not the biggest fan of while wait() do either.
There’s no way they would change wait() to give off the completely opposite signal of what it already does. They are not going to change it as literally major of the platform relies on every way it functions. It’ll continue to work the way it does & they’ll completely take focus away from it.
Most coders recommend not substituting true for wait.
Some say this is because one day wait may not return true.
You can look at some other reasons here: