Hi everyone!
I have got an awkward warning. My line of code is this:
local EnterShop = game.Workspace:WaitForChild("EnterShop")
Whenever i join the game, the script thinks that the part doesn’t exist, even if it’s in the Workspace:
I don’t know what’s going on, i want help from some people so i can continue my developing adventures! 
Many scripts don’t need to start the moment the game starts. I find it very useful to add a task.wait(3) to the top of most scripts. This has a few benefits, one being a nice smooth fast game load. Still use the waitforchild() however … gl
Specifying a maximum wait time will suppress the warning, and let you handle it yourself,like so:
local EnterShop = game.Workspace:WaitForChild("EnterShop", 60)
if not EnterShop then
warn("EnterShop not found")
end
This will yield for up to 60 seconds, and if EnterShop doesn’t show up, the variable will end up nil and the script will continue executing.
Don’t do this, this is a recipe for hard-to-diagnose race conditions. Waiting for an arbitrary amount of time in order to fixing poorly-coded loading scripts is classic Roblox code smell.
Use it all the time on scripts that don’t need to load right off the bat … even my biggest games load in 3 seconds or less. Never had a problem with this myself.
It’s not that my script are written poorly … they work either way. But this will for sure make your load smoother for the entire game.
It’s not a good practice, contributes to most of the reasoning as to why people use frameworks
I’m trying both of your ideas, i will try them right now, i put this:
task.wait(2)
local EnterShop = game.Workspace:WaitForChild("EnterShop", 60)
if not EnterShop then
warn("EnterShop not found")
end
I’ve been programming for 4 decades. Time management is simple. I know what scripts to do this on and what ones to not … I wouldn’t have said it if I wasn’t 100% sure it works.
Are you … 40?
(character limit)
lol almost 60 … programming is my one true love in life!
It actually worked! But there’s another error that i had even before, when i step on the EnterShop part, it doesn’t make my shop Menu (or Frame) visible. But in the properties it says it’s visible but in-game it is invisible.
This is just a small stall … it’s not a fix all. As for the menu you may not have it set up right to see in the 1st place. idk … pull it out of the program and test it on a different one. I would have to look at it to say for sure what’s going on.
But the OP does not. You’ve recommended adding arbitrary wait to a script you know nothing about the context of, like it’s a magic fix that will work anywhere.
What I’m saying is that if a new coder “fixes” their scripts by putting a wait(3) at the top, it allows them to write bad code anywhere below this that doesn’t have the correct yielding behavior, and just works “most of the time”… until in the live game something takes 3.1+ seconds to replicate, then it all comes crashing down.
Adding a task.wait is completely unnecessary. This “Infinite yield” warning shouldn’t affect your game at all. Anyway, the other problem likely has to do with client-server replication. You should use a RemoteEvent to tell the client to open the menu.
Edit: the facepalm wasn’t directed at you, @KCapre_Dev
I’m sorry, i am just a beginner developer and i don’t know much about scripting, but maybe thanks! I think it will help me in the future.
An infinite yield possible error is that when you wait for the child but it will probably take infinity to load or it doesn’t exist.
“Infinite yield possible” is a warning that’s generated anytime WaitForChild() called with no max time limit has been waiting for 5 seconds. It’s not an indicator of whether or not the thing you’re waiting for will actually load, more of a heads up to let you know there might be an issue.
come onnn, you’re trollingg
No, lol … I really would put a wait on that too. Considering the GUI isn’t working. I’m almost sure that is what trigged that warning.
I have to agree. No experienced programmer throws arbitrary-length yields into code to “speed up loading”. This is absurd, particularly in an environment like Roblox where the API not only lets you wait precisely for any specific instance or any RBXScriptSignal event, but has support for coroutines you can use to keep yielding calls from blocking unrelated code. Lots of top devs are using a promise system built on top of coroutinues to get optimal load times.
There is simply no need to ever put some N-seconds wait in a script; this is something new programmers do because they don’t know what they need to wait for, how long, or what events are associated with it. And, as I already noted, doing this can hide problem race conditions, making things work fine in Studio but failing once deployed to an actual client-server system.