Thank you for the heads up!
Oh, I see. Does this only apply if youâre parenting LocalScripts to the player? So if I have LocalScripts already in, say, StarterPlayerScripts, they wonât be affected by this change?
I understand that we should be using WaitForChild.
Given how often youâre advising us to use WaitForChild, I assume that this change requires us to use WaitForChild in places that we didnât have to previously. Where do we have to use WaitForChild after this change that we didnât have to use it before this change?
I understand that we should use WaitForChild for all server-created objects. I donât understand where we have to use it now that we didnât have to use it before. Are you advising us to use it just to make sure weâre following proper practices, and not because this change should affect us at all?
2 Likes
I recommend all localscripts, regardless of where they are parented, to have WaitForChild()
From https://wiki.roblox.com/index.php?title=API:Class/Instance/WaitForChild
When working on LocalScripts, it is recommended to always use WaitForChild to access children (instead of other access functions such as the dot operator or FindFirstChild) so that the script is resilient to any loading issues
It will be enforced stricter at join time.
Youâre saying WaitForChild a lot. Iâve never used it while loading in and never had any issues. Saying it repeatedly is making me think something big is going to change and I gotta start adding it in everywhere when I donât really need it(or so I think, given I dont have issues with not having it)
8 Likes
If Iâm understanding right, this sounds like a much more devastating change than you might think then.
4 Likes
Thatâs correct. Coming up, we will be posting more information about joining process. Since we have discovered some cases where a localscript have a chance of referencing a pre-made part without the use of WaitForChild, we wanted to take this opportunity to remind everyone about the importance of WaitForChild.
And if WaitForChild is used in localscripts, this should not affect you at all.
1 Like
if Iâm reading this right, trying to reference workspace.BasePlate in the baseplate template in a localscript has the potential to error. uhh⌠wut. I thought this was only an issue for StreamingEnabled places
3 Likes
Thatâs correct. From the clientâs point of view, workspace.BasePlate is considered a remote part on the server which needs to be replicated, similar to any other part in the workspace.
but up until now, clients downloaded all the stuff in workspace before localscripts ran, so this might break old places D:
5 Likes
To what extent will this make it more difficult for exploiters to be able to do damage to FE games since even more stuff will be hosted via the server instead of the client?
If we are talking about having 100% of the instance be done via server, Iâm assuming that would mean exploiters would be unable to modify the current workspace they are in; therefore, the only things theyâll have access to modifying is client stuff such as playergui and Character.
3 Likes
Sounds like this could be a potentially annoying update. I dont use WaitForChild anywhere because I havenât run into any issues. If Iâm gonna have to toss it in everywhere in my code, thatâs gonna be real annoying. Why change it for the worse?
1 Like
With this change should we be using WaitForChild for each layer when reference instances?
Given line 23, would line 24 suffice or would line 25 be better?
2 Likes
Moving forward since the Player instance from the client will no longer be allowed into the serverâs data model at join time (after this change is active). At join time, there should be very few (if any) instance that are created on the client that are replicated to the serverâs data model, and we are slowly closing up what kind of objects are allowed into the serverâs data model (even if itâs only for a short amount of time).
But what benefit does this offer, either to devs or Roblox in the future or now? This is going to break so much more than you think. I and many others donât use WaitForChild on parts pre-created in Studio in LocalScripts, because it doesnât make sense to. Not only that, this is going to be extremely unintuitive to new scripters and veterans alike (e.g. why does workspace.Baseplate error in the LocalScript? Itâs right there!)
6 Likes
This might relate, but why would I be getting this warning? Shouldnât stuff within LocalPlayer also never be nil in local scripts?
(Screenshot from April 20th 2018)
1 Like
I would recommend line 25. I assume âDefaultWalkSpeedâ is a âIntValueâ (or similar) instance?
1 Like
I think the biggest benefit of this is greatly reduces exploiting in both nonfe and fe games, so no matter if you are a new scripter or veteran, you donât have to fear your game getting exploited (to a certain extent)
Though I do have to agree with it breaking a bunch of old games on Roblox 
1 Like
In what ways does this hinder any form of exploiting?
1 Like
Most of the items will be changed to be on the server instead of client-sided (if Iâve read this correctly), and since exploits are known to modify the client to give themselves an unfair advantage in FE games, putting workspace to be fully server sided instead of it being a duplicate to the client will prevent exploiters from modifying workspace.