Anonymous | Login | Signup for a new account | 2024-11-03 07:21 UTC |
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
0001469 | Zandronum | [All Projects] Bug | public | 2013-08-17 18:54 | 2024-10-30 17:40 | ||||||||
Reporter | __Lagger__ | ||||||||||||
Assigned To | Torr Samaho | ||||||||||||
Priority | high | Severity | major | Reproducibility | always | ||||||||
Status | needs testing | Resolution | open | ||||||||||
Platform | Microsoft | OS | Windows | OS Version | XP/Vista/7 | ||||||||
Product Version | 1.2 | ||||||||||||
Target Version | Fixed in Version | ||||||||||||
Summary | 0001469: Problem connecting to slaughtermaps | ||||||||||||
Description | Sometimes it is very hard to connect to a server with a lot of monsters, especially when the monster count is above 5000. The bandwidth usage while connecting to the server is at the max download rate that my ISP offers. Within a few seconds the console pops a message: "CLIENT_CheckForMissingPackets: Missing more than 1024 packets. Unable to recover." However, somtimes you do get connected. After you get connected the game will use 5-10% of my max download rate, sometimes even less! I'm very sure it never requires my max download rate during the game. Not even small spikes. Is there any variable I need to set to get connected? I don't care if I have to wait for 2-10 mins to connect to a server. Right now, it looks like the server tries to send a massive amount of data as fast as possible while it doesn't need to do so. I think I'm looking for a variable which lets the server know at what rate the client prefers to receive data... | ||||||||||||
Steps To Reproduce | Use a client with 10MBPS internet connection to get 100% drop. * Player 1 connects to a server and starts playing "Holy hell" MAP05 or "Okuplok" MAP01. * Player 2 tries to connect while player 1 is playing. * Player 2 is unable to connect. | ||||||||||||
Attached Files | Screenshot_2014-06-05-19-28.png [^] (254,473 bytes) 2014-06-05 17:32
| ||||||||||||
Relationships | |||||||||||||||||||||
|
Notes | |
(0007044) Frits (reporter) 2013-08-18 16:38 edited on: 2013-08-18 16:39 |
Pretty much so, even with a 100mbps connection I still fail to connect to some already STARTED slaughtermaps. Whilst people with a much more weak connection can connect/stay connected. Plus it happens on localhost. Is it possible that this is more of a PC spec problem? Some people with a better pc but worse connection don't get dropped so often as me. |
(0007048) __Lagger__ (reporter) 2013-08-19 16:59 |
I've tried setting affinity and priority from low to high, but this didn't affect the amount of data that I received. Although, this doesn't affect my PC perfomance much either. :( These maps run fine (70+ fps) when I'm connected and playing. Unplayable low fps on singleplayer though. |
(0007693) malon (reporter) 2013-12-10 21:34 |
I don't know if it helps at all, but I want to report the same issue. Slaughtermaps often disconnect when huge numbers of monsters are present. I have not tried localhost, but it definitely happens across local LAN. |
(0008112) __Lagger__ (reporter) 2014-01-19 21:01 |
Just like Frits: I've tried this on local host too. Both server and client run on the same machine using a different core (checked with affinity). The bandwidth available should be in the GB/s range. However, my bandwidth monitor says it's not even using 10MBits for a short time, then I get kicked for missing packets. I'm pretty sure this problem is not network related. |
(0008128) StrikerMan780 (reporter) 2014-01-23 20:11 |
I can vouch that I've seen this issue happen before. |
(0008212) Aiur850 (reporter) 2014-02-15 15:11 edited on: 2014-02-15 15:16 |
I can vouch as well. This isn't an issue simply of inadequate bandwidth, since this happens even when hosting and playing locally on the LAN. If too many actors on the map have either moved from their original starting position, or have been killed, the server attempts to send all those packets to update joining clients of this new information during the snapshot request. Now usually on maps with 5-6K+ monsters, such as the holyhellv1.5 wad this becomes an issue. A temporary solution to this issue, is to run a wad that actually removes these actors on death(I think this is possible?) to minimize the amount of packet updates new joining clients need before being able to join. Though I still think this isn't the best idea as packets still need to be sent to clients indicating these actors are no longer on the map, but it may reduce the snapshot size. Though I think the netcode should be re-written to allow either more missed packets or some type of solution to properly download the snapshot without just booting them before they can even join. |
(0008215) Konar6 (reporter) 2014-02-15 17:49 |
Wouldn't it help to simply up the PACKET_BUFFER_SIZE constant from 1024? |
(0008223) Aiur850 (reporter) 2014-02-16 17:10 |
Maybe Konar6, but that's still going to need (I believe?) coding changes to Zandronum to implement. It would be nice if the server host could control this value from defaults. |
(0008228) Konar6 (reporter) 2014-02-16 21:22 |
Unfortunately, we tested PACKET_BUFFER_SIZE = 8192 with Frits and Alien Overlord on sf2012 map30 and chillax map39, and, while we didn't encounter the client missing packets error, our connection to the server was unsustainable anyway. All hell broke loose both on the server and clients. So this simple change is not sufficient for Zandronum to handle such monster heavy maps. |
(0008231) Frits (reporter) 2014-02-17 10:22 |
We didn't test though if a small bump(like 2048) in maxpackets improves missing packets on connect. Bumping the value to 8000+ just crashes the server instead of disconnecting the client. |
(0008232) Konar6 (reporter) 2014-02-17 15:03 |
I tested 4096 before, and still got the missing packets error. |
(0008233) Aiur850 (reporter) 2014-02-17 19:09 |
I've also messed around with maxpacketsize but no value solves this. |
(0008851) Zom-B (reporter) 2014-06-05 17:51 edited on: 2014-08-02 16:13 |
I added a screenshot and I have extra information that shows how ridiculous this is, and may help find the solution. When I connect to a server that fulfills above conditions, but at the exact moment the map is in transition (scoreboard is shown), it connects fine and uses approx 30 kiB/s. When I typed "reconnect" in the console after 1:20 min, it started downloading data at an unprecedented rate, and obviously pulls in way more than it would ever need (in only the first 9 seconds more than it downloaded in the 1:20 min before). Moreover, in the period before I got disconnected, there seemed to be a constant time delay. When I "say", or shoot at the wall, I see the reaction 5-10 seconds later. A few days ago I had the same, on the same map, but I got lucky. The time delay stayed constant for a minute or so and seemed to shorten in the minute after that. When the delay disappeared, the download speed went back to normal. This map is map22 from chillax.wad, if you check you'll see that with just 895 monsters this doesn't justify >30 MiB of data. >34 kiB per monster!? Even if there are 3x more balls in the air than there are monsters, this still doesn't calculate. Like someone said before, it ALSO happens when the server is localhost. (not the server in the screenshot) I think a cheap solution is to just let the clients download without checking for missing packets, and only start the game ticker when everything is received. This still doesn't fix the ridiculous amount that clients unnecessarily download. How can I edit the bug properties? I want to change Priority to Blocking and Version to 2.0Beta |
(0008853) Watermelon (developer) 2014-06-05 23:07 |
Changed it for you (I don't know what you mean by blocking). I have a new huffman encoding table that would help with monster maps, but due t the high monster count, there needs to be an algorithm that knows to safely send only the updates you want. I have a few ideas but this will completely destroy demo compatibility. |
(0008857) Dusk (developer) 2014-06-06 17:26 |
Version changed back. (couldn't set it to 1.1.1 so set to 1.2 instead) We use the earliest version number for the bug to be known to be present in, so using 2.0-beta is incorrect here. |
(0008858) Arco (updater) 2014-06-06 17:41 |
And furthermore this isn't your ticket. Only the creator of the ticket and the devs here make corrections when needed. |
(0010706) Monsterovich (reporter) 2014-10-28 13:43 |
This bug prevents people from having fun in Sectorcraft and Blockdoom. It becomes impossible to connect to the server when there is too much stuff is built. In Sectorcraft it is triggered when too many sectors become different from their original state. In Blockdoom, when there are too many actors (these actors are completely static and don't move or change state in any way). Please, allow downloading bigger game states when connecting. |
(0010776) Torr Samaho (administrator) 2014-11-01 18:45 |
Quote from MonsterovichWell, it's not that we actively forbid big game states. The current way the UDP packets are sent is simply not able to handle this. It's sending all packets at once, which is apparently not a good idea in this case. I guess some buffering to restrict the number of outbound packets per tic could fix this. |
(0010783) Zom-B (reporter) 2014-11-01 22:06 |
Read my post. A throttling the already outbound data won't fix it. The bug is that it's sending way more data (several orders of magnitude more) to new clients than what it cumulatively sent to an existing client. |
(0010910) malon (reporter) 2014-11-19 20:57 |
Sorry if this is not the right place to post this, but is there any potential fixes to this issue on the horizon? From what I can tell, it's mostly just people saying "no real fixes can be applied as it's very difficult" (paraphrasing my understanding). For me, this is the biggest downfall of Zandronum and I would absolutely LOVE to see a fix for this. Slaughtermaps can be so much fun in the right setting, and I'm so disappointed that this issue still persists. Lastly, thank you devs for all your hard work on this port. I am not bashing at all, I would never bash anything free. Thank you! |
(0010911) Watermelon (developer) 2014-11-19 22:42 |
Yes Malon I have a solution and I'm working on it ;) Hopefully it'll be in 2.0, or at least the patch will hopefully be ready in a few weeks. |
(0010912) malon (reporter) 2014-11-19 22:47 |
Thank you watermelon! I'll be excitedly checking this thread in the coming weeks! |
(0012812) Zom-B (reporter) 2015-06-27 16:14 |
Not fixed in 2.1 |
(0014157) Korshun (reporter) 2016-01-22 18:24 |
This bug applies not only to big amounts of active monsters, but also to any big gamestate. This bug makes Sectorcraft servers impossible to connect to if the map on them has too many edits. Zandronum should really have separate connection phases of "downloading gamestate" and "playing", just like other engines do, instead of throwing the whole gamestate at once at the connecting client and instantly kicking them for having not yet received it all. |
(0015505) Torr Samaho (administrator) 2016-08-20 15:02 edited on: 2016-08-20 15:04 |
I added a buffer to spread the full update over multiple ticks. The code is still experimental and available in the sandbox:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/e6363f6daa0234469acb46bfeaa566c16bc43773 [^]' The new CVAR sv_maxpacketspertick allows to tweak the maximal amount of packets send to a single client per tick. Can somebody build binaries and test this? |
(0015508) WaTaKiD (updater) 2016-08-20 19:39 |
this 3.0 build contains sv_maxpacketspertick: 'https://www.dropbox.com/s/60l4jorla43dh4h/zandronum-3.0-r160820-1443-e6363f6-windows.zip?dl=0 [^]' also i noticed a typo here: 'https://bitbucket.org/zandronum/zandronum-sandbox/commits/e6363f6daa0234469acb46bfeaa566c16bc43773#Lsrc/sv_main.cppT373 [^]' most -> must |
(0015509) Torr Samaho (administrator) 2016-08-21 07:31 |
Thanks for the binaries! I'll fix the typo. BTW: The current version of the fix is not very efficient yet, since it stores two copies of the unsent packets. I'll take care of this later. This will not change how the fix works though. So it would be great of someone tests WaTaKiD's binary. |
(0015510) Zom-B (reporter) 2016-08-21 11:32 edited on: 2016-08-21 11:36 |
Still happens in WaTaKiD's built. I get "Connection interrupted" for much longer than in 2.1, then eventually get disconnected with " than 8192 packets. Unable to recover." Although I expected this since the patch sounds like a workaround instead of addressing the CAUSE of the huge amount of packets. Have you even read my first reply? I'll summarize the important part: New clients download more megabytes when connecting to a busy map than existing clients ever received since the map started... many times more. |
(0015511) Torr Samaho (administrator) 2016-08-21 19:46 |
Yes, I read your first reply. And the patch is no workaround, it intends to address what I consider to be the cause of the issue, i.e. the fact that the server tries to send a full snapshot of the current game state, which can be quite big, in a single tick. This will inevitably lead to many missed packets, which the client will all request, which makes the server sent another burst of packets, leading to more traffic than theoretically necessary and more missed packets, and the process repeats. I assume that the missed packets in the process are what causes the excessive traffic you observe. I tested my patch locally before I pushed the code to our sandbox. Without my patch I can't reliably connect to Okuplok MAP01, with the patch I can. Did you try to adjust sv_maxpacketspertick? The current default is just a wild guess and may need to be changed. If this doesn't help, can you post a client side demo of your connection attempt? |
(0015514) Zom-B (reporter) 2016-08-22 16:55 |
sv_maxpacketspertick: * 32 - server crashes / vanishes * 256 - server crashes * 1024 - clients get kicked with 8192 packets lost * 4096 - server freezes * 16384 - server vanishes I tested 1024 with Chillax MAP21, and all the ones above with monsterfest.wad with 10000 awake barons |
(0015516) Torr Samaho (administrator) 2016-08-22 18:32 |
With sv_maxpacketspertick 64 (didn't test other values) and on a local server, I can join a game with 10000 awake barons on monsterfest.wad just fine. The server doesn't survive for long though and either crashes or vanishes after a little while with two players in the game and 10000 awake barons. Nevertheless, at least on my machine the problem of connecting to such a server seems to be fixed and the patch only aims at fixing this. Does a two player game with 10000 awake barons on monsterfest.wad work on 2.1.2 or the latest official beta build of 3.0 for you if both players connect before the barons are awakened? |
(0015518) Empyre (reporter) 2016-08-22 20:16 |
About a year ago, another player and I played all the way through Holyhell 1.5 on a 2.1.2 server and it ran just fine. Others tried to join and couldn't, but we who were already there had no problems. That's 16300 monsters, not counting ones resurrected by archviles, but not all awakened at once like in nuts.wad. |
(0015519) Zom-B (reporter) 2016-08-23 06:34 |
Dead bodies also count toward the packet loss. We tried a few times to suicide together to make monsters sleep to let people in, but the people couldn't get in regardless. |
(0015530) Torr Samaho (administrator) 2016-08-27 16:49 |
Please check if this works better. If you still have problems connecting, please provide a client side demo recorded with this binary from the perspective a player already in the game that shows the failed connect attempt of the new player. |
(0016138) Aiur850 (reporter) 2016-11-02 19:06 edited on: 2016-11-02 19:31 |
Torr, I just tested your latest binary (ZandroDev3.0-OutputBufferTest) from your reply above and can confirm it appears to have fixed the issue during my testing. I have a special version of holyhell map that has 20,000 monsters. I've had all/most 20,000 monsters move out of place, killed them and have no trouble reconnecting at all. I've compared the same map against the current binary 2.1.2 and can't even reconnect to the map w/o the 1024 missed packet issue even on localhost server. Please tell me this will be included in the 3.0 release? If you still would like more testing, I can put up a server and have a play through of the map for further testing. I really would love to see this included in the 3.0 release. Thanks. |
(0016162) Torr Samaho (administrator) 2016-11-06 21:09 |
Thanks for checking! Due to lack of feedback, I feared everybody lost interest in this. I think it still needs some more testing before I can officially include it in 3.0. I'll port the fix to the latest 3.0 version and will create a new testing binary. |
(0016163) Fastclick (reporter) 2016-11-06 21:33 |
Nonon-one lost interest. This problem is still crucial. I can perform a stress-test, but i need Windows and Linux build for that. |
(0016164) malon (reporter) 2016-11-06 23:58 |
I would also like to chime in and mention that I've been monitoring this thread closely. I will also test the build and report back. |
(0016189) Torr Samaho (administrator) 2016-11-13 20:31 |
Thanks for the feedback! I updated the patch to the latest 3.0 version and integrated part of it into the main repository. The experimental buffer is still in the sandbox:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/6b9383609c86fe3d62ba9ae234e675f1161dab1d [^]' Before I put this in 3.0, I'd like to get some more testing feedback. |
(0016190) Fastclick (reporter) 2016-11-13 20:59 |
Can someone provide Linux and Windows build that contain this commit ? |
(0016193) Torr Samaho (administrator) 2016-11-14 07:32 |
Here is a Windows binary. Can somebody also prepare a Linux binary? |
(0016202) Aiur850 (reporter) 2016-11-17 14:29 edited on: 2016-11-17 15:25 |
I put up a temporary server for testing. I don't believe launchers will automatically download the release so please download and apply manually. 68.42.202.198:10666 I notice one downside to this test version is the lack of mouselook support? |
(0016203) Empyre (reporter) 2016-11-17 16:27 edited on: 2016-11-17 19:26 |
I came here to report a problem connecting to Aiur850's server, but I see that it is already known about. Here is the error message I got: Failed to download testing binary. Error transferring'http://zandronum.com/downloads/testing/3.0/ZandroDev3.0-161113-0956windows.zip [^]' - server replied: Not Found EDIT: After installing the testing binary manually, I was able to connect and we tested it and it works nicely. |
(0016205) Aiur850 (reporter) 2016-11-17 19:30 edited on: 2016-11-17 19:32 |
Torr, Empyre and I tested the Windows binary for a few hours, it worked perfectly. The patch certainly solves the missed packet issue. Tried a version of holyhell map that has 16,300 monsters + russian overkill mod and was able to kill all monsters and we could rejoin server without a problem. I then tried dropping 10 hindenburg bombs all at the same time and they went off without any issue or disconnects. That certainly wasn't possible in 2.1.2. We then tried nuts.wad, map 1 which packs 10,600+ monsters into two large rooms. With all the monsters moving around and attacking at the same time, had no problem with disconnects. This defiantly seems ready for inclusion into the Zan 3 alpha for further, public testing. All tests were done with the default 'sv_maxpacketspertick 64'. |
(0016206) Torr Samaho (administrator) 2016-11-17 20:31 |
Thanks for checking! This sounds very promising. I'll include this in the next official 3.0 beta build. |
(0016211) Fastclick (reporter) 2016-11-18 15:21 |
Tested Windows build. Can confirm, that fix works as expected. Finally! (Tested on: Brutaldoom, Russian Overkill) |
(0016212) unknownna (updater) 2016-11-18 17:48 |
Some minor side effects: I tested this quickly and it seems to give "Connection interrupted!" messages after changemap map changes and more movement jitter upon joining games compared to 2.1.2. Tested with an emulated ping of 300 with chillax-v9.7.3.wad and complex-doom.v26a2.pk3. As others said before me, the patch seems to work well as it doesn't kick me anymore from the server when using "kill monsters" with the mods above loaded. Is sv_maxpacketspertick dynamic, or does the server have to be restarted when altering the value? In any case, great work! This will most certainly be highly beneficial to Zandronum as a whole. I've been busy with other stuff lately so I haven't been able to test Zandronum as much as I should have. |
(0016213) Aiur850 (reporter) 2016-11-18 18:01 edited on: 2016-11-18 18:02 |
unknownna, That's strange. We didn't experience any "Connection interrupted!" message when changing a map. Everything was smooth. The only way I could generate a "Connection interrupted!" message was on nuts.wad when there was a lot of activity such as using "kill monsters" command. But it recovered quickly. sv_maxpacketspertick is not dynamic. It stays at the default value of 64 until changed. You do not need to reboot the server for the change to take effect. |
(0016222) FascistCat (reporter) 2016-11-20 20:23 |
I tested the build provided by Torr with HolyHell.wad MAP05 on a local server (via Doomseeker) with a clean config and a 2.1.2 server with my personal .ini. The 2.1.2 client was instantly rejected when trying to join the server. With the new build there was no problem to join at all. After waking up a lot of monsters the game did not show any signs of packet loss. After waking up a considerable amount of monsters at the point the client crawled to 1 FPS I tried connecting one more client. The second client had no trouble at the beginning but a few seconds later it started to show the "Connection Interrupted!" message. The first client did the same after connecting the second one. No disconnections nor packet loss ocurred. The jitter started to increase as I tried to wake more and more monsters. It took a considerable amount to do that however. |
(0016228) Torr Samaho (administrator) 2016-11-20 21:25 |
Quote from unknownna Can you reproduce this? If so, can you make a client side demo so that I can see all necessary steps in detail? Quote from unknownna Changes to sv_maxpacketspertick take effect immediately. Quote from FascistCat If there is so much going on that the client can't even display a reasonable amount of frames, there is no guarantee that it can process all incoming packets quickly enough. |
(0016232) malon (reporter) 2016-11-20 21:53 edited on: 2016-11-20 21:54 |
I tested the Win binaries all weekend over a slow connection with fast PCs with zero issues. Thank you so much. This is so great! Sorry it took so long for me to report back! |
(0016244) FascistCat (reporter) 2016-11-21 10:43 |
Quote from "Torr Samaho" Indeed, it was (sort of) a stress test. Even after two minutes of the "Connection interrupted" message they did not get disconnected nor had packet loss. |
(0016516) Zom-B (reporter) 2016-12-17 13:48 |
404 not found for the 161113 test build :( |
(0016520) Ru5tK1ng (updater) 2016-12-17 16:54 |
You can use this build, it has the fix for this issue:'http://tinyurl.com/latest-zan-3-build [^]' |
(0016815) Dusk (developer) 2017-02-07 18:55 |
Judging from the replies it seems that this issue is resolved now. Or is someone still experincing this issue with the latest beta build? |
(0016816) malon (reporter) 2017-02-07 19:06 edited on: 2017-02-07 20:32 |
We had a reproducible desync on a very specific part of holyhell map. 'https://youtu.be/AZn5yaVuB1Y?t=2h40m33s [^]' Start watching at 2h 40m 33s, he will soon run to a platform which lowers into a room where MANY monsters will become active all at once. It was within 30 seconds that a desync would happen and the client would no longer be able to connect to the server, even after disconnecting. The client would begin downloading enormous amounts of data and never successfully connect. The data was obvious because I was on voice chat with the other player, and our voice transmission became super garbled whenever this would happen, because connecting to the server was using up 99% of the bandwidth. |
(0017306) Korshun (reporter) 2017-04-24 06:35 edited on: 2017-04-24 06:58 |
YOU DID IT! YOU FIXED SECTORCRAFT! THANK YOU! NOTE: setting sv_maxpacketspertick 1 makes clients stuck at "Authenticating level", even on a localhost server, with the following being written in server console: [09:30:27 am]Connect (v3.0-alpha): xxx.xxx.xxx.xxx:xxxxx [09:31:06 am]Unfinished connection from xxx.xxx.xxx.xxx:xxxxx timed out. [09:31:09 am]Unknown challenge (1) from xxx.xxx.xxx.xxx:xxxxx. Ignoring IP for 10 seconds. Setting it to 2 works fine. 8 seems to work fine too, but we set it to 2 for reliability. The default value of 64 causes the same 2048 behavior as before over the internet, but works on a localhost server. These tests were done using a real server with real maps, and a localhost server with "randomcraft" - a sectorcraft map where every property of every tile is random, resulting in an EXTREMELY LARGE but static gamestate. Previously, 4096 randomcraft tiles caused 1024 on a localhost server. Now, 16384 randomcraft tiles (3 MB of gamestate, according to server statistics) work fine on localhost. |
(0017859) Combinebobnt (reporter) 2017-06-21 02:19 edited on: 2017-06-21 03:45 |
ok i dunno about the above fun stuff comments but in 3.0 I could for the first time ever acutally play speed of doom map32 online. I also connected another client just fine while all the monsters were busy firing away hr2 map32 was fine too. Well that's good enough for me lol that means I can handle maps with monster counts in the thousands. Unfortunately holyhell map05 and okuplok is a little out of reach for my connection and computer still probably with the ten thousand counts. Playing wads with 10,000+ per map is probably best done in prboom or splitting it up into multiple maps anyway, pushing the doom engine stuff right there. I don't expect those to be flawless online. Also custom mods with more demanding monsters don't behave as well, to be expected. edit: apparently I could play sod map32 (but extra laggy) in 2.1.2. I must have only played that map in rga2 or something idk. But in general 2.1.2 was way more laggy in stuff (or lagged out) compared to 3.0 |
(0022933) Sparkie (reporter) 2023-12-17 19:57 edited on: 2023-12-17 20:01 |
I had this problem 5 years ago and still have it today when I tried playing MOP again on Zandronum. As the original poster pointed out in his DU meter graph, I have the exact same behavior. A normal game uses about 1-2k up and 4-6k down. Even a large map like CHLX_13 or something in heavy action will only use 30-90k download with the odd missing packet. But if there a large change in the map at the start or any point in like the yamoto taking out a few hundred monster, my packet loss spikes up until connection interrupted. The symptom also appears exactly the same as the above graph, it weird cause it'll recover from a few hundred lost packets but once it goes somewhere between 250-400, it will just keep climbing until 1200 odds, maybe come down and bit and then spike back up to 1200 odds again and sometime it will eventually go the whole Client:Checkformissingpacketrs (Missing more that 2048 Packets). I think I set that buffer size in the past but anyways then it disconnects. I can not reconnect until the next map in most cases like 90% of the time. I tried all kind of troubleshooting, graphics, particle count, network options in game, drivers all to no avail and all the other players do not have a problem, they just play the map as normal according to their feedback. Two points of interest is all I can add to the discussion right now is that, although my computer ethernet connection is auto selected at 100mb because of power adapters the interface is 1gb. Since I seen mention of problems with fast internet connections, I went to my network driver advanced settings and changed the connection type to 10mb full duplex and there was definitely a notable reduction in maps desyncing (like a 90% reduction) however some maps still bombed out and with the 10mb connection I could never reconnect whereas with the 100mb it could sometimes reconnect and still be desynced and showing excessive packet loss. Now this is what I notice about the download thats the same as the original poster here, it seems to cap out at 1.99mb for the download once this occurs (game desynces) and download spikes (I'm assuming it download given the red above in DU meter, Task Manager (networking) or Resource Monitor in windows just show 'Activity'). This situation and the workarounds or changes to builds may have helped some people stave off the issue or avoid it most case scenarios but this bug is not fixed in my opinion on 3.0, 3.1 or 3.2 for me. Somehow the game is unable to catch up and it wouldn't even be an annoyance except that when your having fun and being a big map, I can't reconnect for another hour approx, depending on number of player and I'm losing all the weapons. I will also say I have done some testing just client side with different setting and CHLX_12 which I can bug instantly by triggering the monsters inside at the start. A few things I have noticed: It is much easier to connect to the server when nobody is on it, i.e., if there is players and it's bug, I cannot reconnect, I can if it just me reconnect to the same bugged map. I can also connect and run about for ages and it won't bug as much similar to the 100mb 10mb switch if I don't fire any weapons. So I can trigger all the monsters and jump about but firing my gun seem to add to the problem. I can't really understand how this happens when my computer is on par or better spec than the game server. There might be any number of problems here but I think the game is just sending snapshot after snapshot and the state is already changed too much by the time we receive it when other players are engaged. Maybe if the server could sent us 6mb/s we'd be in and resynced in a second instead of downloading 1.99mb endlessly, well depends, I noticed on my 100mb connection it seems to go on forever but on the 10mb not so much, it often stops download anything after a while 2-3 minuets but never actually connects to the game. It just says stuck with no message from keys/skulls found, it like it download something but never actually did anything with it. |
(0024112) Zom-B (reporter) 2024-10-30 17:38 edited on: 2024-10-30 17:40 |
While 3.2 is still in beta, we're all still waiting for this fix. As I said before, the proposed fix is probably not the right fix for this problem as it has something to do with the networking layer which retries when a send takes too long, but retries with more data (previous data + changed gamestate in between). Since the packet becomes larger, the probability of it failing increases, leading to a positive feedback of ever larger packets. Recently I've seen a few situations where the network recovers, or barely does so, where it's seesawing back and forth between having a short delay → long delay → "connection interrupted" → long delay -> short delay → repeat. This seems to be related to people dropping from the server, freeing some bandwidth. One such map was SlaughterMax MAP25, which we entered with 5 people, and three people dropped quite soon. After about one more minute trying, the other already voted nextmap and "won" the vote (server is configured that 50% is "win"). |
Only registered users can voice their support. Click here to register, or here to log in. | |
Supporters: | malon Frits Combinebobnt Zom-B WaTaKiD Monsterovich Empyre EnsaladaDeTomate Fastclick Korshun FascistCat JC Tenton djskaarj Konda jwaffe Aiur850 unknownna |
Opponents: | No one explicitly opposes this issue yet. |
Issue History | |||
Date Modified | Username | Field | Change |
2013-08-17 18:54 | __Lagger__ | New Issue | |
2013-08-18 16:38 | Frits | Note Added: 0007044 | |
2013-08-18 16:39 | Frits | Note Edited: 0007044 | View Revisions |
2013-08-19 16:59 | __Lagger__ | Note Added: 0007048 | |
2013-12-10 21:34 | malon | Note Added: 0007693 | |
2014-01-19 21:01 | __Lagger__ | Note Added: 0008112 | |
2014-01-23 20:11 | StrikerMan780 | Note Added: 0008128 | |
2014-02-15 15:11 | Aiur850 | Note Added: 0008212 | |
2014-02-15 15:16 | Aiur850 | Note Edited: 0008212 | View Revisions |
2014-02-15 17:49 | Konar6 | Note Added: 0008215 | |
2014-02-16 17:10 | Aiur850 | Note Added: 0008223 | |
2014-02-16 21:22 | Konar6 | Note Added: 0008228 | |
2014-02-17 10:22 | Frits | Note Added: 0008231 | |
2014-02-17 15:03 | Konar6 | Note Added: 0008232 | |
2014-02-17 19:09 | Aiur850 | Note Added: 0008233 | |
2014-06-05 17:32 | Zom-B | File Added: Screenshot_2014-06-05-19-28.png | |
2014-06-05 17:51 | Zom-B | Note Added: 0008851 | |
2014-06-05 17:52 | Zom-B | Note Added: 0008852 | |
2014-06-05 17:52 | Zom-B | Note Edited: 0008852 | View Revisions |
2014-06-05 17:56 | Zom-B | Note Edited: 0008851 | View Revisions |
2014-06-05 23:06 | Watermelon | Product Version | 1.1.1 => 2.0-beta |
2014-06-05 23:07 | Watermelon | Note Added: 0008853 | |
2014-06-06 17:26 | Dusk | Note Added: 0008857 | |
2014-06-06 17:26 | Dusk | Product Version | 2.0-beta => 1.2 |
2014-06-06 17:41 | Arco | Note Added: 0008858 | |
2014-06-15 16:48 | Watermelon | Relationship added | related to 0001030 |
2014-08-02 16:13 | Zom-B | Note View State: 0008852: private | |
2014-08-02 16:13 | Zom-B | Note Edited: 0008851 | View Revisions |
2014-08-02 16:13 | Zom-B | Note Deleted: 0008852 | |
2014-10-10 16:00 | Watermelon | Relationship added | related to 0000757 |
2014-10-28 13:43 | Monsterovich | Note Added: 0010706 | |
2014-11-01 18:45 | Torr Samaho | Note Added: 0010776 | |
2014-11-01 22:06 | Zom-B | Note Added: 0010783 | |
2014-11-19 20:57 | malon | Note Added: 0010910 | |
2014-11-19 22:42 | Watermelon | Note Added: 0010911 | |
2014-11-19 22:47 | malon | Note Added: 0010912 | |
2015-06-27 16:14 | Zom-B | Note Added: 0012812 | |
2016-01-22 18:24 | Korshun | Note Added: 0014157 | |
2016-08-20 15:02 | Torr Samaho | Note Added: 0015505 | |
2016-08-20 15:03 | Torr Samaho | Note Edited: 0015505 | View Revisions |
2016-08-20 15:04 | Torr Samaho | Note Edited: 0015505 | View Revisions |
2016-08-20 15:22 | Torr Samaho | Assigned To | => Torr Samaho |
2016-08-20 15:22 | Torr Samaho | Status | new => needs testing |
2016-08-20 19:39 | WaTaKiD | Note Added: 0015508 | |
2016-08-21 07:31 | Torr Samaho | Note Added: 0015509 | |
2016-08-21 11:32 | Zom-B | Note Added: 0015510 | |
2016-08-21 11:35 | Zom-B | Note Edited: 0015510 | View Revisions |
2016-08-21 11:36 | Zom-B | Note Edited: 0015510 | View Revisions |
2016-08-21 19:46 | Torr Samaho | Note Added: 0015511 | |
2016-08-22 16:55 | Zom-B | Note Added: 0015514 | |
2016-08-22 18:32 | Torr Samaho | Note Added: 0015516 | |
2016-08-22 20:16 | Empyre | Note Added: 0015518 | |
2016-08-23 06:34 | Zom-B | Note Added: 0015519 | |
2016-08-27 16:49 | Torr Samaho | Note Added: 0015530 | |
2016-11-02 19:06 | Aiur850 | Note Added: 0016138 | |
2016-11-02 19:31 | Aiur850 | Note Edited: 0016138 | View Revisions |
2016-11-06 21:09 | Torr Samaho | Note Added: 0016162 | |
2016-11-06 21:33 | Fastclick | Note Added: 0016163 | |
2016-11-06 23:58 | malon | Note Added: 0016164 | |
2016-11-13 20:31 | Torr Samaho | Note Added: 0016189 | |
2016-11-13 20:59 | Fastclick | Note Added: 0016190 | |
2016-11-14 07:32 | Torr Samaho | Note Added: 0016193 | |
2016-11-17 14:29 | Aiur850 | Note Added: 0016202 | |
2016-11-17 15:09 | Aiur850 | Note Edited: 0016202 | View Revisions |
2016-11-17 15:25 | Aiur850 | Note Edited: 0016202 | View Revisions |
2016-11-17 16:27 | Empyre | Note Added: 0016203 | |
2016-11-17 19:26 | Empyre | Note Edited: 0016203 | View Revisions |
2016-11-17 19:30 | Aiur850 | Note Added: 0016205 | |
2016-11-17 19:31 | Aiur850 | Note Edited: 0016205 | View Revisions |
2016-11-17 19:32 | Aiur850 | Note Edited: 0016205 | View Revisions |
2016-11-17 20:31 | Torr Samaho | Note Added: 0016206 | |
2016-11-18 15:21 | Fastclick | Note Added: 0016211 | |
2016-11-18 17:48 | unknownna | Note Added: 0016212 | |
2016-11-18 18:01 | Aiur850 | Note Added: 0016213 | |
2016-11-18 18:02 | Aiur850 | Note Edited: 0016213 | View Revisions |
2016-11-20 20:23 | FascistCat | Note Added: 0016222 | |
2016-11-20 21:25 | Torr Samaho | Note Added: 0016228 | |
2016-11-20 21:53 | malon | Note Added: 0016232 | |
2016-11-20 21:54 | malon | Note Edited: 0016232 | View Revisions |
2016-11-21 10:43 | FascistCat | Note Added: 0016244 | |
2016-12-17 13:48 | Zom-B | Note Added: 0016516 | |
2016-12-17 16:54 | Ru5tK1ng | Note Added: 0016520 | |
2017-02-07 18:55 | Dusk | Note Added: 0016815 | |
2017-02-07 19:06 | malon | Note Added: 0016816 | |
2017-02-07 19:07 | malon | Note Edited: 0016816 | View Revisions |
2017-02-07 20:32 | malon | Note Edited: 0016816 | View Revisions |
2017-04-20 06:03 | Torr Samaho | Relationship added | related to 0002931 |
2017-04-24 06:35 | Korshun | Note Added: 0017306 | |
2017-04-24 06:51 | Korshun | Note Edited: 0017306 | View Revisions |
2017-04-24 06:52 | Korshun | Note Edited: 0017306 | View Revisions |
2017-04-24 06:55 | Korshun | Note Edited: 0017306 | View Revisions |
2017-04-24 06:56 | Korshun | Note Edited: 0017306 | View Revisions |
2017-04-24 06:58 | Korshun | Note Edited: 0017306 | View Revisions |
2017-04-24 06:58 | Korshun | Note Edited: 0017306 | View Revisions |
2017-05-14 19:46 | Torr Samaho | Relationship added | related to 0003085 |
2017-06-21 02:19 | Combinebobnt | Note Added: 0017859 | |
2017-06-21 03:45 | Combinebobnt | Note Edited: 0017859 | View Revisions |
2023-12-17 19:57 | Sparkie | Note Added: 0022933 | |
2023-12-17 20:01 | Sparkie | Note Edited: 0022933 | View Revisions |
2024-10-30 17:38 | Zom-B | Note Added: 0024112 | |
2024-10-30 17:40 | Zom-B | Note Edited: 0024112 | View Revisions |
Copyright © 2000 - 2024 MantisBT Team |