Rune Central http://runequake.com/forums/ |
|
Packet Overflow / Stack Overflow ? http://runequake.com/forums/viewtopic.php?f=9&t=873 |
Page 1 of 1 |
Author: | Baker [ Fri Sep 09, 2005 4:01 am ] |
Post subject: | Packet Overflow / Stack Overflow ? |
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. PanQuake Packet Overflow Fix? wrote: packet overflow / edicts size fix: I added this, even though it is unrelated to panorama mode: you can now have 16x as much entities/gibs on screen before getting packet overflow errors, and max edicts has been increased 10x as well. This means that on moderately fast machines, Doom-style many monster maps are now viable. To even further make such maps playable, you can run PanQuake with my quake-c mod which quickly removes gibs and corpses (after 5 seconds) which is included. Note however that for coop or dm network play all players need to use PanQuake, because these changes affect the network code. http://wouter.fov120.com/gfxengine/panquake/ Source + Download: http://wouter.fov120.com/files/engine/panquake.zip Panquake quakedef.h wrote: #define MAX_QPATH 64 // max length of a quake game pathname #define MAX_OSPATH 128 // max length of a filesystem pathname #define ON_EPSILON 0.1 // point on plane side epsilon #define MAX_MSGLEN 16384 //aard: was 8000 max length of a reliable message #define MAX_DATAGRAM 16384 //aard: was 1024 // max length of unreliable message // // per-level limits // #define MAX_EDICTS 6000 //aard: was 600 // FIXME: ouch! ouch! ouch! #define MAX_LIGHTSTYLES 64 #define MAX_MODELS 256 // these are sent over the net as bytes #define MAX_SOUNDS 256 // so they cannot be blindly increased #define SAVEGAME_COMMENT_LENGTH 39 #define MAX_STYLESTRING 64 JoeQuake quakedef.h wrote: #define MAX_QPATH 64 // max length of a quake game pathname
#define MAX_OSPATH 128 // max length of a filesystem pathname #define ON_EPSILON 0.1 // point on plane side epsilon #define MAX_MSGLEN 8000 // max length of a reliable message #define MAX_DATAGRAM 1024 // max length of unreliable message // per-level limits #define MAX_EDICTS 2048 #define MAX_LIGHTSTYLES 64 #define MAX_MODELS 256 // these are sent over the net as bytes #define MAX_SOUNDS 256 // so they cannot be blindly increased 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 |
Author: | Jozsef [ Fri Sep 09, 2005 4:55 pm ] |
Post subject: | |
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. |
Author: | Baker [ Fri Sep 09, 2005 9:37 pm ] |
Post subject: | |
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. |
Author: | Mandel [ Sat Sep 10, 2005 6:09 am ] |
Post subject: | |
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. |
Author: | sputnikutah [ Sat Sep 10, 2005 5:05 pm ] |
Post subject: | |
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..? |
Author: | Baker [ Sat Sep 10, 2005 7:49 pm ] |
Post subject: | |
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?) |
Author: | sputnikutah [ Sun Sep 11, 2005 6:52 am ] |
Post subject: | |
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 |
Page 1 of 1 | All times are UTC - 5 hours [ DST ] |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |