Why does Roblox require a wait() in a while do statements?

I sometimes mess around with some Lua compilers online, but when I put a while true do statement, everything works normally but in Roblox’s part if you put a while true do statement everything breaks. Why is that?

1 Like

Not quite sure, what I do is just put a wait() in place of the true.

If you were to leave a wait() out of the loop, it will run infinitely at no cooldown.

I know that, but when I do a while true do on an online compiler it works just fine.

My assumption is that luau is a fork of Lua, which aims to improve the performance and add new features to the language. which one of them is JIT (Just-In-Time) compilation

or maybe its in a much larger program (a game engine) rather than a normal lua compiler available online

1 Like

You see technically it doesn’t require a wait in a while loop as long as it has an end point that is foreseeable. Something equivalent to

local Count = 0;
while Count <= 15 do
  Count += 1;
end
print(Count);
-- Also Valid
local Count = 0;
while true do 
  if Count > 1000 then 
    break
  end
  Count += 1;
end 

print(Count)

still works and is completely valid code as far as I’m aware. However yeah it’s caveat is that it will run for ever without some sort of end point causing the script to completely yield and most-likely crash.

In a game, having it run at an impossibly fast time would lead to insane lag. Not sure why an online compiler doesn’t break.

1 Like

Probably because it’s running on a website not a game.

that’s because to avoid crashing the game, i forgot to put wait() in a while do and it crashed despite having a powerful laptop

1 Like

You can install a Lua interpreter on your PC and try while true do print(_VERSION) end, it works just fine printing forever. This is essentially what an online IDE service would do. It’s task is a lot simpler than running an entire game engine though, which has to switch between different tasks like rendering, physics, networking and running user Lua code. If the game engine waited for an infinite Lua loop to finish, then it would hopefully crash but probably freeze. Instead it’s better to only allow user Lua code - which is likely to have infinite loop bugs - to run for a few seconds without halting (allowing other code to run in the mean time). IIRC Studio throws an error and everything, nicely explaining what went wrong. It might look like it “breaks”, but actually preventing you from doing that is better in some ways.

5 Likes

As a follow up:

wait is a Roblox- only function meaning it’s not part of Lua or the Lua standard library. So if you’re trying to write a Lua game engine, here’s how a very simple and kind of bad version of wait can be implemented in pure Lua, which illustrates a bit of what’s going on:

local t = os.clock()
local unWaitT = 0 --The time at which the call to wait is resumed
function wait(time)
    local time = math.max(time or 0, 0.01)
    unWaitT = t + time
    coroutine.yield()
end

function render() end --Do some useful work
function physics() end --Do some useful work

function logic() --Do some useful work that *yields*, delaying it to a later time.
    local i = 0
    while true do
        print(i)
        wait(0.1)
        i = i + 1
        i = i > 10 and 0 or i
    end
end
logic = coroutine.wrap(logic)

while true do --Main game loop
    local tOld = t
    t = os.clock() --Gets the time since program start, in whole seconds with like 6 decimals of precision
    local dt = t - tOld
    print("FPS: ", 1/dt)

    render()
    physics()
    if t >= unWaitT then
        logic()
    end
    for _ = 1, 10e6 do end --Jeez, computers are fast. Do nothing for a bit just to slow FPS down from ~25k to ~25 o.o'
end

You could imagine that the logic function is whatever code we write when we make games with Roblox. It looks like wait calls just magically makes the computer do nothing for a bit, but there’s actually some code behind the scenes to implement waiting for a specified amount of time. If you were to remove the wait call from logic, you can clearly see that the main game loop would never get back to rendering, updating physics or anything else. IRL it’s a lot more complicated than this toy example, like due to concurrent execution on multiple CPU cores.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.