So currently I’m having a problem where my script is unable to find a folder that is a child of this tool. I’ve already printed every child of the tool and the folder I’m looking for is in the print. But whenever I try to define the folder it turns out being nil.
–Defining the tool with my inefficient coding
local gun
local guntry1 = plr.Backpack:FindFirstChildOfClass('Tool')
--player only has one tool
local guntry2 = plr.Character:FindFirstChildOfClass('Tool')
if guntry1 then gun = guntry1 end
if guntry2 then gun = guntry2 end
if not gun or not gun.Parent then print('No gun') return end
Use WaitForChild instead of FindFirstChild in this case. Add the optional timeout to debug, if it still doesn’t work you either have a typo or something prevents the object from entering the hierarchy. FindFirstChild you get an object or nil, since you don’t check it just throws an error.
Note: Adding a timeout also lets it return nil, so you have to check if you include it.
Before I answer your question, let me hit you with a nice block of code. I’d put more detail into it but for the purposes of getting to the point, I’ll give it to you straight.
local gun = plr.Backpack:FindFirstChildOfClass("Tool") or plr.Backpack:FindFirstChildOfClass("Tool") or nil
if not gun then warn("No gun") end
I’m not entirely sure why you’d want to us FindFirstChildOfClass in the Backpack since you’d probably be harbouring a number of tools in there already, but this code just shortens what you have to two lines. Just a little tip for later, if you’re up for adapting it.
You should use WaitForChild to get the Attachments folder. Make sure to use the timeout argument as well so your script doesn’t hang because it can’t get that folder. You also don’t want to call a method directly after getting the child, whether or not you’re using FFC or WFC. If either returns a nil, an error will be thrown that you’re attempting to call something on a nil value.
-- No --
A:FindFirstChild("B"):C()
A:WaitForChild("B"):C()
A:WaitForChild("B", 5):C()
-- Yes --
local A = B:FindFirstChild("C")
if not A then warn("No C") end
local A = B:WaitForChild("C", 5) -- If not found in 5 seconds, stop yielding
if not A then warn("No C") end
if not A:FindFirstChild("B") then warn("No B") end
if not A:WaitForChild("B", 5) then warn("No B") end
local A = assert(B:FindFirstChild("C"), "No C") -- Will throw an error if nil returned
local A = assert(B:WaitForChild("C", 5), "No C") -- Will throw an error if nil returned
local success, result = pcall(function () return A:FindFirstChild("B") end)
if not success then warn("Didn't work") elseif not result then warn("nil or false") end
-- etc.
That’s one solution, however it may not still address the problem. Depending on when the children are supposed to get cleared, the tool should already exist.
@Zooleos So to answer that, when you are you trying to clear the children? When did you print all of the children? (Something could have happened to the folder in the meantime – another way to verify this is to look at the tool’s children when this code is supposed to run.)
@colbert2677 Yeah nice code block, I’ll give a quick explanation of how this works so the OP knows. Basically the ‘or’ condition makes it so you can give two values, and the one that is true or simply exists will be returned. It works similar to an if statement. Here’s an example:
-- returns the first value, because it is true
true or false
-- returns the second value, because the first is false
false or true
-- returns the first value, because it exists (isn't nil, isn't false)
"hey" or true
-- same deal as above
1 or true
-- returns the second (color) value for the same reason as above
nil or Color3.new(1, 1, 1)
-- essentially your tool scenario, if Part is nil then it'll return OtherPart instead
-- (if OtherPart also is nil, it'll return nil)
workspace:FindFirstChild("Part") or workspace:FindFirstChild("OtherPart")
something else I noticed that is kinda odd is that the function works the first time (to equip the player’s data) but anytime afterwards it throws the error. I don’t have anything in my function that would actually destroy the object.
Pretty sure this is a bug in studio that came with the most recent update. I’ve been experiencing the exact same issue of returning folders parented to the tool as nil when I was working on tool animations (In a project which I’ve had and which has worked properly for months now).
I considered it might not be the case, as there might be more conflicts with tools going down, but enough big games use pseudo-tools at this point that it may not initially present itself as such a big issue.
