Yes, to clarify: I would advocate for using WaitForChild on all script-generated objects. If you don’t, it’s pretty common for the first player to join to have timing issues. If you don’t want to name every child something unique though, you can always use the RemoteEvent trick.
With that in mind, the excerpt from the DevHub is still wrong in the more common case of accessing instances that are available in Studio.
Unfortunately yes, you do need to explicitly invoke WaitForChild for each individual descendant that you want to access, not just the root. We do not guarantee atomicity of sending currently. In practice, the instances frequently end up in the same bundle of messages, but it is not a guarantee. You can try this out locally by cloning some huge model (e.g. with 10k+ parts) into replicated storage, using WaitForChild on the root, and then as soon as that returns examining the contents of the clone.
I wrote a post related to instance lifetimes that may be helpful:
The gist is to treat the game tree as a dynamic structure, identify when instances are added, removed, and the conditions involved, and make use of APIs with guarantees as much as possible.
Final question on the topic of script created instances:
It seems simpler to me to merely have a remote function that returns an instance from ReplicatedStorage with the given name as opposed to firing a remote from the server when the player joins or manually waiting for the object on the client. Is this a valid solution or is there some reason remote events would work and remote functions wouldn’t?
Thanks for the answers I have received, by the way. I clearly had a misunderstanding about how Roblox handles replication. I would appreciate it if the documentation was clearer on use-cases for methods like WaitForChild. It might also be nice if there was some visual or worded representation of how things are streamed/replicated to the client on Roblox. Maybe I’m missing some documentation pages somewhere, but I’ve never been able to find a clear source on it and, as a result, have been left second-guessing my codebase at certain points.
This isn’t just me. I have seen too many other developers using WaitForChild everywhere or nowhere. (and just a really bad wait(n) at the start of their client-side code). There does not appear to be general knowledge of how to approach this part of scripting in the community of developers that I have seen, and I think many would benefit from a solid resource. Maybe I’m missing it. I have seen devforum posts, yes. However, they are not comprehensive, and the devhub really needs an update in this department.
Please correct me if I’m wrong.
Status Update: As of late in the day on 8/24 this is now live for desktop clients, with more platforms to follow soon.
This change has broken every RedManta project (Robloxian High School, World // Zero)
We are having a hard time reproducing it ourselves and are working with bug reports from users.
We never saw any issues arise after August 17 when this was supposedly enabled in studio. We only saw users begin having errors when it was flipped live.
Please turn this off to give developers more time to update their projects. This is a huge change unfortunately.
Edit: Reports of other devs saying their games are all of a sudden “exploding” as well
Earlier today we further altered the load order, this seems to have triggered the issues AbstractAlex has mentioned, we just reverted this follow-up change. We will make another post on this thread with an announcement for when we will do a test run of the follow-up change in studio.
Why did this happen without any warning to devs or beta tests? This feels like the definition of testing on live 
When deciding to enable the flag, my (incorrect) expectation was that the flag would not have visible further impact beyond what we had already enabled on 8/24. We will be more careful going forward with this change.
Will this flag being flipped off replicate to existing servers or do we need to shutdown running instances to patch this?
The flag only affected desktop clients. No updates to servers should be needed to resolve the issue, the clients will be resolved after they are closed and they rejoin.
This change seriously had me nervous, popped open studio and BAM! All UI is completely off. I would appreciate the heads up next time instead of just spontaneously enabling a flag that ruined my game’s interface (including billboard UI). I was able to resolve this with code, but please don’t do this again. Ever.
Was this re-enabled? Yesterday I began seeing reports of people not being able to join Robloxian High School, the errors are related to this replication change. Game has not been updated since last Friday.
The secondary change (where siblings are not guaranteed to be in order) has not been re-enabled.
The original change on this thread (where join is not loaded in strict tree-traversal order, but final sibling order is maintained as of when game.Loaded fires) was never disabled / is still enabled.
Ever since this shipped I’ve had really bad ping issues in my game. I believe my issues are related to this update but I really don’t have anything other than timing to link them together.
Is there a way to check if all children of an object have loaded? Or is this not possible and I have to know the names of all children beforehand so I can :WaitForChild()?
LMH_Hutch I’ll reply in your thread
We do not currently have a simple way to verify if all the children of a specific object have loaded or to know all of the children’s names.
You can use game.Loaded:Wait() to wait until all instances sent on join have arrived, but that is more coarse than the apis you requested.
Due to an issue discovered over the holiday weekend with Team Create we have temporarily disabled this change. We will make another post here when we have fixed the issue and are ready to re-enable.
This topic was automatically closed 120 days after the last reply. New replies are no longer allowed.
