Try doing:
local loadedui = game.Players.LocalPlayer.PlayerGui:WaitForChild("MenuGui")
--ui is now loaded, now call the parent
local info = script.Parent.Parent["HeaderContent"].Info
@iNoobe_yt, any luck?
What I would do is use one script at the root of the entire GUI and WaitForChild as I drill down to what Iām looking for.
Still getting the error
That means youāll have to do it the long way, unfortunately.
local info = game.Players.LocalPlayer:WaitForChild("PlayerGui"):WaitForChild("MenuGui").Menus.Worlds:FindFirstChild("HeaderContent").Info
So you use recursion to iterate through all the children and reference them in a dictionary and refer to the dictionary instead of navigating the hierarchy?
Just WaitForChild everything.
It worked 
Make sure to mark it as the solution then 
. The Parent issue is still pretty weird.
1 Like
Thatās certainly one way to do it.
Just to note, guis do not load right away if their parent has already loaded. This functionality only works for scripts and their descendants. (In short, itās not a bug.)
1 Like
I mean by the time you check if the UI is loaded, you already referenced the entire hierarchy (well not really but you know what I mean).
Itās for reasons like this why I stay away from putting any UI-related scripts anywhere that isnāt a place directly descending from the LayerCollector. You get strange errors, such as this parent error and then what seems like a really easy fix starts to become complicated.
To begin, I wouldnāt recommend using spaces in your object naming convention. Thereās nothing wrong with it but normally you only need Name for internal reference and reserve spaced naming for items such as NPCs or places where you explicitly need the name property to be something for display purposes.
Throwing in waits or WaitForChild wonāt solve the issue, because itās an issue with ancestry. Even then, remember that cloning is a synchronous operation. So long as the LayerCollector is available, so will the descendants of the Gui. The LocalScript canāt run if its ancestor doesnāt even exist.
Is it absolutely imperative that you have a LocalScript buried that deeply into your object hierarchy? Perhaps you may want to think about reorganising your code so that you can adequately fetch the descending object, or throw print statements to find out why exactly itās returning nil.
Give me some time to throw a quick repro of the issue, I want to see whatās going on and see if thereās a way to fix this. Entering in from the Playerās PlayerGui is a frankly unnecessary method of handling this issue and merely a band-aid fix. Thereās an underlying problem thatās not being addressed.
3 Likes
Should I put the local script directly under the ScreenGui instead?
I usually have LocalScripts near the top of the hierarchy, so I never face issues like these. And Iād recommend putting it @iNoobe_yt.
I created a bare bones repro of the issue to see if I could replicate the problem. I only recreated the object hierarchy up to the extent that is relevant to the issue, as well as the line of code thatās supposedly finnicky.
Strangely enough, I havenāt been able to replicate the issue. This here does not throw any errors. Iāll have to concur with you that this is a strange happening.
For the sake of getting a hands-on look at the problem and perhaps being able to determine either a cause or a fix for the issue, would you per chance be willing to provide a truncated version of your Gui in a file, uploaded in a response to the thread?
It would also be helpful to know how the Gui gets into the PlayerGui (if you put it in StarterGui), or if thereās anything that affects the object hierarchy.
No. Any Gui coding should exist in the LayerCollector.
What is necessarily wrong with placing the LocalScript in StarterGui?
1 Like
I never said thereās anything wrong with doing so, but itās bad practice. PlayerScripts superseded StarterGui as a container for holding client-side game logic, unless you have code thatās being sent from the server or itās a script you want to run upon each respawn (even though you can handle this manually).
When scripting a Gui, for organisational purposes, it is much more preferred if you contain your logic in the related LayerCollector. If you start adding scripts to StarterGui, you end up with a cluttered object hierarchy with mismatched items.
In addition to this, having your LocalScript directly under the LayerCollector makes for good organisation when indexing variables. Itās also easy on the eyes for developers and potential collaborators to understand where the relevance of a certain script belongs.
In terms of performance, the LayerCollector ancestor will be implicitly available to the LocalScript since its execution will only begin as in when the script is moved to a location where LocalScript code executes. Likewise, itās children also should be (though if they arenāt, you can just call WaitForChild on immediate children of the LayerCollector and index other descendants with dot syntax or whatever).
Itās not worth shooting yourself in the foot for band-aid solutions or unclean hierarchies. No oneās going to stop you from putting a LocalScript for Gui1 in StarterGui, but for the sake of your own sanity (and anyone elseās), just donāt do it.
I just hold all my LocalScripts in a Folder (organizational reasons),
and I really donāt think this is a āsanityā issue. Could you provide some information on this, preferrably documentation?
Information on what? You quoted a very obscure part of my post, which was made in addendum to the whole response.
Documentation on LayerCollection, as I canāt find any.