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. 

Spike, could you theoretically use the save game detection trick to restore those makestatic/ambientsound calls in the third part of the sign-on? Replay all of those calls back to the player on the frame that they load the save? Of course, you'd need some way to store in the save game which calls need to be made again, by e.g. keeping an entity around with the details of the makestatic call. 

when you load a savegame, the signon buffer is based on loading the map from the beginning
All my tests point to the same conclusions as Eric, if I delay spawn models they are excluded from the signon buffer (start and savegame)

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
I assumed there must of been a downside to reducing entities appearing in the sign on buffer and it seems this is it. So the client will send info on all delay spawn entities when they are within the portal space of the player? I assume once the player moves on to another area (with proper portal setup) then they are no longer sent? I imagine this extra frame traffic could be bad for MP but fine for SP? 

@sock
SV_CreateBaseline is called from SV_SpawnServer, this is the same function responsible for 'map' etc.
loading a saved game basically does 'map foo; deleteent ALL; loadentsfromfile'.
so yes, same as ericw - the signon buffer should normally be consistent over reloading games. The only exception to that is if some cvar screwed up your saved game, causing that initial state to get loaded differently (which may also affect model precaches, messing those up).

delaying an entity from getting its model will prevent the server from generating a baseline for that entity. nothing will be added to the signon buffer in this case, and both client+server will use some fallback baseline (all those fields set to 0).
NQ's networking sends a delta from the baseline in every single packet for every entity which is visible to the player entity, so if nothing else, you're adding modelindex and origin_z values to every packet for every visible entity (the other stuff is much more likely to change from the baselines during the course of the game anyway, or remain 0 like colormap, skin, or angles_x+z).

so yes, forcing the prevention of baselines isn't catastophic (and I'd say engines should do it automatically if they've no other way to avoid signons overflowing), but its certainly not ideal.

if you've a thousand monsters, you could try setting their baselines with frame 0 and angle_y 0, and reverting back to their proper values after. this will save a couple of bytes per monster with little real loss once they're angry at you. maybe also origin_x+y for 4/8 bytes per (especially if they're patrolling).

@Preach
you don't want to actually be just calling makestatic or ambientsound once the game has started, as noone on the server at the time will see them. you would need to use writebytes with MSG_ALL or something, THEN you could call the builtin. And yes, if you wanted to restore them after a saved game you'd need to detect that and resend.
Hence why mods don't normally use makestatic for corpses etc...
(side note: makestatic doubles up as a remove(), and writebytes are still as evil as they've always been especially when you have 16bit modelindexes and protocols that incompatibly change the svcs in question)