StarterGui doesn't automatically load if Players.CharacterAutoLoads = false

My game doesn’t utilize a traditional roblox character, so I have Players.CharacterAutoLoads set to false. However, it seems as if PlayerGuis aren’t loaded in if the character isn’t.

I could easily create some code to clone the StarterGui’s contents into each player’s PlayerGui manually, but I was wondering if there’s a particular reason that the PlayerGui behaves this way, and if there’s some easy quick fix that I’m missing like a certain setting or property.

5 Likes
1 Like

I don’t think it’s that. I tried like 4 times in a row with CharacterAutoLoads = false and it never loaded, changed it to true and it loaded, changed it back to false and it didn’t load. Would be extremely unlikely for that bug to coincidentally line up properly with 6 play tests.

That bug doesn’t sound fun either though.

1 Like

StarterGui and PlayerGui are tied to the player’s character. When the player spawns, the old GUIs are destroyed and new ones are cloned from StarterGui (unless they have ResetOnSpawn disabled). The key thing to note here is that this all happens when the player spawns – so if the player doesn’t spawn, StarterGui doesn’t do anything.

Waiting until the character loads is actually a good way to get around some problems – you obviously can’t give GUIs to a player the moment they join, but when their character loads is (or was) a good way to tell when they’re ready.

Personally, I don’t find this behavior much of an issue. It’s a decent way of separating menus/loading screens from the HUD. Fixing your issue is trivial (as you said). Although it is limiting and confusing for people (in your case). A bool or something inside StarterGui/StarterPlayer would be a fine way to get around the behavior, which would maybe link the loading to when PlayerGui comes into existence or something instead of the character.

14 Likes

Yeah, that is a bit of a issue in your case. However, for most people it’s not. Unless you are looking for a loading screen, (which should be executed differently… which you can find more info here ) this code below should solve your problem.
However, it should be noted that I do not know how this will effect your GUI Operations, so test as needed.

The code should be executed in a script on the server side.

game.Players.PlayerAdded:Connect(function(plr)

    local ui = plr:WaitForChild("PlayerGui")
    for i,v in pairs(game.StarterGui:GetChildren()) do
       v:Clone().Parent = ui
    end

end)
With code running

Without code running

17 Likes

I love your response to this issue.

Glad to see your way of solving this issue and I am writing this short notice to bring your attention that if the GUI (not cloned) in the StarterGui and after typing out your code into our game, ( I am referring this to a Main Menu GUI ) the GUI will be cloned twice into PlayerGui and after clicking the Start button which has the following script:

--localscript
script.Parent.MouseButton1Up:Connect(function()
	game:GetService("ReplicatedStorage"):WaitForChild("GUI"):FireServer()
	script.Parent.Parent.Parent.Enabled = false
end)
--serverscriptservice
game.Players.PlayerAdded:Connect(function(plr)
	local ui = plr:WaitForChild("PlayerGui")
	if not ui:FindFirstChild("ScreenGui") then
		game:GetService("ReplicatedStorage"):WaitForChild("ScreenGui"):Clone().Parent = ui
		print("Hello")
	end
end)
game:GetService("ReplicatedStorage"):WaitForChild("GUI").OnServerEvent:Connect(function(Player)
	Player:LoadCharacter()
end)

For any scripter facing this issue, you can resolve it by changing the location of your GUI that has to be cloned ( I’ve kept it inside of ReplicatedStorage ) and change the above script provided by helperobc ( I love your name for some reason ) accordingly.

2 Likes