Is there an Alternative to wait()?

Help and Feedback Scripting Support
#1

I am currently using wait(speed) to determine each stages of growth. But the problem is that when something changes, for example speed, during the wait(), it won’t speed up the time until the next wait() which will have the new value. I’m wondering if there is a way to do this.

2 Likes
#2

You could possibly log start and finish, eg.

local t = 60 --60s length
local start = tick()

while wait() do
  if tick()-start > t then
    -- do your thing
  end
end
14 Likes
How to make my wait() go quicker
#3

You can have a loop function with a NumberVariable saved somewhere on the server while counting down every second with;

while wait(1) do
workspace.Timer.Value = workspace.Timer.Value - 1
end

#4

That’s still using a wait, which is explicitly not what OP wants.

Legoracer’s solution is fairly effective, especially for the use case listed (determining growth). Such should be determined by a variable that can later be changed and checked. A wait is too concrete and it’s better not to sleep the thread for this kind of operation.

3 Likes
#5

It’s not that OP doesn’t want to avoid using “wait()”, he just doesn’t know how to use it in a modular way – and anyways, I’m just providing an alternative to anyone with this question in the future.

3 Likes
#6

If you’re running this code on the client, you could utilise RunService.

-- ~1/60 
game:GetService("RunService").RenderStepped:wait()
#7

I’m not sure if this solves @cornman601’s problem in his given context, perhaps you could explain a bit? One of us might have interpreted the problem wrong.

#8

Ah no, my mistake. Haha.

#9

The title does tell a different story than the message, I fell for it at first too :smile:

#10

Correct me if I am wrong but isn’t .RenderStepped quite taxing on the client? And if this is a game that relies on not having any chance of lag or else it could cause unfair advantages towards a specifc client, then that option wouldn’t be very feasible?

1 Like
#11

Just using RenderStepped alone isn’t taxing. It all depends on what you do inside it (or after it if you’re using RenderStepped:Wait()). Ideally you would have very little logic in RenderStepped, since RenderStepped “freezes” rendering until all Lua code inside (or after for :Wait()) all RenderStepped connections finishes. You can use Heartbeat is you need almost-RenderStepped, where it doesn’t freeze rendering and effects will show up one frame late if they take too long.

4 Likes
#13

i know some people have the problem of wait() and how it stops the who script.
so i think you can use it like this.
` coroutine.wrap(function()

end) ()`

– edits cause im nooby

#15

Why someone has bumped this 2 y.o. topic, I don’t know. For whoever’s reading this, the following wait() implementation has 0.1 seconds accuracy (built-in wait() has about 0.3)

local function wait(seconds: number)
    seconds = seconds or (1 / 60)
    local deltaTime = 0
    
    while (deltaTime < seconds) do
        deltaTime += game:GetService("RunService").Heartbeat:Wait()
    end

    return deltaTime
end
2 Likes