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) 

Hello!
I got trouble! Situation is:
Single map, originally gl quake (not any mode).
I think i put too many entities on map. Because when i deleting 1 the last i putted entity (item_health) - map is working. Error appearing when i try to load map.
Is the decision of this error whithout reducing entity counts?
Im not finished puting monster, items on the map and want to putting items till the finish the map. 

Use a better engine.
Or read the above conversation about signon buffers (aka: use a better engine). 

Hey, I love J.A.C.K. and have been getting back into mapping for Q2 as a result! So, thanks for that!

Unfortunately, I've encountered a problem with texture display in the 3d-view. I've posted details HERE: http://leray.proboards.com/thread/3857/jack-3d-view-textures?page=1&scrollTo=28859 including a screenshot and logs and so on.

Any Ideas? 

Have you tried pressing TAB key few times to see if you have set proper 3D mode in a viewport? 

Thanks, I wasn't aware of the TAB shortcut key; I'd previously been through those different modes via the view menu.
Changing modes just cycles through wireframe, filled (colored) polygons, whited-out entirely and then a greyscale looking version of filled polygons (as in the screenshot I posted) 

Hmmm...
I have 2 ideas you can try:
1) Go to Tools -> Options... -> "Game Profiles" tab.
There you'll find "Texture Format" dropdown. Switch it to "All" and reimport packs if needed.

2) Maybe something is blocking access to textures?
Quit all texture/wad/wal editors and run J.A.C.K. as an administrator.

Btw. can you see textures in a Texture Browser? 

Spike, tnx!
I setup client quakespasm and quake1 map loading very good! 

I know 666 is kind of the standard, but what other protocols have been used/are used? Is 666 specific to FitzQuake/QuakeSpasm? Do they just increase entity/bmodel/brush limits?/ 

The protocol was first released in Fitzquake 0.85 (2009 iirc).

There's some info here:
https://quakewiki.org/wiki/Network_Protocols
https://quakewiki.org/wiki/Fitzquake_Protocol

Do they just increase entity/bmodel/brush limits?
Pretty much, except not brush limits; the network protocols don't care how much geometric detail is in the map.
There are also some rendering things in 666 / other extended protocols, for example supporting the "alpha" key on bmodels (for making transparent glass) needs protocol support. 

i want a trigger_once (to1) (or a info_notnull hack with similar functionality) that kill a func_wall.

but only after an event (triggered by another trigger_once to2). so the player triggers to2 and to1 becomes active.
if the player hasn't triggered to2, to1 shouldn't be triggered. it should be inactive even if the player touch the trigger brush.

so:
player touches to1. nothing happens, to1 exists. func_wall exists

then player touches to2. to2 is triggered.

A) now, if the player don't touch to1, the func_wall keep existing, to1 isn't triggered

B) now, if the player touches to1, it's triggered and the func_wall is killed.

i need these two functionalities

an conditional, in other words

in hideous pseudocode:

if ( player.touch(to1) )
__if ( to2.istriggered() )
____kill func_wall
__else
____//do nothing
____//to1 keeps existing and isn't triggered
--endif
endif 

ok, i figured it out with post #3923 in this thread

the browser search function becomes a little slow with the +18000 messages in this thread