This page contains some less than common errors and their solutions. If you have a problem, but no solution, feel free to put it here too — someone else will try to find a solution and add it!
Starting to replace the surfacelight textures on my map with targeted light entities I run into an odd problem: the staircase that I converted for a quick test compile had the lights flickering for no obvious reason. Bloody strongly, too, going randomly from pitch black to full strength. During my attempts to fix this I noticed that there was an extra shader file in my scripts folder, pointing to a folder full of external lightmaps in my maps folder. I had neither created nor requested any of this…
Finally redoing all those lights I figured out what had happened: I had pointed the info_null entities at the lights, not the other way around. The compiler had helpfully decided that I wanted to use lightstyles and generated the necessary setup for this.
When creating spotlights, always select the light entity first and the info_null entity second.
Pitch black map / hall of mirrors
Texturing the unneeded sides of a hint brush with skip resulted in pitch black map. Turned out that although I could select and apply skip in Radiant, the actual shader didn’t exist in the common.shader file. As a result, the skip-covered faces of the single large horizontal hint in my map were culled along with the skybox faces that touched them, which removed the only light source. See this thread for a case where skip on smaller brushes resulted in HOM (hall of mirrors) effect wherever skip touched any walls. (The same thing happened in my case, too, I just couldn’t see it because the map was pitch black.) The thread also contains a skip shader you can paste in your common.shader.
Unexpected crash on compile
For the duration of building and testing the map I had renamed my textures folder and shader paths from ut4_viljandi_b1 to comeon-ut4_viljandi_b1 to keep everything right next to the common shaders in the texture list. On the next compile q3map2 quietly failed before it even started the BSP stage, no error message or anything. Turns out that there’s a pretty hard limit to path length in q3map2 and this change had caused some of the filenames to go over this. Renaming everything affected to !ut4_viljandi_b1 solved this problem while still putting the folder reasonably close to the common shaders.
A texture looking fine in Radiant is misaligned in the game
I had a manhole cover decal that had worked just fine during the previous compiles, but suddenly it appeared misaligned in-game, shifted down and right by about one third. The cause turned out to be a PNG image with the exact same name that I’d used in creation of the TGA decal — the PNG was 1024×1024 while the final decal was scaled down to 512×512. q3map2 assumed that the PNG was the correct texture and mapped it to the brush while UrT of course could only load the TGA.
Can’t load shaders
A mapper who hadn’t used any shaders until this point had troubles with one of the skyboxes from the CMM repository — even though he extracted everything correctly, the shader was not showing up in the texture list. Flushing the shaders in order to log what Radiant loads and what it’s having trouble with (Tools -> Flush & reload shaders in the textures window) it became apparent that something is very wrong:
Couldn't find 'C:/<censored>/UrbanTerror42/q3ut4/baseq3/scripts/shaderlist.txt'
For some reason Radiant was assuming an unholy combination of UrT and vanilla Quake 3?!? This proved to be a bit of a misleading lead since “baseq3” was found nowhere in the configuration, everything seemed correct. That is, until he posted his full settings file and we noticed that he had set the “engine path” (Edit -> Preferences -> Paths under Settings) to UrbanTerror42/q3ut4 — one folder too deep. The correct path is the one where the game executable is found, i.e. the main game folder that holds everything else. After fixing this and restarting Radiant everything worked fine.
Map shows only lightmap on some computers
blendFunc GL_DST_COLOR GL_ZERO depthFunc equal
to the lightmap stage of the affected shaders. Crappy graphics cards/drivers can't deal with normal lightmapping and need a special treatment.
(Is encountering this even possible today?)