I have a folder and I want to access it from client and get children of it.
The parts are located in workspace from the beginning and they are not created by other script.
The issue is that this code doesn’t guarantee that all children are loaded and I don’t really know any normal ways to fire the code only when I know that all children are already loaded.
I tried to use game.Loaded() event and also looked at this topic:
You should be doing GetChildren() on the Checkpoints folder only when you need to access it.
Of course I want to access it, later in the code I wanted to have a loop on all children but because of the fact that children are not loaded yet I can’t do it (empty loop).
You need to add a checkpoints.ChildAdded event hander for the client script to acknowledge the children of Checkpoints as they are replicated from the server. The children are not guaranteed to have replicated when WaitForChild("Checkpoint") returns, as the Workspace is not a ‘ReplicatedFirst’ level of container.
If you need the client script to know how many children it is supposed to be waiting for, you could have a Server script count the children with #Workspace.Checkpoints:GetChildren() and then add the count to Checkpoints as an attribute or value object that the client waits for.
So it is guaranteed that when checkpoints.ChildAdded is fired all children are already loaded (not only one of them, for example), right?
No, it will fire ChildAdded individually for each child that replicates after you bind to that event. Alone, it’s not enough to know when you’ve got everything.
Is your LocalScript in ReplicatedFirst? The game.Loaded documentation states that game.Loaded only works if the script is a LocalScript in ReplicatedFirst.
Oh, I didn’t know that. No, it is in StarterPlayerScripts. But still, I wrote this in Local Script inside of ReplicatedFirst:
game.Loaded:Wait()
local event = game.ReplicatedStorage.Event
event:Fire()
And after caught it on the client and it it still return zero.
(I will also will be happy if you tell me how to highlight several lines at once, because I had to highlight all this three lines of code one by one)
Thank you so much! I am for sure was not ready for this solution – it seems strange to me.
And thanks everyone else who tried to help 
This might also be because of StreamingEnabled. If you want to keep it enabled, just use the post marked as solution.
Yes, you are absolutely right. I didn’t know about that either. Thank you so much.
Generally, with or without StreamingEnabled, you need to wait for things that are descendants of the Workspace to replicate. Only special locations like ReplicatedFirst, ReplicatedStorage, and the “Starter____” services are guaranteed to have all of their contents replicated before client scripts start running, and then only for instances that are in those locations at authoring time (not added dynamically by server scripts).
So, you often end up with this code pattern where you use GetChildren() or GetDescendants() to handle whatever has already replicated by the time your client script runs, and then the ChildAdded and DescendantAdded events to catch everything that replicates from that point on. It’s cumbersome, but it’s the best way to handle things in a non-blocking way, especially if the client doesn’t know how many things it’s supposed to be waiting for.
If you hard-code a blocking wait loop waiting for some N number of objects, and you either have the number wrong or Streaming makes something not replicate, you get end up with code hanging on the client waiting for something that will never happen. If you do hard code something like this, at least add a time limit, so that if the code ends up blocking too long, it quits and logs a warning for you to notice.
