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! 

I tried to testcompile an early stage of my first map.
I set up Necros compiling GUI 'correct'. I'm using eric w's tyrutils. But I get a qbsp error: MSVCR120.dll is apparently missing. 

There is a microsoft runtime my compilers need. DL link is under the download buttons at https://ericwa.github.io/tyrutils-ericw/ 

FTE+QSS split up the signon stuff, so unless a mod actually uses MSG_INIT then there is no limit - even with protocol 15 (although other limits like max static ents come in to play).
The singular exception to this is the svc_serverdata packet, which can still exceed 8kb whenever a mod/map precaches too many models or sounds (including filename lengths).
(its possible that this will break clients with proquake's mid-map demo recording code, but qss won't have a problem).

NQ's reliables are flushed in 1024 (or more if no longer vanilla) chunks.
If you try sending more than 8k to a vanilla client like proquake then you can crash that client... or server... other than that it doesn't really matter, it'll just take a little longer for the data to arrive over a network.
If its the local client then the networking code will just copy it all over in one chunk, so as long as an engine supports 64k there is absolutely no harm in 60k signon buffers in single-player.

However, protocol 999 with its bigger coords and angles will double the size of significant chunks of data. dpp7 will have the same sort of issue. Thus be sure to test with these, and try to leave a few kb slop for future bloat.
Or just simply tell everyone to use QSS/FTE and stop worrying about it. :s 

Thanks for the explanation on the sign on buffer. I know FTE+QSS works really well and the rain looks especially awesome! My concern is QS/DP because they don't have good solution to break up client/server packets. I know this map will never work with NQ or any MP focused engine and I am fine with that.

I am curious to know, why does the sign on buffer not change when loading a save game? Surely this is the same type of event when starting a map a fresh for the first time? 

I had assumed that installing Visual Studio 2015 for TrenchBroom (cause imma newb) would make Visual Studio 2013 unnecessary. I will see tomorrow if installing 2013 fixes the issue.
Thanks for pointing at the obvious!
I never look at that :D 

the signon buffer consists of 3 parts...
the first part is all the data generated by makestatic, ambientsound, or MSG_INIT.
the second part is the baselines, generated from the entities that have a model set after the second tick.
the third part is anything like the first part that was added after the server was spawned, and won't actually be sent to any client that was already connected when it was added - hopefully your mod won't be generating any of that...

loading a saved game works by loading up the map as normal then wiping out all the entities and replacing with the ents loaded from the saved game (hence precache mismatches being a thing).
thus the first part contains all the same stuff generated by the qc (assuming you didn't set deathmatch 1 just before loading...). the second part is also generated from the entities in the initial map spawn rather than the ones after that (which is kinda lame, but hey, at least the max size is known).
the third part is... well, its your fault if its there. it'll of course be missing in a loaded game, as will anything else you wrote to any network messages...

but yeah, the signon buffer is just a blob of network messages that get sent when clients connect.
My code avoids using it primarily so that clients can be sent data based upon the protocol extensions that said client supports (instead of requiring all to use the same), so its all generated on the fly, with a little extra code to avoid overflowing reliable buffers. Other engines could easily just implement multiple signon buffers and just switch over to the next when the prior one gets a little full.
You need this sort of stuff if you're going to have 32k+ ents... 

the signon buffer consists of 3 parts...
the first part is all the data generated by makestatic, ambientsound, or MSG_INIT
AD does not have much static stuff, but I have plenty of ambientsounds entities all over the map.

the second part is the baselines, generated from the entities that have a model set after the second tick
This is the stuff I have been converting to delay spawns via triggers

the third part is anything like the first part that was added after the server was spawned, and won't actually be sent to any client that was already connected when it was added - hopefully your mod won't be generating any of that
Is this third part all the delay spawned stuff after the map is loaded? Won't this all be added to the sign on buffer for a loadgame?

My question is, If I delay spawn a bunch of entities after the map has started, will they impact the sign on buffer for a savegame? If a map reaches the 64K sign on buffer limit, does delay spawning solve the problem or does it comes back later with savegame sign on buffer? 

that third part is basically sent to /dev/null in singleplayer or saved games.
this is a problem if you're delaying the makestatic or ambientsound calls.

for regular entities, delaying its spawn means that you'll have no baseline generated for that entity. this will result in less data being sent in the signon buffer, but you'll be increasing the data sent every single packet while that entity is visible.

by all means use movetype=movetype_none and nextthink=0 until the player gets close as a way to reduce cpu time spent in the server, but if you're just doing it to reduce the signon buffer sizes then I'd urge you to do that ONLY while your target engine's signon sizes are too low.
that said, if your engine has proper deltas (qw, fte, or dpp5+ protocols), then baselines don't really matter too much anyway. 

does delay spawning solve the problem or does it comes back later with savegame sign on buffer?

I think it solves the problem.. as Spike said, when you load a savegame, the signon buffer is based on loading the map from the beginning. It doesn't look like anything from the save game can get added to the signon buffer.

I also did a quick test to confirm this in ad_swampy, signon buffer on a fresh start is around 20K bytes, and loading a save from around 1/3 through the map has a signon buffer of 19880 bytes.