Check a BSP before release: a checklist for GMod maps

Before a release you check your map in a fixed order: final compile, cubemaps, packed content, a test on a clean client, then name and version. Typical release mistakes are missing textures, broken reflections and faulty spawns, and all three often go unnoticed on your own machine. The checklist below takes you through every point in one pass.

The checklist at a glance

Final compile and cubemaps

A test compile with fast VVIS or fast VRAD is not enough for a release. Fast VVIS calculates visibility only roughly, which costs performance in game. For the release, VVIS runs in normal mode and VRAD with -final. With -both, VRAD calculates lighting for LDR and HDR in one run. Common additions for better prop lighting are -StaticPropLighting and -StaticPropPolys. Afterwards, read the whole log. How to do that is described in how to read a compile log.

You build cubemaps in game after the compile with buildcubemaps. A map compiled for LDR and HDR needs two passes, one with mat_hdr_level 0 and one with mat_hdr_level 2, each after reloading the map. Two things matter:

• Every new compile discards the cubemaps. You have to build them again afterwards.
• Cubemaps depend on the file name of the map. If you rename the BSP later, the reflections on models and props are lost.

Details on typical problems are in fixing cubemap reflections.

Pack custom content and test on a clean client

Everything that is not part of the game has to ship with the map. The most reliable way is to pack the content directly into the BSP. The guide is in packing custom content into a BSP. Commonly forgotten:

• textures of the skybox and the 3D skybox area
• detail sprites and custom sounds
• the soundscape script scripts/soundscapes_<mapname>.txt
• the particle manifest maps/<mapname>_particles.txt
• the navmesh file maps/<mapname>.nav, which usually ships as a separate file next to the BSP

The VMF, compile logs and backup files do not belong in the BSP.

Then comes the most important test: load the map on a client that does not have your content. That can be a second PC, a friend, or an installation from which you temporarily remove your addons. Watch for pink and black surfaces, error models and missing sounds, and read the console. If the map uses content from other games, such as Team Fortress 2, state that clearly in the description.

Cleanup: textures, entities, spawns

In Hammer, search specifically for leftovers from the building phase:

1. Replace developer textures from the dev/ folder on visible surfaces.
2. Remove test entities, for example temporary lights, test NPCs or debug logic.
3. Run Map > Check for Problems (Alt+P) and work through the list.
4. Check spawn points. There should be enough info_player_start entities for a full server, and every spawn sits clear above the floor.
5. For game modes with their own spawn entities, place the matching entities.

If NPCs or NextBots are supposed to work on the map, you need AI nodes or a navmesh respectively. You generate the navmesh in game with nav_generate.

Performance, file size and versioning

Walk the places where the most is visible at once: large squares, long streets, high vantage points. cl_showfps 1 shows the frame rate, +showbudget shows where the engine spends its time. With mat_wireframe 1 (requires sv_cheats 1) you see what is still rendered behind walls. Keep in mind that a full server with players and props creates far more load than your solo test.

File size decides how long players wait on their first join. Pack only content the map actually uses.

For the name: lowercase letters, no spaces, a game mode prefix and a version tag, for example rp_example_v2. Every published change gets a new file name. Otherwise players have the old file under the same name and the server rejects them with a notice that the map versions differ. Keep the VMF and the exact BSP for every published version.

Scan and optional protection

A last technical check catches errors you cannot see in game. For a BSP, the Map Scanner checks the header, lump table and offsets for consistency, looks for risky entities such as point_servercommand or lua_run, checks whether a spawnpoint exists and lists the Lua and asset files embedded in the pakfile. The pakfile list is a good way to verify your packing. The scan is free, and the file may be up to 50 MB.

If you sell the map, you can protect it afterwards. BSP Protection offers the levels Audit, Cleanup, Fingerprint, Obfuscation and Server-Exclusive. No complete copy protection is guaranteed. The order matters: protection comes at the very end, on the finished and tested file. After every new compile you have to apply it again.

FAQ

Do I have to rebuild cubemaps after every compile?

Yes. A new compile rewrites the BSP, and the built cubemaps are lost in the process. Build them only once geometry and lighting are final.

Can I rename the BSP after building cubemaps?

Better not. Cubemap data is tied to the name of the map, and reflections on models and props are missing after a rename. Rename the VMF instead, compile again and rebuild the cubemaps.

Is a fast compile good enough for a release?

No. Fast VVIS leads to worse performance, fast VRAD to coarser lighting. For a release, compile with normal VVIS and VRAD with -final.

How do I notice missing content when everything looks right on my PC?

On your machine the content sits in the game folder, so a packing mistake does not show there. You can only be sure after a test on a client without your files. The pakfile list from a scan helps as well.