Is wait() and wait(n) bad practice?

Help and Feedback Scripting Support
,
#1

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 :man_facepalming:

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
end

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? :confused:

#2

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.

1 Like
#3

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.

#4

Well, you really can’t say BAD practice, just what works for the script you are making and what you are making for. I would try to learn all of them and use them when needed.

#5
2 Likes
#6

It is a terrible practice.

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.

1 Like
#7

I already read those post but still don’t really get it :confused:

#8

In summary:

wait() can easily last SECONDS.

(https://mobile.twitter.com/Kampfkarren/status/1037729712687263745)

5 Likes
#9

I also had this doubt and this is what I learned:

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.

2 Likes
#10

You should not be using loops in this scenario. Instead, you should be using the IntValue.Value changed event which fires whenever the value is changed.

#11

There are a lot of scenarios where using delays can be replaced with an event-based system which is much preferable.

Instead of using an infinite while-loop to check for a specific value you can use a Changed event.

If you want something to update constantly you could bind a function to one of the events of RunService.

The example of code you posted could be done like this:

game:GetService("RunService").Stepped:Connect(function()
	print('runservice loop')
	moneyText.Text = Money.Value
end)

Or this:
(more preferable since you only need to change this “Text” property if the value of “Money” becomes different)

Money.Changed:Connect(function()
	print('value changed')
	moneyText.Text = Money.Value
end)
1 Like
#12

what about when you need to set two string value and repeatedly verify it:

while true do
	wait()
	PetObj.PetName.Value = PetObj:WaitForChild("Obj").ObjName.Value
end

Test - Roblox Studio 15_11_2020 21_01_54 (2)
Test - Roblox Studio 15_11_2020 21_01_54 (2)290×638 14.8 KB

#13

You can still use the Value.Changed event, just check if it is the same. If not, then reset it.

#14

but don’t RunService can only be executed only on client, and if I remember RunService also runs on frame rates, if the frame drops will it affect it?

#15

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.

1 Like
#16

RunService can be used on both the server and client. RenderStepped is only on the client though, but Heartbeat and Stepped are on both the server and client.

1 Like
#17

I would do this instead.

moneyText.Text=Money.Value
Money.Changed:Connect(function()
    moneyText.Text=Money.Value
end)
#18

can you give me an example of the use of the delta-time argument? I never heard of it.

#19

The Changed event has a parameter which gives the new value, so you can do this instead of writing Money.Value.

Money.Changed:Connect(function(value)
    moneyText.Text=value
end)
2 Likes
#20 
local t = 0
game:GetService("RunService").Heartbeat:Connect(function(dt)
	t = t + dt
	print(t)
end)

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.

1 Like