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 ;-). 

You are a legend, but allas - 'tis too late!

No fault of your own though, obviously, its just that i have weakened and folded.... 

the stuff i've seen you do without modifying a single line of code is godly.

been meaning to say that for a bit now... 

I agree and echo the sentiment, Preach. Your level of knowledge in the area of Quake is incredible. Thanks for always being so willing to help with questions and being so eager to share. 

See, I've been meaning to make a post on exactly the opposite thing - how to code things in such a way to defend against mappers hacking them.

Would people like to read that, or is denying people the fun of entity hacking just too much? 

I guess it depends. What would be your reasoning for preventing hacks? 

If you are making a mod which lots of mappers are going to use, but which isn't final - you may release a new version of this mod in the future, then you have to worry that all of the old maps will work in your new version. In an ideal world all you would need to maintain is the advertised features in your documentation.

Of course, the documentation of what you intended is never finished, and it can be hard enough just maintaining things as you add new code (see: quoth 2.0). If people start using "unadvertised features" in maps, then you can get stuck. You would like to make some change to something you thought was internal, but that will actually break the hack in some existing map.

So I guess the message here is that performing hacks in maps for id1 progs is basically safe because there won't ever be another patch for quake, 1.08 is the end. Since it's going to be unchanging, you can get away with a lot more. With a mod that might in the future. With a mod that might come out with a new version, you probably should colour inside the lines for the most part.

In my defence for suggesting the func_wall trick, it is actually surprisingly hard to break with a mod, since the features it uses (think, nextthink, classname) are all hardcoded engine behaviours. The only thing you could really do to wreck it is change info_notnull to set think/nextthink(which seems pointless for an entity designed to do nothing) or change func_wall to do something that isn't safe after worldspawn like precaching things. So I think it's safe to say that will work in future Quoth versions.