wait(n) is not the same thing as RunService.Heartbeat:Wait(n). Roblox servers down will cause no inaccuracy to wait, and it isn’t a void function, it returns the time it yielded the thread for.
wait is not only affected by lag, but also the current amount of threads to be resumed.
What?
Bro, RunService works perfectly on clientside
wait() is inaccurate while RunService allows you to perfectly time anything.
This is incorrect, wait() isn’t necessarily inaccurate and RunService doesn’t allow you to perfectly time anything, it is just more reliable.
If wait is affected by lag, so is Heartbeat.Wait affected by lag.
We are supposed to work with the delta time. It should not matter whether we use wait or Heartbeat.Wait
Heartbeat wait is MUCH more reliable than wait, it is put into the primary thread and has a higher frequency than wait, which is just bound to the 30hz frequency while Heartbeat wait can even exceed more than the 60hz frequency if used on the client with more than 60 FPS.
If Heartbeat is affected, it will not be that noticeable as compared to wait. Your point is irrelevant, delta time is not used for yielding the thread.
The wait is perhaps not as reliable (as in not waiting the specified time as accurately as intended), yet the time that it yielded is returned. Say for example we want to increment a value by 1 per second.
The wait version:
local v = 0
while 1 do
local dt = wait(1)
v += dt
end
The Heartbeat.Wait version:
local Heartbeat = game['Run Service'].Heartbeat
local v = 0
while 1 do
local dt = 0
repeat
dt += Heartbeat:Wait()
until dt >= 1
v += dt
end
As you can imagine, not only is wait much less cumbersome to use, it also gets the job done.
The only difference is that under extreme lag, the Heartbeat.Wait version can update the value 1/60 second faster.
Why are you spreading false information? Heartbeat.Wait will resume much faster than wait, not only under “extreme lag”.
Heartbeat.Wait also returns the time it yielded the thread for which proves your entire point incorrect. We’re talking about wait(), not wait(n).
print(game:GetService("RunService").Heartbeat:Wait()) -- 0.028019992634654
PS: I concluded a benchmark on 10 FPS on the client, testing out both. Here are the results:
You can clearly see that Heartbeat is much faster and superior to use.
No one said anything about Heartbeat.Wait not returning the time yielded. I am just saying how it is much more intuitive to use wait instead of Heartbeat.Wait if the delta time is to be accounted for (we should almost always account for the delta if you still haven’t noticed by now), and it is still affected by lag just as much as wait do.
wait:
Heartbeat.Wait:They are functionally equivalent with a minor difference. You SHOULD account for the delta time anyways.
Sure in loops where we do not have to concern ourselves with the delta time, it is better suited to use Heartbeat.Connect, just like what this page have told us to.
Returning faster or not is not the concern here.
It is functionally equivalent. There is a default value set. Even by switching the Heartbeat:Wait() to wait() there would have achieved the exact same effect.
If wait is such a bad utility it would have been deprecated and replaced.
Returning faster or not is not the concern here.
That is my point.
It is functionally equivalent. There is a default value set. Even by switching the
Heartbeat:Wait()towait()there would have achieved the exact same effect. Ifwaitis such a bad utility it would have been deprecated and replaced.
That isn’t my point, my point was just to address how Heartbeat.Wait can be faster and is much reliable than wait and they aren’t equivalent in terms of accuracy and yielding, this is an false claim.
PS:
They are functionally equivalent with a minor difference. You SHOULD account for the delta time anyways.
This is completely irrelevant, we are talking about yielding, not using delta time. You don’t use delta time for yielding unless you want to create your own function.
If
waitis such a bad utility it would have been deprecated and replaced.
No, wait should be used when it needs to be and you don’t care about exact accuracy. I never said it was a bad function, it should be used when it needs to be.
Sure in loops where we do not have to concern ourselves with the delta time, it is better suited to use
Heartbeat.Connect, just like what this page have told us to.
Have you even read the properly? You’re creating an unnecessary thread (Heartbeat.Connect) and that is definitely not needed for yielding: you need to yield the current thread, not the one created by Heartbeat.Connect.
That page has never stated to use Heartbeat.Connect for yielding and hence, your point is completely false.
(we should almost always account for the delta if you still haven’t noticed by now), and it is still affected by lag just as much as
waitdo.
Like I said, Heartbeat.Wait isn’t affected by “lag” as wait, it is much more reliable and accurate when compared to wait, if wait is affected, sure Heartbeat.Wait will be but since it isn’t bound to the 30hz frequency, the affect won’t be as bad as compared to wait and is mostly unnoticeable, refer to my benchmark above.
There is no point in arguing pointlessly with false claims.
Thanks for that, didn’t really know that you could run RunService on client, I’ve had a few issues where, I thought that the cause of it was RunService. That’s why I’ve come to believe that RunService is only server side.
That test has many different issues. First of all, those wait() yield times only go that low if your running at 10 fps. Those numbers would be dramatically similar if you were running at 60 fps. Also, good optimization reduces the amount of lag in the server, causing higher fps in the client. In a 60 fps benchmark, wait() and Heartbeat are dramatically similar. However, if the given client FPS gets too low or too high(Roblox FPS Unlocker I’m looking at you), Heartbeat will prevail by a large margin.
As most of roblox’s games support optimization, and roblox’s main playerbase are kids, I don’t think getting low fps or getting high fps will be common. For games like adopt me, wait() wouldn’t cause such a huge problem, for obvious reasons. However, I do agree heartbeat would be extremely useful in games such as Arsenal or any other kind of shooters.
while I do agree with you that HeartBeat:Wait() is much, MUCH faster than wait() in most situations, the evidence you used to provide usually wouldn’t happen in most games. (most laptops and computer can easily run games at 60 fps), phones can run adopt me at 60 fps. Not necessarily denying Heartbeat’s speed, but the benchmark doesn’t really apply to that much people, and games. If something like fps caused an issue, the game itself would already be hard to play.
Any wait() method from Luau is just bad.
Kampfkarren already said in this tweet, that he doesn’t even think any wait should be used no matter what, that’s why there’s those modules like BetterWait.
That test has many different issues. First of all, those numbers only go that low if your running at 10 fps. Those numbers would be dramatically similar if you were running at 60 fps. Also, good optimization reduces the amount of lag in the server, causing higher fps in the client. In a 60 fps benchmark, wait() and Heartbeat are dramatically similar. However, if the given client FPS gets too low or too high(Roblox FPS Unlocker I’m looking at you), Heartbeat will prevail by a large margin.
That isn’t my point, the test was to show how Heartbeat.Wait is much superior and reliable than wait on throttling. There is no need to use Heartbeat.Wait if your code is event based and doesn’t yield threads much.
while I do agree with you that HeartBeat:Wait() is much, MUCH faster than wait() in most situations, the evidence you used to provide usually wouldn’t happen in most games. (most laptops and computer can easily run games at 60 fps), phones can run adopt me at 60 fps.
When you want precise and accurate yielding, Heartbeat.Wait is needed. Also, these both are also affected by how many threads the code has to resume, not only FPS. Heartbeat.Wait is added to the primary queue since it’s not bound to the 30hz frequency unlike wait, which is added to the secondary queue. Your point isn’t valid at all.
This is a good read: https://eryn.io/gist/3db84579866c099cdd5bb2ff37947cec
@LucasTutoriaisSaimo That is just a opinion from Kampfkarren, not a actual proved fact.
Any wait() method from Luau is just bad.
This is a completely subjective statement, there is no need to argue pointlessly when you don’t know much about how it works internally.
Big developers answered to this post agreeing. Using .Heartbeat and stuff is just better. In this case at least right now, since they’re gonna be replaced soon.
Anyhow, it’s not hard to implement your own system to use .Heartbeat or .Stepped, or even .RenderStepped (on the client).
Custom wait - the best solution to yielding!
You don’t know about the problem with wait() some performance issues? Wait let me find it.
No, when you don’t care about accuracy, wait(n) and wait() are completely fine. Also, assuming your code doesn’t yield threads much and there isn’t much FPS loss, wait is as accurate as it needs to be.
Anyhow, it’s not hard to implement your own system to use .Heartbeat or .Stepped, or even .RenderStepped (on the client).
Is this relevant?
You don’t know about the problem with wait() some performance issues? Wait let me find it.
Of course I do know about the problem, that’s why I have posted a few replies to this topic. Please don’t be subjective and rather reply with facts and not questionable points. Consider learning how wait and Heartbeat work internally.
Ohh, ok now I understand why wait() is bad. Thank you for linking the post on how wait() works. Thank you for that.
If you are keeping your secondary queue tidy by using these alternative methods, then making timers with
wait(likewait(30)) can be okay, as long as you’re okay with it not being exactly accurate.
I’m okay with it not being completely accurate, considering it’s a minute long.
wait() isn’t necessarily bad, use it when you don’t care about accuracy, use it.
Rule of thumb:
This is the problem with using wait().
I have addressed this already if you bothered to read the points I addressed, and I even stated that I know the problem, please stop being off topic.
