I had no idea you could use negative values to add health! 

It seems to be much easier to gib players with a trigger_hurt brush that is aligned with a regular brush (floor, spike, etc.) than it is to gib players who are passing through one sitting in empty space (falling, jumping, etc.). Can anyone explain this?

More questions. Is it possible, without QC, to use a trigger_hurt to increase a player's health without exceeding the 250 max or triggering the player pain reactions? Can the same be done for armor?

Thanks for the suggestion Bal, it's the best solution I have at the moment. 

Thanks for the info, your alternative sounds nice. =) 

Can anyone explain this?

See above.

Is it possible, without QC, to use a trigger_hurt to increase a player's health without exceeding the 250 max or triggering the player pain reactions?

No.

Can the same be done for armor?

No.

your alternative sounds nice. =)

see: He Falls Like Lucifer ;) 

...for the information. 

It is possible to perform a hack with an info_notnull that makes a trigger which will heal an arbitary amount, that follows the proper healing rules. The essense is make a trigger brush with type info_notnull, and the following keyvalues

think InitTrigger
nextthink 5
touch health_touch
healamount n

where n is the amount you want it to heal. Sadly I haven't found a way to make it usable multiple times. You could add multiple triggers, with targetnames heal1, heal2 etc. Then remove the think and nextthink from every trigger expect heal1, add a key "use InitTrigger " in all the triggers except heal1, and have each trigger target the next one. Not a great solution, and it's never gonna give infinite healing. I'll look into a way of getting round this, but it won't be easy.

(5 minutes pass)
Ok, it was easy, infinite healing triggers with just two entites are possible, although that chain method is still somewhat useful for finite, multiple heals. Here's the deal on making an infinite heal trigger:
Make a trigger brush of type info_notnull with the following key values:

think InitTrigger
nextthink 5
touch health_touch
healamount n
use SUB_regen
targetname heal1
target heal1reset

Then make a trigger_relay with these fields:

targetname heal1reset
target heal1
wait x

Where x is how frequently you want the trigger to reset, the rate of healing

One side effect of this hack is that you'll hear the respawn sound effect while in the trigger every x seconds, can't get around that yet. Anyway, better post all this before I get carried away looking for a fix to that. 

nice 

anybody got it?
could one use a trigger hurt to increase monsters health? That would be cool. 

At the forge. It's currently in a fgd.x format, and I'm not sure how to change that seeing as I am kind of comp-challenged.
how can I change it so that worldcraft will recognize it and allow me to use it? I promise I won't tarnish Zer too bad! 

Just rename the file so that it's extension is .fgd instead of .fgd.x
Then put it where your current .fgd file is. 

is limited to 256. I've hit the limit several times now. What doesn't seem clear to me is whether 256 is the maximum number of model types or actual models placed in the map. I assumed it was the former i.e. I can put any number of Nailguns in my map but it only counts as 1 model to precache.
Having added just a couple more walltorches since my last compile, I've hit the limit again. What gives? 

I always thought the same thing as you did, that any number of walltorches count as one model in the precache list, so I'm at a loss as to why the problem arises. You may want to look at running the map in darkplaces before and after adding the torches, as it has a handy command modellist that, yup, displays a list of precached models.

Since that one weak suggestion didn't really help with the problem, here's two things you might try doing to reduce the model count instead. One can be done without a mod, so I'll explain that one first. It's only useful if you have the same func_wall or func_door or something used several times in a map. Some kind of wall fitting moved to an entity to reduce vis times/speed or a regular design of door. You can in fact use the same single brush model several times within a map rather than making a unique one every time, by using an entity editor.

Essentially you just look at the first entity in the list to use the model you like, and take the model number from the .ent file. You then give every additional entity that same model, but with an origin of the displacement needed to move from the first entity to where you want the new one to go. I mentioned a similar trick in the progs thread for getting effects flags onto a door. The same problem that a door trigger will spawn in the wrong place for subsequent doors still applies.

Another difficulty with this is lighting, you'd need to be sure that the one model is appropriately lit for all the instances you use it in, from the position of the first use. Probably not easy. However, typing this up has made me realise func_doors and func_walls are not the best candidate for this treatment. The best candidate would actually be trigger brushes. If you have many triggers that can be served by the same sized brush, just use one model for them all. Since appearence doesn't matter for triggers, it's a nice safe choice.

The other way of reducing models would require a custom progs, and also boost the size of the map download a bit. It would be to literally combine some models, make them multipurpose. One way would be using QME, shrinking and hiding models within each other in different frames, and saving models that way. You'll also drive up polycounts like this, so it's a much more desperate move. At the very least however, you could combine the keys into one model with two skins, and make one gib with three(four with the zombie bit)varying shapes in frames for different gibs. Going further down the gib route, I'm sure replacing the heads of gibbed monsters with a generic gib blob wouldn't be so much of a crime if you're looking for savings... 

support more than 256 unique models (1024) and you can use the mcache command to see what they are. It's usually the amount of bmodels (triggers etc, listed as running numbers, e.g. *89) that gets you over the limit. 

for the comprehensive replies, guys.

Preach: aye, I wouldn't consider a custom progs as an option since this is an issue unique to a particular map and therefore I consider it my responsibility as the mapper to sort it out, instead of shunting the problem elsewhere.
The trick with using bmodels multiple times is...interesting, but tbh with the number, variety and complexity of what many of my trigs etc. are doing, I think I'd be teetering on the brink of mapper's madness before resolving the issue while preserving the gameplay satisfactorily.

aguirRe: yes, I've employed your GL engine many times with this map - 'tis a vital tool :) Good to know about the mcache command.

So it turns out my problem was a misconception - I wasn't taking bmodels into account because I'm still used to thinking models -> .mdls
That's a big fat D'oh! for me >_<

I'm modifying the map to get the bmodel count down, and also shaving out a few superfluous mapobjects ( how many corpses did I make? o_O )

/me retreats unto the void 

is that I think some editors sometimes attach brushes to point entities, e.g. trigger_counter. If your editor does that and you have many such ents, removing the redundant brushes might help getting under the limit again.

I forgot to mention that when using my engines, you'll also know how many models you actually have (you'll get a warning), thus hinting how much you need to shave off. 

I want to make a rotating room that starts slowly rotating but then accelerates... and eventually spins fast enough to be a convincing deadly force upon the player (if he were to touch it). Are there preexisting accelerating rotation entities? 

you could make a func_rotate_train or whatever that moves to pathcorners with increasingly fast rotation speed at nearly the same position. (the path corners need to be at least 1 unit apart otherwise it doesn't work) 

Proxy's Extra's QC; it adds a number of useful functions without much overhead -- a room like that may need a switch that rotates with the room! 

Pox's extras? 

late at night/drinking/STD's acting up 

WHAT DO I DO? : Wad file gfx.wad doesn't have WAD3 id 

sounds like you're trying to load the quake gfx.wad into half-life, or something like that. 

missing frame0 of +1basebtn

what's wrong, I loaded the right wad-file before compiling.
another one:

ED_ParceEntity: closing brace without data. 

1) AFAIK animation frames begin with 0; make sure you're referencing the first one and that all frames are in the wad. Qbsp will fix the rest.

2) Either the entity section is corrupt or you're using an engine that can't handle .cfg/.rc files that are not properly terminated with CRLF. QuArK often generates such files. You could try using this updated DataQ1.qrk file: http://user.tninet.se/~xir870k/DataQ1.zip .

It's for QuArK 6.3 and later, I don't know if it works for earlier versions. There are also numerous improvements for Q1 entities. 

I am using old compilers versions with new ones to gain my profit out of the maps I recompiled.
Some turn out right, others give the strangest errors I could forsee.
But thanks for your advice.