is available at http://www.planetquake.com/fatty , look in the downloads section. The problematic model is controlled by the srvomech.qc code. 

Can someone answer some q's about r_speeds

1. What is considered "acceptable" r_speeds ?
and wouldn't that be dependant on what system specs were being used? ie, wouldn't high r_speeds for someone on a lower spec machine, not be considered high for someone on a high spec machine, or have I missed the boat all together.

2.What does the info displayed onscreen from the r_speeds 1 command mean ?. Which (if not all) is the important one/ones to watch?

Also, in the Quake console commands file I have, and at "The Forge", it suggests that the following is what will be displayed when the r_speeds command is used

18.7 ms 422/263/127 poly 12 surf

but that is not what I get, I get the following

xx ms xxx wpoly xxx epoly 

xx ms is how many miliseconds it took to render that frame.
xxx wpoly is the number of polygons that is rendered from bmodels. (ie, the world, buttons, doors etc, and also ammo/health boxes) This is also the number that most people refer to when talking about r_speeds.
xxx epoly is the number of polygons that is rendered from .mdls. (ie, monsters, weapons, viewmodel, etc).

The xx ms xxx/xxx/xxx poly xx surf output is in software quake only.

As for what is acceptable r_speeds seems to be variable. In DM, some seem to get pissy if they are over 500. In SP, some think they should stay belov 700, others feel it's fine to go up to a 1000. I know I have sinned a lot on the r_speeds part myself, but what is done is done...
I generally think though that you can justify most r_speeds peaks if the visual gain is worth it. If you can make something excellent looking with 1100 wpoly, then let it be so. If you have made something that takes 1000 wpoly, but looks like crap, forget it. 

I know I have sinned a lot on the r_speeds part myself

[sarcastic comment missing]

If you can make something excellent looking with 1100 wpoly, then let it be so. If you have made something that takes 1000 wpoly, but looks like crap, forget it.

right on. r_speeds average and r_speeds high are different: if your SP map averages around 500 - 600 and peaks only briefly at 1400, that's just fine AFAIAC 

I have made a kinda big map and with a few more boxes Quake III Arena started hanging with "Waiting Snapshot...". I made my map in QuArK 6.3.0 and also put there some portals with "HINT" texture. When i go and check for holes it reports almost about every light. :(((( What should i do? 

if they are too high in a place where there is little or no combat, that is more acceptable than if you have too high r_speeds in a place with lots of combat, where the potential choppiness can hurt your player's ability to fight. 

With the faster machines we have now, doesn't that lessen the need to worry about r_speeds. I have a map which r_speeds (wpoly) "were" (I have adjusted it now) continually up around and above 2000, now, durung play I could not tell any difference between that area, and say, another area where the r_speeds were at a level that would be considered "acceptable" 600/700.
So,...I am just trying to get a grip on why you should worry about it, if it doesn't actually seem to have any effect, except maybe for those with lower spec machines.

I seem to remember a thread about this, but I think it was on QMap :( , I would have liked to have read that today, with my interest in mapping, and not purely as a player, like it was then.
Forgive me if my questions/reasoning is stupid, there's probably a good reason for that :) 

what about a map that averages around 1000 and peaks at 3000 in multiple areas? :o 

it'll probably run fine on recent machines. But very poorly on machines more than a couple years old. 

I put mine back to how it was, even if the r_speeds are not considered "acceptable", I can't see how not dropping below 150FPS at 1600x1200 could be considered unacceptable. Maybe on lower machines, but thats how it goes. I'm prolly the only one who'll ever see it anyway, so who cares. 

"Those arches you had gotten down to six brushes might end up being thirty after QBSP gets at them."

So what the heck do you do about it when that happens? 

(but if you hit MAX_MODELS you`re going to have to live with the thirty.) 

Do i have to delete some boxes or add some common textures to my map? 

"Those arches you had gotten down to six brushes might end up being thirty after QBSP gets at them."

Actually there would be zero brushes after qbsp is done with them.... 

Watch out for those epolys ! 2k wpolys is not a problem even for 300mhz cpu, but add 20 grunts and it significantly slows down . 

...it took me ages to get my head around that.

/me hugs Aardappel for his patience. 

I know that, but what do you do when qbsp is cutting things up in a retarded way (which I think is what the quote is saying)? 

changing the brush order in the map file. For example, copy, delete, and paste one of the brushes. This is something i've thought about, but never tried. 

How to create a changelevel on Return to castle wolfenstein with gtk-radiant ? P.S. :( thanks for help meltslime ;-)) 

I've tried changing that extensively and haven't seen any benefit at all for qbsp.

However, the face order in each brush is very important for how qbsp builds the map. That's why I added automatic face sorting to my compilers. 

To Fat Controller:
Ok, here you go. Follow the link on my website to the download: http://www.freewebs.com/shadowalker/

Note: This mod is always being upgraded. Adding items to the bsp should be easy with the latest upgrades to v1.6 Also, I'm trying to get in the custents mods.

To all:
For those who use quark. I have specialized runes that use bit flags. Within quark, you can use bits on spawnflags. How can I make my own set of bits flags for an attribute entry?

as 

changing the brush order in the map file. For example, copy, delete, and paste one of the brushes. This is something i've thought about, but never tried.

- this has actually helped me out a few times before, especially when working with large visgroups and exporting to .map/compiling only visible groups in worldcraft. got past a few errors that were solved by repasting stuff in pbrsp1 iirc 

Been dabbling a bit with the QC, and hey! I suck at it! What I'm trying to make first of all, is a chasecam of sorts. Now this thing that I've got already, it's called from PlayerPreThink() or whatever its name is, and the positioning bit of the code works like it should, (well, just about anyway) but the angle setting thingy like totally doesn't work.
The camera just points at seemingly random angles each frame and also locks the mouse down so you can't turn around no more for some reason.
Wondering if someone could help me a bit with what I'm doing wrong. Besides poining me to various tutorials.

The point here is to have the camera focus smack bang on the player. (the self entity in this case)

void() Chasecam_Update =
{
if (!self.camera) return;
local vector camera_origin, v1;
v1 = self.origin;
v1_z = v1_z + 192;
v1 = (v1 - self.camera.origin);
local float l1;
l1 = vlen(v1);
if(l1 >= 16){ //This whole if block is a bit dodgy I know
camera_origin = self.camera.origin + (v1 * 0.2);
if(CAM_LOCK_HEIGHT){
camera_origin_z = self.camera.origin_z;
}
setorigin (self.camera, camera_origin);
}
v1 = self.origin - self.camera.origin;
v1 = vectoangles(v1);

SetAngles(v1);
};

void(vector ang) SetAngles =
{
msg_entity = self;
WriteByte (MSG_ONE,SVC_SETANGLE);
WriteAngle (MSG_ONE,ang_x);
WriteAngle (MSG_ONE,ang_y);
WriteAngle (MSG_ONE,ang_z);
};



PLZ HLP KTHX! 

CAM_LOCK_HEIGHT
is toggled between true or false on an impulse.
When it is true, the camera remains at a fixed height regardless of the players z-position.
That particular bit works fine btw... 

<NotoriousRay> some of your vector stuff looked alittle borky

Yeah, that's another problem too...
I'll just admit right away that I have no goddamned clue as to what the two v1 = ... lines about halfway down are supposed to do, even though I drew some goddamned lines and wrote down a little bit of vector math even.
http://www.planetquake.com/greyvoid/dsc00247.jpg
(The poor man's scanner; a digital camera.)