I'm a bit scared 

It makes sense if you're reading posts from about a month ago in the thread. And yes, that would mitigate the issue a bit (although depending on how frequently you run the function some errors might slip by). In 1997 some might have objected that it slows down the game a bit on weak PCs, because it removes one of the optimisations in the physics engine. Doubt anyone would notice any more... 

We may have talked about this, not sure. I want to reproduce the light globe sprite in an info_notnull, because I've hit the static entity limit, but can't seem to find the correct modelindex. Air bubbles and explosions, sure, just no globe. Strangely enough, s_light.spr doesn't show up in the modellist, either. All thanks to makestatic? Surely, there must be away. 

I don't know about other engines, but fte has a 'precaches' command that should show give you the index easily enough.
note that s_light.spr will only have a modelindex if it was precached (and the order should normally be the same for any engine), so if its missing then that's because nothing precached it yet.
So make sure you have at least one light_globe entity otherwise you'll not be able to get a usable index for it.

Do be aware that any other entity changes might change the order spawn functions are called in (depending on your editor). Creation/deletion of doors/triggers/plats/etc WILL change your modelindexes too.
So you should perhaps consider knocking up some find+replace tool if you're going to be making a lot of changes.

Or just use an engine with higher limits. fte+dp shouldn't have any specific limit, while ericw bumped the static ents limit in quakespasm recently though I've no idea if there's public builds for that yet (if not, qss has a slightly higher limit). No idea about other engines.
That said, protocol 999 or dpp7 will cap out at about 2048 max static ents due to the limited sv.signon buffer size. Less if you have many non-static ents too, because baselines contribute to the same buffer. I could rant about how fte servers are immune to that issue, but I'll save that for another time...

If it insists on being invisible still, you'll probably also need to figure out some way to make sure that the entity is linked into the server's pvs nodes. I expect Preach has a tutorial for that somewhere, probably involving triggering a teleporter... I'm not sure if its actually needed though. 

Thanks, got it! 

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 :)