Is it guaranteed that when I do
local frame = myGui:WaitForChild("someChildOfTheGUI")
That all of frame’s children will exist, so there’s no further need to use WaitForChild on children of frame?
This is something I never really received clarity on, so I don’t really know if it’s needed or not.
And I guess also just in general if further WaitForChild statements are needed when indexing a child of some parent object.
Thanks.
Instance:WaitForChild Might help.
But generally, WaitForChild is used in cases where you’re not sure that the instance won’t immediately be there. For example, if you encounter an error such as 'x' is not a valid member of 'y' , you should consider using WaitForChild . However, if you’re 100% sure that it will not error, using x:WaitForChild(y) is actually slower than x.y . Also, if you find yourself repeating WaitForChild calls (eg. a:WaitForChild(b):WaitForChild(c):WaitForChild(d) ), I highly recommend this module: link here.
I appreciate your response, but I don’t think you understood what I was posting.
My question is more in regards to how replication is handled entirely. Specifically, is it necessary to use further WaitForChild statements on children objects where you already yield for the parent object to exist.
Not sure I can really answer this question for you, but hopefully this does! FindFirstChild and WaitForChild: Addressing common bad practices and habits of each - #4 by devSparkle
Sorry I couldn’t help you exactly.
No, :WaitForChild waits for an instance to load then returns it. However this does not wait for its descendants to fully load. I know this from experience when using Player.CharacterAdded and immediately direct indexing it’s children (e.g. Humanoid.Animator), it can’t find that instance.
There are priorities when it comes to loading instances. I remember reading up about it but I completely forgot about it, like how parts would load at different times with instances that contain scripts or different types of things (yet again I completely forgot and probably just made that up).
I’m pretty sure it would load all other GUI descendants.
I understand this thread received a bump, but I figured I’d leave a reply with a definitive no for you. This is not the behavior of this method. WaitForChild will return non-nil if that specific instance is prepared for access.
This is an understandable answer. Instances stream from top to bottom, → parent instance loads, child instances load, etc…
“If your game does not explicitly use WaitForChild for every instance that you need to interact with while loading then your game may encounter an issue when we modify the send order in this upcoming change .” - LordRugdumph on traditional instance replication and loading changes. Even before this modification, which I’m unsure of the current state of, this was not the behavior. You should use game.Loaded:Wait() and WaitForChild to absolutely guarantee that instances exist.
Instance:WaitForChild() doesn’t pause the script, so other variables will load.