The client doesn't know about them, because they don't have a model set, so they aren't transmitted between levels.
If you are having trouble with your signon buffer being too large, the easiest thing to reduce is the number of entities which have a model set at time zero. Static entities count towards this limit, but the only thing you can do about them is remove some.
It's worth noting that things which have modelindex != 0 do in fact count towards this total. I managed to discover this when I tried updating the quoth code to use this code for teleporting monsters:
http://inside3d.com/showtutorial.php?id=171
The line of code which hides the monster:
self.model = "";
is not enough to stop the monster being sent in the signon buffer, and consequently ne_marb started overflowing. If anybody uses that tutorial, it is advised to add
self.modelindex = 0; just after that, a trick which triggers already use.
I suspect though that the map which is hitting the limit is already a quoth map, and so you can't code your way out of it. In which case, I can suggest one or two entity hacks which might save you...
The first suggestion I have is to make some entities spawn later than they usually would, so they are sent in an update after the signon buffer. The candidate I'm thinking of is a func_wall, which is relatively safe to use. But be warned that it should not be done in the following cases:
* If anything is going to spawn on top of the func_wall
* If the func_wall is using an external model in quoth which wouldn't be spawned otherwise
* if there's some other reason that it needs to be in place from the start - don't worry about the player seeing it
Ok, so that's the plan, here's how we do it:
Change the classname of the
func_wall to a
info_notnull (hello old friend!). Give it the following keys:
self.nextthink = 0.2;
self.think = func_wall;
Can you guess what it does? It uses the fact that classnames are also functions (
http://www.celephais.net/board/view_thread.php?id=4&start=7981&end=7981 ) so that the func_wall initialisation is actually run as a think function just after the signon buffer is sent.
If you can't get enough mileage out of doing this on func_walls, you could look at doing it to other entities. Complex things like doors are probably a bad idea because the parts of the door have to link. You have to be careful that the spawn function doesn't do anything like precaching sounds or models, and you can't do it with static entities - they MUST be in the signon buffer.
Quoth is a bit more forgiving in this regard, as long as the model required has been precached by something during worldspawn, the actual attempt to precache it again later on is suppressed by the code. So you could do this trick on monsters for example - but then why not just give them the silent and teleporter flags, and teleport them in a second after the map spawns? It avoids using a hack to do it, and that bug about the signon buffer above has been caught and fixed ;-).