All Activity

This stream auto-updates     

  1. Earlier
  2. general MAX_MAP limits from the old SDK MAX_MAP_HULLS MAX_MAP_MODELS MAX_MAP_BRUSHES MAX_MAP_ENTITIES MAX_ENGINE_ENTITIES MAX_MAP_ENTSTRING MAX_MAP_PLANES MAX_MAP_NODES MAX_MAP_CLIPNODES MAX_MAP_LEAFS MAX_MAP_VERTS MAX_MAP_FACES 4 400 4096/ 8192+ 1024/ 2048 1024 (128*1024) 32767 32767 32767 8192 65535 65535 MAX_MAP_MARKSURFACES MAX_MAP_TEXINFO MAX_MAP_EDGES MAX_MAP_SURFEDGES MAX_MAP_TEXTURES MAX_MAP_MIPTEX MAX_MAP_LIGHTING MAX_MAP_VISIBILITY MAX_MAP_PORTALS MAX_KEY MAX_VALUE 65535 8192 256000 512000 512 varies, see link 0x200000 0x200000 65536 32 1024 Zoner's, Merle's & Cagey's Compiling tools may have some higher limits, such as 8192+ MAX_MAP_BRUSHES or 2048 for MAX_MAP_ENTITIES. Furthermore, some Mods have lower limits. Find the Mod's coder and ask if you think so. see also: Entity Limitation notes: errors & solutions assembled by 0rsp from many sources Hammer Editor problems The new Hammer editor/WC 3.4 is a bit buggy and glitchy. It especially seems to have problems with Geoforce Video cards, WinXP, and Voodoo Video cards. Possible solutions: Right now, there are three known solutions that may or may not work for you: Using SGI's OpenGL driver (438,888 bytes) instead of your video card's native OpenGL drivers. Extract the file named opengl32.dll to your WorldCraft/Hammer directory. Upgrading your video drivers to the latest version. Check out: nVidia's driver page. Downgrading your video drivers to a prior version, the most recent driver may not be as stable as older versions. There may also be problems converting your old WC 3.3 maps to Hammer/WC3.4, the best solution for this is to open your old level in WC 3.3, copy EVERYTHING, then open Hammer, start a new map and paste it all in. There have also been problems with longer map names in Hammer, especially with compiling. Like WC, you should compile outside of Hammer with a batch file or front end. And there are more minor problems. If you have problems with Hammer forgetting your settings so you have to set it up every time, this happens to some CPUs. The version of Windoz you are using may be causing it (esp. WIN ME), or something else. The fixes I have heard of are: Using an older version or different of Windoz. Try to always use a User Profile. Make changes to the .wad files installed, then save. Change the save maps folder to a sub folder deeper down. try to configure [Worldcraft] and then create and save any map, even a single wall will do, you can exit the program and load again and your configuration files will load. If they don't however you can do the process again and it normally works the second time - sometimes. Open the My Computer folder and press F3 to open the search window. Search for files named *.wc. If you find them outside of your Worldcraft/Hammer folder, move them into your Worldcraft/Hammer folder. (Do this while Worldcraft/Hammer is not running) Things should work properly after doing this.....maybe. installing Worldcraft/Hammer into a path with no spaces (ie: C:\Worldcraft) Moving everything to the default setup in c:/prog**/valve h*** which has spaces...conflicts with the one above. In one case where WC/hammer would not reinstall right, it was found you had to hand remove from the registry HKEY_CURRENT_USER\Software\Valve\Hammer before reinstalling. good luck. Textures overlap in WC/Hammer editor 3D veiw If you have this problem in WC/Hammer, the only known solutions are to change your display size or to reduce your .wad files in WC to 1 or 2. (the problem seems to start with 3 wads or more.) Malformed face normal Description: The texture alignment of a visible face is unusable Howto Fix: If using Worldcraft, do a check for map problems and fix any occurences of 'Texture axis perpindicular to face'. Coordinates are usually given, use them if map problems cannot find the problem brush. SubdivideFace: didn't split the 4-sided polygon @(coordinates) In the only case I know of this, it was the walls surrounding a level map. I have no idea of the cause yet of this BSP error. host_error backward mins/maxs "It means that the mins and maxs ( the bounding box ) for the sequence is "reversed" (one of the mins is bigger than the maxs). This happens when anything calls SET_SIZE with bad extents. If you compiling your own code, you can wrap the setsize() calls and check it yourself, but that's probably not a simple answer." Translation: Do you have any special models or prefabs? they may have been screwed up, or you somehow turned a brush inside out, no idea how that could have happened - but some entitys like platforms seem prone to this. You can also look for a brush with bad extents, or check the texture, is it divisible by 16 on the edges EXACTLY? Finally, are you using the most modern version of zoners tools? Old versions or ancient qtools are more prone to this error. "tiny penetration in Hull 4" In the cases I know of this, it was caused by using the -verbose switch to try to find an error while compiling. The warning was ignored without any problems then. I hope you too can ignore it without further problems. I have no idea of the cause yet of this BSP error. sv_recursivehall(hull?)check:bad node number Bad brush work, overlapping brushes, these will result in bad clipnodes or leafnodes and cause this rare problem. It seems to depend on compiler sensitivity also. Max_leaf_faces You have gone over a limit similar to max patches error, but by BSP creating too many leaf faces for VIS to handle - probably due to "shattering" of a brush. Did you carve a complex brush (like a cylinder) or intersect it with another brush? short ### surfaces Similar to max leaf faceserror or ReadSurfs (line xxxxx): 32189 > g_numplanes error, in this one you are running out of face planes for the map. The one occasion I read of this, it was caused by a leak while running in software mode, although it may also be caused by over shrunk textures forcing too much tiling and making r_speeds of wpolys > 800. (Leaks keep the outside of a level map, so there are more surfaces the engine sees. However, this is NOT only a leak error, it is a too many surfaces error and can be caused by other things!) see also: skyboxing. short ### edges Like maxpoints error, in this one you are running out of edges. This is probably caused by running in software mode and having bad r_speeds with wpoly counts higher than 800....and maybe by making complex brushes like cylinders intersecting and causing shattering. Mod_parseMarksurfaces: bad surface number Cause & solution as yet unknown to me. Seems to happen when 2 maps/prefabs are joined into a map. MAX_TRI_TRIS or MAX_TRI_POINTS or MAX_TRI_EDGES An old RAD error code in outdated zoner's versions. Solution, get a newer version. Warning: ChopWinding: Rejected(1) due to too many points Merle says, "A winding is a data structure used in the compile tools to store a set of points. As they are very versatile, they can be used to describe a number of things (surfaces, brush faces, brush sides, whole brushes, etc...). Your Warning (note: which is not an Error.) message is simply alerting you to the fact that one of these winding data structures has a larger number of points than expected, and one of the points was ignored. "It is hard to guess what casues this as most of the typical causes (eg. brush sides with large numbers of vertexes) should be really caught earlier on in the process. Hence, it is most probably the artifact of some subdivision or modification of the points of the map itself during the compile, which makes it even harder to track down. "I recommend using the 'Big Block' method of trying to isolate a particular area of your map that causes it, and to modify/simplify/change the general brush geometry. This is a very generic fix, but its also a very generic message." ShutdownOpenGL-wglMakeCurrent failed This is a bug in the new WC 3.4/Hammer editor. It seems safe to ignore....or you could make sure you have the latest OpenGL drivers for your video card. Spawned a NULL entity You did some setting wrong with a monstermaker entity somehow. The box is empty A WorldCraft error - You are trying to make a flat box/level. Won't work, it has to be at least 1*1*1 unit big. Empty Map You forgot to give the compiler the name of the level you mapped, or you haven't made the level yet! You can't compile nothing! Sometimes this is a mis-error, and something else is the problem. Parsing Entity 0, expected '{' got '@RMF' You are trying to compile a .rmf file, instead of the .map file. These are different file formats, even if they deal with the same levelmap you are making. Make sure you export your level to .map and then use the c:/path..../ with the compile tools! Error: ParseEntity: EOF without closing brace WorldCraft is having difficulty exporting your .map version, somehow the end got chopped off. Means you've hit the end of the file and were missing a close brace "}". Its posible that the exporting procedure ended before it was done or you included quotations or other braces in entity string value names (bad idea). fixes: 1. try again to export your level from WC/hammer into .map format. and retry compile. 2. check in your level for entitys with "" or {} in the path/names. .map version with wordpad, go to end, add a bunch of closeing braces }}}}} then try recompiling again. Host_Error: Bad String This rare error only happens in game/server mode when sprites, models, sounds, or text strings (but not all strings!) are initialized and precached. If the string/name for the sprite, model, sound, or miscellaneous text string either starts with a non-printable ASCII character, or is 0 length (ie: starts with a non-printable null ASCII character), then the error will occur. Solution: search thru entities like env_glow, env_sprite, ambient_generic, env_shooter, etc. - anything the engine has to precache a file for the bad name. Line 5197 is incomplete (did you place a " inside an entity string?) This means that you have placed an invalid character (",'%, etc) in an enitity property/name. This can also mean that you have untextured faces in your map(areas with a white appearance as a texture.) Fix any "invalid texture" errors that show up in the "Check for problems" app. "unmatched target field (start_apc0)" Somewhere in one of your entitys there is a named target which does not exist, for example (start_apc0). Possibly you misspelled the entity targetted, or the entity was removed at some point. You will probably have to go through ALL of your entitys to find it - most tedious - in WC/hammer use the entity report to make it faster. "unmatched key value" You get that error when you personally type a key into an entity (with Smartedit off), and then WC can't find that key in the FGD file. If you know that you typed the key right and it works, the error is nothing to be conserned about. However, double check. My SKY is flashing, distorted or white This is an error that came with the HL 1009 update in Spring 2002. The problem is the update no longer reads the Valve pak0pak.pak file for the default SKY enviornment TGAs. The solution is to get pakexplorer prgm and open the valve pak0pak.pak, then unpak the gfx/env folders and place them under valve as valve/gfx/env....with all the missing TGS files that go with those folders. tracker UI not valid, not loading This is an error in half life patch 1110. Annoying but nothing to be concerned about. IF you want to aviod it, just go into Half-Life/valve/cl_dlls folder and change GameUI.dll to GameUI.bak. there is no bsp/Map not found on server Lots of possible causes for this, here are some of the most common: This means you probably failed a compile, or you never compiled. You must compile your level to make the .bsp map! If you did try to compile, go to your /maps folder and look at your .log for the compile with a text editor. You will probably find one (or more) of the other errors listed on this page. If you had no errors, did you copy the .bsp from your WC/maps folder into your mods map folder? It could be something else like a bad sky enviornment name, or making the SKY into an entity, or using the wrong fgd file to make your level, or You probably set the configurations of directories wrong, or ect. in worldcraft/hammer. Best thing to do is to have worldcraft/hammer not run the map after compile, and just run the game yourself, and play the map on LAN. If you typed in "map mapname" (where mapname is the name of your map without .bsp) in the console and didnt run it from worldcraft/hammer, just try typing it again, without quotes, and include the .bsp at the end. If that doesnt work, disclude the .bsp just to try again. If the mod for a multiplayer cannot find your map, perhaps you forgot to put in a player deathmatch, a player_start, or your mod equivalent? Also newer patches of HL require for HDTV the following entitys, depending on your mod: Info_player_start, Info_player_observer. STEAM is one of our newest causes for this problem. Make sure you have everything set up right for mapping with STEAM. Host_Changelevel2: Couldn't load map.... Usually for single player mods/maps, for some vague reason if you have connected maps, your second one (or other) would not load. Check: the info_landmark entity. can you load your second map through the console? is your map in the right folder? did you load the first map through the console? the map naming conventions. player starts. anything else you can think of. MakeNodePortal:new portal was clipped away from node@(coordinates) This indicates an invalid solid of some kind. You will need to find the brush at the coordinates listed and delete/recreate it. Usually this vague problem only happens in the older Q compiling tools, if you install and use the newer versions of Zoner's Compiling tools the problem will go away, or be given a more specific named error. However sometimes even in zoner's this shows up, due to Malformed face normal. SZ_Getspace Overflow on netchan A bad vague one - some server error caused by a bad map. In one situation of this I know of, it was solved by copy/pasting the ENTIRE level over into another .rmf file; when another time it occured it was solved by reducing the number of doors that used the same sound. In a third it seems it was caused by too many player start entities?, and in a fourth by a bad .wav file. But really I don't know if this was really caused by the WAVs, or by bad brushes, ghost entitys, or what. good luck figuring it out! "Portal file xxxxxx does not exist...." This can be a tough one. If the error causing it is clearly named in the .log of the compile with coordinates, then it is easy to fix. However, if the error is not showing up, it is time to go hunting. You could look at Token too large or some of the other errors. Check your Sky environment name, Wad count, ect. You may even try reinstalling a new copy of the compile tools in case they got corrupted, it has happened! "LoadPortals: failed to read header" or LoadPortals: couldn't read.... or LoadPortals: not a portal file or LoadPortals: reading portal.... or LoadPortals: portal.... has too many points This can happen in compile: an error occured while loading the xxxxx.prt file. It could be corrupted, missing (if you have a leak), or your map is too complex for bsp to generate a valid .prt file. Somehow the portal file made by the other previous compiling programs got messed up, or the reading program is messed up. Usually a Qtools problem, rare on Zoner's compile tools, but most often happens between BSP and VIS. "cannot find pts file" and xxxx.pts are files made in compiling by the compiling tools. Usually when you get "can't find .pts" it means something went wrong with compile. It could be a bad setup you made for the compile, or you're Running WC/hammer thru normal instead of expert, or having "too many wads", or corrupted compiling tools (rare but happens), a bad path/name somewhere, or several others. The solution is generally to use a front end or batch file with zoner's compile tools, then the problem usually goes away or the compiling error becomes clear. Mod_LoadSpriteGroup: interval<=0 Uncertain: When HL engine was loading sprites into its game cache something went wrong. This may mean a corrupt pak file, or a memory problem like precache, or a weird one likeMod_LoadBrushModel:maps/has wrong version number. "Mod_LoadBrushModel:maps/mapname.bsp has wrong version number [571084155 should be 30]" or Mod_LoadBrushModel: Sprites(lgtning.spr has wrong version number (0 should be 30) Here are a few of the problems that popped up under this situation: You may have errors in your compile, if not then, Your pak0pak.pak file may be corrupted? Maybe the wrong game version? Wrong WC/Hammer version? Earlier versions of WC were particularly prone to this. Use WC 3.3 or Hammer! Maybe another compile will make it go away, or not? And make sure you have the most up-to-date version of zoner's compiling tools.... You may have a bad model - like one from another mod or game, or you once installed a custom one? Or you may have a corrupted sprite or model? Have you installed a patch recently? It might be bad.... "Could not validate Half-Life" A similar problem to wrong version above. Solutions are: reinstall Half-Life and the update patches for HL and the mod.(this is usually the fix). But before you do that do a virus scan and a diskcheck/check for back blocks on the harddrive. reinstall WorldCraft sometimes fixes it. otherwise look above to wrong version. SerializeRMF()v2.2 tried to load a file v0.0 Aborting This World Craft/Hammer editor error means you are mix matching prefabs and maps made in different versions of WC/Hammer. Sometimes this is bogus, and then it means the level has been corrupted, or WC/Hammer has been corrupted. See also missing [ in texturedef. velocity too low on func_pushable This means that this func_pushable(s) is\are falling infinitely through space. This can occur when you place the func_pushable sumberged in water, place it on an unclipped skybrush or somehow shoot an entity or model at\through a skybrush. black hand or my player/weapon model is black This is a lighting error, the SKY looks lit, but the map, especially the players weapons are dark. Causes are: floor is func_walled or player is clipped way above floor somehow(elevator?), bad light enviornment settings (the PITCH should be negative "-" to shine DOWN), SKY walls on the side of a level are too low on the horizon, with a spotlight, the "pitch yaw roll" value isnt the same as the "angle" and "pitch", other. Models take their brightness & color value from the brightness & color of the floor below them, so if the floor is dark, far way, or black color, any model above it will be black too. Having them on a bright brush entity doesn't count. "couldnt`read texlights from lights.rad. or bad texlight. or 0 textures parsed from lights.rad" This means your lights.rad is corrupted/screwed up. Open lights.rad up with Wordpad and fix it. If you do not know how, open Valve.rad and copy paste into lights.rad. entity flickering or entity is changing from fullbright to dark and back One at least one occasion, an elevator, this was caused by the brush entity only being lit by RAD bounce. Try adding a direct light or a texture light to directly light the entity. Exceeded MAX_SWITCHED_LIGHTS This new compiler error has appeared with hlcsg v2.5.3 rel Custom Build 1.7 - I do not know the exact limits yet. Self explained, you have too many switchable lights, perhaps from using switchable texture lights? Lightmap for Texture aaatrigger too large [11x32=352 luxels]; cannot exceed 324. Most probably your .rmf, your .map or .bsp has been corrupted in some way. AAAtrigger textures are treated special, and should have a special lightstyle of 255, which means "no light data" = RAD is supposed to ignore them. If AAAtrigger is going through RAD, something is wrong, most probably corruption. (BTW: a luxel is short for "luminosity pixel" -- it's a fancier name for a light sample.) Warning: Too many direct light styles on a face(coordinates given) (revised) You have too many different kinds of light shining on a face(patch) of a brush: either differently named switchable lights, or flickering or strobing lights, or lights with a custom appearance. You need to remove some of these lights in the problem area (probably where you have the most such lighting), or combine the lights' properties into the same style. You can have more than one light shine in an area, but 3 styles maximum; but the lights should be the same light type/custom appearance/name(if any) if possible. The new switchable texture lights count as one dynamic style if they are all the same type/custom appearance/name. I am not certain about the new shadow coloring control, but I do not think that applies to the dynamic, just to the static background. (Each face wpoly/patch can have shining on it max 4 light styles: 3 switchable/dynamic light styles, and 1 reserved style for the static/unchanging lightmap. The reserved is the background lightmap - all the normal texture lights, light env, and lights that are unnamed and normal mode - no matter what the color or brightness. The dynamic lights can be single lights or a group, as long as they have the same light type, same custom appearance, and the same name. You can have 3 sets of dynamic - eg. if the lights have the same name, but 2 different light types (eg. normal and flickering) and one custom appearance then they make 3 dynamic styles.) choice to fix: 1. remove a bunch of lights in the area, named or lights with different types/appearance. 2. change more lights to the same type - type by light properties - or same names - or same custom appearance. 3. (Recent info from Cagey about how the RAD code works revealed that the older compilers look at EVERY entity with a Style property and counts it in as a light style! This includes entities such as buttons that do not give off light!) So also go thru your entitys with Smartedit off an remove Style stuff, or open up your .map of your level with an editor like notepad and remove the Style values from entitys like buttons that do not give off light really.... 4. RAD -coring 0.2 is used in some compiles with switchable lights to make light travel further before the cutoff, which make the switchable light look better - but it may also cause more styles to hit a particular face. If you are using the coring parameter with RAD, consider removing it from the compile. Back to top of page Decal will not work Decals from decal.wad are tricky. They should be in the decals.wad file in the right B&W format. But if the server has decals turned off, or your setup has decals off - then they will not show up. Also some vid cards have caused problems with decals. Also do not try to use regular .wad textures as decals, use the textures from decals.wad, or make your own decals in the decal.wad with wally. Decals are re-sized according to the texture they are on top of. "bad animating texture (texture name)" Animated textures names start off with a +0 and go to +9. If there is a gap in the sequence (like +2xxxx followed by +5xxxx) or if some other character is used with the "+" (like +olab1_gun1or - "o" is not a number.) then you may get this error. Also a texture with a bad name of the random beginning "-" can cause this error, even though it is not animating. Sometimes it is bogus, caused by a corrupt save/export, or by that old "too many wads" mistake. Larger than expected texture This is a warning, and only a warning, that you are using a larger sized texture in your level than some older video cards can handle. It is not a compile error, but it may cause player clients to sieze up if they have an older video card, or are in Software Video Mode. You must decide if you are going to abandon those players, or use another texture. See also Checkered textures. 'texture axis perpendicular to face' For some reason a texture has been rotated on the face of a brush until it is "stick out of" the brush face. Causes are usually, but not always: vertex manipulation, clipping the brush, carving the brush, importing a prefab, and sometimes rotating/skewing a brush with more than 6 sides - like a cylinder - without texture lock(tl) on. You could try map problems to see if it finds the error - sometime it does, but more usually you have to hunt. "mip>=loadmodel->numtextures" Too many textures used, keep the number below 100. However here is a different point of view, a quote from Jay, VALVE programmer: This is a check on the validity of the BSP file. If this happens, it means that some texinfo is referencing a texture map (by index) that isn't in the BSP file. This shouldn't happen under any normal circumstances. Maybe the build failed and you have a partial/bad BSP? It should be easy enough to debug if you have a map that produces the error. Also, the buffer for loading textures is a little larger than 340K (256K + 64K + 16K + 4K) because it assumes 4 mip levels are present and the max mip level is no larger than 512x512. This is kind of a silly limitation now, but it's a real one in goldsrc. However, looking at the warnings for large textures, none of them is actually over 340K so this isn't a problem (if that data is correct and complete). bspinfo may shed some light as well, but I don't recall if it prints out the texdata entry count - it may only print the lump size. My compiler askes for a wad I didn't use and don't have First, I hope you check the spelling of the .wads you entered into the map editor. Obvious, but never hurts to check. This usually happens because of the Too many Wads problem. Remove any wads from WC/hammer you did not use in your level. Try to keep the maximum number of wads installed in WC/hammer 8 or less. Another solution that sometimes works is to make an empty wad, a wad with all the textures removed, and install it as the LAST one in WC/hammer - this especially seems to help Hammer map editor. I cannot see my textures Check, if it is for textures in WC, did you put the texture into a wad of the right format (HL) and install it in WC? If it is for far away textures in the game, did you set the map's max view distance too low? Are you in software mode with more than 800 wpolys in the area? Or do you have too thin brushes or overlapping brushes? Do you have too many wads in WC/Hammer - 8 is the limit? Did you remove the wad from WC/Hammer that the texture is in? Was the texture was over streched or over shrunk, or adjusted to nothingness. If your custom textures are black in the game, did you REMIP them in Wally? If it is an invisible texture/{transparent check all of these: Does the name of the texture start with the { character? Is the blue 0 0 255 color? Is it the ONLY blue? (Wally likes to make extras.) Is the blue in pallette position #255? (Wally likes to move it around.) Is the func_illusionary set to solid mode, fx to 255? Again, did you REMIP in Wally? Are you in software mode? Occasionally it can't see through the "clear" portions of textures. Finally, is there fog in the game? - that might mess things up... "textures xxxxxxx is not 16 aligned" All textures have to have edge dimensions divisble by 16. Check the texture with Wally to see if the sides are a multiple of 16 - if not resize the texture or clip it to size - or just don't use it! Note: 16, 32, 64, 128, & 256 are the BEST dimensions to use! Other dimensions like 48 or 96 are legal, but due to engine texture resizing manipulation they will not look as good as "the powers of 2" edges would. my textures far off get lines in them This can happen because a custom texture has not been properly remipped when made in Wally, or it could happen due to z-fighting. Basically, z-fighting is due to limitations in the floating point precision calculations which your graphics card is processing, objects far away tend to fight over who has presidence to the player's view. Put in simpler terms, if you have, for example, a poster 2 units thick on a wall and walk away from it, sooner or later the card's calculations will become less accurate, and will not be able to properly determine which is in front - the power, or the wall behind it. So you have to be careful when putting thin entity brushes next to regular brushes. Making a space in the brush behind the thin one can help reduce the problem. Also read Checkers below. my textures are checkered or have dots This is often a sign of bad junctions in mapping. Checkers comes most often from overlapping brushes. Dots usually come from bad joints, which come from vertex manipulation or clipping, or come from the translation errors from WC/Hammer .rmf format to .map format. Sometimes these problems also come from too thin brushes. Occasionally checking happens because an old video card gets textures which are too big (over 256x256), or because the player is in software mode and there are too many wpolys seen. (800 wpoly limit in software mode.) One more thing that can cause this is for the compiled level to ask for a texture which is not in the loaded .wad anymore - maybe you removed the .wad from the editor, or switched in an other .wad that is named the same but doesn't have the texture you were using? Some solutions are: to fix the brush, to check the .map version to see if it is a translation error, to overlay the dots with another brush of same texture, to use smaller textures, to have less wpolys/brushes in the area, and to double check that the texture is in the .wads you are using. WARNING: Texture lump "xxxxxx" not found This usually means that you changed the wads installed in WC/Hammer or their locations after beginning the level. Go back and make sure the WAD carrying the texture is still in WC/Hammer when you compile, or when you remove the brush the texture was on. Also make sure you aren't running an -onlyents compile by mistake. But it could also be the too many textures problem or it could be that old "too many wads" mistake. W_GetLumpinfo: font0 not found Did you move or delete the fonts.wad file from where the game needs it? This fonts.wad file is needed by the game engine, and should not be deleted or moved - and along with gfx.wad & cached.wad, they also should not be installed into the map editor either, since you cannot use the "textures" in mapping; gfx, cached & fonts.wad will just cause a problem later when you compile. Just leave them alone in the folder. WARNING: Unable to load xxxxx\.wad You probably did not put the path/name of the wad correctly in WC/Hammer setup, or you moved/deleted the wad since you set WC/Hammer up. It could also be you tried to load an illegal .wad into the editor for the map - see W_GetLumpinfo: font0 not found above. But it could also be the that old "too many wads" mistake, or a bad brush - also bad texturing has set this one off. I cannot hear my wavs or Warning: Unable to open sound/C for transfer or com_loadfile: bad usehonk Wavs are tricky. You must use the perfect path/name, with the right capitals; sometimes even just adding or dropping the .wav extension in the name can fix things. If there are many wavs, you have to watch your sound card channel limits, or you will lose sounds/ambient_generics/wavs. If the problem is a custom wav, it has to be under the max size limit of less than 3 minutes, in the right format. (format is: unsigned, 8bit, mono, one start cue, 11025Hz PCM.) You can also try typing developer 3 into the console while playing the map, then walking through a trigger that targets the wav. The report may give a hint as to what is wrong. sound overrun Probably your wav is longer than 3 min, get a shorter one. However, other (unknown as yet) problems have caused this to appear. WARNING! sound/mapsounds/arc_tango.wav is causing runtime sample conversion! On some sound cards this happens. Many times it is meaningless and can be ignored, but if there are problems see can't hear my wavs above. S_Findname - out of sfx_t Uncertain, but as a guess: S_Findname() function could not find the name of a sound effect data structure. Unknown Command: VMod Enable This is a bug with Half-Life version, a problem with a voice command function in multiplayer I believe, it's annoying but w'ell just have to put up with it until it's fixed in a later version. emit_sound : pitch 346 or "sv_startsound: sound = 2550" This is a sound collision that can happen when 2 entitys try to make the same sound at the same time. An example: 2 trains running the same rail sound, both trains started by the same button so they try to open the sound file at the same time. The only known solution is to turn off the sound fx for both entitys....but that was for one case, feel free to experiment! (For the SV also see SVC_BAD - since I am uncertain if it may not be related to memory overflow of too many entitys loading too many wavs into the precache. sv_startsound is just a guess so far....) You can also try typing developer 3 into the console while playing the map, then walking through a trigger that targets the wav. The report may give a hint as to what is wrong. Can't hear my train sounds It has been reported that when you set the intial speed of a tracktrain to higher than 0, sometimes the train sounds do not work? Sentence or pitch shift ignored > 16 playing This error can show up when you are testing in map, and more than 16 entitys stop at the same time, especially if they are func rotating, which has pitch changes on stop sounds. It is about a sound collision similar to emit_sound : pitch 346 above. This can happen even if you are not using any sound - it may be a programming bug in the engine. Solution is to make it so all entitys do not stop at the same time. sprites problems Sprites are very tricky. You must use the perfect path/name, with the right capitals - or it will stop the game. The path should start with sprite/spritename, not the whole path name. Sometimes browsing to the sprite works best, sometimes typing the path/name in works best. In WC (but not Hammer) a sprite can lock up a level map as soon as it opens, if the animated sprite is in one of the veiws. The solution is to close up all but one view and try again to load the level....or remove the sprite from the WC sprites folder. If there is fog in a game, it reacts badly with sprites, so that the sprite may have a black border/box, instead of invisible. No solution yet. Entity xxx, Brush x: SKY brushes not allowed in entity Just what it says - you made one or more faces SKY in a brush that was tied to an entity. SKY texture cannot be in an entity. Either change the texture, or return the brush "to world". Do not just delete the brush entity - you will end up with an empty brush error. Use the entity and brush number with a goto to find the problem. R_LoadSky: Couldn't load gfx/env/cl_forestrt.tga This is from a bad sky enviornment name. If the six sides are sky_lf, sky_rt, sky_up, etc. you use only "sky_" in the cl_skyname field. Always drop any cl_ and the last 2 letters in a SKY bacground .tga name. Another example: cl_forestrt.tga should be used as only "forest" for the sky name. Again, for most of us a bad sky enviornment name leaves us with the default enviornment. But for some mappers, this can cause odd error warnings: like a bad brush that does not exist, or brush outside of map, or bad lighting in the map, or even a map crash when the bad sky comes into view. Make sure you get that name RIGHT! I push button/trigger in game and get kicked out If the compile was good, and there were no other problems, then the most common cause of this problem is a logic loop with the entitys. Two or more entitys are set to call each other, and somehow you set them in motion - buffers fill with the loops in under a second, crash, and you are kicked out. Or you have named the trigger/button the same name as the entity it targets. Solution: fix the entitys. However, sometimes something else sets off the kick off, so keep an open mind. It could be: You have a too big wav sound files that starts. You have a corrupt sprite/model that is called up. You have something that moves out of the level, like a door - but it goes too far. See also precache and allocblock:full for other possible causes. In one case where firing a gun crashed the map, it seems to have been too many ambient_generics with too many wavs playing at the same time that went over the channel limits of the sound card. Sometimes HL/mod (such as CS) maps which have the game_player_equip entity also crash when players overload on weapons. You are in software mode and are entering an area with sky, but the sky you entered is not in the gfx/env folder. See also: R_LoadSky: Couldn't load gfx/env/cl_forestrt.tgaerror. You have a strange video card that doesnt like the null texture. (very rare). You are triggering more than 16 things at EXACTLY the same time. You are loading too many entities when you enter those areas. You have a texture gone, leaving a window into the void in its place, causing a crash when you look. You have a Linux server, and something is named with captial letters which Linux does not handle like a Windoz server does. It can be also something else in the server settings of any server kind. or it could be something else. Isn't mapping fun? NON-Solid Set To Glow You set an entity into glow mode when you shouldn't have. Check the entitys in the map you made that you did not set a func_wall, or func_door or anything else into glow mode. no HUD In HL you get no HUD until you get the enviornmental suit. In muliplayer mods you often get no HUD because you "ran"(f9) your level thru WC, so you are in test map mode. To get the HUD, open up your mod, go lan/create your map, HUD should show up. ReadSurfs (line 99416): 32189 > g_numplanes or max_map_planes Before you go wild, try a recompile or 2 - sometimes it is just a random thing. Also search for a brush with more than 32 faces, such as a cylinder in the Maxpoints error. Otherwise this error means you went over the limit of the number of planes allowed. This means too many faces in the map = too many brushes, or too complex ones. Time to trim back the level map! Some solutions: Do not put a box around your map to fight leaks. Seal each section seperately and fight the leak war. Try to line up the faces of brushes with the same texture at the same scale. Then the engine may make them into one face plane. Avoid detail brushes, use texture to "fake it" instead. Plain make fewer brushes. Keep construction simple. HL and complexity mix poorly. There are some newer compiler programs being tested that remove unused and unneeded planes from the outside of a level. You could try to get and use one of them. no free edicts or NUM_FOR_EDICT: bad pointer Each entity ingame takes up an edict slot, if the game ever runs out of edict slots you get the crash "no free edicts." Solution is to reduce the number of entitys in the level. Single player mods may have a different number of edicts than multiplayer mods, possible due to the number of player entitys, sprites & models required. Reported general HL limits are SP=900 to 1024?, MP=1365 to 2048?? your Mod may vary. However, in a small map with few entities, the error can also be too many of one sort of entity - some Mods of HL have individual entity limits. In addition the "bad pointer" may mean the bsp was corrupted, or even that your game engine/dll is corrupted. Test other maps to see if it happens with them, and if not, get a new copy of the .bsp and retry. If it continues only with that map, then it is probably too many entitys. node graph out of date, rebuilding The node graph is what controls the AI basicly. It's all the routes between your info_node entities. Each time you change the map it must be rebuilt (which HL does). The more nodes and complexity of the nodes, the longer it takes. The files for the graph are in the maps/graphs folder and should be disrubuted with any final map release if it's SP. Nodes shouldn't even be in normal HLDM maps. Memory allocation failure Description: The program failed to allocate a block of memory. Likely causes are (in order of likeliness) : do not compile thru WC/Hammer F9 "running" - this hogs RAM. Instead use a front end or batch file to organize your compiling; the partition holding the swapfile is full (clean out your hard drive, empty trash, clear out unused files, purge your temp files folders and internet browsers temp files.); swapfile size is smaller than required (let swapfile be dynamicly allocated, do not set it too small yourself.); memory fragmentation (defrag your hard drive); heap corruption (reboot and try again. If you have old RAM, make sure it is seated well. check for viruses!). on at least one occasion this was caused by a corrupt prefab. on at least one occasion this was solved by removing a skybox and so making the level smaller. allocblock:full A tough one to figure out, vague error that usually shows up when you start the game or during compile, or even when WC/Hammer starts up - you have gone over the memory limit somewhere for some reason. It can be too little RAM (128M is about minimum), a leaf saw into leaf error, too long pathnames, too many textures, too big a level, too big or too many model/sprites, too big a wav sound file - or it could be that old "too many wads" mistake, a huge "noob" brush around the map to prevent leaks, too many SKY faces on hidden brush faces in the level - or even something else. Example: In early versions of NS, the 3D area info location entities were a major cause. If it happens during compile, do not use WC/Hammer to "run" the map, but use a front end or batch file to compile with. You could also get more RAM. (The following may still be handy, however be aware that Software mode allocates memory dynamicly, so it may automaticly seem to "fix" any error. Therefore the following info MAY lead you into a dead end: Some brush-based entities have rendering properties that, when they interact in OpenGL/D3D video cards, they crash. Switch Half-Life to Software mode first, then load the map. If it loads you now know it is something that is handle different in software, then for Opengl/d3d check water, glows, additive, sprites, transparencies (illusionaries, windows, ect.), env_beams and so on.) If it happens in opening a level in WC, it may be you have an animating model showing in one view. You must switch to single view instead of multiple, and try different ones until you get past it. z_malloc failed on allocation of xxx bytes or D_SCAlloc: bad cache size 0 Another insufficient memory or misallocated memory error. Possible causes are many, including too little RAM & also by having a texture perpendicular to the face of the solid with WC. In one case it was a script that shifted models one button. Possible solutions are: 1. For memory telling the HL main engine how much memory to use with HL -heapsize # (1024 x number of meg is popular #) or HL -zone # in the shortcut. 2. For texture perpendicular go into WC/Hammer, then you can press alt + p, and select the problem if it is listed, and tell it to fix all of type; then try to compile again. 3. Or go thru the other errors on this page and try them as fixes. It CAN be frustrating! Sorry. Malloc Block: Full The only time I ran across this it was a leak. HOST ERROR: PF_precache_model_l:'sprites/spritename' overflow or No Precache or WARNING: missing precache: or error running precache or Host_Error: No player.mdl precache or host error: precaching overflow on player models or HOST ERROR: PF_precache_model_1:'models/modelname.mdl' overflow or others Precache is a game memory problem. It often could be you have a bad path/name for a sprite/model/wav. But it can also be that you have too many kinds or too large sprites, models(400 obj limit?), wav sound files(limit<3min) or entitys(data limit ~0.5M) and have overfilled the space setup for them. (see also SVC bad below.) Sometimes combining entities into fewer helps, but usually you will have to simplify to fewer kinds of sprites/models, or smaller sprites/models/wavs. Occasionally this error happens when you are using a corrupted or non-standard model/sprite. Using other folk's prefabs are often hidden reasons for this problem. Sometimes the "too many wads" problem sets this off, or having a brush textured with AAAtrigger texture visible in the map will cause this problem. SVC_BAD or "500 overflow temporary ents!" or FSB_ALLOWOVERFLOW Like Precache above, it is usually a memory problem. This error is usually caused by too many entitys that create/call models - like gib shooters, breakables and pushables. The main solution is to cut back on these. Another cause of SVC bad in particular is compiling with -onlyents flag and having changed the geometry of the map. Also the SVC problem can happen because of various combinations of entities that are on the map together, it can be caused by lifts that are set in the up position when they have certain flags set, often a common cause of SVC bad is a bad compile where a brush based entity hasn't been compiled properly, so this can even be caused by a brush based entity with an invalid shape. SVC is a particularly tough one to figure out, good luck! It is also possible that the other problems as in precache above are also causing these problems. Error: too many entities or Too many entity's in visible packet list That means you have too many entities visible/see-able at that time. There are two likely causes for this: Your not running VIS, or your map has huge ammounts of entities visible at a time. Solution: run VIS -full, block line-of-sight (aka. vis blocking), combine like entitys in the same room - but only in the same room. Entity Limitation notes: The HL engine itself has a hard limit of 2048 entities, point or brush based, which is a data limit of about 0.5M. On top of that, Half-Life likes to generate it's own temporary entities in-game for certain effects (ie. beams, sparks, projectiles...), these temporary entities have a limit of around 500, see 500 overflow temporary ents! above. But the compile tools have a limit of only 2048 for all editor placed entitys (MAX_MAP_ENTITIES). (I am not sure if the temp entitys come out of this 2048 limit as well, but I suspect they do.) And there is a sub-limit on switchable lights of 1024 (MAX_ENGINE_ENTITIES). Additionally, you also have a compile side sub-limit of 400 for brush based entities. Mods that use cutscenes to start a round have even lower limits - DoD is now talking about 400-500 as the playing map limit of total entitys! NS has a similar situation. Moreover, there seems to be special limits for some entitys, like the limit of 16 rotating entitys that stop at the same time, due to the sound limitations. Or the limit of 32 players in most mods, or the general 8 fixed lights shining on a face limit, the 3 switchable lights on a face - and so on. see also: general MAX_MAP limits from the SDK HL engine limits for ALL entitys - 2048 HL in-game temporary entity engine limit (part of the 2048?). Used for breakables, sparks, gibs, ect. 500 data memory limit for entitys ~0.5M MAX_MAP_ENTITIES Compiling tools limit for ALL editor placed entitys in a level, incuding brush, models, sprites & point entitys like lights (mod limits may vary a bit lower) 2048 MAX_ENGINE_ENTITIES (light, light_spot and light_environment entities that have either a targetname or a style attached to them (ie. all switchable lighting in the map). 1024 compiling tools sub-limit of brush based entitys (part of the 2048) 400 possible model & sprite entitys sub-limit (part of the 2048?) 400 specialty entity limits various "Invalid Argument" If seen in compile, this means you probably set up the compile wrong, a bad path/name, a bad instruction flag for a compiler, or something of that nature. The solution is to go back and check and recheck everything to make sure it is all right. Rarely it is a freak instance that causes one of the compile programs to pass an invalid argument to one of its subroutines or functions (you may not really understand that last bit unless you do a lot with computer programing). Then you should reinstall your compiling programs. If seen when testing a map in your mod it could be that you set up an entity wrong in the map, for example a sprite calling a wav file. "Warning: No entities exist in hull #, no filling performed for this hull" Fairly obvious, you made the map without putting point entitys, like player starts. However, often this error will come up because an entity is outside the map; and other times this error will be bogus and something else lies behind it like: the "too many wads" or other odd errors, or you forgetting to export into .map format in WC, or a leak, or even a corruption of your level files! This error seems to get pulled up often for the wrong problem. Empty Entity, Solid Entity ..... is Empty or Entity has no brush You made a brush and tied it to an entity, but somehow deleted the brush without deleting the entity. An entity and brush number may be given, but it is still hard to find the problem - and sometimes the wrong brush is shown. The best way to find the problem is to use the goto of the map entity report, and goto each entity of that type. When the goto ends in a nowhere, showing no brush, that is probably the problem entity you can delete. But continue the check just in case there are more. by [DNv]Cross: persistant misnamed errors Solid Entitiy (entity_name) is Empty This error occurs when two existing brush-based entities are selected, then both tied again to an entity. WC/VHE asks the user which of the two entities he would like to keep, and is supposed to discard the other. Instead, however, WC/VHE does not discard the remaining entity, but simply strips it of it's brushes. Consequently, the user winds up with an empty entity. On occassion, in the case that one of the brushes that was combined had an error, WC/VHE will disguise the empty entity problem as that error. For instance, if a brush-entity with a malformed face was combined into another entity, then the malformed face error will persist in WC/VHE and may show up in the compile. However, when the user goes to check for the removed entity ##, he will find that the entity "does not exist." So in effect, the "Solid entity is empty" error was disguised as the malformed face error. In order to correct this, open the map in WC/VHE and press alt-P to open the map error report. Find the error that says Solid Entitiy (entity_name) is Empty and select it. Then press the GoTo button and close the error report window. WC/VHE should now be centered on the origin in the three construction views with nothing selected. Press the delete key on your keyboard. Repeat as neccessary. - [DNv]Cross - "Origin Brush....." ORIGIN textured brushes are not allowed in the level without being in an entity with another "visible" brush. (CLIP brushes do not count as "visible".) Furthermore, there may not be more than one ORIGIN textured brush in an entity. Make sure you did not accidentally clone the ORIGIN brush, and make sure it is tied into the same entity as the rest of the brush it is supposed to work with, and finally make sure there is only one ORIGIN brush in the entity. Note: For many entitys the ORIGIN brush does not have to actually touch the other brushes in the entity. Example: a rotating door as a swinging garage door can have its "hinge"/pivot point, the ORIGIN brush, below and inside the room the garage door is supposed to open. "Clip Brush....." CLIP textured brushes are not supposed to be alone in an entity. There should be a "visible" brush of some sort, even if it is an {invisible textured non-seen "visible". (ORIGIN brushes do not count as "visible".) CLIP textured brushes CAN be alone if they are NOT in an entity, that is how they are supposed to be used. Edge with both face id's already filled. The only time this came up, it was a bad brush with too many vertex points. See MAX POINTS error. "Mod-NumforName: xxxx.mdl not found" Often because the cycler entity, cyler sprite or some other entity used has the wrong path/name. You must use the perfect path/name, with the right capitals - or it will stop the game. The path should start with model/modelname, not the whole path name. Sometimes browsing to the model works best, sometimes typing the path/name in works best. Also if you have changed the model, for example a new player model or a new gib model, it can cause this problem. Re-install the old model. Sometimes the "too many wads" problem sets this off too. custom file has wrong number of lumps # I have only heard of this once, and then this error was just related to a downloaded custom gun or player model. Solution, switch back to the official standard models. green "flies" around a monster or player or model has yellow/gold dots The problem is the monster is stuck in the wall or too close to the wall or a brush entity. When a monster/player/model gets stuck in a wall, the engine creates those dots/flies to draw your attention, so you realize your mistake. Simply move him/it out of the wall and it will be okay. had 5 small blobs of white, yellow, brown, and red dots If you have 5 small blobs of white, yellow, brown, and red dots; one in the middle, and the other 4 circling clockwise. This means you have an info_node error, an info_node or info_node_air was connected to more than 256 or less than 1 other node. Make sure the info_node can see at least one other node, and the blobs should disappear. Host_error: UserMsg: Not Present on Client # This is not a map error or compiler error, it is a server/mod/HLTV/HL error. Some of these problems have been corrected with HLTV/mod/HL updates. I do not know the cause nor the solution at present - but make sure you have all the most recent updates. host error : PF_setview_1:not a client The only time I came across this, it was some error with a camera shot that started the level, and taking the camera out fixed it. EsBe says: As the name implies, this error occurs when the game tries to change the view of a non-client to that of the trigger_camera. What isn't so obvious is that the trigger_camera doesn't automatically target the player. It will target who-/whatever triggered the camera entity. Note that the game can trace the "activator" back through multiple entities. For example, if the player walked through a trigger_once which triggered a camera, the game knows that the trigger_once triggered the camera, but it also knows that the player triggered the trigger_once. The same applies to a func_button, etc. I'm guessing that you tried to trigger the camera with a trigger_auto. This would cause the camera to try to change the trigger_auto's view, not the client's, because the player didn't actually trigger the trigger_auto. I would assume that this error would also occur when a path_corner, etc., triggers a camera. "file read failure" There is a problem reading the file. The possible causes and possible solutions vary so much I cannot list them ALL here, but for a HL/mod game a few are: corrupt bsp, needs replacing corrupt MOD or HL program needs replacing - a virus? corrupt sprite/wav/model/wad a bad HardDrive sector that is not reading well or at all a program is interfering with the game program and many others are possible. Floating point division by zero This is a sign something is wrong. But there is no certain cause nor answer. Check first for leaks, after that ANYTHING or everything on this webpage. Sorry. Back to top of page Info mainly from JCHQ, who used many sources Vismatrix too big The other memory requirements (about half as much as the vismatrix's usage) plus this put you over the top in memory. This pretty means your physical memory + swap is less than all the memory qrad wants to consume. A few things to work around it: Increase swap. Get more RAM. Compile on a computer with more RAM. Use a larger -chop value (default is 64) to make a smaller vismatrix, sacrificing quality until you can get more RAM/access to better machine etc. Use qrad with -bounce 0 (no radiosity lighting) which skips the vismatrix step and just does direct lighting. Uses a lot less RAM but lighting is only a real rough approximation of how it would look if it was allowed to bounce once or twice." use the -sparse value on HLRAD to use less memory. see also: skyboxing. "Warning: SwapTransfers: unmatched" It's often a false problem in QRAD, but sometimes real. solutions: use zoners compiling tools, especially HLRAD. other solutions are: If the map lights fine, ignore it. End of problem. Undo my most recent changes, and see if the map lights then. Rigorously check for any bad brushes. Delete some lights, starting with switchable lights. Make some random changes in the map, usually by way of scaling some textures, and see if the map lights fine then. Scaling a texture changes how big the polygon ends up being on a large surface (and thus helps the speed), and it also affects the lighting of it. Outdoor areas usually have most of the textures scaled up 2x2 or larger. I would first pick textures that you won't really notice scaling on: near-black textures, rocks, concrete, asphalt, whatever. Move random brushes around, or delete brush entities. Pick a good spot and cut the map into two separate maps with a level transition. That is the most drastic but usually works if all else has failed. Other possible fixes from Neil include: Use the "-extra" HLRAD Delete the offending brush (One case was angled on several sides to a point)." "Error parsing brush" "This is usually caused by custom textures. Check all of your custom textures and make sure there are no spaces in their names, all lowercase letters. I'd bet you'll find a texture or 2 with a space in the name. If you find one, just load that .wad back into Wally, change the name, load the map back into Worldcraft, [alt]-p to bring up the error window, and it'll tell you what brushes you used that had the texture you just renamed so you can change it to the newly renamed texture. (You can't save a .wad that's currently being used by Worldcraft, so be sure and close Worldcraft before editing textures.)" Usually this vague problem only happens in the older Q compiling tools, if you install and use the newer versions of Zoner's Compiling tools the problem will go away, or be given a more specific named error. However sometimes even in zoner's this shows up, due to Malformed face normal. "Token too large" This can refer to several different errors: The "too many wads" as mentioned above. 8 wads in WC/Hammer is a good limit, more may cause this error among others. If you are using more than 8 wads you can use Wally to combine the extra wads into one custom wad. Too long a path/name for the map or compiling tools. Only a limited amount of memory is set aside for the path/names. Solution is to move the compiling tools or map into a shallow folder. Having a space in a path/name. Examples: frequently /Program Files/ is part of the path name. Compiling tools do not like the space between "program" and "files". Solutions are to either use the MSDOS pathname, or to move the offending files from under the spaced folder, or put quotes " " around the whole path name in WC/Hammer so that windows uses it right. If your map has the space in its name (eg. Bob map), remove the space and change it to (Bobmap). "Illegal Page Fault" Mostly an old WC 2.1 error not seen often in WC3.3/Hammer. Causes are illegal/bad brushes, or more usually the "too many wads" as mentioned above. "MAX_MAP_MIPTEX" (Zoner's Compiling Tools) or ReadSurfs (line ReadSurfs: 990 > numtexinfo "Although Zoner's Compiling Tools recommends you to merge or remove unused textures (which in itself indeed is very prudent), here's another solution. Just use the "-texdata" switch on the command-line for HLCSG to increase the texture memory. Normally it's is set to 4096 KB (compared to 2048 KB available to QCSG - the compiling tool Valve used), but you can set it up to at least 8192 KB. When you do set it higher, look at the log output from HLCSG - it will tell you how much more than 4096 KB it actually uses now.." The limits for -texdate can go as high as the mem of the video cards you expect to encounter. For older Voodoo 2 cards it goes up to 8 meg (8192 KB) or 12 meg. If you KNOW your level is only going to be used on a local LAN where everyone has 64M vid cards, then you can set the -texdata to 64000 KB! But for public distribution you will already lose software mode players above -texdata 4096, and old vid card players above -textdata 8192. The higher you go above that, the less folks can play it! "MAX_MAP_MODELS" "The max_models error is that you have exceeded the maximum number of brush based entities in your map. This can be either the total amount of brush based entities or of a specific entity. "So it's either too many of one type of brush based entity or you have exceeded the number of brush based entities in the game (like trying to make the whole map out of func_xxxxx entities)". "Each player model, each grenade, nail, gib, etc. counts toward the MAX_MAP_MODELS count. The total model count is always dynamic durring the game and changes as new models are spawned and removed. You simply need to make sure you leave some space. see also: entity limits. "MAXPOINTS" "Most level editing programs will happily allow you to create brushes that cannot exist in the engine because of compiler and/or engine limitations. As an example, use your favorite level editing program to create a room with a 32-sided cylinder in the middle. WC/Hammer will let you do this, and I'm sure that Quark will as well. Then try to compile it - you'll choke on a MAXPOINTS error. The cylinder has two faces with 32 sides, which is above the MAXPOINTS limit (28) set by the compiling tools." "CanonicalVector: Degenerate" "You've combined brushes into a func_water that doesn't form a rectangle (or damn close to a rectangle). Func_waters are notorious for being STUPID. I got this error just combining two worldbrushes that made up an L shape into a func_water." If it isn't the water (most common), then check your triggers and other brush entitys, odd shaped/illegal trigger brushes can also cause this error. Back to top of page Common Mapping Problems & Compile Errors by Zoner with additions: plane with no normal Example: Entity 10, Brush 0, Side 4: plane with no normal Entity 10, Brush 0, Side 5: plane with no normal This error is always caused by vertex manipulation. A plane is defined by 3 unique coordinates. If any of the three coordinates are the same, then you don't really have a plane (its either a line or a point). There is no way to fix this error other than to delete the brush and recreate it completely. This is most commonly caused by dragging a vertex ontop of another to destroy it for several vertexes of the same face. The resulting brush can even look correct, but the side which you have destroyed can still have a point or two defined for it. The proper way to remove a face is to use a clipper. If the object is simple (say converting a square to a wedge), then dragging an edge via the yellow control points to merge multiple vertexes at once will probably be safe. There is a new program HLfix that is supposed to fix these. brush with coplanar faces Example: Entity 10, Brush 0, Side 5: has a coplanar plane at (-753, -9, 251), texture CA1X_CON1B Entity 10, Brush 0, Side 6: has a coplanar plane at (-753, -32, 251), texture CA1X_CON1B This is always caused by vertex manipulation. Say you have a five sided object like the following diagram: Moving the top point down to make the object into a square, will cause this error, as now 2 faces are on the same plane, which is not allowed: To fix this problem, either move the vertex causing the coplanar warning to make the brush convex again, or move the rogue vertex onto one of its neighbors to destroy it. There is a new program HLfix that is supposed to fix these. brush 'outside world' Example: Entity 10, Brush 0: outside world(+/-4096): (-9000, -64, 216)-(9000,23,283) There are a few cases that create the 'outside world' error. The first is an damaged brush, almost always created by a vertex manipulation gone wrong. The coordinates listed in the error are very important in diagnosing the error. If any of the coordinates are -9000 or 9000, then the brush is damaged, and most likely needs replacing completely. The second most common case is actually having a brush near or outside the edge of the allowable region for the world. The brushes are expanded slightly for some of the calculations during a compile, so brushes near the edge within 64 units will cause the error too. The cordon tool creates brushes automatically to box in the cordon region, and their brushes can sometimes be quite large, and also extend outside the world. This can be verified by opening up the .map created by an export with cordon enabled, and looking to see what brushes it made. There is a new program HLfix that is supposed to fix these. These 3 errors are very closely related, almost all caused by vertex problems, often at the same time. Causes can be you, or the editor. Be careful when you manipulate vertexes! But the editor can also mess up - WC/hammer is known for this. Rotating a brush, clipping, carving, hollowing, copy/pasting a brush, even moving a brush can make the vertexes go "off the grid". This is OK with the editor, it can handle decimal points. But when the editor exports to .map, trouble arises. The editor seems to move the vertexes to a grid point, often the nearest, but sometimes not. So vertexes can end up in a line or on top of each other (no normal), or move so that 2 planes line up (coplanar faces), or move so that an illegal face is made and in compile deleted - leaving a hole (which results in outside world). Sometimes the editor even seems to put the vertex outside the map (again, outside world)! One fast way to check for this is to open your .map export with your editor, and look around. If you see some funky brushwork, remember what brushes are involved, then go back to the .rmf and change the vertexes to meet the grid points. A comment by Cagey on a specific example of these problems: For the record, a "Plane with no normal" error occurs when the three points specified for the plane in the map file are colinear. When that's the case, the normal is logically indeterminate... the program attempts to take the cross product of two edges and gets a vector of length zero, causing it to throw the error. Also for the record, if a brush has a bad plane definition, that plane is skipped when calculating face boundaries in CSG, which is the probable cause of the "outside world" error you had for brush 11--if you remove one plane from a brush and the remaining planes don't form the boundaries of an enclosed polyhedron, the resulting brush created by CSG is bounded by arbitrary limits set by program. That arbitrary limit for brush bounds was set just outside the legal world bounds so that logically unbounded shapes will be reported by the program. In the case of brush 10, the remaining plane intersections still define a complete solid even without the missing plane. I should note that skipping invalid planes is only one cause of "outside world" errors... two others are: · explicitly creating items outside the +/-4096 bounds of allowed mapping space (actually "outside world") and · creating items within (largest bounding box dimensions)/2 of +/-4096... when brushes are expanded for the clipping hull, they end up partially outside the world (although this could be modified, since simple geometry can demonstrate that any face that gets expanded across a world boundary must be on the exterior and should be culled unless the map leaks). If the brush being reported as outside world isn't near the edge of the map, however, a skipped invalid plane is the best bet. mixed face contents Example: Entity 0, Brush 12: mixed face contents Texture ROCK_X1 and SKY Entity 0, Brush 37: mixed face contents Texture STEEL_9 and WATER7 In Halflife, brushes are required to have all faces be of the same type (solid, water, slime, sky, origin). Fortunately almost all textures are solid. If you put a water texture on one side of a brush which has dirt or steel textures for example, that would generate the error. The engine needs to know what is inside the brush, and it would be real confusing if different types could be put onto the same brush. The fix is relatively simple. Simply find the offending brush, and then the faces with the inappropriate texture and change it. If a brush uses SKY, all sides must be sky. The same is true for CLIP, and ORIGIN textures as well. If you are careful it is possible to mix water textures (provided you don't accidently use a slime texture on the brush) RankForContents: bad contents Rare error. In one case it was a bad brush from vertex manipulation. In another case it was a func_door with the 'passable' flag set & a large clip brush. Try an editor "check for problems", otherwise retrying the compile may help. If you are still stuck, try the big block method or Cordon Boundry compiles to find the problem. === LEAK in hull 0 === Check out this tutorial: The leak messages starting with 2.4 were updated to replace the old 'LEAK LEAK LEAK' messages. The entity listed along with the error is just where the beginning of where the pointfile is created, and can be used to help find the start of the line. It always goes from inside towards the outside, from this position. Deleting this entity will usually just cause the leak to start somewhere else, without actually fixing it...but sometimes an entity can cause a leak, for example a cycler the puts a model through a wall. see also: skyboxing Info from JCHQ on the pointfile method of leak finding. "Load up Half-Life (or the mod) with your leaked level, using the lines "hl -console -dev -particles 50000" (or a bigger number) then, once its loaded, in the console, type pointfile. [...} You will then see a dotted line in your level that bounces around like crazy! Just follow it, and the point where it leaves the level is where the leak is happening." Purple block leak finding method You surround the area you think may contain the leak with huge purple colored blocks, or another color that sticks out for you. Then you run the map, and walk around trying to see the purple thru the cracks to find the leaks. After you fixed the leak, you remove the blocks. === LEAK in hull 1 === === LEAK in hull 2 === === LEAK in hull 3 === You can generally ignore these, but there is a possibility that part of the world somewhere will either be solid where it shouldn't, or vice versa. If it mentions Hull 4, see: tiny penetration in Hull 4. Big Block method - process of elimination written by Leperous. pros - finds any single leak/problem. cons - tedious, not for multiple leaks/problems. Place a huge block over half of the level and compile with CSG and BSP only. If compile tells you you have a leak/problem anymore, it's in the region that you didn't cover up- repeat step 1. Then if you still have a leak/problem, then you probably have several of them...If not, then carry on with this process, but use multiple blocks, each time 1/2 the size of before. Repeat process until you're using a very small block (e.g. 32 X 32 X 32). Search for the leak/problem using the 3D window. Then you can copy the immediate region of the map (block off corridors etc.) into a new map and do the pointfile thing on it. For this method to work, make sure your info_player_start isn't underneath the big block! my SKY turns invisible when I am in a func_water This can happen when you have not done a complete error free compile with VIS -full and RAD, or it can be because you have a bad driver for your video card. Leaf portal saw into leaf There are fine tutorials here : and at DeWan's Old Tutorial on BSP and VIS. Basicly this comes from an area whose floor is not square enough, square floor areas never give this problem. Note: often if there is only one leaf saw leaf in a map level, it can be ignored. So before getting busy, see how your map plays! Solutions to try when you have a lot of leaf saws, or problems from leaf saws: VIS -full compiles were designed to help with this problem, so the FIRST thing to try is recompile with VIS -full and see if it goes away. func wall any brushes within the coordinates given for the problem, this will simplify VIS in the area because func wall brushes are invisible for VIS. Move walls in the area to make the floors more square. Put a HINT brush across the trouble area. HINT brushes cut VIS leafnodes, so they will reshape the area and may fix the problem. Finally just start ripping brushes out of the area. Fixing Leaf saw error has also been known to fix other errors in later RAD, like FindTransferOffsetPatchnum returned -1 looking for patch 1570 in patch 199's transfer lists and other problems. Exceeded MAX_PATCHES When hlrad runs, it takes all the visible faces in the game, and divides them into sections called patches. These patches are the textures used as the lightmaps for the world. There is a hard limit of 65535 patches that hlrad can deal with. By default, a 64x64 game unit chunk of space is the size of one patch. If the texture scaling (not texture size) is larger or smaller, it will directly affect the lightmap size as well. This means a texture with scale of 2, will have at best 1/4th as many patches as a texture with a scale of 1. Putting a 'box' around the level to protect from leaks is the most commmon cause of this error, beyond excessively large maps. The box causes vis to keep the faces on the outside which would normally be thrown away. These faces are then required to have lightmaps. Worst case, is that putting a box around the level will usually cause an extra 40-80% more lightmaps to be created than necessary. Barring having a box, the other cause is large maps. The fixes are varied but can only help so far. Remove any "box" from around your level and fight the leak leak leak war the right way. If you have not boxed in your level, then the #1 fix is running HLRAD with the -sparse flag - but compile will be slower. Using -chop values larger than the default 64 for hlrad will cause the light patches to be larger. However, for values larger than around 96 the map's lights start looking bad, and will more prominently show the 'staircase' effect on shadows. Using a larger scale on large textures (dirt, rock walls, concrete) will help those large surfaces consume fewer patches for lighting. see also: skyboxing HLVIS is SLOW For most well designed maps, vis should have a worst case run time of about 45 minutes on a single p2-300 class computer. If it is taking longer, then the map probably needs work to add vis blockers. Several things can make vis take way longer than usual: First, if the world has been 'boxed in' to prevent leaks, vis has to spend large amounts of time on the exterior gaps which would normally not exist on a map without a box. Second, The architecture which connects 'areas' together might be a bit confusing for vis to figure out. It is somewhat difficult to explain, but a few examples would be: halls lacking a wall somewhere which is not directly on the XZ or YZ plane; halls that intersect rooms on a plane other than XZ or YZ, large rooms with walls that are not vertical; halls that connect two areas but the areas can see each other through the hall; Lots of little tiny brushwork in an area (especially large areas) that is not an entity. Third, vis is quickly brought to a crawl by large outdoor areas that are not extremely carefully constructed to not too see much 'indoors'.. And finally, using an older version of gensurf that does not support ZHLT's HINT brushes. It is highly advised experiment heavily with test maps with sample architecture, using software mode, r_drawflat 1, and r_draworder 1 in order to see how vis works. Also, read the HINT brush tutorials described in the section on HINTs. HLRAD is SLOW/stuck on makescales HLRAD requires large amounts of memory to run efficiently for all but the most trivial of maps. The vismatrix hlrad needs to run takes exponentially more RAM as the vismatrix grows. The formula is 'number of patches' squared, then divided by 16. This number is how many bytes it will consume. The maximum is 65535 patches, so the maximum vismatrix is 256Mb of RAM. Furthermore, the amount of memory the vismatrix uses is not all the memory hlrad needs to run. Depending on the visibility of the map, the 'scales' cache consumes large amounts of memory at once as well. For most maps, this amount of memory is close to 1/2 the size of the vismatrix. This generally equates to a maximum of 128Mb, or a system total of 384Mb to run the worst case (65535 patches) map. The makescales phase has a tendency to run fast right up until it runs out of physical memory and has to start relying on the swapfile. This is frequently noticeable as makescales running quickly (say 20 minutes) up until the 90% mark, then taking several hours to finish the last 10%. This is always caused by running out of physical memory, and the last 10% work requiring heavy use of the swapfile. If more architecture is added to the map, one can see that it will start taking exponentially longer to compile, until the RAM is upgraded. Besides simply adding large quantities of RAM to the computer, the fix for this problem is identical to fixing a MAX_PATCHES error. Applying those fixes will reduce the number of patches, and cause HLRAD to need less memory, often speeding up the compile dramatically. If all has been done, there is also the option of using -bounce 0 with HLRAD, and using just direct lighting for test compiles of the map. Ideally one would then using a non-zero -bounce for the final compile. by [DNv]Cross: VIS AND RAD KEEP CRASHING DURING COMPILE When compiling, VIS and RAD have a tendency to become completely caught up in their work. Basically, unlike most other programs, VIS and RAD give your map priority over Windows. Windows will poke every program running every few seconds (usually with a redraw command) and wait to see if the program gives a reply. In the case of VIS and RAD, they are usually working so hard on compiling the MAP file that they completely ignore and fail to respond to Windows pokes. The result, windows says "Not Responding" next to the program name and things may fail to be re-drawn (leaving ugly white program forms behind). All there is to do is sit back and wait while VIS and RAD go about compiling your map. Compile times average a few hours even on the most up-to-date machines, so be prepared to wait a while. If your map is poorly constructed, you might even get your compile to take a few days (I've had to wait 96 hours before.. 4 days!). - [DNv]Cross - See also the multilight slowing as explained in Warning: Too many direct light styles on a face. Bad Surface Extents This is typically caused by having extremely large scales on faces, (typically "stretching" far above 10, usually 100+). Otherwise it almost always shows up on a 'check for problems' in Worldcraft as a 'texture axis perpendicular to face' error. If you are using a newer version of Zoner's compile tools, the name of the texture, what # brush/# entity is involved, the coordinates of the problem face, and the amount of scaling should all be listed to make it easier to find and fix. If the numbers given include a 0, such as 16345/0, it often (but not always) means the texture has gone perpendicular to the face. This usually is a result of rotating the brush, clipping, carving, hollowing or vertex manipulation, remember where you did that and you may find it faster. If it is numbers like 3456/2 or 3/532 then it usually means a stretching texture problem. These often come from "fitting" a texture to a brush, especially thin brushes like signs or doors. Then a texture may get shrunk too far also, so do not go below 0.1 for scale or over 10 for scale, either causes frequent problems. If the editor cannot find it for you, using the Big block elimination method or the cordon tool may be you best bet to figuring this out, unless you want to start ripping your level apart.... missing [ in texturedef The 'missing [ in texturedef' message can be caused several ways: One or more faces has no texture, or the texturename is just made up of spaces. Check for problems in WC 3.3/Hammer should detect them as 'invalid texture' messages. The texture name on one or more faces has a space in the middle of the name somehow (Textures are not allowed to have spaces in their names) You are using Worldcraft 2.0 or 2.1, and the worldspawn has a key/value of "mapversion" "220" If so, remove it. A Worldcraft 3.3 map was imported into WC 2.1 or 2.2, same problem as above. A Worldcraft 3.3 map was imported into Quark, also the same problem The map is in Worldcraft 3.3's .map format, but the "mapversion" "220" is MISSING from the worldspawn (this is really rare). MAX_PORTALS_ON_LEAF This is normally caused by having large rooms which connect to a lot of other hallways, alcoves, or other similar shapes. Alternatively it is caused by an invalid brush, of which each one is usually unique and you would have to find on your own (though Worldcraft is pretty good about finding them in its 'check for problems' feature). This image is an example top-down view of a complex room. The pink area is the room, the blue area are the walls. The main big room is one leaf, each alcove is a leaf, but the big leaf joins all the little ones for a total of 32 portals. MAX_PORTALS_ON_LEAF is 256 in Halflife, so this problem is quite rare and usually a side effect of having a damaged brush in the map. How the heck do I use HINTs/How does VIS work There are some decent tutorials. First, there is the excellent CounterMap tutorial for HL/CS. Second, there is Geoffrey DeWan's old tutorial on the subject. Although for Q2, the concepts are identical. It is worth reading the whole article, and it is also worth noting that the SKIP support in Halflife that was added to ZHLT is not as robust. Third, Another old tutorial, also for quake2, is also in the archives. MAX_MAP_CLIPNODES There isn't any way to add more nodes or clipnodes to the bsp's (its already maxed out). However, at least clipnodes can be reduced with a bit of work. When the maps are compiled all the 3d 'space' a player can get to is broken up into convex regions just like brushes are required to be, alot of them are extremely small or too small for a player, and if you put a CLIP brush over them they don't become clipnodes at all (well really there are still a few intersecting the brush on its surfaces, but the brush can be excluding dozens or hundreds of them at a time). If the world has had a 'box' placed around it to prevent leaks, its probably causing several thousand (if not 10000+) extraneous nodes and clipnodes to be caused, not only wasting resources but will cause vis to work a lot harder than it needs to. An example map is available, demonstrating how it is possible to reduce the clipnodes in a map. Without the clip brush in place, the map requires over a hundred more clipnodes to define the player-accessable space. Merle's new compiler also trims some excess unneed clipnodes, which means a little more you can build. Get it. Back to top of page by [DNv]Cross: ALL YOU EVER WANTED TO KNOW ABOUT A SKY BOX: The method which has been described is called a sky box. THIS IS EVIL! NEVER USE THIS METHOD! Ok.. now that i'm done flaming sky boxes, I'll go into an explanation. BSP maps consist of two separate areas. The level area, and the outer void area. When a map is compiled, both MUST be included in the map, or the compiler will not work correctly. The compiler defines the "inner" level area by entities and the "outer" void area by a lack thereof. When the compiler cannot distinguish between the inner and outer area due to a lack of a boundary, entities on both sides of the boundary, or simply no entities at all, a leak is generated. When an entity is specified with a leak, that entity is (99% of the time) not the problem, but is simply the closest entity to the problem. Instead of just simply deleting that entity, you must find the cause of the leak (hopefully you haven't deleted your entire level already). There are many methods to this. The pointfile method, the leakfinder program, and the block (not skybox) method. Each of these has been discussed many many times (and is in the Hammer/WC help file if you take a look ). What happens when you make a skybox: - Your r_speeds will get much worse - Your map will take longer to compile - You will no longer have leaks, but at a high cost - Your map will be a larger file than neccessary What is not good about a skybox: - The outer walls of your map are compiled along with the inner walls, creating a lot more work for the VIS and RAD programs, making the compile much slower. - In game, r_speeds will rise significantly because the engine will have to draw the outside of the level at times as well as the inside. - You will lose valuable file space to the outside faces of your map. This will increase your map's file size and limit the number of objects / walls you can place in your map. How do I make a skybox: I hate to tell you so you don't go and make one. However, since I want you to avoid this method, I will tell you what NOT to do. A skybox is simply a very large box drawn around the entire level, then hollowed out. So use SKY instead as a "lid" for each section, or put it behind the glass in windows. One more thing to Know: Skyboxes are the epitome of newbieism. I have a policy in which I will make a point to delete any map in which a skybox is used. You will notice such a method is not used in any distributed maps nor in 90% of the maps out there. Powered by 0rsp
  3. [Portofoliu] OSwalD NoKa NoKY

  4. Programator - Designer

    Vezi PM @Raull
  5. Link download Updatat, UP cu postul asta !! Allen Carr Download Audio Book METODA USOARA DE A TE LASA DE FUMAT
  6. Programator - Designer

    Salut, Daca ai nevoie de un web-designer ce se poate ocupa de partea grafica sunt disponibil.Am cunostinte in HTML,PHP,CSS,Javascript.Am cateva proiecte recente daca esti interesat, iti pot trimite SS sa vezi cum lucrez.Pe partea cu database,sql nu am atata experienta dar invat pe parcurs,incerc sa le fac pe toate dar la toate trebuie dedicat timp
  7. Programator - Designer Asta pentru ca este in Mantenanta...
  8. [Portofoliu] OSwalD NoKa NoKY

  9. [Portofoliu] OSwalD NoKa NoKY

  10. Programator - Designer

    Nu se deschide pagina "Service Unavailable"
  11. Programator - Designer

    Acceptat nick si pass in pm

    NICK:RandoM Varsta:15 ani Experienta AMXX/CS: Putin Timp disponibil zilnic: Serara dupa ora 21:00 Steam ON/OFF: OFF Facebook?: Cuvant cheie- Il gasesti in regulament: teroare Link ore Gametraker: Putine dar fac rapid Poti dona?:Nu,din pacate.
  14. Cerere Admin DeeK. # 1337#Cods

    pRO hELPER ... dar pe la 5 6 ani de abia te ai deobisnuit sa faci la olita .. vedem ce spune barosanu ...... ramane la alegerea lui
  15. Cerere Admin DeeK. # 1337#Cods

    NICK:DeeK. # 1337#Cods Varsta:13 Nu cred ca e vreo problema stiind regulamentul si ca imi place serverul Experienta AMXX/CS:undeva pe la 5/6 ani am avut admin pe multe servere, chiar si detinator cu ftp ) Timp disponibil zilnic:cateva ore Steam ON/OFF: OFF Facebook?: Cuvant cheie- Il gasesti in regulament:teroare Link ore Gametraker: Am jucat si pe alte conturi si de aceea am atat de putine minute/ore Poti dona?:Momentan Nu

    Respins cerere nerespectata

    Pro Moderator


  20. Apple a venit în România

    Hahhh, ce-mi place ce faci. Spor Cosmin! Sa te vad in x6 peste cateva luni
  21. Apple a venit în România

    Wooow, wooow si din nou, WOOOW ! Felicitari @0rsp™ si ne bucuram sa avem un lider de comunitate strateg!
  22. Gigantul american şi-a înfiinţat propria companie şi va intra direct în războiul de pe piaţa de smartphone-uri, tablete şi PC-uri Compania, care poartă numele Apple Sales România SRL, un capital social de 1.000 de lei şi este deţinută de firmele Apple Distribution International din Irlanda şi Apple Sales de asemenea din Irlanda. Administrator al companiei este Peter Ronald Denwood care, potrivit reţelei de socializare LinkedIn este director juridic pentru afaceri internaţionale ale Apple din septembrie 2013. Cererea de înfiinţare a companiei a fost depusă în 24 august 2018, în Bucureşti. Mutarea făcută de Apple, companie cu o capitalizare de peste 1 trilion de dolari, vine într-un moment în care piaţa de smartphone-uri din România a urcat în primul semestru din punctul de vedere al valorii cu peste 40% , pe fondul cererii tot mai puternice a clienţilor pentru telefoane mai scumpe. domeniile sunt detinute de catre Comunitatea Sa fiti iubiti
  23. Propunere

  24. Cerere Rank

  25. Cerere Helper

  1. Load more activity