Modified August 4, 1997
| Problem | Solution |
| func_train crashes at last stop on its route | The final path_corner needs a valid target path_corner. If you want the train to stop at the last path_corner, give the last one a wait of -1. |
| SV_StartSound: not precacheed - warning message that shows up in the top left hand corner of the screen after using a trigger to fire a burst of lightning in a third-party level, message is displayed four times in a row. | For networking purposes, Quake builds a "precache" listing for each map. It contains a few vital things which
are common to all maps (these precaches can be found in the quakec file world.qc), and specific precaches for
objects found in the quakemap (such as models/textures/sounds for each of the weapons and ammos,
healths, armors). This tells the client to load these objects into memory (if there's room), and to assign these
objects a number, which the server will refer to them by from now on. I can think of two possible solutions to the specific problem. You could add the sound file to the listing of precached files in the world.qc file, or you could add the respective object which that sound would normally be associated with. If the custom map uses lightning-gun sound for its burst of lightning, you could add the lightning gun to the map which would then cause the sound to be precached when the map is loaded. If it uses that sound effect from the lightning tower in E1M7, I'm not sure how you would go about forcing it to be precached. Possibly copying those two electric probes and the switch that powers them to a secluded area of the custom map (somewhere inaccessible) would solve that problem. - Nelson "The Griffin" Hicks |
When viewing large areas and/or lots of entities, the bottom portion of
the screen becomes garbled but there are not grey areas. On the
screenshots below, the average visible planes = 65. | The number of polymodels must be kept to a minimum. I stumbled across the console command r_polymodelstats, which shows the number of "polymodels" visible at any given time. this includes items such as weapons, ammo, and health boxes, as well as the weapon model that the player carries in from of him. The instant this count went over 20, the effect appeared. the solution: reduce the number of "polymodels" by removing extra scenery. Remove some torches and make the ones you leave in brighter, for example. This number was consistent for me in my map, but it may vary depending on how much or how little architectural detail is in your map. I wouldn't be surprised if it's always 20, though. - Ernie Miller |
| I've been having lots of experience with the problem where the texturing in the bottom portion of the screen gets screwed up, and discovered a new solution: It isn't always related to R_POLYMODELS. At higher screen resolutions it can happen in quite small areas with few surfaces visble, usually when a health box is somewhere in view. Solution: don't run at higher resolutions. At the default 320x240, the texturing problems just don't occur. At 640x480, they crop up constantly. - Sonya Roberts | |
| MAP layout: Two simple rooms connected by a short hallway. Grey
areas replacing textures in places. - Ran r_maxsurfs and r_maxedges and both are well below 1000 and 2000 (about half) and the figures are the same for the opposing room. Ran r_polymodelstats and got figures around 30 to 50... But after turning off r_drawentities (0), (ie: turning the entities off,) the grey areas disappear completely and the normal appearance is restored. (apart from the consequent absence of any monsters or torches). Also, if the screen size is decreased (not resolution---then the problem is still apparent), the grey areas disappear. | The level may have a leak -- In that case, you'll want to find it and fix it. Another problem might be the number of entities you have in this "simple" level. I'm not entirely sure, but the Quake engine probably has some trouble drawing a large amount of models in a closed (or wide open) space. Check that you don't have a lot of flashing/flickering lights, too. As for the changing of screen size, this might make the grey areas go away becuase you're not forcing as big of an area to be drawn and redrawn each movement. The reason people decrease screen size is for added performance anyway, right? Last but not least, what are you running? A 486 or equally slow processor tends to have harder time with all aspects of Quake than, say, a P166. And if this is your problem, then I might recommend getting a whole new system -- chances are if you still have a 486, your entire computer's a little out-dated... - Noid=wm |
| packet overflow - warning message while playing game | This happens when there are too many explosions, monsters, or visible entities in a given area within the player's field of view. Reduce the number of entities (usually monsters or explosions) to solve this problem. |
| MOVETYPE_PUSH with a non bsp model - sudden error while playtesting level | Well, that happens when you assign an entity's "movetype" field to MOVETYPE_PUSH, but the model that represents that entity is not a brush model (bsp model). MOVETYPE_PUSH entities must be brush models... Sounds like you have an alias model with the wrong movetype on it. - American McGee |
| Shooting a certain area of my own map caused quake to crash. I checked my map file again and found an unbinded func_door entity right at the end of that file. After removing this entity I played my level without any errors. - Philip Poetter | |
| The editor I used (Quest) claims to have removed the scripts that are attached to brushes when the brush is removed. When I got this error I looked at the .map file and found several instances of scripts with no brushes attached to them at the entity portion of the file. Removing these unbound functions cleared up the problem. Be sure you delete what you think you're deleting! - Scott Benes | |
| When running a made map in Quake, under certain angles brushes (especially those connected to an entity, for instance doors or buttons) disappear. | This happens when you make a connection to the outside world by carving and then fill the hole again with an entity-bound brush; for instance, you cut a hole in the ceiling and refill it with a button; you can avoid this problem by carving not so deeply, so you have no connection to the outside world, or you can put a solid brush (not bound to an entity) over the hole. - Matthias Hoys |
| Vis the level as if it were a final Vis. Do not use -fast. - Nicholas Lawson | |
| Making Deathmatch level. It passed QBSP, LIGHT and VIS. Editor used:
THRED. Created info_player_deathmatch entities in several places, VIS'd the level and copied the *.bsp to the server and all clients. *The Problem:* Deathmatch players sometimes re-spawn from their dead body instead of a random deathmatch spawn point. Sometimes not. This gets hazardous to your health, when you re-spawn right in front of the guy who just blew your head off with a rocket launcher. Any ideas? | Make sure your entities for spawn points are placed a sufficient distance away from all objects IN ALL DIRECTIONS. When placed 40 units above the floor, they work perfectly. - Andy Makely |
| The level in which this error appears only appears in that one place, and
it is a "flashing error"--i.e: intermittant. It has a "peeling" effect: like the
textures are peeling away from their positions in binary space. This is
similar to the "Hall of Mirrors" effect from DOOM, but not identical. (see
screenshot.) Level in screenshot has been VISed at -level 4, so it's not a leak or an improper VISing. Fullbright. - Phil Hall | My guess and this is only a guess is that an improper set of clipping hulls was generated. (you are able to walk through an area you are not supposed to, thus the hom type effect). If for some reason the player is larger than a shambler it could happen. What you might do is insert a CLIP textured brush at the problem area, run qbsp again, and see if that fixes it. - Troy Mann |
| Compiles just fine, but gives this message in Quake: SV_STARTSOUND: NOT PRECACHEED SV_STARTSOUND: NOT PRECACHEED SV_STARTSOUND: NOT PRECACHEED (repeats indefinitely) The map runs, but the func_train is stuck in one position. The map is a Tricks & Traps candidate called Mother of All Spike Shooters. It is supposed to simulate a huge spike shooter that fires giant instant-gibbing spikes by "recycling" func_trains. There are 4 path_corners. The map was made in Thred. - Evan Thompson | I've had this problem with func_trains before and the problem is that you have the sound attribute set to something other than 0 or 1, 0 being no sound at all, and 1 being the ratchet train sound (blech!). I recommend 0. - Shawn Allen |
| At one particular spot on my level, I can look down a long tunnel. Quake
displays a icon warning with the word "RAM". The tunnel is just large
enough for a player to walk through and about 1000 units long. There
are perpendicular walls near the ends of the tunnel so the number of
non-tunnel polygons visible is very small. The tunnel itself was formed
by subtracting one 12-sided cylinder from another. Hence, its
cross-section is a 12-sided, regular polygon and it takes twelve
polyhedrons to make the whole tunnel. As a last resort, I reduced the number of sides to six and the problem went away. All the usual metrics, however, like looking at the tube with r_drawflat didn't reveal why this particular situation gives Quake such a major intenstinal blockage. Any clues? - Dave Wiley | When I shortened the pipe, my VIS time (full) dropped by 15 minutes! - Neal White III (ed. And in more detail...) You have a very narrow, very long tunnel to look down. There are a couple problems with this: 1. The tunnel is presumably textured, and Quake has a significantly tough time drawing distant, textured faces. I would definitely recommend shortening the tunnel, as the amount of memory used to texture large, continual surfaces (with increasingly reduced texture size as distance increases) is rather horrendous. 2. The portals generated by this tunnel are very akward in that they are of many differing widths (in order to accomodate the tunnel's sides), and they are, where the tunnel meets the rooms at either end, in excess of 1000 units long. Try a full VIS, and I guarantee that you will still get sluggish performance. SHORTEN THE TUNNEL!!! IT IS THE ONLY WAY TO SAVE YOUR LEVEL!!!! - Shawn Allen |
| What in the world can be causing the ram icon to appear and the
R_SPEEDS xxsurfs number to be scrolling at a high rate when 'standing
still' viewing a very benign section(s) of a map. There is no dynamic
lighting (I removed all the lights just to make sure it wasn't some sort of
buggy light entity, but that made no difference) or long tunnels or
anything else even slightly weird in those areas. - Neil Manke Here's the image. The section in the picture only has 1 plain wall behind it so R_DRAWORDER 1 reveals nothing but that. So Quake is not rendering a bunch of hidden surfaces. One thing that should be mentioned is those R_SPEEDS numbers, in the image the 4th number (172) "actual visible polys being drawn" is higher than the 3rd number (131) "total polys being drawn", are not logical and must hint at the prob. How can quake say it is drawing more visible polys than the total polys it is saying it is drawing? Also, loading the map files into another editor makes no difference. | And here is the corresponding solution... |
| I have a problem that I can't seem to find a straight answer for. I created
a new DM map that includes 4 DM (info_player_deathmatch) starts and
1 single player start (info_player_start). When I start up a server and
load my map, I appear at one of the deathmatch start points. I have some
lava and if I take the lava plunge, I end up respawning in the lava. This
will happen 3-5 times before respawning at another DM point. If I
continually repeat this, when I finally respawn at a DM point it is always
the same one (The 4 DM starts are in 4 different corners of this large
room -- the first time I start I'm in the NE corner, but the remaining starts
are in the SW corner). I ended up having other problems with this map so I shelved it for a while. The problem suddenly resurfaced with in a CTF game we were playing. We kept respawning where we died, over and over again. The other team thought I modified the server to make this happen. :-) Do you know of anything that can affect this? I assume it's map-specific as we didn't see this problem with other maps (same server). - Al Harrington | Apparently, if you have any (i.e. even _one_) info_player_deathmatch entities too close to a wall, it throws
them all off. I tested this and indeed it fixed the problem. I haven't tested how far away they have to be, but with my previous map I had the dm points in a corner, right against two walls. - from Al Harrington via HAL9000 |
| I have done NO carving or subtracting. I was designing some stairs
similar to e2m2's lift/stairs out of the GoldKey water area. One of the stair
pieces was there and not there, it was visible, but when I walked on it, I
would go into it and get stuck in it. I deleted the offending brush, started
the compile and got this tidbit: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! reached occupant at: ( 0, 624,-144) no filling performed leak file written to d:\quake\maps\tctf821.pts !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 3876 outleafs --- MergeAll --- 4826 mergefaces writing d:\quake\maps\tctf821.prt ************ ERROR ************ CanonicalVector: degenerate * QBSP did not build the BSP file - can't continue. The *.pts file was blank. - Anthony Distler | OK, here's a solution for a problem I've had, and I'm sure others have. It seems that after working on a map for a while, some of the brushes became non-solid, allowing the player to pass through. It was like a func_illusionary wall, but this was not the case. The brushes were not snapped to the grid. After snapping all of them to the grid, the problem went away. Before snapping the brushes, QBSP would report a leaf, and the pointfile would pass right through some of the offending brushes. - Don Riegel |
| MOVETYPE_PUSH on a non-bsp model That's the error that the server sometimes (really ocasionally) crashes with on my map. I'm using the Worldcraft QBSP, LIGHT & VIS. It occured a lot more when the level had 8 buttons but i removed them & the doors they linked to because 1. they slowed down DEATHMATCH play, 2. they crashed the map more often. - Brendan Ragan | All I can tell you for certain is that it means exactly what it says. You have some entity that has a movetype of
MOVETYPE_PUSH that is not a BSP model (so it is either an Alias model or a sprite); this is not allowed. Unfortunately since the game exits, you can not see which entity it is. You need to look for anywhere you are setting movetype. Maybe in a touch or use function? Sorry I can not be of more help. John Cash So basically, there really is no solution other than to remove the entities and/or any moving brushes that are causing the crash, which is what I had to do. Quake simply does not allow that in a game. - Reid Kimball after e-mailing J. Cash at id Software |
| I have an extremely large 32 player map that has what I call phantom brushes. These are brushes that WorldCraft seems to create whenever the hell it likes. I thought it was a carving error but maybe not. The brushes it creates go on forever in the game world. Previously I had one that went vertical and I had to move an area of mine so it wouldnt get in the way. Now I have one that runs horizontally thru a lot of rooms I have. In WC I can select the brush but it is only shown with the bounding box of red lines, no white lines (white on black background). The brush simply can NOT be deleted from WC. - Reid Kimball | And here is the corresponding solution... |
| NO FREE EDICTS | Jack Perdue's No Free Edicts mini-website |
| My map is deathmatch only. The error on the server reads : Find Intermission: no spot Object error in find intermission It occurs when the map times out. It seems like it is looking for the next level and gets screwed up on the change_level routine. This was my first map. Did I leave something out? | And here is the corresponding solution... |
| error: ifnot 4100(???) branch 23 client.qc : selectspawnpoint client.qc : putclientinserver (no function) Runaway loop error host_error: Program error -when trying to play my level after compiling in Qbsp | And here is the corresponding solution... |