In my script there are only 8 instances where I use this code. I will show two functions here but there are actually 4 total. Both of these functions are repeated almost exactly as there is also a leftWall and a redWall.
rightWall.Touched:Connect(function(hit)
if frisbee and brake== false then
if hit==frisbee:WaitForChild("Handle"):WaitForChild("Body") and frisbee.Parent==workspace then
local sound=frisbee:WaitForChild("Handle"):WaitForChild("FrisbeeWallHitSound")
sound:Play()
local clonedSparks=frisbeeSparks:Clone()
clonedSparks.Position=frisbee:WaitForChild("Handle"):WaitForChild("Body").RightAttachment.WorldPosition
clonedSparks.Parent=workspace
wait(.05)
clonedSparks.Right.ParticleEmitter:Emit(50)
Debris:AddItem(clonedSparks,2)
end
end
end)
and
blueWall.Touched:Connect(function(hit)
if frisbee and brake==false then
if hit==frisbee:WaitForChild("Handle"):WaitForChild("Body") then
brake=true
wait(.7)
if frisbee.Parent==workspace then
print("bluewall touched")
frisbee.Handle.AssemblyLinearVelocity=Vector3.zero
pointScorer="red"
pointScored=true
else
brake= false
end
end
end
end)
The error report doesn’t say which line the warning is coming from but I assume its coming from all of them. It is ok but undesirable if the first function doesn’t work as it is just audio and visual effects. But if the second function gets the infinite yield it is game breaking and doesn’t allow a point to be scored ever again. There is never an instance in my code where I destroy the handle. If there is a frisbee, then the handle is in it no matter what. I have also never been able to replicate this in studio and it only happens in live servers.
All waitForChilds() can have two arguments, the thing you want to wait for, and how long total to wait.
To fix this all you need to do is this:
obj:WaitForChild("CHILDNAME",60)
What this does is wait a total of 60 seconds for the thing to be loaded (you can change the time if youd like). By then it should be loaded in and you should be good to go!
I don’t think I was clear enough on the problem. That would get rid of most of the warnings and I will implement it but the problem is that on rare occasions it never actually finds the handle. The reason I’m using the WaitForChild is because if I directly referenced the handle like frisbee.Handle and it couldn’t find it, I would get an actual error saying Handle is not a valid member of tool frisbee.
I think that after 60 seconds if it hasnt loaded in theres got to be another problem.
But if you’re desperate you can use a repeat loop to wait till it is there and set it to that if it doesnt show up to begin with
In your script, calling WaitForChild() inside event handlers can lead to inefficiencies, especially if the child objects are not immediately available due to replication delays or network issues. Preloading these references outside of event handlers ensures smoother execution and avoids potential issues like infinite yield warnings.
Example Implementation:
-- Preload references to frisbee components
local frisbeeHandle = frisbee:WaitForChild("Handle")
local frisbeeBody = frisbeeHandle:WaitForChild("Body")
local frisbeeWallHitSound = frisbeeHandle:WaitForChild("FrisbeeWallHitSound")
-- Connect event handlers
rightWall.Touched:Connect(function(hit)
if frisbee and not brake then
if hit == frisbeeBody and frisbee.Parent == workspace then
local sound = frisbeeWallHitSound
sound:Play()
local clonedSparks = frisbeeSparks:Clone()
clonedSparks.Position = frisbeeBody.RightAttachment.WorldPosition
clonedSparks.Parent = workspace
wait(0.05)
clonedSparks.Right.ParticleEmitter:Emit(50)
Debris:AddItem(clonedSparks, 2)
end
end
end)
blueWall.Touched:Connect(function(hit)
if frisbee and not brake then
if hit == frisbeeBody then
brake = true
wait(0.7)
if frisbee.Parent == workspace then
print("bluewall touched")
frisbeeHandle.AssemblyLinearVelocity = Vector3.zero
pointScorer = "red"
pointScored = true
else
brake = false
end
end
end
end)
By using frisbee:WaitForChild("Handle"), frisbeeHandle:WaitForChild("Body"), and frisbeeHandle:WaitForChild("FrisbeeWallHitSound") outside of the event handlers, you ensure that these references are acquired once and stored for immediate use. This approach improves script efficiency by avoiding repeated calls to WaitForChild() during each event trigger, which could potentially yield indefinitely if the child objects aren’t found immediately.
