Unfortunately (1), it's a hack to get around a hack.

Unfortunately(2). Willem's idea doesn't work - have two brushes touching and set them to be a func_wall. One of the brushes is textured with wall_texture and the other is clip: the clip brush still does not block the player. I
The player probably won't do what I don't want him to do but because I don't want him to do it, I don't him to be able to do it either. 

Weird that it doesn't block the player. If you put a regular texture on it, is the wall there? If so, I'm stuck. 

Stupid idea, but, you could do it with a func_door or a func_wall, setting alpha field to '0'..; It will just restrict engine use to GL enhanced engine (e.g, FitzQuake, aguirRe's GL Quake) 

Errr alpha filed set transparency of the func_wall / func_door, then having a complete transparent brush, menas something blocking the player, but that can be removed ;) 

Have you tried a Skip-textured func_wall with a skip removal utility ( http://celephais.net/board/view_thread.php?id=60088 )? I used that for the void Hell Knights in Schismatic Ablation (768_lurker.bsp). I think RPG did this earlier in one of his RPGSMSE maps. 

Use a func_ consisting of a clip brush surrounded by a solid-textured frame that is inside floor and walls. There have to be at least two proper brushes to determine the volume of the entity, everything within can be clip. 

Ahh, so that's it! Needs real brushes to determine the bounds. OK, committing that to memory... 

Almost done with my map, and now I have this cave cellar with a brush diagonally.

It seems the monsters can see me as they start fighting me as soon as I'm in the apparent place. I checked the walls double but I can't get it sealed.
Strange because I copied it from the other side and there the monsters just wait as if that place is sealed.

Even three walls can't stop them?? 

Thanks for the pointers.

Provided all sections of the func_wall are created at the same time i.e. make the brushes, have them touching, change the relevant (middle) one to the texture_clip, then make them a func_wall; then provided the clip is bounded on two opposite sides, it works.

Unfortunately, it is not removable. 

killtarget 

The alpha trick needs "alpha" "-1", as 0 implies 1. 

Oh, I was not aware of that feature, I thought it was working like r_wateralpha, that has value in between [0:1] range. 

Doh, it's all so simple when you know how. Thanks. 

Full: 52.13%, Elapsed 47h59m, Left: 331h33m, Total: 379h33m, 12%

I've got patience, but 2days left and 14days to go is a big heap. 

MadFox u must reduce many things... map is not that big for so many vis time... :\ guess u got to many errors in map! tchak is much bigger and just take 2 hours...
something is wrong... i�ve got almost 8.000 brushes! 

My current map has around 3,000 brushes and will VIS in under a minute. Seriously, turn some stuff into func_walls or something. :) 

There are 318 errors, but for vising it never took that long. P4 3Ghz.

http://members.home.nl/gimli/QBSPLOG.TXT 

that�s your problem MadFox u�ve got to many outplaced textures!!! you should fix then all...

I use to have these kid of problems... now in my maps i always have 0 errors!!! this is very important for the compiler...

will give you a pain in the ass for 2 or 3 days... but will compile real fast, you will see...

last map i try to compile with errors was wbase... i ~had also a lot of errors~becouse of rotating peaces of map and gave me many errors... took me two days to fix then all but after that was all pleasure!!! :) 

That's a serious number of errors indicating lots of not-so-great geometry in your level. I would agree with Trinca here. Take a day or two and see if you can clean it up and get the error count reduced. I'll bet you speed up some after that since you won't have little cracks and slivers in the BSP anymore. 

Doesn't a mixed face contents situation even prevent the map from loading? Shouldn't be too hard to get rid of those.

As for the "healing point.." warnings, you should check your map for HOMs and clipping issues (nonsolid brushes). Use gl_clear 1 and set r_clearcolor to something salient - BJP's engine defaults to a bright red, for example. This way you can easily spot problematic areas.
The issues are most likely caused by floating vertices or deformed brushes. If there are odd rock formations for example, it might be better to build them from triangle brushes, for they are more flexible than cubes. 

It is also generated by very tiny brushes, like clip brush used for ladder, rather than using func_ladder when available... Generally not a big problem...

Mixed face content is more problematic, as sky/water/etc... could then become solid on one face... (particularly sky)

And now go map ;) 

Your need to simplify the map SOMEHOW.
Maybe make some things func_illusionaries. Anything you can make an illusionary will help.
You can make something an illusionary and put a clip brush over it so that hull 1/2 are simpler, and marksurfaces and clipnodes are less.

Your vis will go from 13 days left to 1300 days left in 650 days.

Remember - 90% of vis time happens in the last 10% of progress. 

Wasn't the map leaked and boxed? I'd really try to fix the leak, it will make compiling much faster, result in a more performant .bsp file and maybe even teach you new approaches or ideas. I always hate it but the feeling of having a "proper" bsp afterwards always makes up for it.

http://user.tninet.se/~xir870k/tooltips.txt has a lot of infos on leaks. 

Oh, you might be right. I don't see a message in that error log about a "prt" file being written.

Is the map leaking? If so, drop everything, full stop, fix the leak. It'll compile WAY faster once you seal it. 

Sorry, that sounds dumb. What I meant to say was ... is the map boxed because it has a leak? If so, remove the box and fix the leak. You're processing a ton of stuff that you don't need to be outside of the play area.