PlayerGui not available with ReplicatedFirst

Myself and my team are trying to create a Custom Loading Screen but we’re having a few issues, the player appears in the game before the Splash Screen is loaded. And that sometimes the warning:

‘Infinite Yield’ is returned when the :WaitForChild is used on Localplayer.PlayerGui to load the UI in.

And the UI isn’t loaded onto the player.

Any suggestions/solutions for this type of issue?

1 Like

You cannot find a GUI using just a server script. You would have to use RemoteEvents / Functions to access them.

We’re using a LocalScript which is placed into ReplicatedFirst (A client-side service which is often used for loading GUI’s) I don’t see why remote events have to be used for this.

“A container whose contents are replicated to all clients (but not back to the server) first before anything else.”
Documentation - Roblox Creator Hub

The LoadingGui is a child to the LocalScript and scripts inside are disabled, the main parent LocalScript deals with enabling the scripts once it is loaded onto the PlayerGui, but it seems that ReplicatedFirst doesn’t see PlayerGui as the player is loading. I’m unsure of how to solve this.

2 Likes

Same happens to me as well, in my local script in replicated first, I can’t use a :WaitForChild , but instead I have to use a While() look and :FindFirstChild to be able to get the playergui without errors. And yes, a lot of times this causes the character to display before the custom load screen can be displayed.

1 Like

I have been encountering this problem as well and have been using repeat to wait until the PlayerGui is not nil. This allows the character to be visible for a split second before the loading UI appears. I have been unable to find a solution and it’s a little annoying.

PlayerGui is a child of each individual player object, not the Players container. Use game.Players.LocalPlayer:WaitForChild(“PlayerGui”)

5 Likes

As far as I’m aware, this has always been a problem. The PlayerGui is added in sometime after ReplicatedFirst scripts start.

A workaround is to use a BillboardGui or a SurfaceGui and put it in front of the camera on every frame. This looks identical to a gui in PlayerGui, but you don’t have to wait for the PlayerGui to appear.

I’ve never relied on the PlayerGui appearing soon after starting; it has always seemed to take too long for me. Maybe that changed recently, but the workaround I use is still relevant.

4 Likes

You’re right but judging from the other replies to this it seems like a typo in the OP not in their actual scripts

I still am trying to figure a way around this. I tried @Corecii’s method but I always ran into issues and could not get it implemented. If anyone would be willing to share a solution that’d be helpful.

What issues do you run into?

The LocalScript looks like this
local RunService = game:GetService('RunService')
local ReplicatedFirst = game:GetService('ReplicatedFirst')

local guiPart = Instance.new("Part")
guiPart.Size = Vector3.new(0.05, 0.05, 0.05)
guiPart.Anchored = true
guiPart.CanCollide = false
guiPart.Transparency = 1
guiPart.Name = "LoadingPart"

local gui = Instance.new("BillboardGui")
gui.LightInfluence = 0
gui.Parent = guiPart
gui.Name = "LoadingBillboard"
gui.Adornee = guiPart

guiPart.Parent = workspace

local screenFrame = script.ScreenFrame:Clone()
screenFrame.Position = UDim2.new(0, 0, 0, 32)
screenFrame.Size = UDim2.new(1, 0, 1, -32)
screenFrame.Parent = gui

RunService:BindToRenderStep("LoadingScreen", Enum.RenderPriority.Last.Value, function(dt)
	local camera = workspace.CurrentCamera
	local viewportSize = camera.ViewportSize
	camera.CameraType = 'Scriptable'
	camera.CFrame = CFrame.new(0, -100, 0)
	guiPart.CFrame = camera.CFrame + camera.CFrame.lookVector
	gui.Size = UDim2.new(0, viewportSize.x, 0, viewportSize.y)
end)

ReplicatedFirst:RemoveDefaultLoadingScreen()

if not game:IsLoaded() then
	game.Loaded:Wait()
end

wait(5)  -- Only added since the test place loads too fast.

workspace.CurrentCamera.CameraType = 'Custom'
guiPart:Destroy()
RunService:UnbindFromRenderStep("LoadingScreen")

Here is a place that shows this code in action:

The place is free for you to edit and inspect. You can use it however you’d like.

Quick Video

https://gfycat.com/WigglySparklingBrahmancow

You can optionally move the Gui from a BillboardGui to a ScreenGui once the PlayerGui appears. I don’t do that here because it’s only meant to be a simple example.

4 Likes

That worked. Not sure what was going wrong when I tried it but thanks.

This is a typo in the post but not the script itself.

I’m not sure if ROBLOX would run into giant problems if we had the replicatedFirst do what it’s defined to do in the ROBLOX wiki.

But it only seems that the current solution is to use a loop to wait for the PlayerGui and then assign it.

I just tested this and it worked properly for me.

The problem OP had was that they had typed Players:WaitForChild(”PlayerGui”).

1 Like

It seems to be a prevalent issue when the game is large. Don’t quote me since I have no clue what the technical shenanigans is occurring (correct me if I’m wrong), but I do believe that the engine is prioritizing the loading of the Workspace, before ReplicatedFirst.

And since the workspace is so large. Instances in ReplicatedFirst haven’t loaded in yet.

ReplicatedFirst will always load before other parts of the game.

As @konlon15 mentioned, you are using:

game.Players:WaitForChild("PlayerGui")

This will never ever work unless a player called “PlayerGui” joins your game.

You need to run this from a LocalScript, and use:

game.Players.LocalPlayer:WaitForChild("PlayerGui") 

You need to reference that player that you are waiting for, else you are looking for a “PlayerGui” which does not exist under game.Players.

(This was a typo)
game.Players.LocalPlayer:WaitForChild(“PlayerGui”)
was used.

2 Likes

perhaps a fix would be to delay the character load.
game:GetService(“Players”).CharacterAutoLoads = false

The loading screen needs to be in well before the character loads. The issue is that they couldn’t get it to properly wait for PlayerGui, but they solved the issue.

2 Likes