...give the entity an 'angles' field with value '90 0 0' that should work, otherwise muck around with the value numbers till you get the effect you want. I think the three attributes for the values numbers are <tilt> <null> <offset>

cheers! 

hey, thx.
this is a pretty cool trick that also works on all other models, like monsters, torches and flames (as you said), exploboxes, trap_shooters. rotating models like the weapons work, as well, but placing them correctly can be tricky. lava balls and air bubbles don't seem to be affected.
giving a teleport_destination stranges angles results in twisted view and controls for the player, as we already know. 

:) 

'Angles' works like 'mangle,' <pitch> <roll> <yaw>.

Using <90> <-90> <0> gave me a crucified zombie on his back, facing up, with his head pointed North and his feet pointed South. 

...if someone was to send me Kell's 'Labyrinthus' skybox for Quake I'd be ever so thankful. 

sunlight is cast as lightstyle 0, right?

... what about minlight?

in theory, you could make all normal lights be, for example, style 63, instead of 0. then code a thingy to flash lightstyle 0 every once in a while, and that would affect only sunlight and minlight, right? 

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