I always thought that this was related to the number of sounds that were being generated at the same time, and that when the maximum was breached, packet_overflow occured and the sound did not play.

I have areas of my map that are not generating large numbers of sounds but I get the PO message. I have a constant sky(?) howl, I have some water, no live monsters within the map (I have killed them all and have plenty of bodies), no doors/platforms operating, no nearby secrets, and I am not shooting at anything.

I am using Fitzquake. Any ideas? 

... and I have not yet done a full vis. 

It's not the sound overflowing, it's the amount of entities that are in view for the engine. Running a fullvis will probably help if the map isn't too open.

You could try one of my engines; they are specifically designed for this situation. Using WinQuake with the r_draworder 1 enabled, you'll see how much of the map that the engine thinks it has to render atm.

After fast/fullvis you'll see that less is in view and therefore r_speeds are lower and less packet overflows occur. 

So, too many bodies (and gibs), and uncollected ammo/health, and visable doors all add to the problem?

And sound, or not to worry about that?

Is there a countable limit? I know I can't account for the gibs but I can certainly move doors, ammo, health etc. 

it's the message traffic between the server and the client (normally both are inside the same engine process) that gets overloaded due to limited message size and throughput. This can also cause the SZ_GetSpace ... error which aborts the engine.

There is also something called visedicts (visible edicts/entities) which can cause flickering/disappearing entities; the normal limit is 256 and I've raised it to 4k. Normal max edict limit is 600 and mine is 4k.

Normally you "hear" when there's a sound problem; doors open silently or during a fight, some monster sounds get muffled or disappear entirely. This is related to two max sound channel limits which I've also raised.

As you can see, there are several "countable" limits and it can be tricky to estimate them.

Hopefully, these problems disappear after fullvis. 

I just would like to have further informations about compilation time for the two process, particularly concerning the running time ratio between fastvis and fullvis. If fastvis run 1mn, how time will run a fullvis process ?? Is there a precise ratio, or something like this ??
Thanks 

no, there is not.
if fastvis goes 1min, fullfis might go from 10 to 600 mins and more and less...
depends on how smart (vis wise) u built your level. 

I've just tried WinQuake and had no Packet_Overflow problems, so that is good.

I did find some Fullbrights that were not noticable in Fitzquake - that I can fix.

But I cannot jump so high in your WinQuake as I can in Fitzquake and this is important in this particular map. It is exactly 40 .map units. Are the engine physics different in this respect? 

Tried your GLQuake, also no packet_overflow problems. In addition, no noticable Fullbtights and the necessary jump is fine. 

Basically what Vondur said, although a longer fastvis usually indicates much longer fullvis. Conversely, if you've made a fullvis that took a long time, cutting down on the fastvis time will cut even more off the fullvis time (in percentage).

I also have a feeling that the higher the relationship between # portals/leafs is, the slower the fullvis will be. More than 3 often indicates a really slow session. 

AFAIK, I haven't touched the physics in either of my engines but I think I recall that there sometimes are small differences in what you can do.

Also, please remember that if you want the map to play well in normal engines, you must check them specifically. But using my engines during development can help with big maps, that's the basic idea. You can watch the console for warnings that indicate that you're exceeding some limit. 

Well, if I understood correctly, there is no way to anticipate what will be the running time of a fullvis with fastvis running time.. And the resulting ratio fullvis/fastvis is at least 3 times longer... hmmmm .. with my latest map I guess fullvis will take many hours... OK, thanks for these crucial information.. 

I was unclear. It's not the fullvis/fastvis ratio I meant; it's the ratio between portals/leafs which you see early in the vis printout. However, I can't substantiate this really, just a feeling.

AFAIK, there's no obvious way to precalculate the fullvis time beforehand without actually doing an extra run just for the estimation ... 

OK, I understand, I will see it "at time"... thanx 

I recall there were some attempts to implement Quake 2-like detail brushes into the Quake 1 compilers. Have there been any attempts at implementing Quake 3-like detail brushes (which are far more useful) into Quake 1? 

Those are already there. They're called func_wall. 

Don't be dense. 

1) func_wall's don't cast shadows

2) using an brush-entity in the same manner as detail brushes are used in Q3 will result in you exceeding entity-related limits imposed by the engine VERY fast. 

3) brush models are rendered very ineffeciently compared to world brushes, resulting in much higher wpolys, and other things like #clipnodes. 

Talk to a coder and he'll tell you the samething. You would need to rewrite the .bsp format to have Q3-style detail brushes work. 

what rpg said and func_illusionary works too.
as for the shadows, use antilight dammit ;) 

You would need to rewrite the .bsp format to have Q3-style detail brushes work.

I'm not arguing with that. But that's not what you said.

Funcs only work as a detail substitue in small, isolated places. And even then, they still add to the bmodel count and mess with the lighting if, for example, you want to make all your protruding light fixtures detail. It would likewise become impractical, or at least difficult and undesireable, to make all of the faceted psuedo curved architecture in a map funcs.
For e.g. a terrain map, Q3 detail makes the whole process easier to implement with vastly reduced compile times. Funcs are - take my word for it - not an option in this case.

Yes, detail isn't going to happen because of the bsp format, but that's no justification for declaring funcs a perfectly acceptable alternative anyway. Because in many cases, they're not. 

Yes, detail isn't going to happen because of the bsp format, but that's no justification for declaring funcs a perfectly acceptable alternative anyway. Because in many cases, they're not.

Of course they're not. But they're the closest you're going to get in all practical situations. I was assuming Jago was familiar with the limitations of using bmodel ents, and thus he could make an informed decision regarding when to use them and when not to. 

The fact that can sometimes manage to pull off some impressive geometry does not mean I am an engine expert :) As a matter of fact, I am pretty clueless when it comes to the inner workings of the Quake engine (or Unreal for that matter, even though I released 10 maps for that)... 

about bmodels and lighting. There is a place in my map where I have a brush model "fence" thing sticking up out of the terrain. Now, it had to be bmodel obviously, because you just don't want to go around arbitrarily jutting other brushes into triangulated terrain, but of course I don't get the shadows cast. Now I'm not too bothered about that, but I wondered if any light gurus (*hint* *hint* Aguirre ;) )had considered the possibility of making selected bmodels cast shadows. Considering how it would only seem to involve changes to the light.exe, and not to the .bsp format or engine, I was just wondering if it would be a theoretically possible thing to implement, or not.