also is there a way of putting a clip brush that only effect monsters? Where did I hear mon_clip or monclip? 

There is no monster-only clipping in Quake1. I think that came in during Quake2. There are 2 clipping hulls in Quake maps and everything uses them equally. 

oh well. thanks anyway! 

If you set the angles key directly it should work, give it
pitch yaw roll

Also, isn't there a hacky way to emulate monsterclip using clip brushes as part of a func_wall? You need a regular brush tied to the same entity to make it valid, which you hide inside level geometry. Then the clip parts don't impede player movement/physics objects, but some glitch makes them count for monster navigation. Anyone remember what I'm talking about here? 

i think clip brushes in func_s do stop player movement. i'm pretty sure i tried that once, but it was a long time ago 

one trick is to put holes or gaps in the floor, which are too small for the player to fall through. The monsters use hull0 for navigation, so they will think they can't cross those gaps. 

The monsterclip by func_wall I posted above does work, but since it's a hack there are some big pitfalls. So far I've found:

* Physical movement by a monster is not blocked. Examples of this include fiends(etc...) leaping, and monsters dropping from mid-air onto the monsterclip.

* If a monster is stepping (that is to say changing height because the ground in front is slightly higher or lower) at the same point which it hits the monsterclip, it will penetrate it.

Although in some of these cases it sounds reasonable for the monster to enter the clipping brush, once one gets in, they are stuck as if they were spawned inside a wall. The fiend can escape by jumping again, but is still glitchy otherwise. So unless you use it sparingly, only in situations where these things can't occur, it's probably wise to avoid it.

Perhaps a good solution would be made QC-side. I've got an inkling of how it could be done in a clean manner, but I'd need to mess around a bit with it. 

i could have swore i had built an old school ladder that moved out of a func_door. 

fire brigade! 

Possibly not the best plan if your house is actually burning down. Phone would probably be quicker... 

phone was the course... 

With a trigger next to it that killtargets it when touched by player - who'll never even know it was there.

That's assuming you don't need the thing to permanently block monster movement.

In Quoth it'd be a togglewall, or you could use a skipped func_wall, or else a clip brushed func_wall which has visible brushes on the extents. I mean visible as in not clip texture, embedded in geometry, with the functional centre being clip. 

Isn't that going to block lots of other important things though, like projectiles, and light of sight checks made by monsters? 

But it's another solution. It could also be only 32 units high, which wouldn't block much, though would look wierd if it, with, say, a grenade.

Otherwise the holey floor would work as long as the monsters weren't jumping or flying. Or swimming ;) 

You could always use a clip wall with small regular brushes textured with skip at the extremes to stop it being glitchy and then kill it when the player gets close. That should work ok whilst allowing line of sight checks to work and projectiles to pass through.

Personally though, I prefer the tip posted by Metl, which I used in a couple of maps in the past - maybe even as far back as apsp1. I like that it doesn't block them movement of jumping or flying monsters, since I will typically want to use it to hold a sniper in place somehow. I may have actually made a small demo map to demonstrate this quirk of clipped brushmodels some time ago, so I will see if I can find it tonight.

Another way that requires no entities and will stop strict walking (no jump attack) monsters is to create a small break in the floor where you want them to stop. Monsters often have problems with floors that have a lot of holes in such as gratings because they do some kind of line of sight check to make sure there is ground below them. When there isn't, they won't keep moving forward. I think the crack only needs to be 16 units wide for it to work, though it needs to be a bit deeper than that. You could then cover the crack up with a func_illusionary if you wanted, though that is not neccessary, and would obviously look shit if a grenade fell in the crack.

Other suggestions include using a trigger monsterjump to fire the monster back very slightly (it may be worth experimenting with speed and angles here) or just embedding it slightly in the wall, which requires no extra entities but is a bit hacky and might not work in all engines.

All of these tips should work in vanilla quake. 

didn't notice metl had already posted the tip about using a gap in the floor. 

didn't notice metl had already posted the tip about using a gap in the floor. 

it was preach who posted the tip I said I like, not metl. Here are some links about the tip:

http://www.celephais.net/board/view_thread.php?id=37116&start=84 (my post about this tip)

http://than.quaddicted.com/files/invisBarrier.7z < the broken link was moved here...

http://www.celephais.net/board/view_thread.php?id=4&start=5611 (preach's previous post on this tip)

http://www.celephais.net/board/view_thread.php?id=37116&start= (tips and tricks thread... full of useful tips)

http://www.celephais.net/board/view_thread.php?id=37116&start=107 (monsterclip trick by preach... a bit scary sounding :) 

trigger_monsterjump with low values - height 10, speed 10. if you want it killable, use the info_notnull hack. 

"trigger_monsterjump with low values - height 10, speed 10. if you want it killable, use the info_notnull hack."

That's interesting. Can anyone think of why this wouldn't work? The monster might get stuck in a perpetual state of falling or something. 

monsters still go through their attack routine whatever state they are in I think. if they are being flung through the air I think they still attack.

Not 100% on that though. 

The problem you'd have though, I think, is that the monster will never get the message. Sure, they'd be rejected by the jump trigger but that will never get them to change their route. They'll just run into the trigger forever, looking retarded. 

i think clip brushes in func_s do stop player movement. i'm pretty sure i tried that once, but it was a long time ago

clip brushes in funcs work correctly, as long as they are inside the bounding box of the visible part of the func. Quake (stupidly) doesn't bother doing collision detection against other entities when those entities are outside the visible part of the func. 

Does work, I forgot that one.

I think I used it with 0 vert ~5 horiz once. 

or whatever it is (the cameras for the scores between levels), er, do they take up room in the signon buffer?