style 0, yes. As for the effects, I don't know. 

Just rewrite the code for the custom lightstyles so that style 1 is simply "m", rather than whatever it was originally - some kind of candle flicker I think. Then just make sure every light in your map has lightstyle 1, the only thing that won't be affected is minlight and sunlight as you say. You could then make an entity to do the flashing, but the best place to do it would be in StartFrame(). Just have a global for the time to the next flash. If time > that global + 0.1, reset style 0 and generate the time for the next flash. Else if time > that global, change style 0 to a bright light and wait. Otherwise do nothing. 

Of course, that sketch of the code doesn't include a thunderclap, which is a dreadful omission. Now, at first it may look a little difficult to include a sound, if you play it when you brighten the lights, then it might start playng several times, as most people have a high enough fps these days to have multiple frames in 0.1 seconds. Instead, make the sound play when you reset the light style to "m", that way it will only play once. This may sound like a compromise, but if you think about it, it makes more sense, as you see the lightning before you hear the thunder : - ). 

So there is no simple way to incorporate lightning and thunder in a quake map? I mean without coding, just using some "Teaching Old Progs.dat New Tricks" method? 

i think there might be a way, sort of...

but it wouldn't be random, it would only happen when triggered.

you could put in an ambient_thunder, this will precache the thunder sound, even though the entity itself never worked.

then, make a door with the 'noise' key set to the thunder sound, then you trigger the door and flicker the lights (have a relay to switch the lightning lights off again)

anyway, i was just fiddling around with an idea i had to make thunder easier to implement, but i think having to make mappers put all normal lights to a lightstyle other than 0 is probably annoying. 

You can have things triggered at random intervals with a lovely little hack. Make a big room with a gib spawner and a trigger_multiple with the hack to make it trigerable by anything that touches it. Set up the trigger so that it will sometimes be hit by the gib, but not every time. Then have it spawn gibs at a suitable frequency. Every time one hits the trigger, you get a burst of lightning.

In addition, wouoldn't it be possible to write a custom light exe(well, hack the existing ones abit) so that minlight and skylight also generate a lightmap for style 32, which is always fullbright wherever it is hit. Combine this with the above and a single switchable light(which should be style 32 itself), and you'd have the whole package without modifying the progs. 

It is possible to light a map without minlight or sunlight ... i've done it. The trick is to use regular lights, some of which are up in or near the sky brushes.

Then you can set all lights intended to represent sky light to the same targetname. 

no matter what I do, my map looks almost identical to Sandstorm.

That's why they're only used one and a half times. :)

Try pairing them with some /stroyent textures. stroy_pillar2 and stroy_pillar2_alight are your best friends. Try something new with the lighting too - see if cool colors look any good with the orangy rust. 

Thanks.
That's what I was thinking about. Some flickering lights triggered by a trigger. The triggers could be placed in some chosen places to get the best effect.
I have a question about setting up the "thunder door". What should be the exact value of the 'noise key'?

The event could be also triggered by an semi-random logical gate. 

Not my own invention but I don't know where it comes from...

"classname"-"func_door"
"angle" "-1"
"target" "extranoise"
"sounds" "0"


"classname" "info_notnull"
"targetname" "extranoise"
"use" "train_wait"
"wait" "-1"
"sounds" "1"
"noise"-"items/armor1.wav"

This gives the door an armour sound when opening.

It doesn't work with thunder because the thunder sound itself is broken: not looped and therefore does not pre-cache. I think... 

Why did it truncate 'door' and 'armor.wav'? 

Set "sounds" to "5", and "noise" and "noise2" (IIRC) to the .WAVs you want to play. Must be precahced. 

How do you pre-cache sound from the editor i.e. no QC? (I think this is what Ankh wants) 

I was thinking that to pre-cache something you have to put it somwhere into the map. So I just have to put the ambient_thunder entity somewhere. I will try that out.
With Hammer it should be easy to set the sounds for the door. It has the required fields implemented with the fgd file already, I think. 

yeah, like i said, even though the thunder sound entity is broke, it still precaches the sound.

keep in mind that players will see that warning about non-looped sounds everytime they play your map. :\ 

What is a "skip texture"? 

Skip in other engines is a very handy texture you can apply to surfaces, and the surface is simply ignored at compile time, it doesn't get rendered or lit or anything. It's usually used for edges of scenes where the player shouldn't be able to reach, but that aren't culled when the map is built. If you try noclipping around some of the HL2 maps, for instance, you can see how the backs of buildings are entirely skipped because the player can't get to a position to see them.

Of course, quake doesn't have skip by default, but tyrann wrote a program that works as a good substitute:
http://www.planetquake.com/tyrann/files/skippy-0.0.zip
If you run this extra tool on your map, any face that has a texture named "skip" will be removed from the visible hull, although it will still clip, block visibility and so on. It's quite a handy addition to the quake toolkit. 

What does a Q1 mapper gain by using this tool? 

Preach, regarding your explanations, either skip textures sounds to be like clip texture, and maybe close to caulking method... or I didn't understand what you said... :P 

btw, what happens in q1 if you use clip texture only on one face? 

It is similar to clip, but there are some distinctions. One is that you can use skip on any face, if you had a brush with some faces clip and some not it doesn't work. Another difference is that skip brushes/faces are in fact solid to projectiles, whereas clip are not. This could be helpful for broken ground, as filling the gaps with skip faces will improve monster navigation over the ground. Of course, it also means you can't fire grenades through the holes in the ground, so it's not an ideal fix.

There are some drawbacks compared to clip as well. One is that a clip face blocks visibility for the vis program, even after it is 'removed'. So if you make a window with skip, even though you can see through it, the contents on the other side won't always be rendered once you run vis on the map. Another is that the whole skip brush is compiled just like a normal brush during the bsp stage, unlike clip which is treated specially. So the edges of a skip brush can clip away other faces, which is often undesirable as you can see through the skip. And the skip brushes will split surfaces, count towards clip nodes, and stuff like that.

A good way round some of the limitations of skip is to not use it on the world, but instead on other brush entities. The previous problems with a skip "window" can be avoided if you use a func_wall for the window, and just make all the surfaces skip. Another illustration of where skip might be useful is a complex shaped platform, or moving decoration or something, that is up against a wall. You can make all the backfaces that are never seen against the wall skip, and cut down the amount of rendering required. Plus some of the tricks in the progs thread use it. 

OK, thanks for these precisions... I understand better now the subtility.. :P 

Thanks Preach :) 

A mapper could gain: lower r_speeds by removing non-visible faces, moving ladders, statues (a la rpgsmse4) a one-unit thick trigger on the floor could be inaccessible until a given event by covering it with a a very thing func_wall skip brush. There's more. 

movable ladders can be done with clip brushes, as long as you make sure the func_whatever has visible brushes (hidden in the floor, probably) that extend to the edge of the model's bounding box in all six directions. RPG, you might notice that i fixed the ladder in SM69 this way. P.S. when's SM69 coming out? P.P.S. maybe we should rename it to SM666 or something, if you think we can get it done before the actualy sessions get up to the 600s. Or not.