Instance:WaitForChild(string Name [, int TimeOut])

[EchoReaper]

@Crazyman32

I feel like I’d rather have a second parameter called “timeout” or something and it would throw an error if that amount of time is reached.

Should default to a couple seconds though and need to manually be set to 0 if you want to disable it in edge cases. Having to explicitly specify you want a warning on timeout would cause the feature to go unused most of the time, and problems unnoticed.

[Sharksie]

My ideal workflow is that in studio I want to know if my WaitForChild is hanging, but online I don’t want my game breaking, and while I’m programming I don’t want to write a ton of bubblewrap to protect my game from failed calls.

I think the ideal solution is to have an optional timeout argument that defaults to 0 (no timeout). Then have a studio setting to change the default timeout while you’re in studio. This way I can set all my timeouts to 5 seconds and test them quickly in studio, then run my game online and not have to worry if something goes wrong and takes 6 seconds.

[EchoReaper]

@Sharksie

but online I don’t want my game breaking

This is not an error – it’s a warning. It will not break your game. The default should be a few seconds because there’s no risk of breaking games since it’s a warning, and you can manually set the optional timeout to 0 or filter out warnings of the dev console if you don’t want to see warnings for some extremely niche thing you’re doing. The reason the timeout is helpful is because it tells us something is wrong when we weren’t expecting it – requiring us to manually enable the timeout warning defeats the purpose for the same reason as this:

@EchoReaper

@woot3

Not an optimized solution, but I don’t see why this is so difficult for you to write if you need it.

Because you have to include it in every single script, clientside or serverside, in the entire game. Don’t put it one and use WaitForChild in that script? Oops – no more timeout warning.

[Digital_Boy]

Didn’t we just disable the FormFactor warning though? We shouldn’t force warnings on people because the way their code worked for a long time is suddenly not optimal because of a change.

[EchoReaper]

Huuuge difference between FormFactor warning and timeout warning. The FormFactor warning was annoying because it magically appeared for something used extremely often and that it was beyond the control of the person using studio (plugins). Timeout warnings have no such issue – waiting more than a couple of seconds with WaitForChild is an edge case and nowhere nearly as common as the usage of FormFactor, so even if it does happen in plugins, it’d be extremely rare. Also, the FormFactor warning was useless since FormFactor doesn’t affect code – infinite WaitForChild yielding does affect code, and knowing that is more important than preventing some rare warning out of a plugin that has 2 installs.

WaitForChild timeout is entirely useless and nobody should even bother implementing it if it’s not on by default. The entire reason the timeout is needed is because something unexpected happened outside of our prediction. Asking developers to foresee and troubleshoot a problem in advance that they already couldn’t predict is dumb.

[Digital_Boy]

I don’t think waiting for more than a few seconds is an edge case. It’s really useful to tell if certain objects are loaded on the client. Some things like SurfaceGUIs aren’t placed on their adornee properly if you have streaming enabled, using :WaitForChild() solves that, it waits until the part is loaded. Waiting for parts to be added for something before it continues, etc.

[EchoReaper]

Those are not edge cases. WaitForChild should not warn for timeout under normal usage like that. An example of an edge case is:

Script:
workspace:WaitForChild("CapturePoints") --Wait for another script to parent CapturePoints to workspace and start game mode from this script

instead of having the game mode being handled by the script that creates CapturePoints.

[Digital_Boy]

@EchoReaper

waiting more than a couple of seconds with WaitForChild is an edge case

It would still cause a warning though in those situations because it waits more than a couple seconds.

[EchoReaper]

Then you can manually set the timeout to 0. In the event you’re waiting for something due to StreamingEnabled=true, you’re in full control of the place, unlike someone else’s plugin.

[1waffle1 (Waffle)]

I wouldn’t want a warning if I were using WaitForChild for something other than delaying a script from trying to access something that hasn’t loaded yet, but I would want a warning if that was what I was doing. Really I just think I should never need to do that though, so then WaitForChild’s only purpose would be these so-called “edge cases.”