Point your face towards: https://tomeofpreach.wordpress.com/category/map-hacks/ 

There's also a thread on this board called "Teaching Old Progs.dat New Tricks." 

Thank you~

It seems like it has all the existing hacks? Is all working hacks going to get there, which are discussed on that thread "Teaching Old Progs.dat New Tricks"? don't know why but it seems to be pretty busy thread in overall. 

Logic gate triggers using spikeshooters are the classic way of having "triggered" triggers. I've used them several times with no problem. They do require extra entities and models to implement. 

And the idea of doing it with spikeshooters looks even more terrible when you can just use the neat solution linked in post #18192 

I had at least one version of a Radiant based editor that didn't get along well with the brush based info_notnull method, but other than that it has worked fine for me. 

Quake uses lightmaps, correct? Is it not possible to edit the luxel density? 

"_lightmap_scale" "n"
Forces all surfaces+submodels to use this specific lightmap scale. Removes "LMSHIFT" field.

I believe this is what you're looking for? its in tyrutils-ericw. 

requires engine support too.
and by that, I mean it only works with fteqw. 

It's only possible to control lightmaps globally, and even then only in one engine? 

Quake uses lightmaps, and the luxel scale is hardcoded at 1 lightmap sample per 16 texels.
Since you can control the texture scale in your map editor, this give control over the lightmap scale as a side effect of changing the texture scale, but you can't change them independently (in vanilla quake). Skacky's map jam5 map is an example using 128x128 textures and a texture scale of 0.5 (iirc), so it has double the normal lightmap resolution: https://www.quaddicted.com/reviews/func_mapjam5.html

The flag mukor mentioned, and some others in my light tool, are more or less FTEQW-only extensions 

Thanks, that makes sense. Do you have a Steam account? I have some more questions, don't want to pollute the thread with running dialog. 

Yep, I'm just "ericw" on steam. I wouldn't worry about posting here though, since other people may have the same questions too :)
(or http://celephais.net/board/view_thread.php?id=61211&start=701 if it's about tyrutils-ericw) 

I think I added you, found an ericw with negke on the friends list. 

How do you make noise gate or blocker in Quake1? 

Surrounding the monster... 

 

In this case ogres are patrolling and they keep making noises a lot, this area is suppose to be secret area and noises are kind of giving away that location. Should I try to give an extra box surround that area? That doesn't sound logical, right? 

give them the ambush flag, they'll be silent (I think) 

@Shamblernaut
They have ambush flag, but since they are patrolling their chainsaw scratches the ground. Don't know is there an another flag to remove that sound effect. 

If its id1, youre out of luck.

If its AD, check the "NoIdle" spawnflag. 

Quake doesn't have any clever way to muffle a sound by building extra boxes, you can hear them if they are near enough regardless of the geometry. So we need to find a way to stop the noise being made in the first place, here are two ideas:

If ogres are on patrol, they make a sound each time they hit a path_corner. One thing you could do is make it impossible for the ogres to actually reach their first path_corner, by blocking it off with a func_wall. Once the secret area is revealed, you can delete the func_wall and the ogres' patrolling will resume.

The second idea is to change the classname of the ogres to monster_ogre_marksman. There are a few subtle (and almost surely unintentional) changes to behaviour in an ogre when you give it this classname. One of the side effects is that it doesn't make sounds when it hits a path corner, so that might sort things in a single simple change.

While typing this up, I thought up a variation of the second method, which might generalise to other monsters in an interesting way. Time for a new map hack article... 

Hmm.. I tried that "monster_ogre_marksman", but it makes sounds as well. Maybe I will try out that func_wall and I remove them when player enters that area. 

They do make the grumbling sounds still, it only spares you the chainsaw dragging sound. I guess that teleporting them into the room once it's revealed isn't an option owing to the one-time noise? What about pseudo-teleporting them with rapidly moving platforms that drop them into place from a long distance away. That could be disguised I expect... 

Over the years the sign on buffer limit has been vexing mappers. There has been many good posts from aguirRe and Preach talking about ways to reduce the buffer and what it does. I know the limit has changed over the years with engines increasing the size from 8K to the latest (QS) 64k. I do realize that it cannot increase anymore without a different (999) protocol change and 64K is really the limit of protocol 666.

My latest map is hitting the 64K limit and I know there is plenty of ways I can reduce this with delay spawning entities. My question is there any advantage to really reducing the sign on buffer size down to a reasonable size? Once I have got it below the 64K limit is there any bad impact on the engine for loading a large sign on buffer maps?

One of the previous posts about the sign on buffer say that a quick/save after delay spawning will increase the sign on buffer. From my tests the sign on buffer seems to remain the same regardless of how much has spawned after the map was first loaded. The quick save/load does not increase the sign on buffer and I am wondering why not? In theory the save file should contain a lot more active entities since the map first started, yet the sign on buffer is the same!