Some clarification: - The demonstration shows that `task.wait()` does exactly what it is supposed to do; our assumption that it always waits a frame is wrong. - As framerates are dynamic, there's no magic number to plug into `task.wait()` to wait 1 frame. You as the dev are responsible for understanding this behavior and acting accordingly. - I did not use the global `wait()` function because it is deprecated.
Watching this has given me a sudden urge to look at the Roblox engine functions and try to catch anything niche with them, adding more depth to my knowledge, i'd like to see more videos like this :)
Is there a particular reason why task.wait waits until the next heartbeat and not the next render step internally? What's the point of that minuscule difference if it's causing unintended behavior?
RenderStepped runs right before rendering the frame. The server does not render anything, thus never runs RenderStepped. Also slow running slow code in RenderStepled can significantly drop the frame rate.
@@binaryparrot3352 I mean server can run RenderStepped in studio, but only in studio because of the server window you can switch to. Live games will never have this effectively making RenderStepped on the server useless
I don't understand what you mean, "if you want to wait a frame wait a frame." That's exactly what I'm demonstrating doesn't work as expected. Even if you put `task.wait(0)` you will end up with the same thing. Frames vary in timing, so there's no secret number that waits 1 frame. You as a dev need to be conscious about your current invocation cycle to properly wait a frame.
@@sleitnick1 i mean , just runservice.renderstepped:wait() or heartbeat or whatever else you need. That way its more clear whats going on. task.wait might have a specific definition but it's not intuitive what it does.
@@sleitnick1 I mean that since task.wait() is so ambigous just use RunService.Heartbeat:Wait() or the other events, since they are more specific , it's more intuitive , you know exactly whats going on
task.wait() waits for the time given then heartbeat wait() waits for the time given and does other stuff you never asked it to do unless the joke is that you haven't provided an arg which in that case, it do be like that...
wait() has some dark magic type of waiting that is meant to wait for like 30ms, but in reality it can wait as much as a minute, nobody knows why, but at some point in development your wait() will start to get slower and slower and can go up to tens of seconds of delay to each wait that you use
if someone wasn't aware that task.wait() runs at heartbeat or at least summarised it as every other frame (because that's usually the context in which task.wait() is used) then this video is pretty valuable and straight to the point as well definitely not click bait. The title is obv trying to grab your attention because that's how the algorithm is but it proposes a question instead of a statement so it's not wrong
Some clarification:
- The demonstration shows that `task.wait()` does exactly what it is supposed to do; our assumption that it always waits a frame is wrong.
- As framerates are dynamic, there's no magic number to plug into `task.wait()` to wait 1 frame. You as the dev are responsible for understanding this behavior and acting accordingly.
- I did not use the global `wait()` function because it is deprecated.
Please do not expose the backdoor in the ROBLOX Source code.
🗣🔥WE MAKING IT OUT OF DOCUMENTATION WITH THIS ONE 🔥
Already knew this but I'll be using this to explain it to others so thank you!
Watching this has given me a sudden urge to look at the Roblox engine functions and try to catch anything niche with them, adding more depth to my knowledge, i'd like to see more videos like this :)
parallel lua video in the works?
This was very neat! I enjoy these kinds of videos :)
You're goated
Crazy useful to know! Should be easy enough to workaround.
Fascinating
yay new video!
e_2
What studio theme do u use?
Very cool
Is there a particular reason why task.wait waits until the next heartbeat and not the next render step internally? What's the point of that minuscule difference if it's causing unintended behavior?
RenderStepped runs right before rendering the frame. The server does not render anything, thus never runs RenderStepped. Also slow running slow code in RenderStepled can significantly drop the frame rate.
@@binaryparrot3352 Ahh right, I see that now. Thanks
@@binaryparrot3352 I mean server can run RenderStepped in studio, but only in studio because of the server window you can switch to. Live games will never have this effectively making RenderStepped on the server useless
thanks!
I just dont use task.wait() without args, its ambious and doesnt make sense, if you want to wait a frame wait a frame
fr, or even just learn how to time events using delta time
I don't understand what you mean, "if you want to wait a frame wait a frame." That's exactly what I'm demonstrating doesn't work as expected. Even if you put `task.wait(0)` you will end up with the same thing. Frames vary in timing, so there's no secret number that waits 1 frame. You as a dev need to be conscious about your current invocation cycle to properly wait a frame.
@@sleitnick1 i mean , just runservice.renderstepped:wait() or heartbeat or whatever else you need. That way its more clear whats going on. task.wait might have a specific definition but it's not intuitive what it does.
@@sleitnick1 I mean that since task.wait() is so ambigous just use RunService.Heartbeat:Wait() or the other events, since they are more specific , it's more intuitive , you know exactly whats going on
Could you not just do task.wait(1) in the instances where the time diffrences are the same , although i agree dose seem to be broke.
task.wait() waits until a Heartbeat, and wait() doesn't
The question is, what does wait() wait for?
task.wait() waits for the time given then heartbeat
wait() waits for the time given and does other stuff you never asked it to do
unless the joke is that you haven't provided an arg which in that case, it do be like that...
wait() is based on an older 30hz system, and the minimum it will wait is 29ms!
@@littensy source?
wait() has some dark magic type of waiting that is meant to wait for like 30ms, but in reality it can wait as much as a minute, nobody knows why, but at some point in development your wait() will start to get slower and slower and can go up to tens of seconds of delay to each wait that you use
wait() uses an old, throttled system that may or may not resume execution after some time has passed
hi guys
Thanks for explaining all this, Sleitnick.
How is your life goin?
task.wait(), what?
Stop click baiting.
It’s not clickbait. Someone unfamiliar with the event cycle might be completely confused by this, as it _looks_ broken, but isn’t.
@@dimitar.bogdanov That's why I made this. I was quite confused at what was going on at first.
if someone wasn't aware that task.wait() runs at heartbeat or at least summarised it as every other frame (because that's usually the context in which task.wait() is used) then this video is pretty valuable and straight to the point as well
definitely not click bait. The title is obv trying to grab your attention because that's how the algorithm is but it proposes a question instead of a statement so it's not wrong
@@sleitnick1ignore the OP. Ive seen this guy hate on other developer youtubers like crusherfire.