Wait(n) is bad, but is there any other solution for this case?

Hi, i’ve been coding for a while and im avoiding task.wait(n) as much as i can since i know it has a bad reputation and is just a code smell anyways but is it still ok to use in this specific case :

Im making a realistic train simulator, and in real life when starting the train, a converter has to spool up, however it stays at half speed for 2 seconds , how can i wait those 2 seconds considering its an actual time delay that has no events linked to it?

1 Like

tick() and repeat/while loops. Simple as that.
Otherwise use task.wait/task.delay

That does not make any sense, why would you make a loop just waiting for something, you’ll have to use wait in that look itself, task.wait() is the same principle and spawning threads just to wait isnt a very good idea

3 Likes

Not really‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎ ‎

1 Like

well yeah you have to use task.wait or wait in a loop else you’re gonna crash the script lmao

1 Like

The only time you should be using task.wait is when you genuinely need to just wait a set amount of time and don’t care about yielding. If you can’t yield, just use something like task.delay.

1 Like

Don’t believe everything you see on the internet, using task.wait(x) is fine if you actually need something to wait without something happening in-between.

Besides, letting a script wait actually gives other scripts more room to execute code.

Everything in a game runs on a single-thread (that includes coroutines, creating a coroutine is basically just creating another script without creating another script).

Computers generally can execute like billions of instructions in mere seconds so it actually doesn’t matter much if your game is completely single-threaded,
it’s rarely ever a problem unless you’re doing some unconventional/super heavy math that takes multiple frames to complete.

The only TRULY multi-threaded logic is if you use actors with parralel Luau.

If your train doesn’t need to do anything, just use a simple task.wait().

IF for some reason you REALLY want to avoid using task.wait() then use RunService instead and tie everything to .HeartBeat or .Stepped and use tick() to measure if enough time has passed.

Though, that’s basically just a loop, but it’ll be synchronized with the physics engine / update of the game.

If your game only has a few trains though, this won’t matter at all.
You could do this for like 10 trains if you wanted.

I’m not entirely sure what exactly you’re trying to do with trains, but it looks like you’ve read too many posts and articles on the internet and are somehow worried about non-existent performance issues.

It’ll be a different story if you’re running 500 trains at the same time for instance.
But using task.wait() is not going to make your game run worse.

There is no correct way of scripting something, just as long as it works and as long as you know how it works and can maintain it.

5 Likes

Honestly, ignore what people are saying about task.wait() - the only real issue is when you’re using it instead of using events, but if you’re doing stuff with specific timing then you may as well use it.

This is just nonsense. task.wait() is EXACTLY that behind the scenes, and that supposed solution has the exact same issues as task.wait() (the main one being that it can take longer than the given time, but that’s only if devices are performing very poorly). @C_Corpze has a good response here.

3 Likes

Thank you for your amazing reply! It kind of feels wrong because people always act like its the worst thing ever and say you’re bad if you use it but its there for a reason.

3 Likes

If using task.wait() was bad then Roblox probably wouldn’t have implemented it in the first place.

When you read things on the internet, always take it with a grain of salt, even if it comes from me.
Because truth to be told, no one actually knows how to write code correctly.

Anyone who claims to be an expert is likely not an expert.
There is no such thing as perfect code.

Just write something that works and is comprehensible.
That’s the most important part, performance comes after.

Optimization is the root of all evil, it should be your last step, and only if performance is actually a problem.

3 Likes

True, all tho wait() itself it kind of goofy when you see that its affected by fps but aside from that yeah just believed it since a lot of people agreed on it

2 Likes

That’s the danger of online conversation.
When a lot of people agree on something it often gets accepted as a “truth”.

For that reason it’s encouraged that you actually always experiment and try to find results yourself.
Test your own code, debug it, see if it works and achieves the goal that you had in mind.

If it works it works.

2 Likes

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