Right now Intellisense can infer the type of a GetService call. For example, if I type game:GetService("RunService"): then the methods of RunService will show up for me. It would be incredibly useful if WaitForChild could do the same thing. Intellisense would take the first parameter of WaitForChild and see if there is a child with that name. If there is then it would respond to . and : just as it would if the child were directly accessed with a .. If there is no child with that name then it should do what it does now (nothing).
Basically, aaa.bbb and aaa:WaitForChild("bbb") should effect the same response from Intellisense if bbb is a child of aaa.
Don’t forget FindFirstChild on this too. I think the largest issue why this doesn’t exist right now is that they have no way of knowing what the kind of object you are waiting for/finding is.
WaitForChild makes sense because you might want to use it for client-side stuff to wait for things to replicate; thus, there are cases where the object exists in the game hierarchy (which is why intellisense makes sense for it), but there still might be value to have the client wait for it.
However, intellisense withFindFirstChild doesn’t make a lot of sense. If the object is there, why are you using FindFirstChild to begin with?
local rightShoulder = torso:FindFirstChild("Right Shoulder")
if not rightShoulder then return end
doStuffWithRightShoulder()
but this is on an object that is created at runtime. Even when working with something other than character joints the objects are created at runtime. Because of this, they wouldn’t exist for intellisense to pick up. That being said, do you have any specific use cases for when something is already created in Edit mode that may not exist while the game is running?
My game is over 100,000 lines of code and doesn’t use WaitForChild once. Ideally your entire script should run after what it depends on replicates. I avoid yielding as much as I can.
How do you ensure that a script runs after what it depends on replicates? Also there’s nothing wrong with yielding to wait for all dependencies at the beginning of a script. I think that’s very common practice.
If this were the case, WaitForChild would never have been created. Maybe for your specific design preferences it’s yucky, but this is the first time I’ve ever heard anything negative about WaitForChild. You’re right that there’s no need to yield on the server because AFAIK scripts run after the game is loaded, but objects aren’t replicated to the client instantly. Not a problem if you’re creating them from the client or passing data over RemoteEvents, but disjunctive services (e.g. StarterGui and Characters) aren’t able to cooperate in that way.
What mainly bothers me is seeing people exclusively use nested WaitForChild’s many times in a script because they can’t reliably predict what gets replicated when. WaitForChild can be used for rapid prototyping and compatibility with other scripts, but a good game architecture has clearly defined dependencies. I stopped using StarterGui long ago because gui scripts ran before the gui finished replicating (I’m not sure if this is still the case) which is just broken. I think a character’s model should be fully populated with roblox’s default instances before it is set as player.Character, and gui’s should be fully replicated before the gui scripts start running.
Instead of waiting for things to snap into place over time, I prefer when scripts request/create them proactively; ModuleScripts enable us to do just that. Imagine if you needed to use :WaitForService() instead of :GetService(), that sums up how I feel about :WaitForChild().
You don’t need to defend yourself. This thread shouldn’t turn into a discussion of who’s development practices are better, and it’s not widely argued that WaitForChild is bad, so a feature request for it is reasonable.
I recently found out that Intellisense infers the return type of modules. However, it can’t when the path to the module has WaitForChild in it since it can’t infer the type of the ModuleScript itself. I’m going to bump this since it would make coding in Studio so much better.
The use case for WaitForChild is probably 80-90% to wait for stuff in the game model to be replicated that we know will be there since it’s there in Explorer when we start the game. We might accidentally WaitForChild something that’s there in the game model when the game starts up and then gets removed before the WaitForChild gets run, but there’s almost no damage done by adding this feature and showing the type information of the object anyways. If we’re using WaitForChild in a case like this, there are much bigger real problems that could actually break the game. What I’m asking for is just a script editor feature. The worst it can do mildly is confuse someone. The positives that would come from it waaaay outweigh this tiny potential problem. Also, the case where we WaitForChild something that isn’t in Explorer when the game starts is irrelevant since we wouldn’t have any type information about that object anyways.
tl;dr
There’s no bad that can come from this feature. If it shows correct Intellisense for WaitForChilded objects that are in Explorer and don’t get removed, great. If it shows incorrect Intellisense on WaitForChilds that infinitely yield, nothing bad happens really. The game that has WaitForChild calls that infinitely yield is broken and the incorrect Intellisense won’t get in the way of fixing it.
You don’t need a staffer to comment on your feature request thread to get it to be considered or worked on. Whenever they post, it is mostly just to request more details or to point out complications with a request. You can rest assured they go through all feature requests and prioritize them appropriately.
If a feature request here is popular and isn’t roadmapped or worked on for a really long time (like most popular requests), there’s one of two things that could have happened. Roblox either could have rejected the idea or they could have made it a task. It’s not really likely that they would take such a long time to decide between the two. There’s also the possibility that they didn’t read the idea, but I’m ruling this one out since we’re told they consider all of these ideas.
If they’ve rejected the idea, then it really deserves an explanation for why. Not providing one leaves the many developers who supported the idea out of the loop and makes them feel like their feedback isn’t being taken seriously. It’s unprofessional and unsatisfactory for a company that cares about developer relations.
If they’ve made it a task, then the Studio team might need more resources. A turnaround time of a year or even half a year to just show up on the roadmap is bad, especially when many of these requests (including the most popular: Disabled Scripts) are small UX improvements. Now, Roblox may offload resources from Studio to other to other areas they find more important, but I think it’s reasonable to say that Studio feels at most “ok” compared to other game engines. If Roblox is fine with that, there’s not much we can do, but I would argue that they will lose most developers coming from other platforms.
The Studio team may also have enough resources to work on these ideas but might instead be working on other tasks. In that case we’d simply have really bad task planning. The people on this forum are virtually the only people who use Studio extensively, so what we think Studio needs should be the biggest factor in planning tasks for Studio. Again, if what we think Studio needs is at odds with what Roblox thinks, they should communicate with us about it.
I hope this covers all of the ways we could be seeing the kind of output we see with Roblox on Studio feature requests. I want to end by saying the most important thing that’s missing is communication. Disabled Scripts not having any staff response is a failure, and there are plenty more examples of bad communication here: Search results for 'features #platform-feedback:studio-features order:likes' - Developer Forum | Roblox. We wouldn’t have to speculate and go through all these different cases if Roblox would simply tell us the status on old and popular feature requests.
