No, lol … I really would put a wait on that too. Considering the GUI isn’t working. I’m almost sure that is what trigged that warning.
1 Like
I have to agree. No experienced programmer throws arbitrary-length yields into code to “speed up loading”. This is absurd, particularly in an environment like Roblox where the API not only lets you wait precisely for any specific instance or any RBXScriptSignal event, but has support for coroutines you can use to keep yielding calls from blocking unrelated code. Lots of top devs are using a promise system built on top of coroutinues to get optimal load times.
There is simply no need to ever put some N-seconds wait in a script; this is something new programmers do because they don’t know what they need to wait for, how long, or what events are associated with it. And, as I already noted, doing this can hide problem race conditions, making things work fine in Studio but failing once deployed to an actual client-server system.
4 Likes
InfiniteYield happens after 5 seconds but will continously to wait for the Instance. By setting the TimeOut though it will not make the Warn appear. But the TimeOut may be a bad idea since maybe the client will not be able to load the instance(s) while they are joining in
1 Like
You can have a masters degree and still be wrong? This is not a good practice at all
5 Likes
Yes you can … and being wrong always leads to being right when programing.
Also I’d like to note I said task.wait(3) not wait(3)
Have a great day arbi
1 Like
Why not explain then how your 3-second system is better than knowing exactly what your code is waiting for, and binding to specific events, or using promises, callbacks, etc. And what is the significance of the 3 seconds, as opposed to say, 2, 5, or 10? Neither grade-school hubris, nor “it works for me” are going to convince me that arbitrary waits are a great idea I’ve just been missing out on this whole time.
1 Like
Three seconds is about the time it takes for the default system to set up. At that point your game will load as is. This is only for the start up and not something you would use at every turn. This takes off a bit of the script “slam” trying to process at the same time. And in some cases (like this one) a few scripts are using the same object. While one is waiting for child the other is tossing a possible error. Both scripts should have the wait for child. In this case the wait exposed that. You are correct in your thinking. But a slight task.wait() isn’t going to hurt anything and make the flow go a bit smoother on load up. This is far from a new trick. example: I have games that take 5-8 seconds to load, doing many things in the background setting up. With this they all load in 2-3 seconds. Myself I do it both ways. First I make sure it loads as is as it should (as you’re saying) then I start looking for scripts I can pause a bit like I’m saying to make the others set up smoother. This is something you must do in assembler as there is no wait for child command … I tend to take lessons learned from deeper languages. I also agree with you with a wait() but a task.wait() is a bit different. That will do this well published or not …
Also great question on why the 3 seconds and not more …
3 Likes
Update. Rewritten for the sake for conciseness.
Is there a chance Instance Streaming is the root of the issue? It’s not clear whether you are trying to reference the part on the client’s or server’s side. Streaming is enabled by default as of a short while ago, and it is mandatory the code is adapted to expect instances streaming in and out of workspace. If that’s the problem, then I recommend disabling streaming until you learn more about it and how to utilise events, object values, model streaming behaviours, and other things, because WaitForChild() alone isn’t enough - in fact, instances in unvisited regions might never stream in.
It’s a fair point that grows more important as the game scales larger. Controlled and ordered yielding is definitely one of the means. The solutions depend on one’s framework and how the game is launched. Modularized architecture really comes in favour here with the control it offers. The whole game doesn’t even have to be loaded as soon as possible, we can start the processes gradually based on priority and require components once we need them (lazy loading).
@EmilyBendsSpace is asserting task.wait() for solving timing problems is usually not wanted in production code because beside of a few valid described use cases it is often (ab)used as a patch or magic code that just works (with time, who knows why?). A fixed wait can often turn out to be too long, but other times an internet connection could suddenly start to channel its inner turtle and cause havoc if the yield exceeded task.wait(n).
I’d argue unexpected yields are the most troublesome of all unpredicted behaviours.
Unless we start parallel execution, the scripts are resumed in serial. Multiple simultaneous WaitForChild()s simply yield all the calling “threads” (unless the object already exists in which case it doesn’t yield at all).
Sorry for the lengthy reply.
1 Like
As far as that warning, pretty sure there is no waitforchild in that GUI to the same object.
And this rob cycles thing should never be used to fix anything. Everything should work without it.