Quake1 Tool Tips ================ by Bengt Jardrup, v0.19 Jan 12 2007 =================================== <=================================== Purpose Of This Document ===================================> This document is mainly aimed at the experienced Quake1 mapper (or player) and is intended as an aid in developing maps and to get a better understanding of the build process. You won't find any descriptions of basic mapping concepts and many terms are not explained here. The Q1 tools described can be found at http://user.tninet.se/~xir870k and are highly recommended. Some of the descriptions may fit other tools as well. See also the readme file for each tool. <============================= Warning/Error Messages Of Build Tools ============================> This list is far from complete, there are many more warning/error messages. QBSP WARNINGS "Brush not closed on line x" Might be critical since the reported brush can cause bsp corruption. Identify brush and repair as necessary. "Brush plane with no normal on line x" Might be critical since the reported brush faces are skipped, possibly leaving the brush in a non-closed state. Identify brush and repair as necessary. "Brush with duplicate plane on line x" Non-critical since the reported brush faces are skipped. Usually caused by an editor error. "CanonicalVector: Degenerate edge at (x y z)" "CheckFace: Face with too few (a) points at (x y z)" "CheckFace: Healing degenerate edge at (x y z)" "CheckFace: Healing point (x y z) off plane by a" "CutNodePortals_r: New portal was clipped away near (x y z)" Non-critical. Inspect specified area and look for warped or misaligned brushes. "Mixed face contents (a, b) near (x y z)" Non-critical when one of the contents types is "Empty". Caused by tiny brush misalignments in specified area. "No entities in empty space -- no filling performed" Normally caused by not having at least one entity that is positioned far enough from solid brushes. Move one of the entities further away from all walls. "No valid wadfiles in worldmodel" No textures will be included in the bsp. Correct wad specifications. "Object x exceeds normal engine max y" Critical since engine might crash loading bsp. "Reached occupant at (x y z), classname" Your map leaks in the hull that's currently being processed. The specified entity is the one nearest to the hull breach. See section "Leaks". "Texture x not found" One of the textures is missing from the specified wad files. If the texture is sky or liquid, you might have problems loading the bsp into an engine. See section "Engine Problems". "UpdateEntLump: Bsp has x models, map has y" You are performing an "-onlyents" run and the amount of brush models differ in map file and bsp. May cause entity problems in engine. ERRORS "Bad contents" Bug in early TxQBSP versions (fixed in 0.75). "Cannot start the program - not enough memory addresses in the process !" "Memory allocation of x bytes failed in y" You don't have enough virtual memory configured in Windows. Increase swap/pagefile manually or let Windows automatically handle it. "Entity with no valid brushes or textures on line x" Normally caused by having only clip textures on a brush entity. "filename is version x, not y" Bsp is corrupt or not a Q1 map. "LoadBSPFile: Odd lump size" Bsp is corrupt, rebuild it. "Mixed face contents (a, b) near (x y z)" You have either one brush with mixed contents on different faces, or two brushes with different contents that intersect. E.g. you can't mix sky with liquid. "Reached the limit x (y), cannot continue..." You've exceeded one of qbsp's or Q1's limits. If it's the MAP_MAP_CLIPNODES limit (32767), see section "Clipnodes". "SubdivideFace: Didn't split the polygon near (x y z), texture" One or more textures are scaled too small on a face. Find face and increase scale. "Textures exceeded MAX_MAP_MIPTEX (x)" Sum of all textures in map is too big, shrink textures in wad or remove some from map. VIS WARNINGS "Leaf portals saw into leaf near (x y z)" Non-critical, unknown cause. Happens mostly when fastvising. ERRORS "CheckStack: leaf recursion near (x y z)" Critical, unknown cause. Inspect specified area and look for complex geometry. "filename is version x, not y" Bsp is corrupt or not a Q1 map. "LoadBSPFile: Odd lump size" Bsp is corrupt, rebuild it. "Vismap expansion overflow, max = x kbyte" You have exceeded max vis data size. Likely causes are leaking map or fastvis of a huge map. Seal the map or try a fullvis (will probably take forever, though). LIGHT WARNINGS "FindFaceOffsets: Couldn't find entity for model x" Non-critical, entity data doesn't match model data. Possibly caused by manual bsp manipulation. "Bad texture axes on face near (x y z), tex" "Texture axis perpendicular to face near (x y z), tex" Texture position couldn't be determined. Check specified area for odd texture alignments. "Too many light styles on a face, lightmap point near (x y z), tex, light->origin (x y z)" Too many styled (torches, flickering etc) lights in the specified area. Reduce # styled lights or their range in that area. You can also try option "-gate #" to limit the range of attenuated lights. ERRORS "Bad surface extents (a, max = b) on face near (x y z), tex" Too large texture face in bsp, qbsp normally makes sure that this doesn't happen. Check usage of qbsp option "-subdivide #" and remove as necessary. Another cause is excessive # vertexes in bsp. Check qbsp log and change map. "filename is version x, not y" Bsp is corrupt or not a Q1 map. "Light data size exceeded, max = x kbyte" You have exceeded max light data size. Likely causes are leaking map or a massive amount of lights in a big map. Seal the map or reduce # lights. "LoadBSPFile: Odd lump size" Bsp is corrupt, rebuild it. <========================================== Qbsp Output =========================================> Normally, qbsp prints a lot of information on the screen while processing. If you find it hard to see the important items or just want a more neat output, use the options "-quiet" and "-numpercent". This will produce a very compact screen output while all the usual info is written to the log file for reference. This will make it much easier to spot critical warnings like leaks. <============================================ Leaks =============================================> ------ Identifying ------ A leak can either be visible (a gap between brushes) or invisible (a corrupt brush, clipping errors). Normally, you can load the bsp into an engine, type "pointfile" in the console and follow the white dotted line to the point where it breaches the hull. If the line stays completely outside the map, there is probably an entity left on the outside, typically a light. If you can't load the bsp into your normal engine, try Enhanced Win/GLQuake or another software engine like Win/TyrQuake (see section "Engine Problems"). If you still can't load the bsp, you can check if you can load the pointfile (pts) directly into your editor, e.g. WorldCraft and QuArK can do this. If you still can't display the pointfile visually, try the following method. After the first build, copy the pointfile to another place. Then in the editor, cut out everything except an area around the specified leaking entity (make sure you've saved your full map beforehand). Make it brutal, no sealing off. Then build again and when done, restore the original pointfile. This small, cut-out part of the map should be able to load into the engine and then you can load the pointfile. If the leak spot is outside the cut-out part, then make the part bigger and repeat until the leak spot can be found. If the leak is of the invisible type (typically the white dotted line goes right through a solid brush), note the position of this brush and inspect this area in the editor carefully. There is probably some small brush misalignment between this brush and its neighbours, often in a non-axial junction. Another cause is very small or thin brush faces nearby; delete those faces. Depending on which hull the leak is in, you'll get different problems here. You can try shooting a rocket through the brush or turn off noclip and try to move through it. If the brush is high up you can enter fly mode in the console. See also section "Hull Explanation". Note that if a corrupt brush doesn't border to the void, there will be no leak warning. This will happen if e.g. the brush is a floor between two rooms. In this case, either you'll have to discover it by actually falling through the floor or you can try looking for visual anomalies using the method described in section "Hull Explanation". There's also a tricky case when corrupt brushes cause invisible volumes outside the player space in the void. This can be detected by noclipping outside, moving around and looking at the inside of the map. If the entities on the inside suddenly become visible from the outside, as if you were actually inside the map, then you are in such an invisible volume. You can also verify this by firing the RL while inside this volume; the rocket then doesn't detonate in your face but goes some distance before hitting a solid wall. Since the invisible volume is still sealed within the map, you won't get a leak report. This case seems to be some kind of corruption of the visible hull 0. ------ Repairing ------ While trying to fix a leak, it's very convenient to use the TxQBSP option "-starthull #", which makes qbsp start processing with the specified hull (the one that's leaking). If the leak is still there, just abort qbsp and make a new attempt. This will significantly cut down on turnaround time. It also helps to use the option "-solid", which removes all liquids from the map and treats sky as solid. There is also a "-noents" option that removes all entities except world and players. This will help avoiding monsters and accidentally touching triggers while noclipping around. If you have clipping errors in hull 1 that you can't seem to fix, try using the "-nofillclip" option. It disables the filling of hull 1 (the player clipping hull), which may get rid of the problem. Beware that this increases the # clipnodes in map, see section "Clipnodes". If you can't seem to get rid of the leak, you could try options "-nosortface", "-oldcsg", "-epsilon 0.05" and "-oldexpand", either separately or together. This changes the behaviour of qbsp slightly and may in rare cases help. If all else fails and the leak is in hulls 1/2, then you can use the option "-leak 0" which will force qbsp to generate a portal file even if there are leaks in hulls 1/2. If you have the case of a corrupt hull 0 mentioned above, you'll have to find the brush bordering to the void where you can fire a RL through it and then repair that brush. This is usually rather close to the invisible volume. An indication of a successful repair is that the # outleafs in the qbsp log increases. This means that qbsp has been able to fill more of the outside of the map, which is good. <========================================== Clipnodes ===========================================> If you've exceeded the MAP_MAP_CLIPNODES limit (32767), it's probably caused by a leaking map. If the leak is in hulls 1/2, use the option "-fill" to force qbsp to fill the outside even if there is a leak. This way, # clipnodes will fall significantly and the build can proceed. This bsp can be loaded into an engine but the player and probably most other entities will be stuck so you'll have to use noclip to move around and find the leak after loading the pointfile. In older qbsp versions, you can use the option "-hilimit" to raise the limit to see how much you've exceeded the limit. The produced bsp might not be able to load into an engine. If you actually have a sealed map that still exceeds the clipnode limit, then you must change architecture to get below the limit again. Try inserting large clipbrushes over parts of the map where the player or other entities cannot go anyway, this will help qbsp to fill hulls 1/2. Remember that the total # clipnodes is the sum of the clipnodes in hulls 1/2, which means that they're normally invisible. You can build the map using the "-hull #" option to make a certain hull visible. This way you might find large enclosed areas that you need to seal off better (or open for the void) in order to help qbsp fill them in all hulls. There is also an option "-nofillvis" that prevents filling of hull 0, thus speeding up compile time so you can see the results of clipnode reduction. Beware that the produced bsp might not be loadable in an engine. Another possibility is to use the "-oldexpand" option that alters the brush expansion logic and thus directly affects the clip hulls and # clipnodes. <======================================== Portal Problems =======================================> This is also known as the "Hall Of Mirrors" (HOM) effect while playing the map. Turn on "gl_clear 1" in the console to better see this effect. First, determine if the problem is vis related or not by typing "r_novis 1" in the console. This will make the engine disregard the vis information in the bsp. If the HOM is still there, it's probably a qbsp error (can be hard to fix, but see below). If the HOM disappears, then it is vis related and the following description applies. There are at least two cases of this, the cause is the same but the problem spot is different. The first is when the HOM is visible from any angle/position, then the problem spot is exactly where the HOM is. The other is when the HOM appear only when passing a certain point, then the problem spot lies in the same plane as this point. Slide to the left/right/up/down to find a nearby edge that look suspicious. Sometimes you can find a strange textured plane inside a brush when noclipping through it, the plane is only visible from certain angles. In both cases the problem is caused by misalignment between brushes. This may cause qbsp to create an extremely thin leaf (volume) which also ends up in the portal (prt) file that vis processes. In the end, the engine will have problems determining what to render around this leaf, hence the HOM effect. If the HOM is a qbsp error, it could be due to having a thin wedge-like brush meeting with its vertex somewhere on the middle of another brush's face. Change the wedge so this doesn't happen, e.g. by beveling it. <========================================== Tjunctions ==========================================> Tjunction calculations are made by qbsp in order to help the engine render solid walls. If they for some reason are not made, in most engines you'll get small light "sparkles" along the face edges that make the walls look non-solid and thin. It's easier to see the effect in dark areas of the map and after typing "gl_clear 1" in the console. Normally, tjunctions are created unless the map leaks in hull 0 or if they are explicitly disabled (and there's no reason to do so) using the option "-notjunc". Unfortunately, older versions of TreeQBSP (fixed in 1.65) and DuBSP have the tjunctions default disabled. Use a newer qbsp or enable the "-tjunc" option. <======================================= Hull Explanation =======================================> Every Q1 map has three hulls 0-2. Hull 0 is what you build in the editor and is normally what you see in-game. This visual hull is not what the player (or other entities) is "clipped" against, i.e. checked for collision so you can "feel" the wall. This is due to speed reasons, it's easy to clip a point sized (infinitely small) entity like a rocket against hull 0, but for bigger entities like the player, there is a bounding box around it that defines its volume in space. When Q1 was made in '96, it was probably considered too processing consuming to clip the entire bounding box against hull 0 in the game engine so another solution was made. If the qbsp compiler would, instead of just building hull 0, automatically build two other hulls (1 and 2) by expanding all brushes in hull 0 outwards the same distance as the bounding box for player or shambler sized entities, it would be much easier for the game engine to clip the bigger entities. It then only has to clip the mid-point of the bounding box against one of the other hulls to see if they collide. This is the same thing as clipping a point sized entity against hull 0. So each time you look at the compiler output, you'll see something like "Processing hull #" three times. This is when the compiler builds your map, first the normal visible hull, then automatically generating hulls 1/2 by expanding the brushes in hull 0. The end result is three separate hulls in each bsp that the engine will load and use while playing. The "-hull #" option can be used to trick the compiler to build hull 0 the same way as it does for the other hulls, by expanding the brushes a bit, thus making one of the other hulls "visible". This may help understanding how a bsp is built and get a clearer picture of what these other strange hulls are. By inspecting the map in the shape of one of the other hulls, you might use certain visual anomalies (like HOMs) to identify areas with problems (e.g. clipping errors). After identifying the area, you just make a closer inspection of that area in the editor and hopefully find the cause of the problem (typically some kind of brush misalignment). If all this still seems confusing, just build a map (preferably a small one) using the "-solid", "-noents" and "-hull 1" options (see readme for details) and load the bsp into an engine and you'll probably understand better. Setting a uniform medium brightness with Light options "-nolight" and "-light 100" will help identifying HOM effects. <========================================== Vis Issues ==========================================> The main problem with vis is the sometimes very long fullvis processing time; hours, days or even weeks. To avoid this, there are the obvious recommendations to avoid too open (arena-like) map design, use vis-blocking and reduce brush details. Another trick is to turn detail brushes into func_walls, thereby hiding them from vis. This often reduces vis processing time significantly (>50% is common), but it has some drawbacks. The problems are that func_walls don't cast shadows (but they have shadows cast on them), tjunctions are not created for them, the entity count may get too high, engines render them less efficiently (i.e. higher r_speeds) and they may cause engine overflows. With careful handling, most of these drawbacks can be kept to a minimum. Shadows can often be fixed by having a simple solid core completely inside the func_walls that is used only to cast shadows and build the fancy detail brushes around this core. Shadows are normally not very detailed so it can be hard to notice that they're actually cast from less complex objects inside the visible brushwork. You can of course also change lighting around the func_walls to mask the lack of shadows. To reduce the impact of the entity count, group as many brushes as possible in each func_wall. Just make sure that they're all in the same visible area, otherwise the engine may have problems rendering them. If you encounter HOM (Hall Of Mirrors) effects while playing, see section "Portal Problems". In vis considerations always remember, it's not the brush count that matters, it's the face count and the visible relationship between the faces. Also in some maps, vis cannot do much more in a fullvis than fastvis, so consider settling for the much quicker fastvis. <========================================= Light Issues =========================================> This part of the build process is very related to taste and preference. Some like dark and moody high-contrast lighting while others prefer brighter with soft shadows. However, most people will dislike overly dark combat areas or fullbright/minlight maps. Also, what's dark for one combination of graphic card, monitor setting or even time of day when playing, can be very different for another. As a general rule, look at the lighting in id's original maps and try to keep the lighting around these levels. In any case, having strangely dark faces in an otherwise bright area always looks bad. This can be compensated by using the "-soft" and "-softdist #" options. They enable lights to be more or less behind a surface and still cast light on it. This might make it easier to use fewer lights in an area. If you experience bad shadows in a map that has been compiled with enhanced texture positioning information (e.g. QuArK ETP or Valve 220 Hammer), you should probably add the option "-etp" to get the lighting correct. TyrLite 0.94 (see Tyrann's site below) or later also supports this. Another tricky situation is to light up multifaced objects like pillars or arches, they often end up having different light levels on each face ("banding"), making them look less round. There is a key "_anglesense" for each light entity (including worldspawn for sunlight) that can help reducing the banding effect or otherwise create interesting visuals. This key directly controls the incoming angle sensitivity for each light, making it possible to have lights that are more or less attenuated by face angle. With a value closer to 0, there will be less angle sensitivity (distance attenuation is unaffected) and this will create a very flat lighting which will hide the face edges of the architecture. On the other hand, setting it closer to 1, will make the architecture to be more pronounced, each face will be more separated from its neighbours. The value can be 0-1 and the default is 0.5. The angle sensitivity can also be set globally from the command line but will not override the entity values. If your map needs more flexible minlight, you can use the local minlight (delay 4) entities. This way you can have a global minlight level for most of the map and then override this with local minlights in some areas. The local minlight can be darker or brighter than the global level. It's often easier and looks more realistic using darker local minlights rather than antilights. This is because antilights use a subtractive, compensatory method while local minlights just lower the light "floor", leaving the positive light sources intact. When using local minlights in spotlights to limit their range, you can use the "_softangle" key to create a softer spotlight cone. This way you can have gradient minlight to reduce their otherwise flat effect. After doing an "-onlyents" run with qbsp, you must also do an "-onlyents" run with light to fixup switchable (targeted) lights. This will not change any lighting, only rebuild the styles in the entity section and it's therefore very quick. When having very big trigger brushes (e.g. trigger_hurt) or other solids with plain textures (e.g. "black"), make sure to set their texture scale high, e.g. 99. This has several advantages; light processing time, light data amount and # GL engine lightmaps is reduced significantly. To shorten turnaround time while testing out lighting, make use of the "-fast" and "-soft" options. When testing outdoor lighting, use the "-nolight" option to disable all light entities except ambient. For indoor testing, use the "-sunlight 0" option to disable all sunlight processing. Also make use of the "-gate 1" option which can dramatically reduce processing time with only minor (normally invisible) light distortion. For release builds, use the "-extra4" option to reduce the jagged edges of shadows. Together with "-fast" and "-soft", the extended processing time will be reduced and shadows will get even less digitalized. It's also recommended to use the "-gate 1" here as it can cut processing time 2-15 times. Approximate rules for processing times are that 2x2 oversampling is 4 times slower and 4x4 is 16 times slower, while using the "-fast" option cuts any time in half or more. In a large map, 2nd sunlight will add quite a bit to processing time. As many mappers can testify, spending a lot of time on the lighting is essential to make a map look good. <======================================= QuakeC Problems ========================================> A pretty common issue in Q1SP paks is invalid total/killed monster counts. This can be as simple as monsters being out of sight or placed in secrets that haven't been found yet. Another cause is monsters mistakenly placed partly or completely inside solid walls, look for "walkmonster in wall" warnings at startup. Another way to find missing monsters is to save the game when all monsters should be killed, open the .sav file in a text editor and look for the string "health" (*with* the quotes). Any monster with a health >0 is an indication of being orphaned and you can find its position via the origin key. The .sav files can offer a lot of information when having strange entity issues. There's also the old bug in monsters.qc that makes fish counted twice. This bug is still present in surprisingly many custom progs. A more complex but also common cause is badly configured triggers; in one or more skills, the required trigger is missing. If the object that should be triggered is a trigger_teleport, you can find the orphaned monster in its repository. If it's a func_spawn*, you can't find the monster as it's invisible and non-solid. Light 1.41 or later will print warnings for some suspicious trigger chains. When using more advanced monster spawning code (e.g. func_spawn, statues, spawn64 etc), it's recommended to put in self-checking code that will detect missing targetnames/triggers so it will print warnings automatically at startup. This will save a lot of grief later. Hipnotic's (and most inherited) func_spawn code has a bug when using the spawnmulti flag that generates invalid monster counts. Most spawning code (including the original and Hipnotic/Rogue) has issues when a monster is killed immediately at spawn time due to e.g. insufficient space or trigger_hurts. This might not end up as invalid kill counts, but may cause really weird entity issues, e.g. unkillable "ghost" monsters. You may find a gibbed head behaving like a living monster with sounds and all. When playing a map that generates engine "packet overflow" warnings, there's also a risk that one of the lost packets was information of a killed monster. This will also cause invalid kill counts. Finally, there's a malicious bug in the original QC 1.06 code in the shalrath.qc file. In the monster_shalrath function, the walkmonster_start function isn't called directly as it should. This doesn't cause any problems in the original code, but in most later versions that include func_spawn* entities, it will cause invalid monster counts if shalraths are spawned in. This may also cause invalid models displayed, as QC and engine then has different ideas about the monster counts and this affects model numbers when loading a saved game. It's vital that QC communicates this info dynamically to the engine to avoid confusion. Another cause for invalid models when loading saved games is non-deterministic precaching, typically using the random function. Always precache all alternatives. Enhanced Win/GLQuake will print warnings if there are model mixups when loading saved games. Another common QC issue is accessing already removed edicts (entities). Even though it works in some cases due to engine design, it should be avoided completely. After removing self, the current function should usually be exited right away. After removing other edicts that may be accessed later, set them to world (0) for clarity. Enhanced Win/GLQuake has detection of accessing freed edicts and it's enabled by setting developer 2. While testing QC, you can also set cvar edict_reuse to 0, which will delay reusage of edicts in the engine. This can catch very complex scenarios when a freed edict is accessed several seconds later from a completely different part of the code. A more convoluted QC error is to call the engine findradius function, enter a loop that goes through all the chained edicts and then inside that loop, call another function that in turn may call findradius again. If the two chains share any of the edicts, there might be very strange issues. One way to avoid this is to add another .chain2 variable that can be set up after the first findradius call and use that in the outer loop. <======================================= Engine Problems ========================================> TIP: To help troubleshooting map/engine problems, it's recommended to add "-condebug +developer 1" to the engine command line. This enables extra warnings to be printed to the console and also logged to file qconsole.log in the game directory. This file is overwritten each time the engine is started. Beware that some GL-engines might crash at startup on computers with modern graphics cards when the "-condebug" option is enabled. Enhanced GLQuake or software engines don't have this problem. No message, the engine just crashes Try loading the bsp into Enhanced Win/GLQuake or another software engine, like Win/TyrQuake. Inspect qbsp log for warnings and repair as necessary. You can also run bspinfo on the bsp and see if there's a warning about BSP limits exceeded. This might indicate that something went wrong in the qbsp stage. "AllocBlock: full" The map requires too many lightmaps (normal limit 64) and this is normally caused by a leaking or boxed large map. Seal the map or remove box. Increasing scale of textures will probably help but often look bad, except for trigger or plain textured brushes (see section "Light Issues"). Another cause is excessive # vertexes in bsp. Check qbsp log and change map. Enhanced Win/GLQuake or Tomaz/Win/TyrQuake can usually load this kind of bsp. Software engines don't have this problem and Enhanced GLQuake has higher limits, will print warnings when exceeding normal limits and you can check the amount with the "lightmaps" console command. "ED_Alloc: no free edicts" The map requires too many edicts (normal limit 600) either at startup or while playing. This typically occurs when playing on Hard/Nightmare skill due to more entities. Use console command "edictcount" to see current amount. Enhanced Win/GLQuake has higher limits and will print warnings when exceeding normal limits. In these engines, you can also enable cvar scr_showedicts to display continuously. "SZ_GetSpace: x is > full buffer size" "SZ_GetSpace: overflow without allowoverflow set" These error messages indicate various memory buffers overflowing, typically in the protocol. The major cause is too many things happening at startup, while playing or when loading saved games, typically occurring when playing on Hard/Nightmare skill due to more entities. Enhanced Win/GLQuake has higher limits and will print warnings when exceeding normal limits. "Bad surface extents" "D_SCAlloc: bad cache size/width x" This error is normally caused by missing sky/liquid textures in bsp. Check the qbsp log for missing textures. If there are no missing textures, check if the qbsp option "-subdivide #" has been used and remove as necessary. Another cause is excessive # vertexes in bsp. Check qbsp log and change map. Enhanced Win/GLQuake will print warnings in the console about excessive # objects. "R_RenderView: called without enough stack" This error message is normally invalid; the real error is usually the above "D_SCAlloc: ...". Enhanced WinQuake will print the real error message. "Hunk_Alloc: failed on x bytes" or engine runs choppily with flickering disk icon Try allocating more memory for the engine by adding the command line option "-winmem 32" (DOSQuake) or "-heapsize 65536" (most other engines). Adjust value upwards if insufficient. Enhanced Win/GLQuake will print warnings in the console if excessive mdl caching occurs. Engine hitches momentarily or slows down to a crawl See above about heapsize issues. A less common reason is that your graphic card's texture memory is being saturated. Try setting cvar gl_picmip to 1 or higher in autoexec.cfg and restart engine. Another cause can be a too high value of cvar gl_max_size (max texture size for graphic card). Try reducing it and use only values that are powers-of-two (e.g. 256, 512, 1024 etc). "Too many static entities" The map requires too many static entities (normal limit 128). Static ents are created from QC and are typically light globes, torches and func_illusionaries. Enhanced Win/GLQuake has higher limits, will print warnings when exceeding normal limits and you can check the amount with the "staticents" console command. "Model progs/player.mdl not precached" This probably means that the startup QC code for worldspawn hasn't been run. Inspect entity section in bsp for corruption or delete any spawnflags keys in worldspawn. Enhanced Win/GLQuake will prevent deletion of worldspawn via spawnflags. "Too many efrags!" This console warning is normally caused by having entities (typically torches) too close to or even partly inside solid walls. Another possibility is too many (or too far apart) brushes that are included in one brush entity. EFrags means Entity Fragments. Enhanced Win/GLQuake has higher limits. "total_channels == MAX_CHANNELS" or muted sounds while playing This is caused by having too many ambient and dynamic (from e.g. monsters/torches) sounds in the map. Some sounds will then be muted. Enhanced Win/GLQuake has higher limits. "walkmonster in wall at: x y z" "Bonus item fell out of level at x y z" This console warning is caused by having objects (monsters, weapons, ammo etc) too close to or even partly inside solid walls. The objects may also not be too close to each other, make sure their bounding boxes are separated. If you don't move the objects to a proper place, remove them altogether. Monsters completely inside solids will cause invalid kill counts, see section "QuakeC Problems". "SOLID_BSP with a non bsp model" or "MOVETYPE_PUSH with a non bsp model" while playing This is either an engine bug or there might be brush entities without brushes in the map (e.g. a func_button without a brush). In the latter case, this typically happens when firing a missile near origin (0 0 0). Remove or repair such entities. Enhanced Win/GLQuake has fixed the bug, will print more information when it happens and also try to detect the issue already when loading the map. "Trigger in clipping list" while playing This is either an engine bug or there might be a problem with the self.solid variable in QC. Enhanced Win/GLQuake has fixed the bug and will print more information. "SV_StartSound: not precacheed" while playing This probably means that there's a misplaced sound key in an entity or a sound key with invalid value. Using the wrong progs.dat might also produce this error. Enhanced Win/GLQuake will print more information. Strange behaviour of triggers, doors etc while playing If you've recently rebuilt using qbsp with the "-onlyents" option, the brush entity order might have changed compared to the original bsp (likely caused by the editor). Rebuild bsp completely. Another common cause is having brush entities without brushes in the map, see "SOLID_BSP with a non bsp model" above. "packet overflow" or entity flicker while playing This is normally caused by the engine trying to render too many things at once. This in turn is probably caused by playing a fast/unvised large map with many entities. Fullvis the map and see if that helps, otherwise you'll need to reduce # entities or visibility in the map. When testing this, don't settle for just a quick notarget run-through. Play the map properly, preferably on Nightmare skill and with a brutal touch that produces more gibs. See also section "QuakeC Problems". Enhanced Win/GLQuake has higher limits. All white textures in GL-engines This might be caused by graphic drivers that offer 8-bit shared texture palette handling but fail to actually do so. Try adding option "-no8bit". Slow framerates in GL-engines in areas with sky Try setting the console cvar gl_subdivide_size to 512 or higher in autoexec.cfg and restart engine. Enhanced GLQuake has this value as default. Greyflash in software engines This is caused by the engine trying to render a too large or fast/unvised map. Fullvis the map and see if that helps. You can also set the console cvars r_maxedges and r_maxsurfs to 100000 and restart the map. Enhanced WinQuake has these values as default. Texture flicker while playing, "zebra-effect" This is normally caused by the engine trying to render several textures in the same plane, typically at some distance away. This is probably caused by overlapping brushes or e.g. a door that isn't sufficiently encapsulated. In GL-engines you can also try setting the cvar "gl_ztrick 0". Hall Of Mirrors (HOM) effects while playing See section "Portal Problems". Invisible walls while playing Either you've forgot to remove a clip brush or you have a clipping problem in hull 1. This is often caused by brush misalignments, similar to the ones in section "Portal Problems". To find the cause, look around in the area where you're blocked by the invisible wall. Look for a suspicious edge where two brushes may have a bad junction. Strange-looking models while playing This typically happens in GL-engines when using a mod (using the "-game x" option) with new models (e.g. weapons). Just delete the contents of the "glquake" folder beneath both the mod and "id1" folders. This will force the engine to recreate the model meshes next restart. Another common cause is missing skins (.mdl) or invalid QC for some models. This can also cause the engine to abort suddenly while playing. Enhanced Win/GLQuake has extra warning printouts for missing model skins/frames and Enhanced GLQuake doesn't need/use the glquake folder. Bad player skins while playing This is caused by the engine trying to overlay the current player shirt/pants colours onto the player model, that now may have a totally different skin. Set cvar gl_nocolors to 1. Trouble loading saved games This is probably because the map startup message (normally the map title) has one or more newline ("\n") characters in it. Remove the newline characters using a Q1 entity editor (e.g. QuArK). Another way is to use the bspInfo utility with the "-copyents" option, edit the extracted .ent file using NotePad and then rebuild using qbsp with the "-onlyents" option. Enhanced Win/GLQuake normally doesn't have this problem. Another cause is too many edicts, see "SZ_GetSpace: x is > full buffer size" above. Total/killed monsters count is wrong or invalid models for some entities after loading a saved game See section "QuakeC Problems". Invalid models can also be caused by having changed certain cvars since the game was saved. E.g. in Nehahra, this can be caused by changing the value of nospr32. Recommended engines: Enhanced Win/GLQuake http://user.tninet.se/~xir870k FitzQuake http://www.celephais.net/fitzquake TyrQuake http://disenchant.net