Common errors and warnings

  1. Errors:

  2. Warnings:

  3. Misc Problems:

  4. Credits

  5. History

  6. Sources

  7. Copyright

  • 1. Errors:

    Error: aas_point arena num: aas not loaded


    This is normally where you are trying to load a single player map and you havent got any .aas files. Also remember to use "/spdevmap yourmapname" to load up. For each single player map you make you need two .aas files, these are information for the AI, you only need to compile them using a tool, and they must relate to the same name as your map. See more in the tutorial for how to make aas files.

  • Error: AllocWinding failed: MAX_POINTS_ON_WINDING exceeded / WindingFromDrawSurf failed: MAX_POINTS_ON_WINDING exceeded


    What does this mean [mehoo]:


    **** ERROR ****
    AllocWinding failed: MAX_POINTS_ON_WINDING exceeded


    Imagine the first square is you looking at the end of a brush. The face has 4 vertices.


    Now, in the second picture, we have another brush, the face which you can see is co-planar with the first face, such that the two vertices touch one edge of the face. The compiler will split that edge on the first face and add the two vertices shown in green to it, making it now have 6 vertices. With multiple repeated brushes, this can quickly build up to the maximum of 64. [djbob]


    Often happens when you have a lot of brushes touching one brush, like 64 (which is meant to the the limit )all touching the same brush. Which if you can imagine you have made a wall and have 64 brushes up against it you will probably receive this error, so try to cut them down to less.


    There are too many vertices repeating themselves along a single axis. This can be caused by ladders. It can also mean you have a "brush side polygon" somewhere with more than 64 corner points. The ladder case specificly has to do with T junctions (SCDS_reyalP)


    This error often occurs when there are just too many vertices on a brush. Look for long, thin brushes and clip them (Shift-Enter) into multiple brushes to get rid of the error.

  • Error: Backwards Tree Volume


    ERROR: Backwards Tree Volume


    I fixed the error turning all brushes touching the void to structural brushes.

    Just ran into this one on a small test map, a few detailed detail brushes surrounded by a hollowed box of caulk, which was structural. And touching one edge of the detail brushes. Got rid of the error by making the caulk hull not touching the detail and getting rid of the overlapping parts of the caulk hull.


    This error can be caused by several problems. The two most common are start position in the void or start position on a floor with a detail surfaceparm. Make sure that you place the start position on a floor made out of a solid texture and that it isn't too close to a wall.

  • Error: Chose a 0 valued axis


    What does this mean:


    **** ERROR ****
    Chose a 0 valued axis


    This error occurs when you try to Cap a cone. The problem is that the top of the cone gets a 0*0 cap. So... remove the top (read small) cap of that cone.


    I got

    choose 0 valued axis

    during initial stage of BSP. Did not have anything to do with the last number of brushes I placed, I think though. [fischu]


    It might be related to your using an axis of rotation on an entity set with 0 rather than 360 (which is the default 0). Check your entities for a key/value pairing of angle/0.

    A quick way to check entities is to open the map Entity Info browser (L-key) and go down the listing selecting each entry and reading what it says. Once you found the bad entity (assuming it is a 0 angle error) click the Select button and then Close the browser.


    Checked all entities, no angle/0 pairs. I found a light with an angle, but that did not fix my error. Deleted and remade everything I did since last successful compile, still the same error. q3map2 disconnects after the error.


    What version of q3map2 are you using?


    Using latest? v2.5.11, doubt though whether version of q3map2 really matters. It is probably something stupid, but I have got no idea where to start looking.


    The answer was in this thread funnily enough:


    ************ ERROR ************
    Chose a 0 valued axis A.

    This error occurs when you try to Cap a Cone. The problem is that the top of the cone gets a 0*0 cap. So... remove the top (read small) cap of that cone [Hr.O]


    The thing is, I have not capped a cone since the last successful compile. I do recall thickening one by 2 units. Would this have the same effect? Also I have already deleted everything I had built since the last compile. Or would I have to do open it up in notepad and look for a patch with a 0*0? angle, I do hope there is an easier solution as I do not think I would know what to look for, patches I can recognize but the bunch of numbers under that I can not.


    Do a quick test map, just a box with a cylinder mesh in it. Cap the cylinder and then try a compile (do not forget a player spawn as well), if you have a clean compile then you know that "cylinders" are generally OK and there is a problem with a mesh in the previous .map file.

    What the error actually means is in capping the cone (or cylinder) you have created a mesh section that is so small that it no longer has a valid size 'X' x 'Y' units. If you are still getting the error now then it means there *is* a mesh somewhere causing the problem. Thickening in of itself will not necessarily cause the problem so the best thing to try is to hide the patch related brushwork (Ctrl + P) and select/copy/paste everything else to a fresh new .map file. Do not add any meshwork/cylinders to this file and just do a compile to check it is OK. Once you have done that, if it compiles OK, you can then either rebuild the patch work or copy/paste that stuff from the old file one mesh section at a time compiling a new file each time (so you can backtrack when you find the error) it is a bit of a long winded way to find the problem patch mesh but if you cannot remember where it might have started to happen you have to be quite methodical in tracking it down.

    You could probably track it down in notepad but the entry might not actually be 0*0 on the patch mesh. Open the .map file anyway and look for a patch mesh func_group and see if you can find anything out of place. Make backup versions of the file as you work as you could totally mess up the file by deleting entries like that.


    yeah, did it. Lazy as I am I tried to think of a quicker way, simply placed brushes where I had thickened the cones, and clicked on the select inside button. And as you said 2 tiny white lines/dots appeared. Hitting the backspace button really made me smile. Compiling sweetly now.

  • Error: ClipWindingEpsilon: 90 > MAX_POINTS_ON_WINDING


    This error often occurs when there are just too many vertices on a brush. Look for long, thin brushes and clip them (Shift-Enter) into multiple brushes to get rid of the error.

  • Error: DispatchBSPCommand failed with a COM exception


    A problem with gtkbuild and q3build, you must have the .dll in the plugins folder and it needs to be compatible with the editor or it will give this error, with wolf you probably wont be using any of these compilers anyway, but if you are somehow this might occur.svsv


    This is a Q3Build/GtkBuild error. The .dll must be put in the plugins directory, and you must be using a version of xxBuild that is compatible with the editor. (QER)

  • Error: Duplicate Planes / Entity x, Brush x: duplicate plane / degenerate plane / mirror plane / bad normal


    The q3map2 compiler works on this error fine. If you are using too much Drag Edges then you get this error though [reptile]:


    ***ERROR*** <insert error message here>


    You will probably find you have got some corrupted brushes somewhere if that is the reason you think the error is happening. I take it you have used the bobToolz to clean up the brushwork (Plugins menu, bobToolz, Brush Cleanup)? If you are still getting errors then you may need to go through the map and check the brushwork you have been dragging around and manually fix any bad brushes.


    Entity x, Brush x: duplicate plane


    First, entity x and brush x are the name of the brush that's causing the error. What's wrong is you have two faces on a brush that are in the same plane, meaning one brush has a single face composed of 2 faces. Simply search for the brush and fix the problem, deleting and rebuilding it is the best method of fixing it.


    When you were editing a brushes vertices, at some point you dragged the vertices in such a way that the two planes opposite each other were in the same place. While this error isn't necessarily a vital problem in the compile process, it can cause some weird visual side effects as you basically have a double-sided texture. It is generally best to avoid this, but it is technically okay to leave it as it is. In EFRadiant, click Plugins, Rogue Brush Repair, Remove duplicate planes.

  • Error: Error opening c:progra~1ravenstartr~1baseef/maps/purectf.bsp: No such file or directory


    The vis stage of your compile was unsuccessful. This error is caused by another.

  • Error: iKernel.exe


    I get a strange error when I try to install GTKradiant v1.2.1. The install program throws up a

    The Installshield engine (iKernel.exe) could not be installed. It cannot read from the specified drive error.

    Anyone seen this before? [miez]


    I have had this error in the past when trying to install from a "corrupted" copy of the program - usually when trying to install from a CD backup of the app. I found that either re-downloading the app or copying it (from the CD) onto the harddrive usually solved the problem. Seems especially so under Win98!

  • Error: Leaf has too many portals


    Generally means that you have a very complicated brush someplace probably with a lot of faces and is far too irregular and complex so the map wont compile so you need to make it less complex.


    This error is results when one of the leaf-nodes in your map meets too many other leaf-nodes, and therefore has too many portals. To fix it you can split the offending leaf-node up, or reduce the number of leaf-node it meets.
    To reduce the number of splits made you can simplify the brushes in the map. You can also make the compiler ignore certain brushes by tagging them as "detail" (Ctrl+M with selected brushes).
    To force a split in the map, you can use a Hint brush, which is an invisible nonsolid brush which only q3map can see and use (Hint brush = axial brush with all faces common/hint). (Courtesy SmallPileofGibs) (QER)


    A leaf is a leaf-node, one of the leaves in the BSP tree that is used to store your map. Each leaf-node is a small convex volume of space within the player-space inside the map's outer hull. Each leaf-node in the tree has a set of faces, which are flat (planar) surfaces which form portals where they meet the faces of other Leaf-Nodes in the map. This error is results when one of the leaf-nodes in your map meets too many other leaf-nodes, and therefore has too many portals. To fix it you can split the offending leaf-node up, or reduce the number of leaf-node it meets. Leaf-Nodes are created at the first q3map compile stage when the BSP Tree is generated. Put simply, the compiler arbitrarily splits the inside space of the map up into convex sections, using the faces of the brushes in the map to split along. To reduce the number of splits made you can simplify the brushes in the map. You can also make the compiler ignore certain brushes by tagging them as "detail" (Ctrl+M with selected brushes). To force a split in the map, you can use a Hint brush, which is an invisible nonsolid brush which only q3map can see and use (Hint brush = axial brush with all faces common/hint).

  • Error: Line <xxx> is incomplete


    ERROR: Line <xxx> is incomplete


    I got that single error when I tried to BSP. I checked the .map file in a text editor, tried recreating brushes, etc, etc...

    Turns out it was one of the Shader files. In line <xxx> I used surfaceparm without a parameter. You would never guess it from the error message. [[AF]haste]


    The "Line [value] is incomplete" error is actually referring to a problem picked up by the *.srf file during the BSP compile process.

    As it's text based it can be opened in NotePad and the corresponding line to the error inspected. The .srf files lists information to do with the data in the map file as the compiler runs through the process of converting the map to a BSP.

    The following is an example of an 'error' as shown in the .srf file;

    85 // SURFACE_TRIANGLES V: 86 I: 288
    shader //textures/widget/widgetbody
    sampleSize 0

    It should read like this;

    85 // SURFACE_TRIANGLES V: 86 I: 288
    shader textures/widget/widgetbody
    sampleSize 0

    Note the double backslashes, '//', in front of the shader path reference aren't present, those are referring to the actual 'error' in this case; two backslashes ('//') that have been left in place somewhere in the asset chain.

    So for Quake 3 game editing check the shader paths used in models, in particular ASE models. Make sure that when you edit in the shader path that you don't leave any backslashes '/' in place before the texture path. Doing this;

    • *MATERIAL_NAME "//textures/widget/widgetbody"

    is incorrect and will result in the "Line 178 is incomplete error". It's corrected by doing this;

    • *MATERIAL_NAME "textures/widget/widgetbody"

    The two forward slashes, '//', have been removed from in front of the texture/shader path.

    So as a first port of call when this error crops up is to look through the .srf file and the corresponding line of text to see what it's picking up as causing the error. It's then a case us finding what asset or assets are using that reference and then correcting the problem.


    Can be where you have missed out an end bracket } in a shader or some sort of missed out part of some code in a shader on the line mentioned, so check your custom shaders for incomplete brackets etc.


    In the previous case, this was fixed easily by copying the entire map in text form (open up the .map file in a text editor and copy everything), and then paste it into a new .txt file, then rename it to .map and open it. Run a Brush Cleanup (Plugins menu, bobToolz), and you should be good to go. [Fjoggs]

  • Error: LoadPortals: couldn't read c:progra~1ravenstartr~1baseEF/maps/unnamed.prt


    Your map has a leak somewhere that needs to be fixed.

  • Error: LoadTGA: Only type 2 (RGB), 3 (gray), and 10 (RGB) TGA image


    I have the following compile error after loading the shaders:


    **** ERROR ****
    LoadTGA: Only type 2 (RGB), 3 (gray), and 10 (RGB) TGA images supported.

    How can I find out which .tga file does not fit? [Strahlemann]


    It is quite possibly not a .tga file at error here but more likely you have got a .jpg in your working directory that is been saved with Progressive Compression which Q3 does not like. Resave the image without and you should be OK. [anon.]



    Usually means you have a really complicated complex brush in your map, thats not allowed! You need to make it less complex!

  • Error: MAX_FACETS during vlight (maxfacets >= 65XXX)


    You've got too many spheres and/or cones in your map. The maximum number of facets allowed is 65,535.

  • Error: MAX_IMAGES (512) exceeded


    There are too many image files referenced by the map.


    It seems that you've used too many different textures. Try to reduce the used textures.



    Are there some unwritten rules concerning the building of Portals? I have had to simplify the portal I made for my WIP considerably just to get it to compile. It appears that a portal's geometry cannot go beyond a certain level of complexity, nor can it be too large (i.e. the size of the world or larger). I got the


    error in the BSP stage when I attempted to construct some buildings from brushwork in my portal. I have now just made a few simple buildings, ASE'd them and cloned/rotated them, and there are ano problems. Has anyone had this error before? What is the difference between a BSP leaf's face and its portal? [seremtam]


    This error occurs when you have too many drawsurfaces in a single BSP leaf. The maximum is 0x2000 (8192). You must have some exceedingly complex set of surfaces or are not using q3map_nonplanar or meta to merge stuff, or using _blocksize with a value too high or simply not splitting them map up enough.

    I do not recall the last time I saw anyone get that error. [ydnar]

    Note: Or your skybox area is too complex. Try to keep it reasonable, because the 8192 leaf/surface max means you are limited to 8192 surfaces in your skybox. Usually less, since sky leaves tend to have other surfaces already in them.





    You have a brush that is too complex. [anon.]

    You have too many brush sides (total), in your map. As simple as that. Possible solution, slice up brushes which have sides not visible to use fewer sides. [Kat]


    This is normally a problem with your total amount of brushes on the map being over the limit, the limit is apparently 32768, so you should try to get rid of some brushes. If your amount of brushes is around that area or you can remove some brush sides, each brush has multiply sides so try removing some of the sides that wouldn't be seen when playing.


    It means too many TOTAL brush sides in your map. The solution is to reduce the TOTAL number of brush sides (SCDS_reyalP)



    This might occur if you have put tesssize 1 in your shader by mistake, this means that texture is being tiled thousands of times so to speak. You need to enlarge the number to around 128, 256, etc



    Your brush work is too complex. You need to simplify your design and try again.

  • Error: MAX_MAP_EDGES


    As the error name suggests, this crops up during the compiling of *.maps when they contain more than an allowable limit of EDGES.

    A polygon (commonly called 'tris' in mapping parlance), as used by game engines, is constructed of three distinct elements;

    • Face (the bit you see in game)

    • Vertexes (points of reference in 3D space)

    • Edges (connections between vertexes)

    Each of these 'elements' has a physically hard coded limit in the; a maximum number of allowed 'units' (of that element type) over which the compile process with stop if breached, so in the case of MAX_MAP_EDGES, the limit of 60,000+ (or thereabouts) has been exceeded resulting in the compiler crashing and spitting out that message.

    It usually happens as a result of badly constructing your map, specifically 'where' and 'how' brushes butt up to each other.

    Design note: 'bad' in this context can mean overly detailed brushwork (a map full of fiddly brushwork or detailed architectural features) as opposed to poorly made/constructed brushwork; this error can occur irrespective.

    Depending on what compiler options were used, it will create an extra vertex or split where brushes butt up to each other; this is done to prevent a number of related issues ("sparklies") but as an 'optimisation' method it inadvertently causes the max map edges error.


    Generally there are two ways to fix it;

    • Better map construction techniques

    • Converting brushwork to models

    Better construction methods means paying closer attention to how brushes are connected to each other; a general rule of thumb is to try and make things 'even', and 'neat' rather than haphazard based on the assumption that the compiler will 'fix' it. It won't and as shown above, the process will tell you.

    Converting brushwork to either ASE or LWO models (if the game allows for it) is the better option as models tend to be 'optimised' already. The kind of things that are generally regarded as good candidates for conversion to models are any elements that get used repeatedly, anything that's overtly detailed (has tiny physical features) or objects that are placed or rotated at odd angles.



    Usually means far too many lights are in your map, and to solve this you need to up the gridsize setting. You can use Worldspawn to enter gridsize with values of 128 128 128 or higher You can also use the common/lightgrid texture to make a single brush around your map which q3map will keep in these bounds, therefore not lighting up anything not in under the bounds of the brush.


    You have too many lights in your map. In the worldspawn enter key lightgrid and for the value, 64 64 64. Infinite brushes can also cause this error. (QER)
    Nothing to do with the number of lights. It is the size of the lightgrid. A lightgrid brush is another plausable solution (SCDS_reyalP)



    What does this mean [anon.]:

    ****Error MAX_MAP_LIGHTING****


    The "LIGHTING" part of MAX_MAP_LIGHTING refers to the lightmaps created for the map.

    Lightmap images are created by the third stage of the compile... either by -light using the old light-tracing algorithm or -vlight using MrElusive's Volume-casting light algorithm thingy.

    Each Drawable Polygon surface has lightmap texture coordinates created for it by the first stage of the compile. The third stage creates the actual lightmap images for each surface, and all of these images are squeezed onto "pages", with multiple lightmap images on each page. Each of these pages is 128*128 pixels in size, enough to cover 2048*2048 units of brush surface at the standard lightmap resolution (16*16 units per pixel). There is an upper limit on the number of lightmap pages that can be crammed into the BSP... probably about 4 MB. That works out to about 80 pages of lightmaps, which is quite a lot of surface area.

    If all the sections of your maps compile fine individually, then it must be that the lightmap pages created for the combined map are greater than this limit.

    There are two solutions to this problem:

    • - Easy but lower quality, use 32*32units per LM pixel resolution.

      • Code:

      • q3map -samplesize 32 <mapname>

      • q3map -vis -saveprt <mapname>

      • q3map -vlight -samplesize 32 <mapname>

    • - More difficult but much better result, reduce the total surface area of the drawable polygons in the map. This will reduce the number/size of the lightmaps, reducing the number of lightmap pages created, reducing the total size of the lightmaps in the .bsp.

    Drawable polygons are created for a surface even when that surface is hidden by a detail brush. Apply textures/common/caulk to these surfaces, or delete them entirely if they are patches.

    Drawable polygons are also created for surfaces that are only partially hidden by structural brushes - and, providing that the drawable polygon is convex, parts of it may still be hidden behind structural brushes, taking up extra lightmap area. If there is a significant amount of the area on a surface hidden by a structural brush, split the surface up until only the visible part exists.

    Also read Technical by SPoG.


    This error message means that you have too many lightmaps in your map.

    1. Try adding surfaceparm nolightmap to your terrain's shader.
    2. Try adding the following order to your environment box- or sky- shader: q3map_lightsubdivide 256.
    3. Reduce the light emitting surfaces like environment/skybox, lamps or the number of simple light entities.
    4. Increase the sizes of surfaces/planes with vertex lighting. You can do so by using surfaceparm nolightmap. (QER)


    Reduce the total surface area of the drawable polygons in the map. This will reduce the number/size of the lightmaps, reducing the number of lightmap pages created, reducing the total size of the lightmaps in the .bsp. Drawable polygons are created for a surface even when that surface is hidden by a detail brush. Apply textures/common/caulk to these surfaces, or delete them entirely if they are patches. Drawable polygons are also created for surfaces that are only partially hidden by structural brushes - and, providing that the drawable polygon is convex, parts of it may still be hidden behind structural brushes, taking up extra lightmap area. If there is a significant amount of the area on a surface hidden by a structural brush, split the surface up until only the visible part exists.



    Messing around with some ASE model produced this error during BSPC (for RtCW) as a result of them being q3map_clipmodel. Removed that and manually clipping the models solved the issue. The clipped ASE models were creating an excessive number of 'planes' which broke through the limit. [Kat]



    Associated with AAS files for Bots or AI. Usually caused by using large numbers of models (with q3map_clipModel in a shader) or large numbers of patch meshes in a map. For Models - removing q3map_clipModel from shader and manually clipping with weaponsclip (or some other clip brush) seems to fix this.

    For Patch Meshes - depending on the number of models in a map, converting patch mesh work to ASE models sometimes helps leave clipModel out of shader) to remove the error.

    But for AAS problems, ydnar has noted that "BSPC needs to be updated with larger allowable values for planes, brush sides, etc." This affects any Quake3 engine games using Bots or AI. [Kat]


    You have two choices: cut down on the number of brushes in your map, or don't add bot support. You can try putting clip brushes around heavily detailed brush work, but no guarantees that it will work.




    I can't find it in any Q3 error listings, so I can only presume it's new to either ET or recent Q3Map versions.


    It only happens during the FixTJunction phase of the compile. Apparently, you have hit the limit of 65536 original edges. At this point, my understanding of the q3map2 code fades, and I'm not sure if "original edges" are the set of unique triangle edges in the map, or if it is the number of unique edges allowed per meta surface.
    EDIT: If it is the later, then I wonder, do you have an extremely large terrain?


    It was the number of edges in a meta surface. I had to reduce the number of triangles in my terrain.



    This usually means that a brush face that is visible is being split to many times, seems similar to max points winding in that you might get this error if you have too many vertices touching one brush or face.


    The visible brush face is being split too many times. Extra vertex points are created by q3map on visible face edges, where they are split by other visible face points (corners, or vertices). So if you have too many visible face points touching the edges of another face, that particular face will be split many times and have many vertex points. (QER)



    MAX_POINTS_ON_WINDING error [anon.]


    I have found a solution to the MAX_POINTS_ON_WINDING error, and it does not involve deleting any brushes. Use the -meta switch in your BSP compile, and the error does not pop up. I do not know why, do not know how, just know that it works.


    Entity x, Brush x: MAX_POINTS_ON_WINDING


    This error often occurs when there are just too many vertices on a brush. Do a search for the offending brush and clip it (Shift-Enter) into multiple brushes to get rid of the error.

  • Error: MAX_SHADER_INFO Exceeded


    Remove some PK3 files or shader scripts from shaderlist.txt and try again.

  • Error: MAX_SUBMODELS Exceeded


    I got this message while I was loading up my map [darkalan]:

    MAX_SUBMODELS exceeded


    Believe it or not, the error is more related to entities, not models. Correct me if I am wrong, but I think you are limited to 255 brush entities (func_ brushes). If you exceed that amount, you will get the MAX_SUBMODLES exceeded error. Keep in mind that you can make one brush entity out of several brushes, and it only counts as one. [Grand Nagus]



    MAX_SURFACE_INFO is specific to Quake 3 engined games and tends to crop up more often when using the original version of Q3Map rather than ydnars updated Q3Map2 (the original Q3Map has lower limits and a lower tolerance for errors than Q3Map2 so will throw up problems more frequently), the former (Q3Map) usually being included in 'official' tools sets based on QeRadiant and not GTKRadiant.

    The MAX_SURFACE_INFO error itself happens because the compiler is reading (parsing) too many shaders (surfaces) when it gathers data for the compilation of a map. Becuase there is a limit to the number of allowed shaders - somewhere in the region of 3000+ - if the compiling process goes over that it errors out with the above message.


    Remove any custom shaders you may have installed, either by directly extracting them to the 'scripts' folder or by their presence in various custom PK3 files. Essentially your editing environment should be as close to the original state it was in when the editor was first installed.


    Main cause of this is when you have too many shaders. Try removing lines of them that are not used or remove entire ones, the limit is 3192. Unlikely to occur unless you have a large amount of shaders and textures in your map.



    This usually happens with large maps, it occurs when you have 256+vertices on one face, which reminds me of the MAX_POINTS_ON_WINDING which has a limit of 64 vertices touching one brush, so its odd how it can even happen. Anywho you need to rectify the error by not having so many vertices on one brush!


    Means you've got a lot of patches and curves. If this is the case, try deleting some of them and go for a less ambitious design. (QER)
    This is very similar to the MAX_POINTS_ON_WINDING error, though i think it applies to patches instead of brushes, i.e. you have too many control points (djbob)

  • Error: MAX_TW_VERTS exceeded (Max Trace Winding Vertexes)


    A trace winding is created for every triangle in the map and then chopped up into the BSP, then further chopped up until each of the raytracer's nodes is smaller than a certain size or complexity.


    Explanation: Hitting MAX_TW_VERTS means you have got some clustercrunch of geometry getting sliced up too much. Run a BSP compile with -debugportals (assuming you have the q3map.shader installed & in shaderlist.txt, or you are editing with the newest version of Gtk) with no vis or light stage, and run around the map looking for areas with lots of portals.

    Other Possible Fixes:

    • If you can't find the offending area, then run the -light phase with the -lomem string to disable the trace tree subdivision.
    • Your map may be quite complex. Did you use a larger _blocksize key? Try _blocksize 8192 (or 16384) in the worldspawn.

    A big thanks goes out to Ydnar for his lengthy explanation of this error. [Raven]


    If you have this error, then you have a cluster of geometry getting sliced up too much in the compile. If you can't figure out where the problem is, then compile your map using Q3map2 with -debugportals (assuming you have the q3map.shader installed & in shaderlist.txt) then run your map and look for areas with lots of portals (the portals should appear as colored transparent walls in the game if you used the -dbugportals switch). Once you find the area that looks like it might be causing the problem, see if you can cut down on the geometry there and/or make sure your using detail brushes as well instead of only structural brushes. If you can't figure out where the problem is, then your only option is to run the -light phase in the compile with the -lomem switch (using Q3map2)to disable the trace tree subdivision, but use that as a last resort.



    Has anyone ever gotten this error while doing the -vis compile:


    I am working on a, well... huge map and I am noticing this problem more and more. Right now I am only able to do the minimal BSP and test out the map, but I would like to do lighting and everything else when I am ready to present the finished project. Does anybody have any advice besides downsizing the map? [quakefraggin]


    Yup... you have basically made your map too big! You have used up your allotted VIS data (it is around 2 MB I think [2,040,000 as you see it reported in GTKradiant Bsp monitoring] someone will correct me on this though.) [Kat]

    Note: Or use Detail better so that the BSP is less complicated, and so requires less vis data. [djbob]

    Note: Actually, it has nothing to do with the size of your map, but rather the structural complexity. Rather than cut down your map, you may want to consider rebuilding it taking vis into account.

    Every structural brush face in a map has an associated plane. The higher the number of unique structural planes, the larger your vis data will be.
    To clear up a common misconception, larger vis data does not mean vis is working harder or more effectively.
    A gross oversimplification: The vis data is simply a collection of lists that answer "is this area visible from here?" Every location in a sealed, fully vis'ed map has such a list. The more unique "locations" in a map, the more memory the vis data will consume.

    Those locations are BSP leaves. As the goal of the Quake 3 BSP compiler is to create a BSP with convex leaves (i.e., no interprojecting volumes), then the hairier the makeup of your structural brushes, the more leaves in the final BSP.

    Certain individuals (myself included, on the rare occasion I am mapping) subscribe to the notion of building for vis. That is simplifying it a bit, as there are other things to take into account, but the basic method is this:

    • Build the Structural Hull of the map entirely with caulk. Caulk is solid, opaque to vis, invisible to the eye, and unless changed in Radiant, structural.

    • Build what the player sees out of caulk detail brushes and patches, then texture the visible faces.

    • Share planes wherever possible. Terrain, or any other "meshy" mass of brushes, for instance, should share a single plane on the backside. Cutting down on the number of unique planes is a Good Thing.

    If you are feeling up to it, read SPoG's Quake 3 BSP doc for a more in-depth explanation. [ydnar]


    You may get this error when making a very large map, and although the obvious thing to do is to downsize the map you can do other things such as use detail brushes more so the vis data is less complicated so then the vis data wont be so large. Also dont forget to use the caulk texture. Take into account the way the map is structurally made, it might not of given the error because the map is huge, but because its been made poorly in that you can see too much on screen at once and the view of whats on screen at once hasn't been taken into account well enough.


    In most cases this means that your VIS data size has gotten too big. To reduce the size of your VIS data size utilize detail brushes more efficiently.

  • Error: Multiple Crossing Points for Patch - Can't Clip


    Compiling a RtCW SP map with q3map2 v2.2.38 I get this error:

    Multiple crossing points for patch - Can't clip

    It happens during the initial stage of a BSP compile (once it is run through the shaders and 'longest curve' entries). It does not bork out the process (and q3map2 happily continues to do the rest of the process) so I just wondered what it meant. I am guessing it has something to do with a weird twist in a patch mesh somewhere (due to miss-aligned control points?) that means clipping the mesh is not completed? [Kat]


    That is due to a patch cutting the surface of a fog brush more than once, because the compiler can only split the patch once. [dayve]

  • Error: No file to process. Run with -? for help


    You're either compiling in DOS which is bad, or you are using an old version of the compiler. Get the latest version of Radiant.

  • Error: PicoLoadModel: Failed loading model [path]


    The most common cause of this error is related to the various file paths used by the editor (both GTKRadiant and QeRadiant); usually  it'll be  the file paths to the compiler options rather than specifically file paths to models as set out in your projects settings.


    From your/scripts/..folder find the following and then;

    1. Open 'user0.proj' into NotePad and check the file paths; make sure they are correct in relation to the location of the compiler you're using.
    2. Open 'user0.qe4' into NotePad and check the file paths for the compiler options. As above make sure they are correct relative to the compilers location.

    You should where possible use a text only editor because certain word processing applications tend to add hidden 'formatting' syntax to a file which will crash the editor and compiler when it subsequently tries to access the file.

    Or whilst you've got a map open in the editor;

    - Select a model (or models) and check the file path listed for that entity in the Entity Inspector panel, make sure they're listed as models/mapobjects/.. or similar and not something along the lines of C:/Program Files/Quake 3 Arena/models/..

    '1' and '2' tend to happen if you load in an old *.proj ('project' file) or *.qe4 file from a previous installation, the file paths to the various compiler options and location are usually incorrect so when you run Q3map2 (q3map) the process will report various 'failed' messages.

    Doing any or all the 'fixes' about should solve the problem.

  • Error: RB_CheckOverFlow: verts > (#### > 1000)


    This happens when you compile your map (and it has models in it) without a -Meta stage and the models in your map have over 1000 verts


    Check the model in ModView. It might give you a rather surprising vert count. When exporting to .md3 format, any face that doesn't have a smoothing group assigned to it will be separated to an element, so a model with 600 faces and no smoothing groups gets split into 600 elements, each with their own set of verts.


    Thanks for the help. Modview is saying 1000 verts. Is there anyway to fix this, besides deleting verts? All of mine are absolutely necessary.


    Either give faces smoothing groups or import your .glm file, convert it to editable poly and weld all the verts together.

  • Error: safe_malloc failed on allocation of 71058624 bytes


    Set com_hunkmegs to half your RAM, exit the game normally (don't type /quit), and load it up again.


    You may have to tweak your solution appropriately and test.
    I was able to increase my worldspawn _lightmapscale size from 1.25 to 1.75, and successfully compile. The -light stage in q3map2 no longer blew up with the error above. Shaved about a half-hour off -light (from ~75m to ~50m) as I no longer require -lowmem as a band-aid fix. Meanwhile I'd also found all patches and increased (less detail) _lightmapscale size on their entity groups to waste far less lightmap data.

  • Error: stylenum == MAX_SWITCHED_LIGHTS


    I have placed some lights with targets (I do not know exactly if it causes the problem or not). Then when I complied I got this error:

    stylenum == MAX_SWITCHED_LIGHTS

    What does this mean? [3tehakanyuksel]


    This occurs with targeted lights. It is a Quake/Quake 2 vestige where targetnames were indexed for lightstyles. Since Quake 3 has no lightstyles (no flickering lights), you cannot target light entities. [ydnar]


    This usually occurs with some abnormal targeting of lights, check for lights with "targetnames" in by mistake, remove all the targetnames from the light entities to fix it.

  • Error: target_speaker without a noise key at (xxx xxx xx)


    Wanted to test my speaker entity but I can't even load my map. I see the quake logo in the background and in the front it says:

    target_speaker without a noise key at (296 320 -40)


    As you can read in the error message, one target_speaker in your map doesn't include a noise key as attribute. Just load your map in the editor, find the speaker and type in noise in the key field and path/filename.wav in the value field. It could also be that you accidentally used music instead of noise since the worldspawn entity uses this key.
    If you can't find the speaker the game requests then open up your map in a writing tool like the Editor and search for the coordinates. Since the target_speaker is an entity there will be something like "// entity 20". Either you delete it completely starting at the "//" and ending at the next closing bracket "}" , or you type in the noise key and its value.
    That method is also very useful if you have a broken brush, need to delete it and only know the number.

  • Error: wglMakeCurrent failed..


    ERROR: wglMakeCurrent failed.. Error:[value] is usually associated with having Anti Aliasing enabled in your graphics card control panel when trying to use the the various flavours of the Radiant editor; QeRadiant, GTKRadiant or Doom 3/Quake 4 Radiant.
    The editor is intollerant of Anti Aliasing and will often display various forms of the "wglMakeCurrent failed" error - giving a 'value' that refers to a specific error code reference (a number that refers to a specific error) - when it's run and finds AA enabled.


    Anti Aliasing will need to be disabled via the control panel of your graphics card vendors drivers; there will be a setting somewhere in the control panel that deals specifically with Anti Aliasing settings, make sure they're disabled or set to "Application Decide" or similar - in effect the GXF card is being told to use whatever AA settings it finds when as game is run; uses 'internal' game specific AA settings - or you can append the following to the editor short cut;

    • +r_multiSamples 0

    This applies specifically to wglMakeCurrent failed errors produced when running Doom 3 Radiant and Quake 4 Radiant (D3Edit and Q4Edit) and needs to be appended to the editors startup icon. If that still doesn't work then remove the two *.cfg files placed the 'base' folder of the game, usually;

    • Quake4Config.cfg

    • editor.cfg

    This is especially so if copying a previous install of Doom 3 or Quake 4 to another location on your system or if you have updated the graphics card, replacing an old with new card.

  • 2. Warnings:

    Warning: bad PointToPolygonFormFactor: [float]


    This is some sort of patch/mesh error, some say its caused by large patches and you can ignore it if it doesnt cause any problems. Also it is said that it can occur from a patch/mesh being to close to a sky texture.


    You've got a mesh too close to the sky box. (QER)


    You have a curve patch with at least one dimension larger than 512 units. This is not a fatal error, but may cause lighting artifacts on the curve. This error may not have to affect your map at all but if you see some strange light effects on one of your curve patches try to create that curve patch with several smaller patches. (q3me)

  • Warning: Brush Plane with no Normal


    I have been using Brush Cleanup all along (the one that came with the latest version of GTKradiant) and I have still had the "brush plane with no normal" problem. So I am guessing it is the rotated patch mesh that is causing it. What do you mean by manually rotating it? A lot of time I use the Z-axis rotate 90 degrees button. Should I not do that? And I looked in the .map file, I am assuming a patch looks something like this:

    • Code:

      • // AEon: Added indents, map source does *not* use indents!

      • // brush 23

      • {

        • patchDef2

        • {

          • proto2/concrete02

          • ( 3 3 0 0 0 )

          • (

          • ( ( -1344 784 128 0 0 ) ( -1376 784 128 0 0.250 ) ( -1408 784 128 0 0.500 ) )

          • ( ( -1344 720 128 0.500 0 ) ( -1376 720 128 0.500 0.250 ) (-1408 720 128 0.500 0.500 ) )

          • ( ( -1344 720 64 1 0 ) ( -1376 720 64 1 0.250 ) ( -1408 720 64 10.500 ) )

          • )

        • }


    But which of those sets of numbers is the coordinates? [wviperw]


    90 degree rotation from the toolbar is fine. It is using R-key for manual rotate that can mess things up. The first three numbers inside the brackets in each case are the coordinates, so for this patch, everything is fine. [djbob]


    A brush has a dodgy face. Usually means that you can't see it in the editor, but can in the map (in game). You can use bob toolz: brush cleanup to get rid of this in some situations. In other situations you might have to search your map file (in notepad) and look for decimal points (in the first 3 numbers in the brackets) and round them off (get rid of the decimal point). Also you might manually rotated a patch and it went all funny. Best not to rotate patch meshes manually (by using rotate and then move the mouse around to move them)


    You have a brush with a messed up face which will not be shown. Vertex manipulation of the brush is likely to make it disappear and become a phantom brush, if it is not already one. Brush Cleanup (Plugins menu, bobToolz) will fix these. Alternatively, it could be a patch which you have manually rotated (not a good idea), which is nasty, as you probably will not be able to see it in editor, but will show up in game. I (djbob) enhanced Brush Cleanup to sort these too. However, I never seem to have patched the changes.

    To get rid of it, look through the .map using notepad. If you see any patches which have coordinates that have a decimal point, round them manually. [djbob]

  • Warning: could not find path/filename.wav - using default


    I added a target_speaker to my map, set the "noise"-key, but all I get is this message:

    WARNING: could not find sound/mymap/torch.wav - using default

    and all I can hear is a default, ugly noise.


    There can be several reasons why Q3A doesn't recognize your file:

    1. The filename is wrong typed.
    2. The path which leads to the file is wrong.
    3. You use a *.mp3 not a *.wav file.
    4. The file is a stereo, not a mono file. Target_speakers can only play MONO files (use Audacity or any other sound program to convert it).
    5. The file has an other sample rate than 22050. Convert it into this format.
    6. The file hasn't 16bit. Q3A only reads 16bit wav files.

  • Warning: entity x, brush x: microbrush:


    This is an extremely small brush. Remove it from your map. Locate it by using the entity and brush numbers (misc -> find brush)

  • Warning: Flipped Triangle (xxx) (xxx) (xxx)


    IF you get a ton of these warnings during BSP.
    AND you get a crash on VIS (probably MAX VISIBILITY EXCEEDED) OR LIGHT crashes with an error (can't remember what the typical one is)...
    AND you have BRUSH (not model) terrain in your map...


    You need to caulk all sides of ALL brushes in your terrain except for the top surfaces. You probably have terrain on all sides of all brushes. Have fun updating those textures. My advice is to caulk it all, then select large groups of the top sides at once, apply the terrain texture, save, select another bunch, apply, save, rinse, repeat as necessary.

  • Warning: light grid mismatch


    Can mean you havent done the part of the light compile possibly due to a leak or other error, which has resulted in full bright in map and that error message, so check for leaks and other errors, or run a full compile if you forgot to run the light part and had full bright light.

  • Warning: MAX_FACE_POINTS exceeded: xx


    This error seems to be similar to MAX_POINTS_ON_WINDING.

  • Warning: models/mapobjects/texturename.tga has empty alpha channel


    WARNING: models/mapobjects/kmlamp_white.tga has empty alpha channel


    The first one is harmless. Just means it does not have an alpha channel, which it does not need to have. [djbob]

  • Warning: music file in path/filename.wav is not 22k stereo


    I set a "music"-key in the worldspawn entity. But instead of hearing anything I get this message in the console:

    WARNING: music file in music/background_loop.wav is not 22k stereo


    It seems like you either used a wrong sample rate or a mono file instead of stereo. Convert your file into a wav file with a sample rate of 22050, stereo sound and 16bit. You could use Audacity for this.

  • Warning: Node without a volume / node has x tiny portals/ node with an unbounded volume


    Usually a problem with small brushes of 1x1 or infinite brushes, it needs to be deleted. You also might want to try using bobs tools to delete it, by pressing "brush cleanup". Also by using the coordinates given in the error you can try to find the brush and delete it that way.


    An infinite brush. Delete it. The latest build of GtkRadiant has a debug tool that can help the mapper track down infinite brushes. Go to the BSP menu and select No_Vis (No light). After the compile process, a window will open up - assuming you've got bad brushes - and the first brush in the list will be selected and visible in the Z-Window. Merely press Backspace to delete this brush and repeat the No_Vis process. Or, you can use the Find Brush command (Misc menu) to find and then delete those bad brushes.


    This happens usually in vertex manipulation and the vertex flies out of the grid. A lot of times you won't notice this until you reload the map. So QBSP3 gets the error because it can't calculate something that's not on the grid. The solutions is to delete the brush and rebuild it.


    An infinite brush, usually caused by bad vertex or edge manipulation. Use Bob Toolz' brush cleanup to get rid of it.

  • Warning: R_FindImageFile could not find ''textures/xx/xx.tga''


    Either you have forgotten to put that texture into your *.pk3 or you have some old version of your texture on some brush.  Means that you have perhaps moved the textures but forogt to apply the new texture and its new path on the brush again. Just open up your texture manager ("t") and look for textures with the same image. If you recognize the old path (click on a texture and you see its path on the right bottom), look which sides of which brushes are covered in and replace them with the new texture (open the texture manager and select the texture, DON'T close the texture window but click once into the camera view and press Shift+A).

  • Warning: RE_Add Poly To Scene: Null Shader


    After doing a compile I tried to run the new map and half my textures were missing. In the console I was getting this message repeatedly:

    Warning RE_Add Poly To Scene: Null Shader

    Anyone know what I need to do to fix this? I did not do many changes since my last compile. Mostly added some clip textures to a few spots and made a few small new areas. [Pennywise]


    SOF2 may be using an older version of the compiling software. As a part of the Team Arena code, id redid the way that shaders are loaded. Broken shaders were treated as bad script code and broke the game and had to be fixed or removed if they were in the user's game folder.
    You may have a broken shader in some script in a pak file. You may have written a bad shader yourself that the SOF2 compile was overlooking. Heck, it may even be a bad shader inside SOF2.

    The method is to remove all extra content from your game folder and try to compile. If it works, then add in the files you most want back and try again. Repeat until the compile breaks. The most recently added file is your culprit. [Posted on MapCenter - answered by PJ]


    Usually an error with a shader which you need to find, it can prove difficult, you have to move custom pk3 files one by one into a temp folder and then see if you still get the error, when you dont get the error you will know what pk3 file to look in and look for the broken shader you have made.

  • Warning: Reused image <skybox image> with mixed glWrapClampMode parm


    WARNING: reused image skybox/texture/path.tga with mixed glWrapClampMode parm


    Appears in the game console whenever a map is compiled with -skyfix. You can safely ignore this error. [Obsidian]

  • Warning: shader [shader name] has lightmap but no lightmap stage


    One of your custom shaders has a lightmap but no lightmap stage. The surfparam nolightmap should rid you of the error message. Or, add a lightmap stage: (q3me)

    map $lightmap
    blendfunc filter
    rgbgen identity

  • Warning: Unknown q3map_alphaMod method: dotproduct2


    This error is a shader error in another PK3. Just get rid of the PK3 or fix the shader. (no surfaceparms in shader code)

  • 3. Misc Problems:

    ******* leaked *******


    A leak is just that, a hole in your map. Think of it as a submarine, if the hull around the submarine isn't completly sealed from the water outside (the void for maps) it would sink like a rock. It's the same for a map, if the map isn't completly sealed from the void, the bsp process wont generate a portal file (*.prt) which is needed by the vis process. (q3me)


    When the compile cancels and you see a red line in your camera view then you have a leak in your map. Fix it by putting a brush in that hole. If the compile cancels and you DON'T see a red line, but the compiler window said that your map is leaked, then go to File -> Pointfile and a red line should appear.



    Extremely high walls cause this problem for some reason. Apparently, there was a version of bspc that caused that problem but was fixed with an update (QER)
    You just have too many unique planes in the map that bspc cant cope, think the limit is something like 65536 (djbob)

  • AAS Shutdown


    1. After compiling and paking, I will go to select the map in-game, but get booted to desktop with a console error:

      • Code:

      • ----- Server Shutdown -----

      • ==== ShutdownGame ====

      • AAS shutdown.

      • ---------------------------

      • Requested feature was omitted at compile time

      I am not sure what request they mean, as I did a full vis and light extra?

    2. Also, the q3map.exe always has to close during the -vis due to an error. Then it goes on with the -light. This happened with a previous map I made, and I had no problems with it from its .pk3.

    3. What is the significance of the .prt file to the .bsp? Does this need to be done before vis/light? (Is it included?) As I have noticed, it is not there after doing the vis/light. I am using GTKradiant v1.1 under XP. [psion]


    1. This problem occurs if you are using a .jpg saved with progressive encoding as your levelshot. Use standard encoding instead. [Anwulf]

    2. Found the nightly build (of GTKradiant) is doing the trick. Was not aware it was a vis crash bug. [psion]

    3. The .prt file contains the portal information which you would use in conjunction with the Portal Viewer plugin. Unless you add a compile option to your projects file with the -saveprt switch, the .prt file is automatically deleted. [Anwulf]

  • Bad Index in Triangle Surface


    This error is related to terrain. The most likely cause is because of improperly removing triangles or parts of triangles using CSG subtract.

  • Bots just standing around in the map


    My bots just stand there in my map and don't move or do anything untill I walk into them.


    Download q3map2toolz and run bspc with that. make sure you check the -forcesidesvisible box. Using -forcesidesvisible will solve your problem, however, it will also increase the size of your aas file and take longer to compile.


    Since q3map 2.5.16, aas file can be reattached to different bsp.
    Below is a step by step procedure to make it work.

    1. create an original map file (let's call it "") and fully bake it (bsp,vis and light)
    2. copy the "", open it in radiant then remove unnecessary geometry (especially patches), adding spoofing brushes and uncheck autoclipping for mapobjects (or delete models completely), etc... then save as ""
    3. bake "" (only bsp, no need to append "-meta")
    4. create bot file ("original_b1.aas") for "original_b1.bsp" with the switch "-bsp2aas", no need to append "-forcesidesvisible" *warning* DO NOT OPTIMIZE HERE!
    5. rename "original_b1.aas" to "original.aas"
    6. run q3map2 with the switch -fixaas "PATH_TO_original.bsp" (now "original.aas" has been fixed and broken again)
    7. download aasfix2 (by a13n) then fix the aas again.
    8. now run bspc again for "original.bsp" with the switch "-reach"
    9. finally optimize the aas with the switch "-aasopt"
    10. play with heavily optimized bots

    What I've noticed so far(might be wrong):

    1. Botclip doesn't necessarily have to be aligned to the geometry for human players; it can go both below and above as long as they won't exceed excessively.
    2. Map runs faster with this fixed aas!
    3. Some entities need to be "suspended" (also item_botroams) depending on the place where they are laid.

    Note: Utilise this method if you use a complex modeled terrain or any other complex structures the players should walk on (delete the model after clipping).

    Note: You'll have to go through these steps everytime you try out a new version of your map.

  • Can't find map maps/mapname.bsp


    This could be one of a few things. Your map could have a leak which caused the .bsp to never be created during the compile, for some other reason the map isn't in the maps folder, or you didn't start your map by typing /sv_pure 0 and /devmap mapname in the console.

  • Can't find spawn point


    Your map most likely doesn't have an info_player_start or _deathmatch.

  • cg_ParseSpawnVars:EOF without closing brace


    This is talking about your script and is fairly descriptive. It means that you left out a closing brace "}" in your map's script. Make sure that each "{" has a "}" to close it.

  • CL_parseGamestate: bad command byte


    You get this error message when you try to start a certain map. This error occurs when a map has too many non-light entities. If you want to get rid of this problem, remove some (or a lot of) entities.
    If you're not the mapper and you face this error message you have three coices:

    Set the server to unpure by entering into the console "sv_pure 0" and try again.

    Remove most(or all) of your 3rd party maps(.pk3 files) from your Urban Terror folder except for the map you want to start.

    Go home and cry...

  • CM_Inlinemodel: Bad Number


    I have researched this a little bit, and found the primary causes are:

    1. Having more than 256 brush entities in the map
    2. Having an origin brush that is not associated with any brush model entity

    Brush Model Entity: This is any set of brushes that has been turned into an entity complex in a level. Examples of this are Func_statics being used as elevators/platforms, Func_rotations, Func_breakables, Func_walls etc etc etc. These entity complexes have to have an origin brush associated with them.


    1. If you are one of the many people experiencing this error here is a brief explanation from the guys at RAVEN itself. (also applies to Q3A)

      "The unspecified error is a try/catch block to handle crashes! In JK2MP the brushmodel limit is half of what it is in SP (256 in MP (already had problems with 255) and 512 in SP, I think)."

      Brush Models especially include things like func_brushes - in particular func_doors, func_buttons, even func_groups (moving them into worldspawn again deletes the brush entity entry). Triggers count as brush models, too. eg. I removed 6 doors each made from 6 brushes (For a total of 36 Brush Models) and I no longer get the error.

      There's also a global entity limit with an amount of 1024 (including ALL entities this time).

    2. Open up the textures browser in Radiant, select the origin texture, click once into a grid view to activate the other window again and press Shift + A. Now every brush covered with this texture should be selected. Go through each brush and look if it's connected to a brush model entity. Otherwise delete it, since it has no visible function anyway.


    From what i can ascertain, the error is caused by func_ brushes being flagged as "detail" as opposed to "structural". the detail and structural flagging can be changed by selecting the item, then going to the "selection" menu and selecting either the "make detail" or "make structural" options.

    This includes func_group brushes! i didn't think so at first, but apprarently it does...if a group needs to be set as detail, go to selection - ungroup entity, then flag it as detail.

    The solution: if you get this error for some reason, select the entire level, go the selection, then "make structural". it'll take longer to compile and your framerate will drop, but it'll work. when you've succefully compiled and run your level, go back and set some of the stuff to detail, but pay close attention that you don't flag any func_ brushes as detail.


    Press "i" to select the whole level (don't forget to deactivate all filters) and copy and paste it into a new mapfile. Afterwards you will have to re-enter every worldspawn entry from the old mapfile again.


  • Compile Time too short to follow Console Output


    Compiling my maps from GTKradiant works at times. But sometimes it just closes when I try to compile it with anything other than "BSP". It starts to do something but then closes. I have this problem when compiling any map. I have even tried deinstalling GTKradiant and then installing it again. What is going on? [sk8rocksam]


    I would suggest you take a look at the GTKradiant console (entity window "n" -> console)... sometimes the compile times are so short one can hardly follow the infos in the dosbox windows, the console will track the compile, so you can read up on the possible warnings/errors there.

  • Couldn't find image for shader noshader


    You might see this pop up now and again, it usually means a slight error in a shader, but it can usually be ignored with no problems

  • Couldn't find image for shader textures/xxx/terrain_0


    This error occurs during the compile if you have terrain. It can be disregarded.

  • DEFAULT_MODEL (xx) failed to register


    This error occurs when the lightmaps in your map are just too complex and/or large for the EF engine to handle. To fix it, you just have to lower the resolution of the lightmaps in your map. To do that, go to your worldspawn entity and add in key: "_lightmapscale" value: "2". The shadows won't look as sharp, but at least the map will run. If you still get this error, increase the value to 4 and it should fix it.

  • Entity x: func_areaportal does not touch 2 areas


    This seems to occur when you put an areaportal in but leave some other route between the two areas you want to split. It is analogous to a leak, and in fact could be described as an "internal leak". The "error" is non-fatal, it just means that the areaportal won't be used.

  • Entity x, Brush x: mixed CONTENTS_DETAIL and CONTENTS_STRUCTURAL


    I get


    when compiling my map. Though it tells me the entity and brush number, I cannot get rid of this message, because deleting the brush does not seem to affect this message, it just mentions another brush which "has" mixed contents.

    I selected my whole level and made it Detail, than I built a big Brush -> CSG Make Hallow -> func_group -> Make Structural. That is the way everybody does it, maybe my map file is messed up? And selecting the whole level again -> Make Detail makes no difference. [libertyforrest]


    Someone here got it once by turning hint brushes into detail.


    That is exactly what happened. I did not filter the hint brushes when selecting and turning them into detail by accident. Now I have a clean compile. [libertyforrest]


    This means you have a hint brush or area portal set as detail.

  • Entity x, Brush x: mixed face contents


    This just means that one of your brushes has different textures on two or more sides. You can usually ignore it.

  • Entity x, Brush x: origin brushes not allowed in world


    This error is caused by having an origin brush in your map without having it tied to an entity such as a func_rotating or func_rotating_door.

    (-> also see SV_SetBrushModel: NULL)

  • Fatal: empty .aas link Heap


    You have a very complex structure in your map and it's causing problems for the bots. (QER)

  • FloatPlane:bad normal


    A Not to common error, this seems to occur after some vertex manipulation gone wrong, check your vertexed shapes for irregulars and you can try deleting vertexed shapes that disappear when you try vertexing them. Im not 100% sure but you could also try using bobs tools in the plugins, and select brush cleanup which should delete bad brushes for you.


    Caused by faulty vertex manipulation. You'll know it when you're trying to move a vertex and the brush suddenly "disappears." Hit undo if this happens. Delete the brush from the map if you've already run into the error during the compile process. This can also be caused by several other situations. Back up your map and run bobtoolz brush cleanup on it.
    Happens with vertex editing when the geometry is invalid, for example when you alter the number of faces (ie: take a block [6 sides], take two vertices from the top and bring them over the lower 2 vertices to transform the block brush in a wedge [5 sides]. The face isn't a plane anymore (now an edge) so the normal can't be calculated)

  • Full Bright Map (OverBright)


    Every level I build in Q3Radiant - after compiling it - is
    blindingly bright (OverBright)
    and I cannot seem to fix this. I do not remember what option I changed, but I have reinstalled Radiant 3 times and even though I put no lights in my level the world is full bright. Only my gun is dark - the way it should be. [anon.]


    There is a known bug that happens when your map is very small. Making it bigger will definitely help. You can also load your map in debug mode (on console type /devmap mapname), then when your map loads, type /give all. Then switch to the BFG and magically the lighting pops in. [anon.]

  • G_AddSpawnVarToken: MAX_SPAWN_VARS


    I've experienced a error after playing around with EasyGen;

    G_AddSpawnVarToken: MAX_SPAWN_VARS

    I guess I messed up somehow. It wasn't in the list, anyone know what's wrong?


    This is related to entity keys within a single entity. Either there are too many of them or there are more characters used in the entity's keys than are allowed. There's also the possibility that a key/value pair in the entity isn't being parsed correctly. You might have a " in a key for a path or something, and they aren't allowed in keys. That's what I'd look for in the most recent entities you've added.

    Oh, the max keys in a single entity is 64, and the max characters allowed for all keys in a single entity is 4096.

  • G_Script_ScriptParse(),Error (linexxx): unknown event: eventname


    Usually this is causes by a typo or by missing an opening/closing bracket - { or } in your script. Search through your script section by section and verify that each event is closed properly. Make sure your game manager is closed and illegal events aren't inside it.

  • G_Scripting : Trigger has unknown name: game_manager


    This can be caused by not having a script_multiplayer entity in your map. Most likely this can happen if you forget to add a game_manager section to your script as well.

  • Got to split the buffer


    This is memory related. Chances are your map is far too complex or there are brushes in your map that have issues. Try running Bobtoolz brush cleanup on your map. Also check your VIS data size. If it's high try utilizing detail brushes.

  • How to compile with -patchshadows on?


    Where and how do I execute / add this option? [BNA]


    Assuming you do not want to go for a full out "let us go into DOS and compile the thing", then I suggest you either create a new BSP menu option, or modify the existing ones. This can be done using the Project Settings on the File menu. However, if I remember correctly, there is a line limit in the edit box, which truncates even the default ones, so you might have to open the project file up in notepad or something similar, and just add a new line there. If you study some of the existing ones, you are sure to understand the format. [djbob]

    Note: I had to add the -patchshadows option manually in Q3Radiant because of that line limit, but in GTKradiant v1.1.1 using the built in editor seems to work just fine. [pjw]

  • How to reduce long compile times?


    I do not get an error exactly, vis gets to the 4... in the last count, then it stops, I checked the Task Manager and the process shows the "System idle process" at %99 and q3map at 0%.

    I thought maybe this was normal so I let q3map keep running, for 2 days, 40 hours to be exact, during that time the process stayed at 0 and the memory usage did not fluctuate although the Task Manager reported it as running.

    -fast vis works, it is only when I try full vis that it does not. The only errors I get are about 50 duplicate planes, (which the manual says is only a problem for .aas, yes I know amazing, someone who actually checks the manual first). Anyone have any ideas? [Mortal]


    Scratch that, got it worked out, let this be a lesson to other beginners: Use detail brushes!

    Note: I will try to sum it up in a few sentences if I can Mortal.... Select all the brushes in your map that do not touch the void and are not part of walls, ceilings and floors (these brushes usually touch the void). When you have everything selected, hit Ctrl + M (Make Detail). Once a brush has been converted to detail, it will not be considered during the vis compile stage.

    Right now, it seems that every brush in your map is considered during the vis stage... which has a maximum visdatasize of 2 MB. Convert everything I mentioned to detail and your map will compile the vis stage in a few seconds. [GONNAKILLYA!]

  • idtech3 Shader overflow bug (e.g.: RtCW SP)


    If you've done any single player level design for Return to Castle Wolfenstein you may have come across this bug where the textures appear to get messed up in game. It's usually the associated with weapons flashes and explosions, or are the most noticeable offenders. The reason for this bug is a "shader overflow"; but it's commonly called the "weapons flash bug"


    RtCW weapons flash shader overflow bug

    • Basically this happens when you've got a map that's generating too many lightmap/shader combinations and has gone over the limit.

    • Design note: it's to do with how many unique lightmaps the brushwork creates not how much lightmap data is being generated as part of the overall KB/MB file size of the BSP. Each time you chop a brush up the textured surfaces create an associated lightmap, the more faces you have the more unique lightmaps that get created.
      Next time you run a compile take a look at the last few lines in the BSP monitor during the LIGHT stage of the process (or file dump if you do them from BAT files) and note the number that's listed next to 'shaders / lightmap combos' (or words to that effect - I've not done a BSP for a while so can't recall off the top of my head what is says exactly), if that number is greater than 390 then you're stuffed.

    • To fix the problem you have to go back through the map and be mercenary about what *needs* to be there and what doesn't, you've essentially got to limit or reduce the number of shaders you've used

    • It's also worth pointing out here that the bug isn't necessarily related to the number of surfaces you have but more the number of different shaders you've used and the resulting lightmap data that then generates (although it's been a while, I think that's correct).


    RtCW shader overflow quick fix

    • As a quick fix use this switch in the LIGHT stage -nocollapse. If you still get the error after than then I'm afraid to say you have a lot of optimizing to do and there isn't a short cut to fixing this issue either.

    • Some things that might work to fix the problem;

    • Create new single textures by combining two or more together; like a step texture and a floor trim used on the edge of the step - instead of using two separate textures (and hence shaders) you could combine them into a single image for use in game.

    • Complex geometry should be converted to ASE models which is then player or weapon clipped - as they already have heavily optimised lightmaps..

    • Any non-axial brushwork (like cracks, rocks, broken walls etc..) should be converted to ASE models and clipped appropriately as above.

    • Try caulking every hidden face, esp. on detail flagged brushwork as they're not always culled by the compiler.

    • Try converting patch mesh objects into either ASE models or brushwork - the crypt vaulting in my last SP was brushwork and not patch meshes.

    • Try not to break brushes into too small or unnecessary sizes.

    • By the way, depending on what version of GTK you have you're more than likely to already be using q3map2


    Some additional shader overflow fix information

    • There are ways to fix the problem depending on how bad the weapons_flash bug is - you may noticed that cutting back and simplifying brushwork will result in the weapons_flash bug decreasing in severity, the flamethrower for example would gradually become partly functional, then a bit more until it was a complete flame.

    • Some known things to try to 'fix' the bug (may be repeats of above info);

      • Reduce the number of faces in the map, if you've got tonnes of 3pt clipped or vertex manipulated brushwork remove as much of it as possible and leave only the bare minimum for the effect.

      • Try func_group brushes that have more than one face in 'coincidence'.

      • Try 'merging' as many brushes together as possible.

      • Allied to func_grouping above... 'convert' any big 'terrain' sections into just that, a terrain mesh by adding the following key/value settings into the entities world spawn;

        • - key = "terrain", value = "1"
        • - key = "layers", value="1"
        • - key = "shader", value = "textures/yourfolder/yourtexture"
        • [note: you don't need to add an actual file extension here .tga]
        • - key = "alphamap", value = "maps/yourfile.pcx"
        • [note: this is basically a white texture that's been saved as a paletted image (256 colour palette), I've also not had any problems with placing it in various locations so long as the worldspawn path is correct.
      • use q3map2 with the -nocollapse.
        What this does is force q3map2 to create unique lightmaps for everything instead of 're-using' similar lightmaps on other objects.

      • q3map2 with -meta or -patchmeta.
        Results for me with this were unreliable, it does 'odd' things to the lightmaps and created some heavy shadows where it should have done...!

      • gridsize xxx xxx xxx does work but it really makes the lighting go noticably grainey. The default setting are similar to the following:

        • - key = ">_gridsize", value = "128 128 256"
      • Changing the 'value' reference to "256 256 256" or above will increase the size of the lightmaps (by decreasing their resolution - same sized images are stretched over a larger area) and should reduce the number of unique lightmaps that are generated.

  • No data chunk in filename.wav


    The quake 3 wav loader seems to be a bit limited in the data it can handle. Instead of searching through chunks based on the lengths in the file, it just looks at every 4 bytes in turn looking for the chunk headers. This doesnt work if a chunk before the DATA chunk is not a multiple of 4 bytes long - for example the fmt chunk on newer WAV files. When loading music it seems even more restricted, in that it appears to assume the DATA chunk will immediately follow the fmt chunk.
    This causes quake3 to report "No data chunk in <filename>" on the console when it tries to load the wav file.


    FixWAV (by AnthonyJ) is a small program which changes 26 byte fmt chunks to 24, thus fixing this problem. I've only tested it with wav files created by the version of Sound Recorder bundled with WindowsXP, but I understand other programs also generate similar files. As of version 1.1 It also strips FACT chunks which appear to cause a similar message when you are using the /music command.

  • Passage Portal Flow (xxxxx)


    You've got some complex brushes that are creating tons of portals. eg) spikes at the bottom of a pit. Make them detail so that vis ignores them during the compile.

  • RE_LoadWorldMap: maps/testctf1.bsp not found (error can also be: Couldn't find bsp)


    testctf1 is my test map, that yields:

    RE_LoadWorldMap: maps/testctf1.bsp not found

    Anyone got a clue on this one? I followed a Q3Radiant manual and did exactly as it said (even in the sample map) and it did not load in Quake 3. [MEtAL]


    You tried sv_pure 0?

    Did you put the .map file into a .pk3?
    If not, try that as I seem to remember someone saying .pk3 files have preference over folders/files in baseq3\ (the game will look at .pk3 files 1st). Also make sure you have an info_player_start entity in your map. [Kat]


    Always type /sv_pure 0 before loading your map up, it turns off pure server. Also could mean you have a leak, so check for leaks!


    Usually means you didnt put in /sv_pure 0 before you loaded your map, you must use /sv_pure 0 for mp maps otherwise it wont load. Can also occur very rarely when your map is there, yet it doesnt seem to see, try renaming it and it normally works.


    Quake3 defaults to PURE SERVER mode, and will not let the client game see anything not in a .pk3 file that has been CRC checked against the server's copy of the same .pk3 file. When you load a map with \map or \devmap in Q3, you are running both the client and the server. If you're running in PURE mode, and the map you're trying to load does not exist in a .pk3 file in your baseq3 folder, the game will think it is not there at all. (Courtesy SmallPileofGibs) (QER)

  • SetQdirFromPath: no 'quake' in G:/Q3A/baseq3/maps/


    The word "quake" is not in the path. Change the dir name from "Q3A" to "quake". (QER)


    This happens when you install Q3A to a non-default location. Open up "baseq3/scripts/quake.qe4 in notepad and change all "startr~1~quot; to "quake"

  • Shader_max_vertexes hit in FillCloudySkySide()


    Shader_max_vertexes hit in FillCloudy Sky Side


    Basically, the error says what it means, your sky shader is asking the engine to render much more in the way of cloud domes than it allows for. Usually caused by either sky shaders with two or more cloud stages and a really massive area visible in game, or sky shaders with three or more stages.

    In general, be wary of using more than two cloud stages in your sky shaders. Using sky portals may now be a good alternative if you feel a standard sky is not interesting enough. [Shallow[BAP]]


    A sky shader can't have more than 2 layers in the shader script.

  • Shader not found/shader image missing


    This is where you might not have loaded any textures and you will see that blue and black image. Also if you have added some custom textures, make sure there in the textures folder, and that you have entered the shader into the shaderlist.txt. Say if the texture folder you have created is called "town" then you need to add "town" to the shaderlist.txt on a new line. Sometimes common textures may suddenly disappear, this can be often solved by reinstalling the editor. No one seems to know why this happens, but its rare and can be solved usually by reinstalling radiant. On occasion you might have made a texture and in the shader not put in "qer_editorimage textures/mymap/texturename.jpg " if you dont have that line then the editor wont display the texture image. Also shader image missing is often a harmless message appearing in the console or compile.

  • Shaders not working and Missing Textures In-game?


    What to do when textures are missing in the game?


    You should always test your maps or at least a pk3 with the beta status in a plain new install of Q3A, so you will definitely not use any shaders or textures from other custom pk3s (including mapmedia.pk3). When you've loaded your map open up the console. If you have missing textures or shaders (also corrupted ones) it will be shown, in yellow letters or behind big WARNINGS:, in the last lines. Afterwards create a new pk3 with the missing files and try it again (or do a recompile with fixed shaders if they were broken).


    I added some shaders to the Q3Threewave assets pak, there are some jumppads in there with red and blue glowing circles, but the ones I need for my map are not in there. I copied the shader, placed it in my own shader file and changed the source texture. After adding the new shaders to some faces in my map and compiling it, they do not show up in-game. Instead I see the default black and white tile texture. Checked the shader again and tried again. Did not help alas.

    Because I am making this map ready for beta testing, I put the buggy .bsp into a .pk3 with the textures and shaders. Now it works!

    So, if you make shaders of your own and they do not work in game:
    Check the shader again.
    Pack the bsp, textures and shaders into a .pk3 file.
    Check if the shaders work in game now.

    Comment: I have the feeling this is a priority problem, e.g. the same shader name in scripts\ superseding the one mentioned above, and that once in a .pk3 file the "right" shader is actually read first. [AEon]

  • sp_worldspawn: the first entity isn't 'worldspawn'


    I was just remaking a map I have done for another game, I put in a jumppad and a deathmatch start point, when I try to start it in Quake3 I get:

    sp_worldspawn: the first entity is not 'worldspawn'

    What is going on? It worked fine up until added the jumppad and the spawn point to the map.

    [Edit] I was using Q3radiant instead of GTKradiant, the error might not happen now. [measter]


    The 'worldspawn' entry at the top of your .map file is missing. Open up an older version of the map in a text editor and copy the 1st line (or copy what you see in that one that is not present in the latest .map file), paste it into place at the top of the newer file and save.
    If you can open the map in Radiant select a brush object and right-click, select Move into Worldspawn and then save the map. Hopefully that should have created the worldspawn key that is needed for the map to work.

    Make sure to make a backup before you do this so you can go back if it totally borks up as has been known to happen.


    Works fine now that I got GTKradiant, though I did have to start the map again. [measter]
    Before you re-do all that work try these 1st: Look for the autosave backup files, you will have 2, one is actually called and the other your_last_maps_name.bak.

    The autosave you load into Radiant like any other map. The .bak file needs to be 'loaded' into Radiant (File menu, Load) or you can change the file extension to .map and it will load up.

    Make sure you save your map from time to time. If you are not doing this already, each time you do significant changes save to a new file! [Kat]

  • SubDivideError: can't split the polygons


    This seems to be related to stretching, and or resizing textures on really thin brushes. I got the errors on brushes 4x$ and 8x$. When I removed all resizes and stretching, the error disapeared. (Ultrahigh)
    This error appears when there is one or more vertexes which are not snapped to the grid, OR 2 vertexes in exactly the same place. This error is common to get when you use vertex manipulation, or when you create a cylinder and then rotate it, so see to it that all the vertexes are aligned to the grid after rotation. (Ultrahigh)

  • SV_SetBrushModel: NULL


    There are several possible causes for the SV_SetBrushModel: NULL error, if in trying to fix it with one method you find the solution doesn't work then that means the error is being caused by one of the other alternatives.

    Corrupted brush in the map:

    • During the course of manipulating brushwork these 'broken' brushes happen occasionally. They're often 'phantom' brushes, brush objects that you can't see in the editor but appear in game when once a map has been compiled.


    To fix this first try the 'brush cleanup tool' from the main menu (it's location may vary depending on which version of GTKRadiant you're using. If that doesn't work make sure you've not got any objects hidden and make sure the show/hide options in 'View > Filter' are set to display everything.

    • Draw a brush in the editor and resize it so that it covers the whole map. Leave it selected.
    • Right click and from the pop up menu choose 'Select > Select Inside'. This will select everything in the map (that was contained inside the brush).
    • Go to 'File > Save Selected' and save the selected brushwork to a completely new and clean file.

    If the error was caused by a phantom brush doing this should remove it from the map.


    Bad func_group

    • A collection of brushes that have been 'connected' together using the editors func_group 'entity' has got corrupted somehow, usually by the presence of a bad brush in the group, or in some cases by the accidental deletion of a brush from a group (it's usually best to ungroup, delete and then regroup).


    The only way to fix a bad func_group is to ungroup the entity and clean the brushwork up (using brushcleanup) before regrouping the objects back together.


    Incomplete or partial brush entity

    • This is the most likely cause of the error and it happens when trying to make brush based entities that involve the 'origin' shader. The origin brush is 'entity specific' which means it can't exist in the world on it's own like other brushes, it always has to be grouped with other brushwork to form an entity; func_door, func_mover, func_rotate, func_script_mover and so on, all of these are brush based entities that are comprised of normal brushes and an 'origin' brush. If an origin brush is left in the world ungrouped with other brushes the 'Null' error results.


    You need to track down the offending orphaned origin brush. Once found either delete it, or regroup it with whatever brushwork it was supposed to have been grouped with. You may need to ungroup the entity, select the origin brush and then regroup.


    Improperly placed 'entity' texture

    • Related to an orphaned origin brush is the accidental improper use of entity specific textures/shaders. This happens when an entity shader is 'mixed' with other normal textures on an object. More often than not, it's the 'origin' texture/shader that's been misplaced on one or more faces of a door or similar brush based entity (see above). Entity textures/shaders can't be mixed in this way (unless it with specific instances of 'nodraw'), they have to be placed on all faces of a brush.


    Again as with an orphaned origin brush, the offending texture will need to be tracked down and corrected. Look at all the brush based entities in the map to see if any faces are covered in origin (or areaportal, clusterportal and so on)

    Design note: If you're working on a big map that has a lot of real-estate being used, tracking a single faces on any given brush can be very time consuming so here's little 'trick'. Simply draw out a block and then texture the whole thing in 'origin' (or whatever texture you think may be causing the problem). Once done, select a face and then press 'Shift+A'; this selects all brush objects that have the initially selected texture applied to it allowing you quick and easily visible reference points as to the location of likely offending brushwork.


    Caused by a brush entity such as a func_door or func_plat with no solid brushes, or a func_rotating with no origin brush. If you have added anything like that recently, check it, and add a solid brush if necessary. If you cannot find anything, look through the entity list and see if you can find an entity that should have brushes but has somehow lost them. Note that adding something like a clip brush is enough to make the entity qualify as having solid brushes, if you are using a model as a func_ entity. [Shallow]

    This problem is easily solved using Brush Cleanup from Plugins menu, bobToolz . [Fjoggs]


    This is an error which related to one of the entities in your map, say you have placed an areaportal texture on a door entity, thats going to give this error. You should look through your entities and see if you can see anything dodgy. Look for mainly irregular textures on entities, like the areaportals on doors, origin textures on triggers etc, remove textures that shouldn't be on certain entities. Debatably can also be where you have entities that are only 1 smallest unit thick. This error has been debated to whether it does really cause this error, still if the other solution doesnt work try this.


    You may get this error when you have a brush model entity which does not have any valid brushes, i.e. a func_rotating with nothing but a common/origin brush. This could also be caused by a func_areaportal with a common/areaportal brush.


    The map has some brush ents which are only one unit thick (paper thin). I'm not sure what the minimum thickness is supposed to be, but it apparently needs to be thicker than one unit. You may also get this error when you have a brush model entity which does not have any valid brushes, i.e. a func_rotating with nothing but a common/origin brush. This could also be caused by a func_areaportal with a common/areaportal brush.

  • Team_wolf_checkpoint does not have a scriptname


    Check your team_wolf_checkpoint entity to make sure it has a scriptname value. If you're just testing and haven't written a script yet simply put the word void in for the value.

  • Textures/dirpath/texturename had odd vertex count autosprite2 shader


    You're implementing a shader script that uses vertex deformations that are greater than the size of the brush you're using it on.

  • Texture not found for shader: path/texturename


    Your shader is pointing towards a texture that doesn't exist or is in a different location.

  • The procedure entry point g_dir_open_utf8 could not be located in the dynamic link library libglib-2.0-0.dll


    I got an issue, when i go to compile it. it says

    "The procedure entry point g_dir_open_utf8 could not be located in the dynamic link library libglib-2.0-0.dll"


    Go to gtkradiant 1.4 root directory and notice the file q3map2.exe, there's another one named i think q3map2.exe.bak, just switch names between these two files (name q3map2.exe -> q3map2.exe.bak and q3map2.exe.bak -> q3map2.exe). This shall do the trick.

  • UnmatchedToken "({)"; MatchToken( "{" ) failed at line xx


    I have a weird error. It started when I did something simple - retexturing two faces to caulk. Well, after I finished retexturing the second face, Radiant crashed (I have GTKradiant v1.1.1, and I do not remember the error message. I get them all the time).

    Well, I thought, "Oh well, no big deal. All I did was change two textures, I will just reload and redo it." Then I go to reload, and I get an error message about an

    UnmatchedToken "({)"

    (or something) and Radiant crashes again. I load it up a second time, same error, but about a different line. I open up the .map file in a text editor and find weird characters (e.g. é µÃ„`æ ¶), so, being that I had this stuff before, I deleted the brushes. [Pathogen]


    An unmatched token message means that there is a "{" that lacks a matching "}" (or vice versa). The most frequent cause seems to be something going wrong at the very start of the .map file where the worldspawn info is. Open that .map file in a text editor, find an uncorrupted .map file, and copy over the missing info. You might also be able to use the map's .bak file to the same end provided there is nothing wrong with it. [Anwulf]

    e.g.: Say it gives MatchToken {"{"} failed at line 55, then you need to open up your map file or shader in notepad (check your map file first) look down for line 55 and see where you can add in the bracket.


    You have an error in a custom shader. Most likely you forgot to close out a final shader stage or you have two brackets instead of one. Where xxx = the offending line in your shader.

  • 4. Credits:

    - thanks to AEon who posted the first FAQ in the level editing forum on
    - thanks to asw from who made the first error list I've found and worked with the last few years
    - thanks AnthonyJ for this nice tool he wrote for wav files
    - thumbs up for a13n's aasfix2.exe and the nice description he wrote, which I copied into the bots section
    - thanks to morbus for the MAX_SHADER_INFO error - greetings to Pan whom I did this list for, to add it to his maps and tutorials archive (

  • 5. History:


    1. - edited one link
    2. - added some lines in the Shaders not working and Missing Textures In-game? section
    3. - added two new messages to the list:
      1. Error: MAX_SHADER_INFO Exceeded (thanks to morbus)
      2. CM_Inlinemodel: Bad Number


    1. - extended the Bots just standing around in the map section


    1. - added 4 new messages:
      1. Error: target_speaker without a noise key at (xxx xxx xx)
      2. Warning: could not find path/filename.wav - using default
      3. Warning: music file in path/filename.wav is not 22k stereo
      4. No data chunk in filename.wav
    2. - changed the alphabetical order of the errors (ikernel)
    3. - deleted some breaks
    4. - fixed link


    1. - converted all tab stops into normal spaces (so the list should work now on
    2. - added a link in the Entity x, Brush x: origin brushes not allowed in world section


    1. - deleted approx. 200 wrong converted headlines which also caused formatting bugs on Pan's site


    1. - errors and its fixes collected from several lists and checked them against each other
    2. - sorted and formatted them
    3. - added pictures
  • 6. Sources: (Quake3world -errorlist) (Quake3world -fixaas) (Quake3world -inlinemodel) (Katsbits) (Jedi Knight Forum) (Urban Terror) ( (FixWAV by AnthonyJ) (Map-Craft -Jedi Knight section) (Massassi Temple -Jedi Knight section)

  • 7. Copyright:

    This document was created by me (Bliccer) also including text written by AEon, Kat, ydnar and other authors (standing in brackets). You can view the original posts by clicking on the links above.
    The logo was made by myself using GtkRadiant and Adobe Photoshop.
    The map in the picture is called amt-snowflakes and was designed by me.

  • @ 2010 Bliccer