quakeworld overflowing

[Batman!]ZFA[]

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]

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

[Spike]

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[]

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[]

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[]

anyone have any suggestions?

only seem to overflow with ezquake and not fteqw

[Spike]

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]

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[]

Were are using MVDSV 0.28 version

maybe should try newer version.