The loading screen is the first thing every new player sees, and it is also the first thing that breaks on a server that was working fine yesterday.
Most "my loading screen is stuck" tickets have the same shape: the resource starts, the player connects, and the screen stays black — or the player lands in the world without ever seeing it.
What the loading screen actually is
A loading screen is a NUI resource. The client loads an HTML page in an overlay while the server assembles the session: character data, inventory, framework state, spawn point. The screen you design is the visible layer over that wait.
Two separate things can therefore be wrong, and they look identical from the outside:
- The design never renders. The NUI URL is wrong, the file name does not match, or the resource is not started before the client needs it.
- The design renders fine, but the session never completes, so the screen stays up forever.
The second one is not a loading-screen bug at all. It is a broken database query, a missing framework resource or a failed event, and the loading screen is only where you notice it.
The three checks that resolve most cases
Is the resource started? ensure the loading screen in your server.cfg, before the resources that depend on it. A screen that is started after the join flow has already begun will not be shown for that player.
Does the URL match the file? The ui_page in the manifest points at a path inside the resource. A file that was renamed to index.html in a ZIP that unpacks to Index.html is a broken URL on a case-sensitive host, and it works perfectly on the author's Windows machine.
Does the client actually send the event? The standard flow is: the client asks the server for session data, the server answers with the player identifiers, and only then the client hides the screen. If the server never answers, the screen stays up.
What to check when it hangs
Open the browser console on the client with F8 developer mode enabled. You will see the NUI messages the resource sends. If you see the initial message but never the "hide" message, the screen is fine and the session is not.
From the server side, the first red line in the console is usually the real answer: a missing dependency, an undefined table in a shared script, a query against a table that does not exist yet.
Build it where you can see it
Designing a loading screen in a text editor means guessing how it looks at 1920×1080, at 2560×1440 and on an ultrawide. The RPScripts Loading Screen Builder lets you lay out the design in the browser, preview it against the messages FiveM actually sends while a player joins, and export a ZIP you can drop straight into a resource. The preview runs the exported files at the real resolution, and the "Simulate FiveM loading" mode sends the same messages the game sends, so the progress bar you see is the progress bar players will see.
You can also export the design as JSON and import it later, which is the difference between iterating on a design and re-implementing it every time.
A note on the "first join" case
The first player to join after a server restart often sees a longer wait, because the server is loading resources and the database is cold. If that is the only case where the screen is slow, the screen is not broken — the server is. Progress reporting helps, but the fix is on the server side.
Disclosure: this post is from RPScripts. The builder linked above is ours and free to use in the browser.
Top comments (0)