If CharacterAutoLoads is set to false, then when a player joins a game StarterGui will not load any UI onto the character’s screen, and no UI is parented to their PlayerGui. The only way I could manage to get a GUI onto the player’s screen is to manually parent it to their PlayerGui. Is there a better way of doing this?
This is about the best method i can think of. Insert a LocalScript inside StarterPlayerScripts and then parent your ScreenGui to said LocalScript like so:
and in that LocalScript you only need to type in one line which is:
script["YourGUIName"].Parent = game.Players.LocalPlayer.PlayerGui
you have to change “YourGUIName” to the name of your gui.
5 Likes
In my opinion, as I have no experience with CharacterAutoLoads, if it is no Imperitive for your player’s character not to load, then load them, maybe in a hidden part of the map, then TP them (or similar) when they use the GUI to do whatever.
Again this is just a small suggestion and may infact be completely wrong, although I have seen this method used before.
2 Likes
I was hoping for a property or something but honestly it makes no difference, so this is fine.
1 Like
You can directly mimic the behaviour of the StarterGui container when CharacterAutoLoads is false. I don’t recommend changing the structure of your game, unlike what @20amir02 said. In the off chance that it poses a problem for you later, you’ll find yourself back here. It’s also not worth, well, butchering game structure to work around this.
The server will only populate the PlayerGui when CharacterAdded fires. Assuming that at some point you will load the character and let the engine take over once again the responsibility of populating PlayerGui, it would be better to have the client give the server a one-time signal that they’re ready to receive Guis. The server can then clone all the children of StarterGui to PlayerGui.
2 Likes
I don’t get what you mean that it’s better to have the client give the server a signal to receive Guis. Isn’t that basically what the current solution already does? Edit: (If it were to be done in a server script and not a local script.)
1 Like
The current marked solution suggests using the client to populate PlayerGuis initially when all LocalScripts start executing and parenting all your Guis to a LocalScript. This is fine, but the thing that doesn’t sit with me right is that you’re effectively changing the structure of your game to work around one issue and the behaviour isn’t like what the engine does.
While the server’s only involvement with StarterGui is to copy those Guis and place them into the PlayerGui each time CharacterAdded fires and so moving the task to a LocalScript is fine, you have a bit of extraneous work to do when you want to start working on Guis.
What I’m proposing is changing the PlayerGui population work from the client to the server so that you can retain your original structure (Guis in StarterGui where they belong and not in scripts). On that note, scratch the signal part: you won’t need that at all. This is different from the purely client-based solution in the way it’s handled but at a conceptual level, is yeah - pretty much the same.
local Players = game:GetService("Players")
local StarterGui = game:GetService("StarterGui")
local function playerAdded(player)
local playerGui = player:WaitForChild("PlayerGui")
for _, gui in ipairs(StarterGui:GetChildren()) do
gui:Clone().Parent = playerGui
end
end
Players.PlayerAdded:Connect(playerAdded)
for _, player in ipairs(Players:GetPlayers()) do
playerAdded(player)
end
14 Likes