I have a platform that won't be useable until the power is turned on to full. It's actually a func_door, and I have a trigger_once inside the plat cage that will start the plat only when the player is inside it.

I was wondering if theres anyway to, once the power is on (a func_button or something) - it will make that trigger_once valid - but until then, it wouldn't work.

Otherwise I'll just have to make a func_door in front of the plat that will be open once the power is turned on. 

what bsp, light and vis compilers are the beautiful people using nowadays? 

http://user.tninet.se/~xir870k/

Compile utilities from Aguire aka Bengt Jardrup. 

muchas gracias. may your camel never stumble or fall. 

I've been searching around a few editing sites and can't find the answer.

1.) -- How do you switch a texture upon trigger? I have a set of lights that turn off, one by one (player passes through several trigger_once brushes), I'd like the light fixture's texture to switch to the less-bright light texture, once that particular light is switched off.

2.) -- Where/how might you edit the end episode text, or add such a thing to the last of a set of maps? 

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