Give us some way to know when an object and its children are fully loaded

[EmeraldSlash (Rio)]

This is a similar feature request dealing with the same issue, however it’s based around a different solution. I thought it’d be better if these two things were separated, mainly due to the detail of this post.

---

As a scripter, I find it really frustrating having to write :WaitForChild("ChildName") all the time, for things that I should just be able to access error-free. What is even the point of being able to do Object.Child if it breaks most of the time?

I propose a different solution that I’ve seen work fine on a different engine, and that won’t break any older scripts.

Godot Engine has a function _ready() that runs when the object the script is attached to and all of its children are loaded. It also has a keyword onready added to variable assignments so that it will assign the variable when said condition has been reached.

Example of ready implementation in Godot

onready var child = get_node("child")

func _ready():
    child.connect(signal, func) # hook up a listener

Lua version (for understanding):

local Child = script:WaitForChild("Child")
Child.Signal:Connect(Func)

I suggest all scripts have some way to know when an object and its children are fully loaded. A signal, and possibly a bool property, would be a good solution to this IMO.

Example usage

-- LocalScript inside a ScreenGui
local Gui = script.Parent

-- A ready signal
Gui.Ready:wait()

-- A ready property
repeat wait() until Gui.IsReady

-- Do stuff that could cause an error in the current engine
local Frame = Gui.Frame
local Button = Gui.Buttons.Button1

I can see lots of use cases for this. Not only would this make GUI scripting easier and quicker, it would also allow us to just wait for something to load (e.g. a large map cloned into workspace – goodbye custom map loader system!).

And since we’re just adding stuff, there’s backwards compatibility.

From a design perspective, I believe WaitForChild should be used a lot less, too (about the same amount as FindFirstChild). It’s a method that’s supposed to be for waiting for things that may not be there yet, or at all – and yet it gets used primarily for things we know are there and for things that should be there now.

Thanks

[Extuls]

@EmeraldSlash

From a design perspective, I believe WaitForChild should be used a lot less, too (about the same amount as FindFirstChild). It’s a method that’s supposed to be for waiting for things that may not be there yet, or at all

If your idea comes to be, I think a lot of cases WaitForChild would be used in are cases where the object may not ever even exist, or won’t for quite a while. That being said, right now WaitForChild gives a warning when it doesn’t find what it’s looking for, for a while.

This warning right now is extremely useful and has probably kept me from long debugging processes i would have had to go through. However, if this feature request comes to be, I would like to see that warning done away with. Sometimes it just clogs the output, and with a feature like this the usefulness of the warning would be gone.

[EmeraldSlash (Rio)]

Mm, I agree.

In fact I also think the current warning is another reason to stop using WaitForChild all the time - it makes it so we don’t have to wait those 5 seconds during each test to see if we made a typo with a name, therefore meaning a more efficient workflow.

[berezaa (Bereza)]

I was just going to post a thread like this! But I found a solution to my problem

If you are waiting for a specific instance to be replicated, Instance.DescendantAdded is your best friend. It will fire whenever anything is replicated within a model, and you can just disconnect it once you are certain everything has replicated (after like 5-10 seconds)

[EmeraldSlash (Rio)]

Yeah, that’s a fine temporary solution thanks

It’s just in a UI situation I’d like to get everything up and running ASAP.
(Plus I think I’ve had enough of making custom code to work around this issue xd)

[Shedletsky]

Maybe an intuitive way for a lot of Roblox developers to handle this case would be to implement something like DOM document state in JS, only in this case the “document” is any arbitrary node in the Datamodel that can have children.

This incantation is the most Roblox-like:

document.addEventListener("DOMContentLoaded", (event) => {
    console.log('DOM is ready.')
});

But JQuery also supports the super-slick:

$(document).ready(function(){});

More on this:

http://codetonics.com/javascript/detect-document-ready/

[EmeraldSlash (Rio)]

Being annoyed by this recently. I’m extremely sick of having to write Parent:WaitForChild("Child") instead of Parent.Child. You can sometimes use the Parent.Child method on the client but on the server my game just breaks.

@EmeraldSlash

From a design perspective, I believe WaitForChild should be used a lot less, too (about the same amount as FindFirstChild). It’s a method that’s supposed to be for waiting for things that may not be there yet , or at all – and yet it gets used primarily for things we know are there and for things that should be there now .

Annoying me again too. I know it’s there, why do I have to act like I don’t?

[Quoteory]

Another use case is cloning/adding models that the client will access via .ChildAdded or with CollectionService tags.

I have a weapon giver that clones a custom weapon model into the player’s character when they touch the giver button, and the player detects weapons being added to their character, but since the model isn’t fully loaded I have to use :WaitForChild() on every child I need to access.