Hello, I recently started an investigation on wait(n) and wait() to fully understand why I should not use these functions, some said to never use wait() or wait(n), some said use tick() instead of wait() or wait(n) and some said to use os.time.
I tried searching Lua books talking about wait() or wait(n) but found none covering the full topic, I’m confused as to whether or not use wait() or wait(n) the main reason I don’t want to use it, is that it’s not a fixed time, if frames drops than the wait time will be longer thus making the game look laggy ich, like who wants that?
After I came after loops
oh, boy, does loops confuse me more than anything, most scripters are thought from the beginning that ‘to solve the game getting frozen, just add a wait() or wait(n) function to your ‘loop’ and ta-da!’ but I soon realized that it’s not the answer and just misleading information.
for example what if I had this piece of code:
while wait() do
print('while loops work ha ha ha ha')
moneyText.Text = Money.Value
Imagine your self releasing a game with this, you see so many players coming in your game(20, 30, 50, etc…) and you think everything is going so well but then 1 player says he is not getting his Money and then another player says that his money text is slow and then another player says the same thing until you get disliked punched your game because it’s ‘broken’.
This is exactly what happened to me so I have been searching and learning about wait() or wait(n) and its better solutions. What do you guys do instead of using wait() and wait(n)?
I’m still confused about this subject can anyone clear It up for me?
Different types of waits sometimes have different way times, and if you want to set the money value you should probably use Value.Changed so it won’t lag the game too much and will only update if the player’s money is changed. Honestly I never used a wait(n) or tick but I have used RunService but it really doesn’t matter.
The code I wrote is only example code, I know how to use Value.Changed. To my knowledge, RunService also is running on frames so if the frames drop then the code you put in the RunService will execute slower or will execute fewer times.
The wait function (likewise as spawn and delay), in general, does not resume threads at a consistent interval because they’re using the 30 Hz pipeline, meaning that they’re not a priority in the queue, this results in them being resumed several seconds later sometimes if Roblox were to begin throttling.
Strictly speaking, using wait to generate delays is a good practice, because it was designed for that.
However, you should not use it for games that will be published. And the reason is performance. Online multiplayer games, such as Roblox games, are especially complex and need to make the most of every resource. And, as mentioned above, wait can be quite bad at its job.
For tests, experiments, or anything in Studio you can use wait without problems (in the Roblox documentation itself it is quite used), but for the code of your game that will be published, you should avoid its use.
RunService can run on both server and client, and the Hearbeat, Stepped, and RenderStepped events all have a delta-time argument when they fire, which can be used for accurate timing regardless of frame rates.
local t = 0
t = t + dt
In this script the value of ‘t’ will increase at precisely 1 point per second. The ‘dt’ parameter of the Heartbeat event is the amount of time in seconds since the previous frame. So if the game is running slowly then ‘dt’ will be higher, so ‘t’ gets incremented slightly more in that frame to compensate for the drop.
IOW, these RunService events run at a variable frequency, but they tell you that frequency so you can keep things accurate like in this example.