1.) The brush with the texture you want to change must be a func_wall, the texture name must start with +#, where # is either a number or a letter. The texture will animate in sequence of the numbers/letters, and when the entity it is applied to, it will toggle between animating the letter sequence, or the number sequence. In your example, you'd need a texture called +0light_whatever for the on texture, and +alight_whatever for the off texture. Put the +0.. texture on a func_wall, and target the func_wall to toggle the texture on/off.

2.) Changing the text must be done in the progs.dat. Check out client.qc line 162 and onwards. There are if/then/else statements for the various endlevels there that print out the text. You can add your own text there. 

Thanks, works wonderfully. 

There is a way to have the lift inactive until you power it on with a button in standard quake, but it's the mother of all hacks. It involves constructing a 'logic gate', which is a trap_spikeshooter aimed at a trigger_multiple with health. In between there are a set of doors that block the shot when they are closed, and let it passed when open.

Toggling these doors open and firing the spikeshooter activates the trigger at the end. That description is a bit vague, but no matter, because I have an example map! Download it from http://www.btinternet.com/~chapterhonour/lift.map , it shows how the logic gate works much better than my explanation could.
Try the lift before you press the button, then afterwards, to check it works right.

Also, I haven't forgotten about the floating zombie, but it's a little more involved than I thought. The func_plat uses the think functions to control it's movement, but monsters already hold the monopoly on think functions for their animations. It would be a simple hack added to the func_plat if you were willing to add an extra animation sequence to the zombie model, with the crucified animation in a framegroup - similar to the way torches animate even though they are static entities. Would that be a workable solution? 

I don't mind mucking around with the zombie model as long as I know what I'm doing ;)

I figured you could take the ability of other monsters to follow paths, and apply it to the crucified zombie as well.

Also your logic gate idea is kinda clever and interesting. I pretty much understood it from how you wrote it, but I'll give the example a look.

Appreciate the help! 

This is weird. I have a func_door with the name of plat1. I have a brush in front of it that is a gate, which is also a func_door with the name of gate1.

I have a trigger_once that is to trigger gate1 - which it does, but for some reason it triggers plat1 too! 

Apparently you have to check DON'T LINK - if the 2 func_doors are right against eachother. I still don't know why they would let 2 funcs_ that meet, to trigger eachother. 

Doors linking together so you'll only need one key to open a set of double doors, and possibly other reasons too. 

http://www.skore.de/Q3A_Electronics_skOre.zip

http://en.wikipedia.org/wiki/Digital_circuit#Logic_systems 

I'm messing around with HL textures in quake - I know some people will think thats sacrilige, but whatever...
Anyways, I have 2 questions

1) how could I darken the whole wad file in tex mex?
2) how do you get rid of the fullbright spots on some textures?
thanks alot. 

Some questions for ya :)

1.) Fastvis -- if I use this in a map that doesn't have cavernous areas, but maybe a moderate corridor or 2, might any software Quake users have grey-out issues? Also, I read somewhere through here I believe you recommended somebody use the parameters -fast -level 4 -- is that right? Or is -level 4 actually -full?

2.) Faces... heres what my process window reads:

9801 faces
1607 brushes
219 entities

I am apparently near my limit of entities (255 or 256). Um but generally, I have little details in the map - like floor trim, and inset lights and such, which will contribute to any VIS concern, regarding too many faces (as I read brush count isn't really the issue). Basically I am wondering, when might I want to start worrying about too many faces?

3.) Light -gate 1 -- I've read changing the gate can help issues with too many dynamic lights in one area or proximity. I have several warnings of "Too many light styles on a face" which I could fix manually if it gets excessive... will this just print to the player's console, and not crash the engine (software)?

Overall I am trying to be a little considerate of software users, as few as their may be. When I release all this I'm recommending Fitzquake though.

Thanks! 

2) how do you get rid of the fullbright spots on some textures?
thanks alot.

Select a texture, right click and choose "Brightness", then click "Remove Brites". 

1. Software greyflash appears because there are too many things in view for the engine's default values of the cvars r_maxedges and r_maxsurfs. Doing only a fastvis just increases this risk. Level 4 vis is what's usually considered a fullvis and you either use -fast or -level 4, not both.

2. I don't know why you think you're close to the edge with any of those values, but I can't see any obvious problems. Faces are a concern for vis, but it's better to look at the vis leafs/portals values for hints. Entity limits are usually much higher than your values if not each entity is unique, i.e. has its own model.

For comparison, Lun's recent huge lunsp1 has 2275 entities and 20900 faces. I don't think you'll have to worry too much about entity/face limits yet and when you do, you'll probably hit the edict/portal/packet limits instead.

3. The Fade Gate in Light is mainly for cutting processing time significantly with basically no losses. It has cut times by up to 93%, but typically around 50-75%.

The problem you mention is a basic limit of the Q1 switchable light styles; you can't have more than four on each face, including ambient light. You'll have to reduce the overlapping of switchables.

This can be done by e.g. brushes, linear attenuation or spotlight cone. Disregarding this issue will in the engine just cause bad lighting (depends on switchables setup) in that area, nothing else.

To help software (i.e. WinQuake) players, just follow the classic rules for good Q1 maps. Many limits are basically the same in most engines, soft or GL. Greyflash can be fixed by just increasing the cvars r_maxedges/r_maxsurfs to 99999 e.g. in the autoexec.cfg.

In my WinQuake (and other engines), most limits are raised so it's more of a performance issue, e.g. having 2000 shamblers attacking you in one big room will probably be a slide show ...

Maybe the easiest rule is to make full builds of your map now and then, check the logs for errors/warnings and make sure it's loadable/playable in the target engine(s). This way you'll catch problems early on. 

don't release a map that's only fastvis:ed or the mapping gods will eat you alive 

And cyBeAr -- well, I certainly hope I don't come across a VIS that takes days or weeks, mostly because theres only one computer and I'm not the only one that uses it - and also, no feckin' way am I waiting that long. 

come to think of it, how hard / unorthodox would you consider making a detail brush type that casts shadows? So a lot more stuff could be func_wall:ed and thus vis quality would improve and time lessen a _huge_ amount.

(always fullvis a release. And run around with software to see grey-outs. Even czg's terra6 has one greyout place in sw... :( ) 

> don't release a map that's only fastvis:ed or the mapping gods will eat you alive

No, that would just be Archos, the god of ancient hadware, outdated software, and pottery. 

Listen to the words that have been spoken to you.

If you really can't do a long vis in one session on your computer, then:

1. Use aguiRe's tools, I believe they allow you to pause the VIS job and resume it later,

or,

2. Ask some nice person to run the VIS job on their own computer. 

If you come across a full vis that takes days/weeks on a modern computer, you've probably done something totally, utterly, horribly wrong. Design the map properly. 

I've read aguirRe's reply, thank you.

I use his tools (what else is there to use?) and am aware of VIS save states. It's just I've read of people having huge, detailed maps that will take days no matter what. 

I don't know, but there are other aspects than reducing fullvis processing time, e.g. higher r_speeds and tjunction sparkles in-game (see also my ToolTips). Not to mention saturating the unique model limit (usually <200) pretty quickly.

And vis "quality" wouldn't improve at all, you'd just shortening processing time (which of course still is important). 

There are many excellent Q1SP maps that take days or weeks to process. Kinn's Marcher took about 140h to finish and several of necros' and Tyrann's maps required many days.

As more mappers want open and epic style, this trend is probably here to stay. If only I could find a cure for vis like the Fade Gate for Light ... 

I did say 'probably'. :D

I'm assuming Phait is not doing anything that is even close to the scale/complexity of Marcher. That's a pretty extreme example.

And with all due respect to Kinnecros, if you're doing something that is that far beyond the limits of the original game engine and tools, you have to expect that kind of grief. Personally I don't believe in 5000 poly Q1 maps.

That doesn't mean I won't play and enjoy maps like Marcher, but I do feel that stuff like that is excessively indulgent. 

I've read aguirRe's reply, thank you.

Good for you. I didn't. It didn't concern me. I was just trying to be helpful. Sorry.

It's just I've read of people having huge, detailed maps that will take days no matter what.

Well, that's not necessarily true. There are a few things to note:

Q1 compilers are fairly fickle and unpredictable. Your map may take much more or less time to process than you can reasonably expect, depending on the exact geometry/layout of the level. However, having said that...

Good vis blocking will probably cut down the VIS time of your level tremendously. You can have a complex, high poly level and still have a short vis time, if you are sensible (and a little lucky).

If you have a level which is essentially one or two massively open areas, with a lot of complex geometry partially occluding other areas of the map (or not!?), your map will take a long time to vis, and (probably) run like ass.

However, if you section off each major area very well (eg long/bendy corridors, water with no -watervis, etc) and guarantee that no large, complex areas see directly into other large, complex areas, you will keep your vis time under control.

You WILL drastically increase your vis time if you don't do this. Basically, if you have a complex room/area which has direct visibility to another complex area, your vis time will go up exponentially. So if you have a complex area which can see into another complex area which can see into another complex area... well, you get the idea.

Of course, this is just my layman's understanding of it, based on experience and only a little real knowledge. I'm sure if I've said something incorrect, aguiRe will call me on it though : ) 

No it's basically correct. The thing that maybe is the most difficult to intuitively understand is that visibility for vis/engine does not mean point-to-point, it's leaf-wise. If you can see another leaf from anywhere within the current leaf, it's considered visible.

Leafs are the many small or big blocks of empty air inside a map that's generated by qbsp, all separated by the portals.

Also, there's no obvious relationship between the vis processing time and the "quality" (i.e. low r_speeds in-game). One might even say that the longer vis runs, the more it fails to optimize the map (i.e. higher r_speeds).

Maybe the best way to understand how vis works, is to load a map that's fast- or fullvised in WinQuake, enable cvar r_draworder 1 and have a look around. This is how the engine sees the map. 

Insightful posts. I did know of the hinderances of long distances from area A to B and/or C, and so on. I don't have any areas that are reaaaaaallly long and open, so maybe I have disregarded a couple spots I could implement some VIS blocking, that didn't seem as problematic.

The thing about big, detailed maps is - it's like the new standard these years now. Kinn's work actually inspired me to start the addon I'm working on - and while no map is *yet* ;) as big in scope, detail still abounds and I might get a little more ambitious.