I can’t find the reason that is causing this… My game is FE, I checked the explorer on both the client and server side, both shows that the IntValue exists.
1 Like
Try replacing with local Vin = script.Parent:WaitForChild("Vin"), GUIs have notoriously weird replication rules (at least in my experience).
3 Likes
Does WaitForchild make a difference if the value is already there before the gui is cloned?
That’s what I meant by GUIs have weird replication rules, it shouldn’t but it’s fixed many of my issues in the past. It’s worth a shot.
The script just keeps on waiting for the thing and stops running. The basically means the script is still waiting for the thing to appear, but it already exists… Can you please make a bug report about this?
I can’t make bug reports for other users but I’m hesitant to say this is an engine bug as it’s something seemingly too vague to not have happened before; I’m certain this is simply a user error somewhere.
Try testing again and using the explorer during the play mode to see if the object exists in the actual object inside PlayerGui.
I tested 5-10 times, the object exists in the playergui for both Play mode and server mode. I also checked both the client side and server-side.
- I tried to put that line of wait() ~ doesn’t work.
- I tried to put the code inside the function ~ doesn’t work
- I tried with other types of values ~ doesn’t work
- I tried to put the object as the children of the script instead ~ doesn’t work
- I tried to have the code of line make a direct call instead of using a variable ~ doesn’t work
- I tried Waitforchild which doesn’t produce any errors, but it waits forever
- I tried re-inserting the value ~ still doesn’t work
Bug report needed
If you want to make a bug report you’re free to do so under Rule 15.1, but as I said I’m hesitant to do so for reasons previously stated.
As it turned out, it works in the actual game and play mode, but not the Local Server
sometimes I prefer using a
repeat wait() until parent.ObjectToLookFor
over WaitForChild
not sure how it behaves, but if it does wait indefinitely in the case that the object it should be looking for already exists, then that would justify why I would prefer the method I mentioned
WaitForChild is infinitely better than this in that it instantly gives back control of the thread, doesn’t yield if the child exists. Also that code wouldn’t work unless you used FindFirstChild. WaitForChild will never infinite yield if the object exists.
WaitForChild has a timeout parameter, so it would be a better method to practice.
A good rule of thumb to follow is to always use WaitForChild on anything you’re accessing from the client.