Is there a way to write whole game codebases without the use of arbitrary waits?

[Kampfkarren (boyned)]

I made an entire thread on how to avoid wait() and why. There is, and as I say in the thread, wait() does not belong in production codebases at all.

[EmilyBendsSpace]

@colbert2677

I am asking how to write codebases without the use of wait or to use it minimally in such a way that is not intrusive or against my use cases.

What’s not made clear anywhere above is why you are asking how to write code without using wait. You seem to think there is something bad about “sleeping a thread” when being able to suspend and resume coroutines is actually a huge and desirable benefit of having them in the first place. You keep mentioning things like “execution freezing” and “needing things to happen in between”, and all this just suggests to me is that you’re not using coroutines effectively or correctly. Of course you don’t want to block your main thread, but no one is suggesting (or doing) that. Wait(n) statements go in your coroutines and event handlers (functions passed to event.Connect()), not your main game loop!

Just to be clear, creating a coroutine that uses wait(n) is a correct, efficient and desirable way to do something like a long fixed delay or periodic, infrequent execution of a block of code. The next best way would be a timestamp comparison inside an existing game loop that’s executing periodically on something like RunService.Heartbeat. For and while loops should generally be avoided for long-running game loops, since they can stop unexpectedly (e.g. if some error causes a script execution timeout) with no way to resume.

[EmilyBendsSpace]

@Kampfkarren

I made an entire thread on how to avoid wait() and why. There is, and as I say in the thread, wait() does not belong in production codebases at all.

This discussion is only about the wait(seconds) variant. The no-argument variant of wait() is a different beast, and I don’t think anyone will contest that there is always a better option for that one.

[colbert2677 (ImagineerColbert)]

@EmilyBendsSpace

What’s not made clear anywhere above is why you are asking how to write code without using wait .

@colbert2677

Essentially what I want to accomplish is coupling event-based systems with a way to perform functionality after a specified amount of time, without sleeping threads.

It’s there in the OP? My reason for writing this is scattered everywhere.

@EmilyBendsSpace

You seem to think there is something bad about “sleeping a thread” when being able to suspend and resume coroutines is actually a huge and desirable benefit of having them in the first place.

I’m not using coroutines. It’s explicitly stated in the OP that I’m using an event-based system. I’m fully aware of how to use coroutines. This thread pertains to abdicating the use of wait(n). Suggesting coroutines initially would been fine, but that assumes I have any in the first place. I’m asking how to write codebases without wait(n), given coroutines or not.

@EmilyBendsSpace

Of course you don’t want to block your main thread, but no one is suggesting (or doing) that. Wait(n) statements go in your coroutines and event handlers (functions passed to event.Connect()), not your main game loop!

See the responses on this thread and my reply to each one of them. If it wasn’t suggested, a solution would be marked now. See above as well. Putting a wait in my event handlers doesn’t solve my issue.

@EmilyBendsSpace

Just to be clear, creating a coroutine that uses wait(n) is a correct, efficient and desirable way to do something like a long fixed delay or periodic, infrequent execution of a block of code.

I do not want to use wait(n). I don’t know how many times that can be reiterated in my responses to this thread.

I’m just going to flag this closed. I don’t feel like it’s yielding anything productive anymore.

[Maximum_ADHD]

This thread seems beyond redemption at this point. Rather than continue arguing about it, lets just put our keyboards down and let it close.