does ogre_marksman do? 

void() monster_ogre_marksman =
{
monster_ogre ();
};


obviously something ID never got round to implementing 

rj: http://user.tninet.se/~xir870k/tooltips.txt has a whole part just about leaks and eliminating them. Good luck!

megaman: It's no different from an ogre but can be used to have infighting. 

rj: Quite possibly portal(?)-related. Try changing the shape of the brush in question or delete/recreate it (so it's moved to be bottom of the .map file). Maybe running QBSP with -hull # might give a hint.

megaman: It's a regular Ogre minus the wakeup sound who can infight with monster_ogre. Isn't spawned in Quoth. 

spirit, negke, thanks

i've been reading that textfile. the '-hull 2' option didn't seem to give any extra info; the pointfile just seemed to shoot up the wall instead (which was still solid to player & rockets). i've yet to try some of the other params but the '-leak 0' caught my attention; seems too much of an easy fix to be true.. what drawbacks arise from using it? 

BspEditor 0.95b:
File #1
7000+ brushes, .map file 70535 lines long, 3.542 meg, everything visible in editor.

File #2 - next saved version of #1
Added small number of brushes, .map file 70945 lines long, 3.564 meg, only 9 bruhes visible in editor, all Groups set to visible, Map Info says 9 brushes.

Any ideas?

No big deal as it was only about one hours work but I am curious. 

I had a ton of leaks similar to the one your describing in omlabx. The ones where they pass through a solid wall.

As negke mentioned, change the brush shape a bit and see if that fixes it. It may in some cases, and sometimes it won't.

But I found out the best guaranteed method to eliminate a leak like that is to place a hollow box around the brush on the outside of the map, where the leak is. It doesn't have to be a big box either, just enough to cover the bad brush up. 

cheers. managed to pinpoint it in the end by deliberately leaking another part of the map (so as to split hull 0 up & prevent the outsides from filling) then noclipping outside; turns out i could fall through the side wall and down into the level.. so built a bunch of brushes around it in a similar fashion to your suggestion and it seemed to work :-) 

Tends to happen when the centre point of the brush (an X in worldcraft) is near the edge of the brush. Splitting it into two brushes can help when you don't want to change it's shape.

In other news I've been getting brushes that delete their own faces on compile - they generally retain a few but some go missing, just aren't drawn so the map leaks.

Seems to happen when using 45 degree angles that intersect with others, usually I have to bracket the offenders as in Orl's solution - but in a limited resources competition I don't want to have to do that if possible. 

So that's where to look. Thanks. 

I've discovered that I'm no longer able to select brushes from the 3D view in hammer 3.4, no clicks register in that window. The 2D windows work fine, except that it's a pain to pick out overlapping brushes like that.

The biggest thing I remember doing recently is installing the latest catalyst drivers (running on a mobility 9700). Is it possible that installing these could have broken hammer? Has anyone encountered a problem like this and have a fix? And why does the cart on goldrush keep flickering, the new drivers didn't fix that either... 

What sounds like a classic WC bug - go into options and turn off hardware acceleration in the 3d window options.

I'm guessing that you had it turned on before but your previous drivers didn't conflict.

Hopefully that'll sort it out. 

Can anyone explain to me why a trigger_count needs to have a brush model, when it seems to me that it could be a point entity? The QC specifies it as needing one in the QUAKED line, but the code associated with it doesn't explain why... 

All triggers can be point entities as well. 

This may be fairly obvious but how do I get a func_door to light itself in the open position rather than the closed? I have a large door entity that I want to slide into the level but the default position places most of the entity in the void - therefore, it's mostly black when it slides into the level. 

Then check the 'Start Open' spawnflag. 

Damn it, I knew it would be something obvious. Thanks! 

Sweet. Even more brushes left over now... 

Yeah, it was the drivers, by going back to 5.x catalysts I managed to get clicking to work again. The option to disable hardware rendering has disappeared from 3.4, although if you uninstall your drivers then it does default to some kind of software rendering, where selecting things works again. 

I have the same problem and am forced to map without hardware accel, making the 3d view painfully slow on large maps. Visgroups help somewhat, but it can still be a pain. 

Half my problem with attempting to map on the laptop is dealing with the lack of hardware support, and the other problem is the interface is a pain. Oddly enough, Blender, a much more sophisticated and complex app than Radiant shows very little performance loss without the HW acceleration. The source of the problem could be what Bambuz pointed out some time ago that GTK is a slow api. 

Are there any "definite quake 3 custom textures archive" sites out there where I could grab most of the decent publicly available / free to use custom texture and shader sets for quake3? 

http://fyad.org/uz3f

^ The Wadfather is the best one I can think of (shortened for ridiculously long URL) 

Lets assume you a substracted a room from the world, added some details and then proceeded to work on other areas of the map. Now, let's say we go back to the original room and decide that we need to add some variety to the wall textures and the obvious way to do this would be: reduce the height of the original substracted room brush, place a new substracted brush using the new texture right on top of the old resized room.

However, we end up with a problem: the new substracted room brush is going to "override" and erase any additive brush details that were placed in the top part of the old room. Since the old room now has lower height, these details now find themselves inside the new room brush which we added later, meaning that the brush "creation order" of the detail brushes precedes that of the new room brush, meaning the new room brush overrides/erases any such details.

What do I do?