quakeworld overflowing

Batman!]ZFA[ · Post by **Batman!]ZFA[** » Thu Mar 26, 2009 3:16 am

anyone know what causes overflowing in quakeworld?

seems to be totally random.

probably comes down to and issue with the client not reporting info correctly to server.

it could be just issue with thunderwalker ctf mod too.

Thunderwalker Revival Project
http://twctf.org

r00k · Post by **r00k** » Thu Mar 26, 2009 3:46 am

Packet overflows are caused by messages sent to the server too quickly. I'm not sure how this effects the client's /rate

Spike · Post by **Spike** » Thu Mar 26, 2009 3:20 pm

QuakeWorld clients only have a 1400 byte unreliable buffer.
if you send too much reliable data, the unreliable data cap is reduced for those packets (unreliable will be delayed).

In QuakeWorld, you should never use MSG_BROADCAST or the limitations of packet sizes/throughput will result in truncated packets.
Reliable writebytes can also have issues, tbh.

Use cl_shownet 2 if you want to see the data that is being sent. You might be able to trim it.

But yeah, you didn't say which buffers were overflowing.

Batman!]ZFA[ · Post by **Batman!]ZFA[** » Fri Mar 27, 2009 12:03 am

does it matter what rate the player connecting to server is using?

because we have that reset once they join server to 10000

Batman!]ZFA[ · Post by **Batman!]ZFA[** » Sat Mar 28, 2009 4:32 am

Here is what it shows from client

and from MVDSV server console

Client BATMAN!]ZFA[ connected
SZ_GetSpace: overflow: cur = 610, len = 946, max = 1450
BATMAN!]ZFA[ overflowed
WARNING: reliable overflow for BATMAN!]ZFA[
Client BATMAN!]ZFA[ removed

Batman!]ZFA[ · Post by **Batman!]ZFA[** » Tue Apr 07, 2009 1:26 pm

anyone have any suggestions?

only seem to overflow with ezquake and not fteqw

Spike · Post by **Spike** » Tue Apr 07, 2009 2:13 pm

Batman!]ZFA[ wrote:anyone have any suggestions?

only seem to overflow with ezquake and not fteqw

As a work around for some sort of overflow, fteqw caches its client commands and removes duplicate connection commands.
I don't rightly remember why fte does this.
But from your screenshot it doesn't appear to be the case here, but as ezquake doesn't show what its sending to the server, its not possible to tell 100% reliably.

Then again it might be just chance that FTE dodged it (disable high res textures or enable filesystem caching and FTE should connect a little faster).

Spike · Post by **Spike** » Tue Apr 07, 2009 2:33 pm

I added the dup connection command removal at around the same time I made fteqwsv no longer flush reliables.

From memory, mvdsv and other legacy servers flush the client's reliable buffer, and start afresh. But it writes directly into the reliables, so has no support from the backbuffers. Hence overflows are possible on the condition that the data is written entirely inside the relevent function in sv_user.c (as that's the only place that doesn't use backbuffers).
This may be the cause of your overflows.

Looks like its the first prespawn client command triggering it.

But I have no idea how FTE clients would be more resilient to this.
I can only think of how fte servers would be better than mvdsv servers, and that really doesn't help you. :P
Tbh, I do think its a server bug really. Its got to be. I don't even see any lightstyles.
But yeah, no idea why fteqw clients might be more reliable here. Its too long ago since I wrote any code that might relate to this.

Batman!]ZFA[ · Post by **Batman!]ZFA[** » Tue Apr 07, 2009 4:04 pm

Were are using MVDSV 0.28 version

maybe should try newer version.