headthump's suggestion will work, but it will only go down once. if you want it to keep going up and down, you will need to also set the toggle flag on the door, then put a trigger everywhere around the crusher, with a wait key of it's own that would be the approximate time the crusher takes to go from one state to the other. 

Mike: The alloc block full error comes from a brush with a face that is far too large for glquake to handle. don't know what the exact unit X unit amount is, but a safe bet is to just chop anything larger than 2048x2048 and go down from there until the error stops. It should be noted that this may also be caused by an invalid brush which Quake thinks has an infinite face, you can test for these by loading the map in dos or winquake and noclipping outside the map, the offending face will be pretty apparent if you take a good once around. 

Qbsp chops large faces up so I don't see how that would ever happend and I've think we've had this discussion before (although I don't remember what the conclusion was). 

is to just stretch the texture a whole lot, if it's in an area the player can't see (I've gotten errors like that just from using really big boxes to seal off the level using a non-sky texture) 

jesus crap! wtf is wrong with it?! when working on small brushes, selecting the right vertex is a pain in the ass... for some reason, clicking on one vertex will select another, and clicking far away from the brush will select another vertex... is there any way to change settings so that clicking on a vertex will select that specific vertex and not another one? it's nigh on impossible to create some decent organic shapes as it is. 

I wish I was home so I could get GTKRadient so I could be completely certain (anyway to get it running without one of the specified games being on your harddrive, btw) but if you look on the second toolbar down there is a set of buttons marked x/x y/y z/z this will change the screen that is the current one to reverse the given view so if you were looking from the front you are now looking from the back.
That should help, but I have a feeling someone may need to clarify, and please feel free to do so. 

so I could get GtkRadient up and running 

This happens in the lightmap code. Two reasons you'd see this:

1. you too much surface area in your map. Reduce the surface area, or scale up the textures (which reduces lightmap coverage on a surface.)

2. you have messed with the -subdivide option in some qbsp variant, and produced a single surface which is too big for its lightmap to fit anywhere in the memory arrays glquake allocates for lightmaps. You shouldn't be messing with -subdivide stuff anyway, becuase it breaks compatability with old engines (like quake.exe, winquake.exe) 

I don't play with scissors, matches or -subdivide.

Do you mean by "surface area", the amount of the 4096 x 4066 grid that is filled with a brush or brushes? Or is it the total surface area of each and every brush added together, on which light falls?

The point being that my terrain map (following the amendment suggested by R.P.G.) covers the full 4032 x 4032, and contains 32K triangular brushes. Height is only 0 to 1024 at present. And I have not yet added the Caves section of the map, which will add another 32K brushes.

At Brush Merge stage, the brush count will reduce to <8000 brushes but the grid area and the brush surface area will not change.

Perhaps a smaller terrain? 

Surface area meaning actual polygons in the game, becuase these are what consume lightmap space. Either reduce the terrain area, or scale up the texture on it (lightmap resolution is tied to texture resolution.) 

i know putting big clip brushes over complex geometry will reduce clipnodes, what about turning said geometry into func_illusionary? there's no clipping there, because you can walk through them... right? 

qbsp doesn't know what func_illusionary is, so it won't compile it any differently than any other bmodel. And, i'm pretty sure bmodel clipnodes do contribute to the total clipnode count. 

is there any way to trick qbsp into compiling the visual aspect of the brushes, but ignoring the colision part? so like, a bunch of ghost brushes? 

no, but in theory, qbsp could be modified to have that feature. 

nonono... thanks for the info though.

a clipping we will go, a clipping we will go... 

ways to modify qbsp hull processing for testing purposes. To get the effect that necros mentions, use the option -fill to make qbsp force fill the clipping hulls even if they leak. If they leak, they will be practically removed and you'll have to noclip to move around in the map.

This is especially useful in large maps that leaks, because otherwise the bsp probably wouldn't load in any engine. Please see readmes and ToolTips for more details on this issue. 

I often use your bspinfo tool to create .prt files when I have map leakage. I have never known it to fail to create a loadable map, even when the raw bsp (only qbsp used in the process I mean) wont load.

In fact some of the minor leakage issues wont even effect the size of the map to any substantial degree when a full -vis is done using your tools.

A big thanks for your setup while I am at it. 

I have a series of func_trains. As soon as the first one lands, I want the second one to go, and as soon as the second lands, I want the third to go, etc.. The only way I know of to do this is to measure the distance each train will travel, compute the number of seconds it will take, and then use trigger_relays with "delay" "x". That doesn't seem too bad until you realize that I have seventy-two trains.

So, any suggestions as to how I could do this in a simpler manner? 

Go work you lazy hippie! 

If you have leaks and still want to force a prt file for vis (not recommended though), you can use option -leak 3, i.e. only generate pts file for leaks in hull 3 which doesn't exist.

If the leak is in hull 0, vis processing time will most likely be significantly extended, since the entire outside of the map is also in the prt file.

I'm glad to hear you like the tools. 

the only thing i can think of involves custom qc. custents and hipnotic (i think) have new train code, lets you change speeds at different path_corners, fires targets when trains reach certain corners, and lets you set a 'duration' instead of speed, so it will take 'duration' amount of seconds for the train to go from the one corner to the other.
but no can do with normal quake...
and 72 func_trains? just... wow... 

I finally got my Orb and Stegosaur in Quake1 by managing the progs.dat with frikbot.

I got their health and dmg settings up, and to my surprise I could also change the intermission txt between the sequel.
Yes great!

But...
I suddenly got all levels on gravity 800, and I don't know what I done wrong. I used to seek it in World.qc but left it because it wouldn't archieve result.

What's gone wrong? 

I found it, there are several world.qc

Has anyone ever succeeded in creating a Q1level with the habbits of e1m8?
Looks a good speedmap theme to me. 

<pre>fdsfsd
sdf df</pre> 

if (self.model == "maps/e1m8.bsp")
cvar_set ("sv_gravity", "100");
else
cvar_set ("sv_gravity", "800");


that's the lines involving the gravity stuff, just change it to this:

if (self.model == "maps/e1m8.bsp")
cvar_set ("sv_gravity", "100");
else if (self.model == "maps/##YOURMAP##.bsp")
cvar_set ("sv_gravity", "##SOMENUMBER##");
else
cvar_set ("sv_gravity", "800");

and replace ##YOURMAP## and ##SOMENUMBER## accordingly.


ps, no preformatted text? bah. :P