You bring up some excellent points, however I know a few users including myself have had issues with our code where the WaitForChild item never arrives, and we don’t even notice it because it yields the entire thread and there’s no way to warm myself that it hasn’t arrived after X amount of time without rigging my own WaitForChild that times out. One of my points of the timeout idea is to help with debugging, and helps the coder know “Did I misspell?” or “Wait, did I instance the object in time/at all?”. It’s assumed that people who are timing out their WaitForChild in these cases can handle when it’s not there with some alternative code or a warning
"One of my points of the timeout idea is to help with debugging, and helps the coder know “Did I misspell?” or “Wait, did I instance the object in time/at all?”. "
I understand those needs, but I don’t understand why you think a timeout is the right way to fill them. All the timeout is going to do is hide the problem, or move the bug to a different place than it is actually ocurring (now you have a nil variable possibly referenced in an entirely different location instead of a wait that’s hanging forever where the problem actually is).
That’s why I suggest the throw-warning-after-set-delay solution, it helps with debugging just as much, and doesn’t encourage people to band-aid the problem.
I also suspect that even most of the rare cases where you’d want timeouts, you’ll find that you really need a more sophisticated instrument than a WaitForChild with timeout to write the logic that you actually want (Suppose for instance that you chain 20 waitforchilds, each with a timeout of 10 seconds, is the user waiting 3 minutes really an acceptable outcome? Because under that code that is a possible outcome.)
Totally support this!
In many cases while I script, a script isn’t working and it outputs no error. Usually its because a waitforchild is waiting for a misspelled object. Having a timeout would make things easier.
Bump. I would really like the long-wait warning that Stravant described in his first post. I’ve spent close to hours debugging when I accidentally delete something from the game and find out I was waiting for it in in a script.
3 Likes
Bumping because I think this should be in the engine. Regular WaitForChild is too tedious because it will not notify you it’s still waiting.
function waitForChild(parent, name, timeout)
local start = tick()
repeat wait() until parent:FindFirstChild(name) or (timeout and tick() - start > timeout)
return parent:FindFirstChild(name)
end
Not an optimized solution, but I don’t see why this is so difficult for you to write if you need it.
I think it would be super great to be able to provide a time until a warning is thrown. So the waitforchild behaves like usual, but if you provide a time and it waits for longer than that time a warning will be printed that tells you what object is waiting for what name, for how many seconds, and what line of what script called the function. The warning doesn’t cause the WaitForChild to change its behavior though.
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. ROBLOX created the WaitForChild method even though it could be accomplished by that same function, and the same principle applies here. If we need to rewrite a ROBLOX function every time we use it, that should be a big red flag that something is probably wrong.
1 Like
We’re considering adding a studio setting to warn after a set amount of time. There’s some internal discussion on this too, but I want to get the community’s feedback.
Behavior would look closely like Nevermore’s current WaitForChild implementation, where after a set time (5 seconds),
What behavior would you prefer? Would a warning after a few seconds be annoying (i.e. is anyone using children + WaitForChild as a hacky yield system (i.e. MyFlagsFolder:WaitForChild("FlagGameReady"):Destroy()))
1 Like
Is it possible to get the warning to display in the in-game developer console as well? Occasionally I’ll come across a bug where I’m waiting for something to exist with WaitForChild, and it works fine in Studio, but it never exists online because of lack of replication (e.g. me waiting for something to exist that was created by the client in a FE game). It’d be awesome if it were possible to get warnings in-game as well.
Regarding the hacky usage of WaitForChild though, I personally never use it to wait for something that’s parented minutes later – I always use it to wait for pre-existing children that haven’t loaded in yet.
This would be possible if we changed default behavior to always warn on timeout. This will be fine unless someone is using WaitForChild to yield threads to handle tasks in their game code. In that case, the warning becomes annoying.
I sometimes use WaitForChild for certain object markers to be found, but typically those systems only yield for a quarter-second or so.
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. Leaving the parameter out would assume no timeout thus allowed to wait indefinitely. Example:
local success, someItem = pcall(function()
-- Maximum yield of 5 seconds; throw error if elapsed time exceeds given timeout:
return model:WaitForChild("SomeItem", 5)
end)
if (not success) then
error("Something ain't right: " .. someItem)
end
2 Likes
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.
1 Like
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.
1 Like
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:
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.
2 Likes
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.
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.
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.
It would still cause a warning though in those situations because it waits more than a couple seconds.