Do you think there's a way to make zombies start off lying down and only "wake up" after certain conditions are met? Something smoother than a hurt trigger keeping them incapacitated (not least because of the pain sounds). I was just wondering considering that freak glitch where zombies sometimes don't get up again but can't be gibbed, either. Something to make use of? 

zombies use walkmove to get up, so while you could probably create some sort of crusher that squishes into them for 50 damage at a time and then stops above them, that'll both knock them down and prevent them from getting up. you can then killtarget the crusher and they'll be able to move again.

however, walkmove also includes a down-tracebox from 22qu above so you'll need your crusher to sit at least 24qu off the floor, which is also more than the player can step.
so you might need to make your crusher as a stepped-pyramid so that your player can still step over the sleeping zombie.

make it out of clip brushes and it'll be invisible. many qbsps complain at that though.
a train that moves to a single path_corner will do it (with a really long/infinite pause), there's probably some better way.

obviously it'll still keep playing zombie/z_idle.wav every 5.1 seconds... and flicker between $paine11 and $paine12 at the sameish time.
alternatively, AD has some proper feature for it... 

There's a way to make a silent zombie corpse which can be triggered to wake up using SUB_CalcMoveDone. The problem is that it's always solid, and also wakes up (without playing the animation) if you shoot it. So you'd need to build a skip brush shield around it which you killtarget, which is pretty much the same as putting a zombie inside a skip shell then hitting it for 25 damage at the start of the map. The skip shell prevents it from standing up, so you don't need to keep injuring it.

Anyway, if the marginal benefits of silence and waking up the instant you trigger it are worthwhile, the entity goes like this:

"classname" "SUB_CalcMoveDone"
"origin" "240 -64 56"

//finaldest must be the actual origin
/you want the monster to appear at
"finaldest" "240 -64 56"
"think1" "monster_zombie"
"use" "zombie_paine12"
"targetname" "reanimate"
"frame" "172"
"yaw_speed" "20"
"view_ofs" "0 0 25"
"flags" "32"
"takedamage" "2"
 

Thanks, guys.

Ineed, this only works in certain special situations due to the clipping/skip box thing, not for zombies lying around in openly accessible areas (=on the floor). For the spot I have in mind, however, the hack is just perfect. 

He's the best. 

Another noobish question that I feel has either been answered before and I'm too dumb to find or can't remember.

I know how to create custom stuff based off other entities using their model/modelindex values, but how do I make an info_notnull brush entity appear in the first place - visibly, that is. A function to get it started on the actual bmodel, like InitTrigger for trigger volumes.
Thought I could make a simple nonsolid prop that's doing something or nothing depending on the touch function. Problem is nothing shows up in game. 

You need to use a func_illusionary hack. 

func_illusionary has the problem that it makes the entity static straight after, so you can't make it interactive.

Probably the best thing to do is to use
http://celephais.net/board/view_thread.php?id=37116&start=36&end=36
to create a visible entity. If the "model" key added to your brush entity by the compiler is "*1", you need to use modelindex 2 (0 is no model and 1 is the world, 2 is the first "free choice" slot).

You'll probably need to handle any interaction in separate entities (e.g. killtarget this entity) - InitTrigger interferes with this trick, likely because it calls setmodel. 

What I mean is having a brush-based info_notnull show up in game like a normal entity would - instead of 'visually cloning' an existing entity in a point info_notnull. All in one edict if that's possible. It appears a brush info_notnull strips itself of its own model/modelindex properties unless if used as a trigger volume (the model=bbox part in this case). 

The trick does work with a single brush-based entity (referencing the modelindex of its own model). It is - like you suggest - when you turn it into a trigger that things go wrong, because the trigger is trying to do its own thing with the model code which interferes with the modelindex hack. If you didn't want a trigger, you'd probably be OK. 

To avoid a possible misunderstanding: I'm not using any trigger stuff, just mentioned it as an example.
I can't seem to get it working as a visible entity just like that, even if I make the info_notnull reference its own modelindex (unless I'm doing something fundamentally wrong and can't see it). That's why I thought perhaps there was some neat think function to run (in a similar way that InitTrigger that makes the bbox appear); sort of like "think" "func_wall", for instance, but without the hardcoded behavior this would add.

The weird thing is, I'm under the impression that for a while I had some floor bits show up just being brush info_notnull without any extra fields, but at some point during development this ceased to work. IIRC, anyway... 

If you add a brush entity with classname "info_notnull" it gets translated by the compiler something into this:
{
"classname" "info_notnull"
"model" "*1"
}
What may vary is the number after the * in the model key. What you want to do is add keys to that brush entity so it ends up like this after compilation
{
"modelindex" "2"
"mdl" "progs/player.mdl"
"think" "SUB_regen"
"nextthink" "0.1"
"classname" "info_notnull"
"model" "*1"
}
The tricky part is that you need that modelindex key to be 1 larger than whatever number the compiler decides to put into the model key. The numbers are given out in order by the compiler but if you delete other entities or do something to reorder them in the .map file it may change.

If you do all of that, you should get a visible entity which is only different from a func_illusionary because it is non-static and so can be killtargeted or given a use function. You can probably move SUB_regen into the classname slot and use a different think function as well. However, bear in mind that many other hacks (like the aforementioned trigger stuff) does break this hack, it's pretty fragile. 

We know its possible to make any item respawn, but is it possible to make power-ups last longer or shorter than the usual 30 seconds? For example a biosuit that lasts a minute, or a quad damage that's only 20 seconds. Can this be accomplished? 

Finally got it to work. Apparently the "mdl" field is crucial whereas "model" doesn't have to be specified in this case. This is different than with point-based cloning which got me confused. In game, whatever is referenced in "mdl" is copied over to "model" as well, so I set it to "*1" (or rather the respective number of the model) instead of player.mdl; either seems to work as long as the modelindex is correct. However, the hack also required me to set "mins" and "maxs" for the entity to be drawn. The "think" function, on the other hand, seems only necessary if the entity is supposed to be used further, e.g. for a touch action.

Playing around with mins/max/size/origin made me curious as to whether it's possible to customizable trigger sizes from point entities like in Quoth...


Orl: I briefly tried it a couple of years ago. If it is possible, then at least it has to be more complicated than simply calling "powerup_touch". You can replicate the visual effects like that, but not the actual powers. 

@orl, yes increase the nextthink to respawn,
```
if ((self.classname == "item_artifact_invulnerability") ||
(self.classname == "item_artifact_invisibility"))
self.nextthink = time + 60*5;
else
self.nextthink = time + 60;

```
and for each pwoer up theres a *_finished timer

this is in items.qc 

Thread title "Teaching Old Progs.Dat New Tricks" means needs to work with original progs.dat, typically via entity/think/field abuse.

It's a shame you don't play single player maps, some like negke manage to do seemingly impossible things in maps that work in original Quake. 

Is there a way to place a static corpse in vanilla quake? Like a 3D model of a killed grunt or something? Is there a way to add custom entities? if so is there a place that has models of dead grunts or enemies?

Thanks 

You can do a corpse in a map. Do a func_illusionary and set the model (like progs/player.mdl")and frame number (like 169).

In vanilla quake there is no way to add custom entities. 

Interesting, thanks. I'll have a play around :) 

So i create a brush entity, set it as func_illusionary, and then add the keys "model" and "frame" ?

Like this?
http://imgur.com/7bNARAr 

Create a point entity, set the type to func_illusionary and yes change the "model" and "frame" (it *may* be "mdl" if "model" doesn't work).

Like if you were creating a monster. 

(There are differences between TrenchBroom and Jackhammer. In Jackhammer, you create a point entity and change the entity type. I would assume you can do that in TrenchBroom, but couldn't swear to it.) 

Ah yep it works! great. Is there a place that shows the various model names? like gibs for example? 

Open up pak1.pak in Pakscape 0.11 and look in the progs folder. To find out frames, you would have use QME to look at the different model frames.

https://www.quaddicted.com/files/tools/qme31.zip

Without opening a model in QME, it's gonna be hard to pick the frames for most models as all the monsters have dozens of frames.

You also may want to set "angle". 

amazing thanks, that should give me everything I need to make some nice corpses...

I tried setting angle as -1 and rotating the entity but it doesn't seem to change the angle it appears at. Say I want the player model to appear lying on its back facing upwards - shouldn't angle -1 do this?