Rune Central

I've played 2 -- maybe 3 -- single player mods or maps where I got "Packet Overflow". These were situations where using dead body filter wouldn't work.

ne_sp06 / Necros / Once Upon Atrocity: the final fight against the dragon where it shoots fireballs all over the place. Got several packet overflow messages. (In my book, and probably some others, this is one of the best single player maps ever).

fc1 / Fat Controller / Duke of Ontranto: the final map has about 40 monsters and the "Duke" in a single room and all hell breaks loose. No dead bodies, just lots of hell knight attacks, vore balls, ogre grenades, etc. About 3 or 4 times I got Packet Overflow leading to a Stack Overflow which kicked me out of the game.

Neither were situations where dead body filter would help.

Is there anyway to have JoeQuake a little more immune to Packet Overflow and Stack Overflow situations?

While they are rare and affect few maps, it seems to be the more cutting edge and recent maps.



http://wouter.fov120.com/gfxengine/panquake/

Source + Download: http://wouter.fov120.com/files/engine/panquake.zip





Just a compare and contrast, I have no clue the impacts of any of these variables/constants have on single player/multiplayer or if this is even the right place in the code for the Packet Overflow fix.

I think I have heard some other engines address Packet Overflow, but I don't want to use those -- JoeQuake is perfect

yea i know the current number is low, but i got some problems with changing them. Namely that it causes incompatibility with older engines. Like if you record a demo with MAX_MSGLEN > 8000 then it might happen that you are unable to play that back in an engine which only supports a max value of 8000. And this sux.

Compatibility is king.

I like the way all the changes you have done over time are cautious and maintain compatibility with everything else.

So ... if there is no good fix, I can live with it.

Oh Joe better maintain compatibility - or we'll ban joequake from SDA

On a related note, Bengt Jardrup has a tool (convdem) which (amongst other functions) can remove data from demos that have too long messages (recorded in some new fancy engine), thus making the demo compatible with other engines again.

http://user.tninet.se/~xir870k/

Seeya.

Would it be useful to create cvars for the packet lengths?

example:
cl_ext_packet_reliable {0/1}
cl_ext_packet_unreliable {0/1}

could toggle the 8000 -> 16384 and 1024 -> 16384 respectfully..?

Packet overflow at least doesn't crash a progs.dat (as many single player mods use, especially those with custom monsters), but it's unsightly to get those messages.

But when playing FC1, like I indicated above, I got an actual stack overflow which crashed the progs.dat and got a whatever.qc error. The client didn't crash, I got the single player equivalent of being kicked to the console. It doesn't sound like changing message length settings would prevent a stack overflow, would any of the memory settings?

(I only encountered the stack overflow once or twice and only on 1 particular map packed with monsters)

If I am correct, when recording demos JoeQuake forces FPS to be no greater than 72 and maybe it even forces a normalish host frame rate. Maybe make the message length settings forced to default only when recording a demo? (Or would changing those have adverse affects in multiplayer?)

I tested the upped settings online/ and while watching a demo.. but I think its more as the server sends out the smaller packets so its only benifit if both server and client use increased packet size.. seems i remember zmodem using 8192kb packets ? not sure what all the diff would be unless its doing a crc at the end of every packet
in that case i wold think that a moderate size would be usefull