You can kind of do it by selecting the texture (or one face with that texture) and pressing SHIFT+A. This is not the ideal solution though, as it selects all brushes with that texture, rather than all faces...

Depending on your needs though, that may be ok.

SHIFT+A is usually used to select all entities of the same type as the selection. 

i learn something new about gtkr everyday. :P
thanks, that will come in handy in the future. ^_^ 

When I try and compile my map with c:\..\qbsp gibmap1.map

I get the warning: no wadfile specified, any idea what could be causing this? 

AFAIK, GTKRadiant still doesn't add the WAD files you use to the map worldspawn. You have 2 solutions for this:

1) add the WAD files manually to the worldspawn entry of your map.
2) open the map in another map editor and re-save the map. I've done this with WorldCraft. 

Thanks I think I'll do it via wc. 

Im trying to use your TreeQBSP to compile a Q1 map. If i understand correctly all i have to do is add "-q2map" to the command line for it to spit out a Q1 map. However when i try this i get an error message "***ERROR 54: Line 6: Line is incomplete". I've tried googleing but no luck. Theres no entities in the map and i havint modified it in any way other then with gtkradiant. also theres no wad file specified.. not sure how to go about doing that

Any suggestions? 

the first thing i'd do it open up the .map file and see what is on line6.

there is something wrong with that line. if it's not obvious, then copy it and paste it here and i'll take a look. 

I sometimes get that message if I have converted the map back and forth between .map formats a few times.

Take a look at the worldspawn entity, does it look like this,

"classname"" "Worldspawn"?

just do a find "" and replace with " in a text editor if this is the source of the problem. 

Ok below are lines 1 through 13. with it like this i get the error "line 7 is incomplete.

// entity 0
{
"classname" "worldspawn"
"wad" "egyptsoc.wad"
// brush 0
{
( -320 320 320 ) ( -512 320 320 ) ( -512 -448 320 ) egypt/block06a 0 0 0 0.500000 0.500000
( -512 -448 352 ) ( -512 320 352 ) ( -320 320 352 ) egypt/stone01c 0 0 0 0.500000 0.500000
( -512 -416 328 ) ( -320 -416 328 ) ( -320 -416 320 ) egypt/stone01c 0 0 0 0.500000 0.500000
( -320 -448 328 ) ( -320 320 328 ) ( -320 320 320 ) egypt/stone01c 0 0 0 0.500000 0.500000
( -320 -192 328 ) ( -512 -192 328 ) ( -512 -192 320 ) egypt/v128-01c 0 0 90 0.500000 0.500000
( -512 320 328 ) ( -512 -448 328 ) ( -512 -448 320 ) egypt/stone01c 0 0 0 0.500000 0.500000
} 

you have there with the latest build of txbsp because I'm more familar with it as a basis than treebsp. It has the same support base as treebsp however.

I saved it as a test map, adding only a brace at the end to enclose the worldspawn entity, like so:

// entity 0
{
"classname" "worldspawn"
"wad" "egyptsoc.wad"
// brush 0
{
( -320 320 320 ) ( -512 320 320 ) ( -512 -448 320 ) egypt/block06a 0 0 0 0.500000 0.500000
( -512 -448 352 ) ( -512 320 352 ) ( -320 320 352 ) egypt/stone01c 0 0 0 0.500000 0.500000
( -512 -416 328 ) ( -320 -416 328 ) ( -320 -416 320 ) egypt/stone01c 0 0 0 0.500000 0.500000
( -320 -448 328 ) ( -320 320 328 ) ( -320 320 320 ) egypt/stone01c 0 0 0 0.500000 0.500000
( -320 -192 328 ) ( -512 -192 328 ) ( -512 -192 320 ) egypt/v128-01c 0 0 90 0.500000 0.500000
( -512 320 328 ) ( -512 -448 328 ) ( -512 -448 320 ) egypt/stone01c 0 0 0 0.500000 0.500000
}
}

and I ran it without the -q2map option and it compiled without a problem. It would seem that the option is no longer necessary to compile q2map builds, but that is just my inference from this test. 

You must use the -q2map option for maps in Q2 map format. However, from what I can see in the excerpts above, the face format seems to be mixed Q2/Q1.

There are paths in the texture names like in a Q2 map, but the additional values after the tex name are missing (like in a straight Q1 map).

Something seems wrong in the generation of this map file. As for the wad, you must either include it in the "wad" key in worldspawn (like you already do, but check file position) or have a wad file with the same name as the map file in the same directory (the default wad logic). E.g. "mymap.map" and "mymap.wad".

Dakza: If you wish, you can send me the zipped (unconverted) map+wad and I'll take a look at it. 

I used the replace feature in wordpad to deleate the texture paths... then i saved it in worldcraft.. for some reason if i didint some of the brushes went missing when i went to compile. then i just run it like a normal quake map. Works, but its an awful hassle. Plus i have some consern re not knowing whats going wrong.

ALso, how do you go about modifying entities in gtk? eg. adding targetnames and spawnflags and such. 

(shouldn't that be leaves?)

So there I am, happily polishing my effort for the SM40 contest, when all of a sudden I get 'Vis leafs 8684 exceed normal engine max 8192'. Bugger!

During this latest bout of polishing I have added about 12 brushes. I haven't seen this message before on this map so am somewhat surprised.

Am I right in thinking that vis_leafs are 'the sides of brushes that face into the map that a player can see'? For simplicity, I am assuming that we have a hollow cube and that it is made of six brushes, resulting in 6 vis_leafs. Each brush is six sided in the .map file but the player can only see those sides that are 'inside' the map when it is played i.e. the six inside surfaces of the wall, ceiling and floor.

I know about func_walls (from earlier posts) but my most numerous brushes that fit my simple scenario are all cave walls and ceilings. If I turn these into func_walls and place brushes outside of these to seal the map, am I likely to get some success in reducing vis_leafs?

I don't seem to get a vis_leaf count unless it's a problem and I have 5500 brushes in this map so I don't want major changes unless I need to.

Any suggestions? 

well, i don't know tons about this subject, but vis_leafs isn't the visible surfaces, that would be surfaces and marksurfaces i think.

anyway, i think the simplest way to reduce vis_leafs is to reduce the complexity of the vis data, so, for example, convert sticky outey bits into func_walls. 

The most common cause for that warning is a leak. Assuming you've already checked that, the "vis leafs" is the first of the two values that vis prints out at startup (can also be read from the prt file), the other being the portals.

AFAIK, a vis leaf is an empty volume inside the map that the player can theoretically be in, regardless of size. Each leaf borders either to solid faces or other leafs via portals ("doors" between leafs).

The more complex a map, the more leafs/portals there'll be and the longer vis will take processing it.

Due to a bug in most engines, the max # vis leafs is limited to 8k, otherwise the stack will be trashed and the engine will crash. This is one of the most common causes for an engine crash and it usually happens when trying to load a big leaky map.

In my engines, I've upped the limit to 32k and added a protection for amounts beyond that. Like necros said, try to reduce complexity to get down vis leafs. 

I want to ask a question that I wanted to ask a long long time ago.

How to make trigger_shooter work as trigger_spikeshooter? I mean it should start to shoot when player enters the trigger zone and stop to shoot when player leaves the zone of the trigger that is targeted at shooter.
So far even if I give it a targetname it always shoot, no matter where the player is. 

have you tried calling it a trap_spikeshooter? 

pulsar - although i've never used shooters before, i'm just looking at the QC, and they seem simple enough. Just hook a trap_spikeshooter up to a trigger_multiple (with "wait" set to the time between spike firings) and bob's your uncle! 

OK, something going on here that doesn't make sense to me.

I spent the morning clearing leaks: the map had all of its major brushwork in place and up to this point I had been using -nofill in Qbsp. I then ran Qbsp normally (about ten times), using each generated .pts file to clear all leaks and eventually running a quick vis all without problems.

Only then did I add my dozen or so brushes, all inside the sealed map. Does this mean/suggest that these few brushes pushed vis_leaves over the top?

I have since changed 200ish brushes to func_walls to see if this would make a difference, and it didn't.

Right now, I intend to retrace my steps from the pre-leakcheck map to see if I can recreate the problem: of course, I can't get the vis-leaf count as I go as I have leaks. Is this Catch22?

Anyway, thanks for your input. 

I understand what I say, I know that.
It seems I need to explain it more: trap_spikeshooter works exactly in the way you described, but it shoots too fast. It hard for player pass thru it without getting damage. Trap_shooter shoots slow (as I want), but it shoots always and triggering it just makes it to shoot faster (like trap_spikeshooter does).

So I want to know if it is possible to make it start to shoot only after triggering it and not from the time the has been loaded. 

the has been loaded.
the map has been loaded. 

I take it you are using a trigger_multiple to trigger the trap_spikeshooter, yes?

Just set the trigger_multiple's "wait" field to the time you want to elapse between spike firings. The trigger_multiple's default wait is 0.2 secs, so if you don't set it, the spikes will be launched at a rate of 5 per second. 

I haven't thought about it in a such way. I'm going to check it right now. 

AFAIK, you'll get the vis leaf warning also when the map leaks (which is the normal reason why the amount is so high). Having a sealed map with >8k leafs usually means >24k portals and then you'll have a fullvis nightmare ...

If you can't sort it out, send me the zipped map and I'll take a look at it. 

I have this 'system' that I use when working on a map: I compile regularly (like every 15 minutes) using Qbsp -nofill, and Light, which also saves the work done so far. Every so often I will save the WIP with a new name, in this case SM40_mw1.map, SM40_mw2.map etc. Occaisionally, I will try some major change that I am not sure about and will use the file test.map so if it doesn't work I can just dump it and continue where I left off.

So, I am moving a piece of terrain that is on a grid of 1536 x 1536 x 768 - this is big so I use test.map to try it out first. It's a success and I am so pleased that I continue leak testing (post 2969 above) and resolve every leak. Then I go and have some lunch.

When I come back I load the last map (SM4_mw9.map) and continue polishing. I add my 12 extra brushes, compile and... get the vis_leaf problem. WTF, it worked before lunch? But of course as we all know now, the last map I saved was called test.map and had all of my leak fixing in it - I had forgotten to save it with the usual series name.

Oh well, at least with the system I use, when I retraced my steps back to the last good map and then worked forward, as soon as I got to the need to move the piece of terrain I realised what had happened. Only wasted a couple of hours and now back on track, no leaks, full vised, so polishing continues.

There's a moral there somewhere...