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? 

The client doesn't know about them, because they don't have a model set, so they aren't transmitted between levels.

If you are having trouble with your signon buffer being too large, the easiest thing to reduce is the number of entities which have a model set at time zero. Static entities count towards this limit, but the only thing you can do about them is remove some.

It's worth noting that things which have modelindex != 0 do in fact count towards this total. I managed to discover this when I tried updating the quoth code to use this code for teleporting monsters:
http://inside3d.com/showtutorial.php?id=171
The line of code which hides the monster:
self.model = "";
is not enough to stop the monster being sent in the signon buffer, and consequently ne_marb started overflowing. If anybody uses that tutorial, it is advised to add
self.modelindex = 0; just after that, a trick which triggers already use.

I suspect though that the map which is hitting the limit is already a quoth map, and so you can't code your way out of it. In which case, I can suggest one or two entity hacks which might save you...


The first suggestion I have is to make some entities spawn later than they usually would, so they are sent in an update after the signon buffer. The candidate I'm thinking of is a func_wall, which is relatively safe to use. But be warned that it should not be done in the following cases:

* If anything is going to spawn on top of the func_wall
* If the func_wall is using an external model in quoth which wouldn't be spawned otherwise
* if there's some other reason that it needs to be in place from the start - don't worry about the player seeing it

Ok, so that's the plan, here's how we do it:

Change the classname of the func_wall to a info_notnull (hello old friend!). Give it the following keys:

self.nextthink = 0.2;
self.think = func_wall;

Can you guess what it does? It uses the fact that classnames are also functions ( http://www.celephais.net/board/view_thread.php?id=4&start=7981&end=7981 ) so that the func_wall initialisation is actually run as a think function just after the signon buffer is sent.


If you can't get enough mileage out of doing this on func_walls, you could look at doing it to other entities. Complex things like doors are probably a bad idea because the parts of the door have to link. You have to be careful that the spawn function doesn't do anything like precaching sounds or models, and you can't do it with static entities - they MUST be in the signon buffer.

Quoth is a bit more forgiving in this regard, as long as the model required has been precached by something during worldspawn, the actual attempt to precache it again later on is suppressed by the code. So you could do this trick on monsters for example - but then why not just give them the silent and teleporter flags, and teleport them in a second after the map spawns? It avoids using a hack to do it, and that bug about the signon buffer above has been caught and fixed ;-).