a - same as Q2; +/- 4096 in all directions.

b - I haven't encountered any such limit.

c - Dos/Winquake.exe has limits that are changable in the console. Otherwise the r_speeds limits are...

d - r_speeds are up to you. After a certain number you start getting artifacts in dos Quake and Winquake engines. If a mapper is conscious of r_speeds, he usually tries to keep it around 600-800, or maybe 900 at the absolute max. 

Go for it. You might want to check "no_intermission" on the trigger_changelevel, though. 

That looks funky neat.

As for terrain, I recently found a very easy way to do it, of course using the triangle method - but the way I used to try it was create a brush at a time, clipping it on one face into a triangle, Copying it, manipulating it and blah blah... I often ended up with wanked terrain.

Now what I advise is something like this, viewed from your Z plane, I'll try best as I can to represent it:

_________________
\/\/\/\/\/\/\/\/
\/\/\/\/\/\/\/\/
\/\/\/\/\/\/\/\/
\/\/\/\/\/\/\/\/
---------------

Each \/ and /\ is a triangle. Thus you have a wall of them. Drag 'em from there, and/or use varying sized tris, but keep this simple pattern generally. Hope that made sense o_O 

Great responses and thank you.

Jago
-Yes, I was referring to minlight (Arghrad for Q2 is -minlighta) and I am not a huge fan of the washed out look either but the question is whether that is a tad better than completely dark shadows in SP. This will be my first venture into the Single Player realm... Opinions?

-I am not locked in on the whole lava thing, water or slime would be fine but I am not planing any underwater routes.

R.P.G. - Nails struck firmly upon the heads, thank you. That info makes me a lot more comfortable with moving forward.

Phait - That is precisely how I am working it, that was / is the process I used in my Q2 terrain mappage.

I did not plan to turn this into a picture posting bit but here are a few more simply to demonstrate my "issue"

This one shows an all but finished small map, two major areas, about 21 critters to fight, 1 key to open the second area...

http://www.maricscabinet.com/m1a.jpg

When I add this section,

http://www.maricscabinet.com/m1b.jpg

I can no longer get the whole mess to compile, Tread (yeah I know but I am used to it) does not trace down leaks for Quake as it does for Q2 and Q3. I get the impression that the .map file is not being written when I have a leak after it has reached a certain size.


This third exemplifies what I am trying to do. I end up with 8581 faces from 1587 brushes, that is why I inquired about the limitations...

http://www.maricscabinet.com/m1c.jpg

I even tried the "unthinkable and threw a large box around the whole thing just to see if it was a leak, no joy there either. Thus I was of the mind to break it up. As parts of a whole the r_speeds are very decent, it is just very, very brief per part. 

I am not a huge fan of the washed out look either but the question is whether that is a tad better than completely dark shadows in SP.

I'd say completely dark shadows are fine, but this depends on the style of the map, and your own personal preferences. I used lots of completely dark shadows in could.bsp, but there weren't many, if any, in rpgsp1.bsp. 

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