Troubleshooting Level Design
From Valve Developer Community
Revision as of 21:19, 2 October 2008 by Bluestrike (→In-game problems: warning Vis decompression overrun/ This can also be caused by compile proces errors like the vbsp error Face List Count >= OVERLAY_BSP_FACE_COUNT)
Trouble with Compiling Maps
- Compiling the map takes a very long time
- If your map is large or complicated, make sure you are using func_detail appropriately. See Controlling Geometry Visibility and Compile Times.
- The compile window says there is a memleak
- Don't worry; this is not an error. Carry on.
- Compiling the map gives an error
- See Compile Errors for a list of compiling errors with explanations, or visit this site: Interlopers.net error list
- Models are black
- This can be caused if you have a 3D skybox in the map, and don't have a light_environment in both the level itself, and the skybox.
- This can also be caused if the
0 0 0for the entity it is used in.
- The third cause is if the nearest worldbrush directly beneath the model is either unlit, or using a non-rendered texture such as tools/sky.
- Brush entities are black
- This can be caused by a corrupt entity. Recreate the entity by clicking Move To world, then Tie to entity in the Tools menu, or use the buttons on the New Objects toolbar.
- The second cause, a common cause for map porting, is having the
colorkeyvalue set to
0 0 0, which worked fine in Goldsource, but it shows for all rendermodes in Source.
- People on the Internet join the game while you're trying to test it
- By default, testing your map sets your computer up as a server over the Internet, so casual players may come across it and join. To prevent this, type sv_lan 1 in the console before loading your map.
- Everything is very bright (no shading or shadows)
- You probably have a leak. It is also possible that you turned off the lighting stage in the Compile Options dialog.
- If you HAD the lighting turned off and have fixed it, you need to restart the game or set mat_fullbright to "0" in the console.
- Dynamic shadows (shadows for players and prop_physics) appear where they shouldn't
- This is a shadow rendering error due to the method that shadows are calculated. It can often interfere with gameplay, because it gives away player positions when they think they're hidden. To fix it, create an info_no_dynamic_shadow entity, and use its Pick button to select the offending surface.
- Reflections look weird or too bright
buildcubemapsin the console, and reload the map. Sometimes new cubemaps do not look correct until the map is reloaded. And make sure you've put in enough env_cubemaps.
- Water is invisible from above, but looks correct from below
- Sometimes this happens if cubemaps have not been built yet. (Type
buildcubemapsin the console.) It will also happen if you skipped the visiblity or lighting stage of compiling. The visibilty compile phase will not run correctly if you have a leak.
- Invisible Props
- The prop may have its End Fade distance set too close. Sometimes the value is accidentely changed while moving prop entities. To avoid this, keep the "helpers" button turned off until you need it (right most toggle button on the top tool bar that looks like a wireframe sphere).
- Also, some props can only be used as certain types of props and otherwise will be removed from the map when loading the level in the engine. For instance, there are tables that only work as prop_physics, and other props that only work as prop_dynamics.
- Certain textures appear black or unusual when moving around the map (often flashing from any distance when firing)
- This is normally caused by using a model texture (vertex lit generic) on world geometry. World geometry can only use "lightmapped generic" shaders. Check the full name of the texture and make sure it does not begin with 'models/'. There is usually a similar texture available elsewhere which will work properly. As a preventative measure, you should exclude the models directory from Hammer's materials list (go to tools-options-materials tab and add the "models" directory to the "Material directory exclusion list"). This will also allow Hammer to launch much faster.
- Ladder doesn't work
- Make sure the ladder entity is not touching anything solid. It must be at least one unit away from all solid surfaces. Read the Creating Ladders instructions carefully. Ladders work differently in Half-Life 2 and in Counter-Strike: Source.
- Building cubemaps causes the game to crash with a memory reference error
- Make sure the game resolution is at least 800x600. This can also happen in widescreen mode.
- In game the Console Is spammed with "warning Vis decompression overrun"
- Try and tone down the number of leaves in your map
- This can also be caused by compile proces errors like the vbsp error Face List Count >= OVERLAY_BSP_FACE_COUNT
- Your map won't run and the console will give an error
- When you're trying to run your map from Valve Hammer just the main menu starts up... When you look in the console it says 'Host_EndGame: Map coordinate extents are too large!!' You'll have to check if you have errors in your map. Press Alt+P in Valve Hammer Editor, and fix most of the errors. You won't have to fix the ones that say 'Entity (prop_static) has unused keyvalue "spawnflags"' (and for CounterStrike 'There is no player start.')
Trouble with Counter-Strike:Source Maps
- The hostages won't move
- Hostages require a navigation mesh in order to work. (They used to use info_nodes, but that is now obsolete.)
- When the map is loaded, it says "Both Teams are Full".
- You need to have both info_player_counterterrorist and info_player_terrorist entities in the map. See Counter-Strike: Source Level Creation for information on the necessary entities. Also check the console: if it reports that there are invalid spawn points, try moving them up away from the surface, because they may be intersection with the terrain. It is okay for them to start a little bit in the air.