I already discussed that point with aguirRe during "Castle of the Dark Ages" fullvis runtime (around 51 days ... remember...). I asked him about multi processors vis executable existence, and maybe re-coding vis sources to target multi processors platform... He told me that first releases of vis.exe (correct me if I misunderstood please) were able to support multi processors... but on Unix environment only.. It was used by Id initially..
And as most of PC have only 1 processor.... it was not really a "priority"... well.. It is well known that it would divide runtime by two at most (or more if you have more than 2 processors installed on your PC)...
However, I never saw multi-processor PC platform... except at office (..under Linux... exactly like Tyrann's PC, but with P4 3.2GHz, 4Go RAM, 180 Go HD, etc..etc.. )...
Maybe these high performances machines will become cheaper in the next coming years... and then a multi-processors vis tool could help... though.. 

So, the map won't load in Fitzquake but does load in a couple of other engines. So, I am using aguirRe's 1.31 and although the map loads and I can play, I get some weird effects like certain monsters not taking their shots i.e. I cant kill them but they can kill me!

Also, some monsters don't wake up until I walk right up to them AND blast them with both barrels.

One question for aguiRre direct: you say the GetSpace error can be caused by too many static entites, max 128. Does this mean 128 different entites or a grand total of 128? And what is a 'static' entity: non-moving models (torches), triggers, doors?

My Qbsp output says that I have 1296 entities (1013 of which are lights) and I have 111 BspModels. The monster count is 118. There are 10 monster types.

Looking at the figures, is there any benefit to getting rid of torches and braziers, and replacing them with lights?

I'm gonna play with some worms :-( 

Right now I can't remember in which case the engine aborted with a GetSpace error when having too many static ents, but I recall having that problem.

In any case, the static ents are just the ones that are made static from QC by calling the makestatic function. I don't think there's any check for if they're the same type; it's the # makestatic calls that counts. Calling makestatic also frees up that edict.

In my engines, you can check the current status by using the staticents command. It's hard to say from your description whether replacing torches with simple lights would help.

If you send me the zipped stuff (or better just a link if it's big) to reproduce the error, I can probably help you more. 

I already discussed that point with aguirRe during "Castle of the Dark Ages" fullvis runtime (around 51 days ... remember...).

Argh! You're scaring me :-P

I asked him about multi processors vis executable existence, and maybe re-coding vis sources to target multi processors platform...

Yes, I know how to do this now (at least on Linux, but I think I can do the same for Windows). I'll put it into my next version of rvis and I'm sure aguirRe will pick it up soon after that. It won't be 'til after this map is done though. 

Thanks.

It seems to be a question of 'sharing'. I have 200 static entities, which is 72 too many. Max_edicts are 1024 in Fitzquake and your engine reports that I have 700 in my map.

So, remove 'makestatic' from my five models in QC and they become 'edicts', which will then total 900 with 124 to spare. Or does something else fall into the melting pot?

I'll try it later today anyway. 

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.