Who told you it will return false? Have you seen it in the official documents? I have never seen a function that is meant for numbers return a boolean evevr.
while true do
wait()
print("lol")
end
-- is the same as
while wait() do
print("lol")
endOfficially there should be no reason to return false. I’m saying that some in the community believe wait() can rarely return false [this could be due to a bug], and I’m interested in if there is one.
No
No, but it can last longer than the number you give it if it’s being throttled
If “it” is wait, then no
No, but you should probably use task.wait() instead (I forget if we deprecated wait() or not, but I can’t think of any good reason you’d want to use it)
The bug doesn’t even exist in original lua, why would it exist in luau?
You can use wait() if you want a slower loop. : ) (Don’t wanna write down task.wait(0.04264230000262614))
You use while true do to determine if the condition is true, while wait() do will do the same thing but (this is a IF according to many posts, which doesn’t mean its true) if it returns false, it will break, from what I see is just IFs, not it does, or it will, its mainly just them saying potentially if roblox made it return false.
However just so you know, it isnt true
task.wait(0.03) will probably get you what you want, I don’t know if I would want to be beholden to throttling I don’t control to such a degree as a developer 
I don’t think it has anything to do with any potential bug/breakage (there’s no chance we’d ever make wait() return a falsy value especially given the prevalence of while wait() do), but simply that while wait() do looks kinda weird. I don’t like abusing truthiness like that, but it will never break.
Good point! Keep in mind Luau is almost entirely rewritten and has a lot of changes to standard Lua.
Correction on this: wait() doesn’t even exist in original lua, I just realized this. Roblox made it, no wonder it didn’t work when I tried it outside luau.
Lua doesn’t even have any yielding functions if I recall. Either using a custom library or from scratch.
That’s why I said a Big IF, its people mainly saying if it did or if it didn’t.
Is there a estimated time on wait()'s depreciation? On the docs it still doesn’t show as depreciated I believe.
ps. So siked a roblox staff guy here ^^
Almost everything that Roblox deprecates still works so that old games don’t break. They’ve just found a better way to do them.
Although when they got rid of TorsoMeshes a few years back it pretty much trashed some of the builds I was using them in.
Dunno, I thought it already was.
As per:
Existing Methods
We will eventually mark the existing methods (spawn, delay, and wait) as deprecated in favor of their alternatives however they will continue to work as they do now for the foreseeable future and we have no plans to change this.
(That last part is pretty important, don’t let me scare you 
)
It’s really just a case of us marking them as deprecated in our documentation and advising users to use the alternatives under the task library. The task variants have a number of improvements so I would recommend using them over the yet-to-be-deprecated ones.
This doesn’t really matter. It will always perform the same and will probably never break.
Additionally, task.wait does not also return time yet, but wait does.
The differences between task.wait and wait are mainly that task.wait is more optimized and runs at 60 Hz (or whatever framerate the task scheduler is set to). The reason why it is optimized is a mystery to me, but I’d recon it’s because it only returns one value, unlike task.wait.
Wait is identical to wait. Spawn is identical to spawn.
The interesting part is that task.spawn is not a replacement for spawn. This is because spawn will wait until the next frame and then run the thread. This makes task.defer a replacement to spawn.
coroutine.resume and other thread functions are similar to task.spawn but wrapped in a pcall.
delay can almost directly be replaced by task.delay if I’m not wrong.
However, I wonder why we don’t have a task.time() yet. I’d prefer something like that to determine the number of seconds that has passed since a specified thread or current thread has started.
Curious, can you give an example of where ir would be useful? (Over os.time, tick, and clock of course)
I’m not sure, but I would probably use it for debugging. This timer would start once the thread has started.
I know it’s not the answer you want, but you could record the time beforehand…
local robloxStarted = os.time() - select(2,wait())
-- Other stuff here....
print(os.time() - robloxStarted)
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.