turning the statics back into dynamics might add to the SZ_GetSpace problem (and/or packet overflows) as they then have to be updated to the client.

Btw, Fitz can handle up to 8192 edicts via the max_edicts cvar. Although I wouldn't recommend pushing it that far ... 

OK, back on-track. I had mis-interpreted what the engine was telling me. When I looked at the .qc files, the 'makestatic' entries had already been turned off. Therefore the GetSpace error was not in fact to do with the staticents but probably with the edicts.

Turning some of the different types of torches back to 'makestatic' allows the game to run in FitzQ.

I now have 121 staticents and 235 edicts. So, I guess that means no more torches and the like but bung a few more monsters in.

I will now carry on, shaken but not stirred. 

I'll look forward to aguirRe's and your next vis version for sure ! 

Is it more or less mandatory in QC to call setsize together with setmodel? I've noticed that if setsize isn't called on some mdls, then in some cases, the mdl isn't rendered properly by the engine; it sometimes disappears. This behaviour seems generally engine independant.

Specifically, there's a monster_rider in Malice that consists of one leg part and one upper body part. The body's size isn't set properly and in some of the maps, the body is sometimes invisible when it moves around. 

don't know about rendering problems, but every time a model is set with setmodel, the bounds of the bbox are changed to the max and min of the largest frame in the model, so if you don't reset them, then collision will get screwed up. 

Same problem with SZ_GetSpace errors.

I added to the monster count and was at 119 with everything working OK. But I added one more (now 120) and crashed out of FQ with GetSpace: > 8010.

Using your GLQuake 1.31 I can see in the loading log 'SV_CREATEBASELINE: excessive signon buffer size'. And it tells me that it is 8010 and the maximum allowed is 7998.

I have 121 statice ents, 427 edicts and 120 monsters, which is at least 30 short of my target.

My question is a simple, "How can I reduce the signon buffer size?" But I suspect the answer is not going to be staightforward :-(

This is not a revolutionary map by any means (except that as an FMB map it's all my own work!!) and I have already slashed it to the bone, but I would like to finish it to at least a half-way decent standard.

As always, any help or pointers you can give will be much appreciated. 

I made the last two monsters (119 & 120) into spawned monsters (spawned-in not transported), and it now runs in Fitzquake.

Can I somehow read the SV_CREATEBASELINE value to see what effect the spawning had?

Is this the way to go i.e. make plenty of the monsters spawn in after the engine has loaded and is running? 

is used by the server to build a list that represents the initial dynamic state of the map and this buffer is then meant to be sent to the client.

If the map contains too much dynamic stuff (e.g. monsters), then this buffer can't hold the entire list and the server aborts. The original buffer size was 8000 bytes, but due to a bug it can only handle 7998. I've increased that to 64k along with many other similar buffers.

As you've already noticed, delay spawned monsters usually help to cut down on the list size. This method is used extensively in e.g. Marcher or the recent JPL maps that utilize my variant of the old Zer trigger_spawn monster code. By spawning in monsters as the player is going physically through the map, the total dynamic load on the server is greatly reduced. Delayed spawning helps in the beginning and middle of a map and corpse removal helps in the middle and end.

There's currently no way in my engines to see the buffer requirements if it's lower than the old limit. Beware that some combinations of dynamic stuff (e.g. moving brushes) may cause overflow also during play or when reloading a saved game, even if seems OK at startup. My typical example is Menkalinan on Hard skill; try loading it with Fitz repeatedly and you'll see that sometimes it works, sometimes it doesn't. 

Thanks for that, I feel a lot better now.

I have had spawning monsters since the start of the build (Preach's "style" "1" code that I have adapted somewhat) but only used it for ambushes and return routes. I will now extend it.

I also have selective corpse removal (I didn't like the look of monsters sinking through overhead walkways) and numerous 'killtarget', more for tidying up than anything else, so I will review the further use of these.

On the one hand I am fedup with continually finding limitations within Quake (yes, I know it's ten years old!) but on the other hand, it's great fun learning new things about it :-)

Thanks again. 

You might try to contact the author of NetVis:

seanc ::at:: gearboxsoftware.com 

if anyone has been tempted to add Quake support to Q3map2 now that the code for it is GPLed. I build my maps testing for leaks with that compiler before compiling to Quake format, and the compile times are usually quicker. 

Quick question for a Quake 2 or Quake 3 mapper: when you vis a map in those games, I assume it tells you the number of portals. Are the portal counts similar to those for Quake? If possible, could you post the console output from a vis job for a large map?

I'm just trying to get some perspective on some of the different tradeoffs used in the Q2/Q3 vis tools.

FWIW, there are some nice optimisations in there, and I've already managed to speed things up about 20% so far. That's only testing with medium size maps though (obviously I'm not going to run 10 different benchmarks on JPL's map ;). 

Thanks for the tip. I might try contacting him once the QExpo stuff is out of the way. 

tonight for a large Q3 map, if no one else gets around to it, and I don't get distracted by some shiny object.

I don't really want to post it because it would just be a big bolus of crap in the middle of the forum. :) 

Thanks pjw. 

I sent the vis log for pjw3dm5, along with compiler/switch info; let me know if you need anything else. 

I noticed the vis time on that gigantic Q3 map took...six seconds. Is there a simple non-coder explanation for why vis takes so damn long on earlier engines?

700 portalclusters
1682 numportals
2736 numfaces
3364 active portals
416 hint portals
visdatasize:61608
Total visible clusters: 54658
Average clusters visible: 78 

I guess detail brushes help a shitload, now that I think about it.

I'll shut up now. 

Yes, I think it's the detail brushes mainly. numportals is the important one to watch - I'm dealing with about 40,000 numportals for my stupid map...

Another interesting fact: the "-fast" vis process on this map is so innefficient that the resulting visdata adds about 12MB to the bsp file size! 

Ok, my level is nearly finished, but now I seem to have hit upon a curious problem which crashes LIGHT if I add anymore brushes.

At the moment I can light the map only if it is less than a certain amount of brushes. If I add new brushes, I have to delete other brushes, so at the moment I am just disabling the clip brush visgroup when I export to map. This works, but soon I will run out of clip brushes to do this with, and actually rather like the map to have clip brushes.

Aguires light crashes straight away, but when I tried using tyrlight, I got an error, whgich was something like "bad face normal at x,x,x". Of course, this was on a compiled bsp, so finding the culprit was difficult, and I think it might be different every time.

BSP and VIS run fine without any warnings, and I have tried using other compilers, not using remove skip etc. all to no avail. If anyone has any idea what the problem is, I will be your best buddy for life!

Please help! Sorry I haven't clarified this more, I don't hve much net access time left. 

If you send me the zipped bsp, I'll look into it. 

shortly it will be done.

I love you, AguiRe! xxx 

I need a couple of people to help test my dm3 sp remake before QExpo. I have already sent the first beta off to some people, but would like a fresh set of eyes to look when the second is ready. Any takers? 

me! 

I'm in as well..