"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.) 

blah 

Does anyone know why a func_train (a small boat for the player) suddenly becomes invisible somewhere along the ride (always at the same spot) ? The object is still there, it's just invisible.

The func_train travels quite some distance (the end path_corner is way out of sight from the start), is there a problem with that ? 

back a little while ago, i tried to do something like that... a long ride with a func_train.

basically, i think it's something to do with the vis code.

func_trains only get calc'd at their starting point, and, as you know, func_s aren't drawn if they aren't visible... what's happening is your train is moving away, so that it's start point (the point at which the vis calc'd it's visibility) is no longer able to be seen by the player... therefore, quake stops drawing it, thinking it's no longer visible.

to get around this, either don't vis the level (heh) or remove vis blockers so that no matter where you are on the path, you can always 'see' the func_train's startpoint. 

there's just an inherent limit to how far away you can be from the starting point... :shrug:

oh, and what happened to the textbox font! it's all crayzeh! 

that doesn't sound right at all.

But, there might be a related problem. Vis for all bmodels depends on the visiblity of the leaf they are in. What happens when they are in more than one leaf? I think it goes by the leaf that the model origin is in. If it's a big model, that leaf might be outside the PVS, and other parts of the model might be right in front of you. 

is present also before vis is run. I also had a suspicion that vis could have something to do with it, but I can't see how when the problem is there before vis is run.

I've tried to reduce amount of objects (not many) in the area, block out areas beyond this point with a big brush, manipulating the path_corners to see if anything changes. So far, no luck.

The func_train is from the Custents package and therefore slightly modified. However, I can't find any documentation regarding this particular invisibility "feature" ... 

This occurs in czg01 as well. The "train" you ride into the exit also disappears when you have travelled some distance. And this is just along a straight line, so it would be odd indeed if it had anything to do with vis... 

you mentioning that in the readme. I have now tested extensively and I can only conclude that it indeed seems to be the actual distance between start and end that is the culprit.

Changing # path_corners or removing all visible obstacles doesn't seem to help at all.

Thanks for the info. 

interesting... i don't know why i would have thought it had something to do with vis then...

i stand corrected.

maybe it has to do with the engine itself? anyway tried this in modified engines? 

so far. It is the same behaviour using the traditional (non-Custents) func_train as well.