The Q3 support.

I've been wanting to use your BSP compilers for a while now, for the better error reporting etc... but since they did not import Q3 map files directly, I used DuBSP instead. (Got to thank Riot for his tools, too!)

I could have used a map converter before, of course, but you know how it is (ohm's law.. path of least resistance... )

Now that your BSP(s) have the same q2/3 importing as DuBSP, I can have the best of both worlds. 

I'm building a map for quake 1. After adding some new monsters and brushes I get error after launching the map in quake (winquake, joequake). The error is "SZ_GetSpace: 8024 is > full buffer size". I get this error only after switching skill to 2 (means more monsters). Please help! Do I have to remove some entities? I wouldn't like to. 

Take a look at my engines and the readmegl at http://user.tninet.se/~xir870k , they're specifically modified to fix this issue (and others).

AFAIK, the error is caused by having too many entities and events happening which cause the protocol between the server and client parts to overflow.

Typically this happens on higher skill levels since there are more action going on. The recently released Menkalinan had a similar problem.

I believe that either you'll have to cut down on entities or require a custom engine that has a higher limit. 

Found a serious bug in Light 1.36 that invalidated light data when using -onlyents option.

I've uploaded a new version 1.37 to http://user.tninet.se/~xir870k that hopefully fixes this.

Sorry for the inconvenience. 

Ok chaps, I'm having a spot of bother when it comes to deciding whether or not to scale up my terrain textures for performance reasons.

I'm aware that the whole issue of scaled textures is a bit of a salty subject around here. Should I go with the aesthetic and keep the rock textures at 1:1; or should I use *gasp* double scale and maybe squeeze a bit of juice out of the old nag? 

i really depends how carp it looks at 2x scaling... some textures scale better than others... best bet would be to experiment a bit... 

Also, it depends on how close the player is. If the player is kept 512 units away, then you would be more likely to get away with a scale of 2.

Also, I don't think you would get many complaints if the change in scale was appropriate and well thought out. Doing it randomly or on a global scale is a bit different. 

that I can't gauge an accurate reading of the wpoly's until I've fullvised the map (which I won't be doing until I've completely finished the map) so my question refers to a sort of "general case" scenario really. Those of you who have seen the early screenshots should have an idea of the extent of the terrain involved. 

Thanks. I guess a logical compromise would be to keep the flat ground texture at normal scale and apply double scale for the mountains - the problem is though, the player can walk over the mountain terrain at certain points, so I can't really avoid contact with the scaled textures all the time.

Worth bearing in mind though is that my only real problems with scaled textures are: a) the dynamic lighting issues, and b) the ugliness in software mode. Some custom engines have fixed point a), and of course in that case, point b) is irrelevant anyway. 

I'd say go for the scaled look, it'll reduce the effect of tiling if the faces are large. A good rock texture should tile without looking especially odd, but over enough repeats the human eye is good at noticing the pattern. I'd say that combine that with the performance boost and the positives outweigh the negatives. 

the best way I have found to avoid the pattern issue is to fire up Photoshop, use the filter/distort/twirl, and I recommend twice. Once clockwise, a second counterclockwise, so you will have three seemless textures that fit together to avoid repeats.

I would have just e-mailed you an example that I was working on over the weekend, but I have been having some problems with my e-mail. 

you want a rock texture to repeat over a large expanse, try making a larger rock texture. Say, 256x256. 

256x256 is still repeated 16 times over a 1024x1024 surface. 

oh, right, so i guess the solution is to make it 65536x65536. What was I thinking? 

No, that's just silly. The Quake map bounds only go to +/- 4096. 

I appreciate the comments :)

My rock texture is pretty big anyway (512x512) and I have decided to scale it 2x. I think it looks good even at close range actually :) 

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.