That’s an okay thing to have, it’s still finding the TextLabel, but the script is also loading faster than the text label, thus it’s warning there’s a chance that it’s not going to load, I’d just add a wait() or a wait(1) to fix it.
Maybe call the variable on it’s own, before cloning it, such as;
local ownPremium = script:WaitForChild("OwnPremium") local ape1 = ownPremium:Clone()
You could also probably try to move the textlabel into the parent/a different place that’s not the local script and then clone it from there, and see if that makes a difference.
Otherwise, there probably was a deletion at first when you just got started to run the game. May I see your “OwnPremium” properties?
If you can’t show, try checking “Archivable” property, if it’s disabled, then that was the problem, it got deleted in the beginning of the game. Setting this to true won’t delete it, otherwise its going to keep deleting every time you start the game again.
Not really, I have done Character:WaitForChild('HumanoidRootPart').Position and didn’t do that problem that the guy had.
The Property Archivable is a thing that you MUST keep it active, otherwise that object with that property disabled will delete the part when starting the game again.
It seemed you gave heart to my comment ApeRuss, was this a solution for you, or was this only a valid tip to know?
Not to get all in and brag, but it’s important to mark the solution as “Solution” so people understand the problem was addressed and help a million others in the future with the same problem.
If this wasn’t the solution, then there could be something else affecting that part and deleting the object itself. You spelled it right and something deleting it is the only troubleshoot I know of.
This is a problem as the game can’t just load everything at once. When you put that FindFirstChild() in there, it will look inside the parent and nothing is there, so it returns nil.
FindFirstChildWhichIsA() won’t work either, as it does the same purpose, find the object, if not, then nothing.
The reason hes using WaitForChild() is because it yields and waits for the part to become present in the parent.
Just think about this, something is deleting the object in the first place of the game, or that Archavible is not active.
Also, cloned objects get place in the parent nil, not directly in the parent of the object was cloned at.
And see if that returns a cloned OwnPremium or nil. If it returns nil then its a loading error, but if it returns OwnPremium, then maybe just keep it without WaitForChild() and just add a wait() above to be safe.
I had the same issue before. I’ve found that if you put “drafts” inside StarterGui/PlayerGui to use them later, it would cause the same error.
Try moving all the script’s children to StarterPlayer or ReplicatedStorage and then clone and parent them again to PlayerGui once you need to load them.
The thing is, we need to know where is that script at. Just because it’s a local script doesn’t always mean player places. Besides, he also should show us what the script’s children look like when playing/testing the game. The Studio edit mode is not the same as playtesting mode.