So, I only use WaitForChild when my scripts are guaranteed not to work without it. (i.e declaring instances stored within the workspace with a LocalScript)
When I created variables for some instances, the scripts worked most of the time, but on rare occasions, the scripts errored because I needed to use WaitForChild on some variables.
When I re-ran the game, the scripts worked as if nothing happened, but they just rarely error because of not using WaitForChild on some variables, which may make the game error for specific players as well, if they’re playing on low-end devices.
At this point, should I use WaitForChild on almost any variable referring to an instance?
You should use WaitForChild in local scripts (because it takes a while to load on client) and on instances that are created later on from the start of the game.
You don’t have to use WaitForChild at every variables. You can do same thing im doing with this.
When i create scripts, i use FindFirstChild and WaitForChild equally, but mostly findfirstchild.
To use findfirstchild you have to make sure you’re checking in the instance. If you use findfirstchild in a nil object it will return an error called “attempt to index nil” something like that.
if you have to get variables at start of script then yeah, i recommended you use waitforchild. that’s what im doing too.
for local script i strongly recommended you use waitforchild at starting of scripts. the client takes a bit to load.
For client-sided scripts, I always use WaitForChild when indexing children of instances, although only if they’re guaranteed to exist, otherwise you could run into issues with infinite yields. If they aren’t guaranteed to exist, I use FindFirstChild
Using WaitForChild in server-sided scripts is optional with the exception of a few cases (such as waiting for an instance to be created by another server script), although some players have experienced situations where server scripts run before all instances have loaded, so you could use WaitForChild in server scripts just-in-case
Remember that players use a variety of different devices (even their network connection quality makes a difference), so it’s not guaranteed that instances will load at the same or close enough time that they will for you, which is why using WaitForChild is recommended
“although some players have experienced situations where server scripts run before all instances have loaded, so you could use WaitForChild in server scripts just-in-case”
The reason behind why Instance:WaitForChild is used on the client is because the requested instances may still be in transit as the client downloads (streams) them from the server. This typically occurs when the client first connects to the server, but can persist if streaming is enabled. The server does not need to concern itself with instances “loading” as the instances in question were being downloaded from that same server; the instances you speak of originate on the server alongside the Scripts that interact with them, so there should never be a case where any shipped game assets need to be downloaded on the server. The only scenario where Instance:WaitForChild should be used on the server is when instances are created at runtime.
There are also some exceptions on the client with atomically streamed assets whose existence is guaranteed prior to the LocalScript’s execution. This means you can guarantee all of the descendants of the related assets. If I am not mistaken, one of these exceptions is with all children of PlayerGui. Models in “StreamingEnabled” mode can also be streamed atomically by the developer, meaning only one Instance:WaitForChild call is required to first gain access to the related model
In experiences with streaming enabled, I prefer using tags and CollectionService for handling instances, both for client-sided scripts and server-sided scripts (this method is best for groups of similar instances, such as street lights)
Now that it’s possible for client-sided scripts to run in Workspace (thanks to the RunContext property), you could store the script as a child of the Model itself, which makes accessing the Model’s children much easier (this method is best for unique instances, such as a clock tower. Using this for groups of instances is not recommended, as it makes updating them a massive pain)
Using WaitForChild is also optional for accessing instances stored inside of ReplicatedStorage, both from client-sided scripts and server-sided scripts
There’s also the fact that some players prefer indexing instances using WaitForChild in-order to differentiate between indexing a property
Even though I’m aware that there’s no need to use WaitForChild in server-side scripts (with the exception of some special cases), I still find myself having to use it whenever I’m using strict type-checking, in-order to avoid an annoying type error (An example of the error I’m talking about: Key 'Humanoid' not found in class 'Model')
