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. 

You can make solid, moving invisible walls to slap metlslime with.

SM69 filename remains the same; although I'm thinking about changing the map title. 

could someone list all the sm chainmaps? I don't know exactly how many there are. Did sm40 ever get finished? 

See SM40 Contest Results thread: http://www.celephais.net/board/view_thread.php?id=28383

Change the DL link to http://rpg.leveldesign.org/files/mirrors/sm40contest.zip

Too bad my map died and scampie laughed at me. :(

Also, SM82 and SM32 are linked on my site, SM28 is on TEAMShambler, and SM36 is on Underworldfan's review site. 

some one send me some porn 

some one send me some porn 

Is there any info_notnull trickery to make a light_flame killable?

Just wondering :) 

There is, but it's a painful hack invovling modelindexes. Make an entity with the following collection of fields:
model progs/player.mdl
mdl progs/player.mdl
modelindex *theindexofflame2.mdl*
think SUB_regen
nexthink 0.3

It doesn't actually matter what model goes in mdl or model, as long as it's precached already, so player.mdl works well. The important thing is getting *theindexofflame2.mdl* correct. This should be the number of flame2 in the list of models(so you will need a regular flame somewhere to precache it). Every time you add a new bmodel to the map, it will bump the index of flame2 by 1, so best to do it right at the final stage, or you'll be correcting it all the time. Also, be warned that the correct index in regular quake may be wrong in other mods - even things like weapon patches.

You may find the command modellist in darkplaces handy for finding the modelindex, it prints the entire precache list in order to the console. 

someone mentioned a while ago that func_illusionary has special magical properties, and can't be killed like a regular func entity. I was wondering if func_illusionary is treated by the compilers as world or as an entity, and whether or not I can place them freely or have to worry about the precache model index getting full.

I am guessing it is an entity... I think they vanish when you noclip into the world anyway.

Would it be possible to treat func_illusionary ents as world in the compiler and have their polys compile into the world, cast shadows etc, but not split world polys or add to the clip hull? Would this be problematic?