When a player joins your Garry's Mod server, the first thing they see is your loading screen. While the server sends them the files (addons, sounds, models), they stare at that page for ten, twenty, sometimes sixty seconds. A generic gray screen makes the server feel dead. Give it your branding, your music and your rules, and that same wait becomes a real first impression.
This guide walks through how to create a Garry's Mod loading screen from start to finish: how it works under the hood, the two ways to set one up, the steps to build it. And, most importantly, the GMod engine constraints that trip up most people the first time.
What a GMod loading screen is and how it works
A GMod loading screen is simply a web page (HTML) displayed by the client while it connects to a server. Garry's Mod downloads that page from a URL you specify, then shows it full screen while the client fetches and mounts every file needed for the game.
While it displays the page, the Source engine also injects JavaScript functions into it to communicate in real time. The engine calls callbacks such as GameDetails() (server name, map, gamemode), SetFilesTotal() and SetFilesNeeded() (number of files to download), DownloadingFile() (current file) and SetStatusChanged() (current status). Thanks to these callbacks, a good loading screen can show a live progress bar, the name of the file being downloaded, and server info without you having to write a single line of Lua.
On the server side, it all starts with one line in your server.cfg: the sv_loadingurl command, which points to your page's address. The rest is just HTML, CSS and a bit of JavaScript.
sv_loadingurl "https://lumescreen.com/ls/your-server"The two approaches: self-host or use a generator
There are two main ways to get this page. Neither one is wrong, but they don't ask the same amount of effort from you.
Self-hosting an HTML page
The old-school method. You write the screen's HTML/CSS/JS yourself, host it on a web server (or a file repository over FTP), then point sv_loadingurl at it. Perfectly doable, and 100% customizable. It also assumes you can code a web page, run publicly accessible HTTPS hosting, and keep all of it working over time. Get one engine callback wrong and your progress bar just sits there frozen while players wonder if the server crashed.
Using a generator like Lumescreen
The alternative is to use a dedicated generator. You pick a theme, customize it in an interface, and the tool hands you a ready-to-paste URL with nothing to host and nothing to maintain. The callbacks, hosting, HTTPS and CEF compatibility are all handled for you. That's the approach behind Lumescreen, built for admins who want a clean result without spending an evening debugging JavaScript.
Creating your loading screen with Lumescreen, step by step
- Pick a theme. Start from a template that fits your world (RP, sandbox, military, cinematic…). Every theme is already optimized for GMod's constraints — all that's left is to make it your own.
- Customize the branding. Tune the colors to your community's palette, add your logo, and choose an image or animated background that matches the server's mood.
- Add music, staff, and rules. Upload some background music, list your team (with roles and Steam avatars), and show your main rules so players have already read them before they spawn.
- Fill in the server info. Link your IP and port to display the map, gamemode, and number of connected players in real time.
- Grab your URL. Once the screen is saved, the tool generates a unique address like
https://lumescreen.com/ls/your-server. - Paste the URL into sv_loadingurl. Add the line to your
server.cfg, restart the server, and you're done.
The CEF constraints you absolutely need to know
Your loading screen runs inside the CEF (Chromium Embedded Framework) built into the game, not in a normal browser. This environment is more limited than Chrome or Firefox, and ignoring its rules is the number one cause of broken screens.
- No HTML5 video. The CEF is too limited to play video. Go for a background image, an animated gradient, or a subtle particle effect instead.
- Audio autoplay is allowed. Unlike in a browser, your background music starts automatically. The “click to play” fallback is only useful for the preview in the dashboard.
- Everything must be BIG and READABLE. The player is looking at their screen from a distance, sometimes on a large TV. Generous fonts, strong contrast, little cramped text.
- Plan for responsive design. The screen renders at the player's exact resolution. Your layout has to hold up just as well at 1080p as on an ultrawide.
Best practices and common mistakes
- Show real progress. Hook your screen up to the callbacks to display a bar that actually moves and the file being downloaded. A player who can see it's working waits far more patiently.
- Keep the text minimal. Three or four key rules is plenty. Nobody reads a wall of twenty rules while a progress bar is ticking, so save the full rulebook for an in-game menu.
- Test on a real connection. The dashboard preview is close, but I've been caught out by music that autoplayed in-game yet needed a click in the preview. Actually join your own server once before you call it done.
- Avoid oversized media. A huge image or uncompressed music slows the page down. Favor optimized files.
- Don't rely on clickable links. This is the most common mistake: no clicking is possible. Put your URLs in clear, readable plain text.
A good loading screen feeds directly into your player retention. When the wait feels handled and the server has a clear identity, people are more likely to stick around past that first minute.
Where to go from here
The whole thing is really just a web page served during loading, declared through sv_loadingurl, built to respect what CEF can and can't do. Start with a plain image if that's all you have time for, then add music and live server data once the basics work.
If you'd rather skip the coding, you can build a working screen in a few minutes with Lumescreen and check the options on the pricing page.