Nice bled of materials there. It looks sculpted somehow.

Maric, I'll make you a set of lava textures, if you like. 

cybear that was exactly the problem, but I ended up troubleshooting it with metl shortly after I posted this thread. Thank you both anyway :] 

Lava: to shamelessly blow my own horn ( fnar fnar ) - I'd strongly recommend the lava from the knave wad, which I think you already have. It has a grainier, more interesting look than the old fashioned 'gloop' look of the id liquids. It can also stand being used across larger pool surfaces without repeating so obviously. With respect to repetition, you can also use the HL trick of overscaling the texture to 1.5x1.5 and rotating it by an arbitrary amount, say 33�

Minlight: generally you want to avoid relying on minlight IMO. It's tricky. Lighting always is, espeically when you have the concerns of both gameplay practicality and SP atmosphere to realise. Quake likes pools of light and shadow, e.g. walltorches intermittently down a corridor or shafts of skylight interspersed with roof beam shadows. Always try to keep such things in mind when building - shadowcasting brushwork, such as aforementioned roof beams, are very useful.
From your editor shots, I see you have mostly cavernous stuff, and very nice at that. I'd recommend using walltorches and flames here and there. Use aguirRe's tools and take advantage of the _anglesense value which can be added to light entities individually. Setting it to less than 0.5 will blend the light from a walltorch over the surrounding rockface without showing up the edges between surfaces. Probably the best way to go, at least to begin with. Larger flames can be set inside brushwork braziers for occassional sharp shafts of light/shadow casting.

Map Size: several small maps as a mini-episode is absolutely fine IMO. The important thing for Quake is to not, as Jago alluded to, end up with the Half-Life design of intentionally dull, utilitarian locations that are no more than one place on the way to some other - probably just as utilitarian - place.
Build something in each map as a focal point of the design. It doesn't have to be big and it doesn't have to use a lot of brushes, it just has to establish the character of the map. Think of the maps in your episode as tracks on a concept album, or chapters ( ahem ) in a story. They don't contain everything, but they always contain something that contributes to the overall piece.
I would disgree with RPG about the intermission camera though. Seeing one's kills and secrets racked up at the changelevel is part of Quake and many players like to know this stuff. Only disable the intermission if you're going for a pseudo-seamless level transition, again a bit Half-Lifey. Dario Casali used one to cross from the outer town to the inner castle in one of the sections of his Prodigy SE. You need a very good reason to do a pseudo-seamless transition though, something dramatic which needs to be immediate and thus justify denying the player their glory score. 

I agree with kell on minlight being ugly. If you need to soften a pitch-black area, try putting in some dimmer lights to simulate ambient light. A low light value light will fill in a small area. A low light value light with a lower "wait" value (default is 1.0) to fill in a larger area. With the right balance of brightness and proximity to walls, you can fill in the area with some faint light that doesn't have a hotspot at the center. 

Why does a trigger_hurt brush (dmg 600) placed at the bottom of a pit fail to kill players consistantly on contact with it? What other technique can be used to build a Coagula-style void map?

If a trigger_hurt brush (dmg -5) does not incrementaly heal players on contact, is it possible to build a healing area similar to the one found in Q3DM10? 

placing a trigger_hurt at the bottom does kill the player (unless they have the pentagram or use god mode). you don't even have to set the dmg value that high. the higher the dmg the stronger the gibs get pushed back (ie. fly back up). the trigger brush has to extend over the entire floor of course.

negative dmg values painfully add to the players health - the max health amount of 250 can be exeeded this way. 

About the trigger_hurt thing, often enough, the player drops right through it and doesn't die, not sure why, to make sure it works every time I always put 3 or 4 of them one over the other, to make sure that at least one works... But there's probably a cleaner way to get it working every time...? 

the player drops right through it and doesn't die

This is due to the way Quake calculates the player's position relative to surrounding stuffage. Vertical movement calculation isn't as quick or precise as horizontal ( presumably because the rarity of vertical movement made it acceptable to skimp a bit ).

Simplest way to avoid this is to make sure your trigger_hurt goes all the way to the bottom surface; so when the player comes to land at the bottom they definitely fire the trigger.

The strength of the dmg needs to be high enough to overcome the armour/health combo the player could potentially have at that stage. I would have thought 600 would be enough.

As an alternative to this method of void implementation, I had necros add to Chapters the trigger_void entity. It will kill the player on contact, even if they have the pent, but without gibbage or knockback. It will also instantly remove monsters on contact.
Much more thematically accurate. 

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)