Custom Loading Screens are Still Broken

Describe the bug:
The PlayerGui sometimes does not load in quick enough(particularly on larger games) so trying to create a custom loading screen and using :WaitForChild(“PlayerGui”) to determine when to add the custom loading screen to the PlayerGui will not work. A warning will be issued for an infinite yield on WaitForChild in this case, and then the custom loading ui will not be visible until the entire client has loaded and the default Roblox loading screen has disappeared anyway. This results in the player spending a few seconds just staring at the map loading in before the custom loading ui even appears.

How often does the bug happen:
It’s roughly 50/50 whether it will happen or not. My game is particularly large so it takes longer to load in so I’m assuming this means the PlayerGui is loading in after something else that is taking a while.

Where does the bug happen:
This happens on the current version of Roblox. This issue has existed for a while now, here’s a thread from May.

When did the bug start happening:
I first found out this was an issue when I tried making a custom loading screen all the way back in late April. I thought I had fixed the bug in my game but I found out tonight that it has existed the whole time.

Anything else that you would want to know about the bug if it were your job to find and fix it:
This bug basically makes custom loading screens useless as it’s a 50/50 chance that they will actually replace the Roblox loading screen anyway. This is a big issue as the Roblox default loading screen is less than ideal and having the few seconds of the player watching the map load in is very unappealing and unprofessional.

I have tried everything I could think of to fix this bug but it appears the only solutions are hacky solutions such as putting the loading ui in a billboard ui in front of the player’s camera(which they could still move anyway!). There is no easy solution to this and it’s driving me up the wall as it’s making my game look very poorly made right off the bat and I’m sure I’m not the only person encountering this issue.

18 Likes

Yep, I’ve seen this too. Although, it seems to me that this is 100% caused by terrain loading in before everything else. We have a game that uses something like 8mb of terrain, and until that has all loaded, none of the scripts run, and our custom loading screen is moot. All you see is a big blob of foggy voxels, until the terrain loads in completely and the loading screen appears.

2 Likes

We will take a look into this. Thanks for the report!

2 Likes

That might be a possible explanation as the game I’m referring to uses some terrain, I would love to see this get fixed, thanks for the quick responses guys.

Edit: If this is the issue here’s another thread from last year that mentioned it(we both also responded to that thread so it is likely the same issue). Terrain loads before PlayerGui -> Impossible to make custom loading GUIs

1 Like

Also qq, shouldn’t custom loading screens disable this and replace it with the custom loading screen?

3 Likes

You have to use PlayerGui:RemoveDefaultLoadingScreen(). If you are then the issue this thread is about might be why as the PlayerGui won’t load until that one is already gone.

What @wravager mentioned is a separate issue, not really related to the loading screens in the same way as the terrain issue is. Roblox removed the “waiting for server” message from the website and put it into the game client instead. So basically, unless you instantly find a server, you can’t customize the loading experience completely anymore, just partly. It’s not really clear what a solution would be here though, since ReplicatedFirst has to be loaded in from the game server (which you are not yet connected to).

1 Like

I had the same issue. It’s an issue with ReplicatedFirst itself.

I know this because my game has a flag for whether or not the game uses ReplicatedFirst - with StarterPlayerScripts as the fallback - because this has been an issue for a very long time.

Any time I had ReplicatedFirst handle it, it would not run at all sometimes. Pretty much your “50/50” description. I’ve resorted to just using StarterPlayerScripts again as it’s 1000x more reliable.