I have a line of code in a script with a CharacterAdded() function that waits for a Powerup tool in a player’s Backpack when they would happen to die and respawn as shown:
Powerup = player.Backpack:WaitForChild("Powerup")
In my game, the player may not die at all so yielding forever is a thing, but I need a way to access the Powerup that shows up in the Backpack coming from the StarterGear after a player may happen to die.
The issue is that I always get the warning of an Infinite yield possible. My script works exactly how I want it with no problems, but I can’t seem to find a way to disable this warning. It can be quite annoying to see it everytime I playtest my game.
Conversely, is there another way I should be going about this?
In your game, the player is able to die? Or never die?
If the player dies, the tool got removed from the player’s gear?
Then you got the infinite yield waiting for the tool, and the tool is not there?
On player death, get the his gear, store in a table, after respawn, give all those tools again, and :WaitForChild(“Powerup”) again.
That doesnt work?
You could add a second argument that determines the maximum yield duration before returning
nil. I would probably set that to a very high number, such as
Omg i hate this i just saw a module that allows you to have custom wait for child’s, let me see if I can find it
In my game, the player is able to die, yes. But there is a chance they won’t die at all.
Also, for your suggestion, 5 seconds after I start playtesting, I get the warning so it gets seen right away. I assume because it’s just in this:
local function CharacterAdded(char)
Yeah, only problem is that in my game, the :WaitForChild() could go on for literally forever because the player might never die, so I can’t really name a time out.
You could make do Child Added, and check if it’s this tool, there’s also Disconnect() which allows you to stop slot of these events.
local reallyCool = game.Players.PlayerAdded:Connect(function()
You can disconnect functions like these when the player dies if that’s your worry.
Hold on, you mean that once the game is starting for first time, you already got the infinite yield warning, without the player dying/respawning or something?
Means that you are trying to get that tool’s instance even when it doesnt exist in the player’s gear?
You should not do that. That :WaitForChild parent should be done once the player collects the Tool, not before when the player doesnt have it
What about just using
local tool = Gear:FindFirstChild instead of waiting for it?
if tool == false then do nothing
WaitForChild, if you are not expecting to wait for the tool cause that doesnt even exist?
Yeah, that’s what I was thinking if I stick with it. Are there any performance issues or other issues with putting the TimeOut as a very very high number?
December 21, 2020, 6:40am
I imagine it’s the equivalent of doing
local timer = 0
timer += .00001
until parent:FindFirstChild(childName) or timer >= timeOut
which could have performance implications if used in mass
December 21, 2020, 6:42am
Its exactly like having a loop, just to wait for a tool, which would not be a good approach, I think, isnt?
Thanks for your help everyone. I think this seems to be the best simple alternative for me:
local function CharacterAdded(char)
repeat wait() until player.Backpack:FindFirstChild("Powerup")
powerup = player.Backpack:FindFirstChild("Powerup")
--tool code here
December 21, 2020, 6:55am
I support you friend, we can do anything we want in our games!
I still think that you added a loop for something which is not required. You will find a better approach on the future :3
You could just do this:
Powerup = player.Backpack:WaitForChild("Powerup", math.huge)
WaitForChild() has a second argument, which is the timeout. Am I missing something here?
You’re right, that should do it. I was not aware of .huge in the Lua math library. Thank you!
If you’re like me, your interfaces are both a) not built with Roact and b) have a whole lot of nested components. As a result, spamming UI scripts with WaitForChild calls seems almost inevitable.
Last year I wound up making a function to deal with the never-ending pain, and I’ve had a fair amount of success with it so I think it’s worth sharing here. It works by accepting the object to start searching from, and then an object path as a string, the same way you would write it to normally referen…
There’s also this module which is just a better Wait For Child.