Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001469Zandronum[All Projects] Bugpublic2013-08-17 18:542023-12-17 20:01
Reporter__Lagger__ 
Assigned ToTorr Samaho 
PriorityhighSeveritymajorReproducibilityalways
Statusneeds testingResolutionopen 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version1.2 
Target VersionFixed in Version 
Summary0001469: Problem connecting to slaughtermaps
DescriptionSometimes 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 ReproduceUse 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 Filespng file icon Screenshot_2014-06-05-19-28.png [^] (254,473 bytes) 2014-06-05 17:32

- Relationships
related to 0000757new Monster Bandwidth Mitigation 
related to 0001030new Clients lag out more when connecting to a server with a high active monstercount 
related to 0002931closedTorr Samaho SERVER_Tick ticks all clients packet buffers, whether valid or not 
related to 0003085new Weapon causes client to completely desync from server 

-  Notes
User avatar (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.

User avatar (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.
User avatar (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.
User avatar (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.
User avatar (0008128)
StrikerMan780 (reporter)
2014-01-23 20:11

I can vouch that I've seen this issue happen before.
User avatar (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.

User avatar (0008215)
Konar6 (reporter)
2014-02-15 17:49

Wouldn't it help to simply up the PACKET_BUFFER_SIZE constant from 1024?
User avatar (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.
User avatar (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.
User avatar (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.
User avatar (0008232)
Konar6 (reporter)
2014-02-17 15:03

I tested 4096 before, and still got the missing packets error.
User avatar (0008233)
Aiur850 (reporter)
2014-02-17 19:09

I've also messed around with maxpacketsize but no value solves this.
User avatar (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

User avatar (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.
User avatar (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.
User avatar (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.
User avatar (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.
User avatar (0010776)
Torr Samaho (administrator)
2014-11-01 18:45

Quote from Monsterovich
Please, allow downloading bigger game states when connecting.
Well, 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.
User avatar (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.
User avatar (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!
User avatar (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.
User avatar (0010912)
malon (reporter)
2014-11-19 22:47

Thank you watermelon! I'll be excitedly checking this thread in the coming weeks!
User avatar (0012812)
Zom-B (reporter)
2015-06-27 16:14

Not fixed in 2.1
User avatar (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.
User avatar (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?

User avatar (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
User avatar (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.
User avatar (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.

User avatar (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?
User avatar (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
User avatar (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?
User avatar (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.
User avatar (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.
User avatar (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.
User avatar (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.

User avatar (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.
User avatar (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.
User avatar (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.
User avatar (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.
User avatar (0016190)
Fastclick (reporter)
2016-11-13 20:59

Can someone provide Linux and Windows build that contain this commit ?
User avatar (0016193)
Torr Samaho (administrator)
2016-11-14 07:32

Here is a Windows binary. Can somebody also prepare a Linux binary?
User avatar (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?

User avatar (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.

User avatar (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'.

User avatar (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.
User avatar (0016211)
Fastclick (reporter)
2016-11-18 15:21

Tested Windows build.
Can confirm, that fix works as expected. Finally!
(Tested on: Brutaldoom, Russian Overkill)
User avatar (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.
User avatar (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.

User avatar (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.
User avatar (0016228)
Torr Samaho (administrator)
2016-11-20 21:25

Quote from unknownna

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.

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

Is sv_maxpacketspertick dynamic, or does the server have to be restarted when altering the value?

Changes to sv_maxpacketspertick take effect immediately.

Quote from FascistCat

After waking up a considerable amount of monsters at the point the client crawled to 1 FPS I tried connecting one more client.

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.
User avatar (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!

User avatar (0016244)
FascistCat (reporter)
2016-11-21 10:43

Quote from "Torr Samaho"

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.

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.
User avatar (0016516)
Zom-B (reporter)
2016-12-17 13:48

404 not found for the 161113 test build :(
User avatar (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 [^]'
User avatar (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?
User avatar (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.

User avatar (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.

User avatar (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

User avatar (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.


Issue Community Support
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






Questions or other issues? Contact Us.

Links


Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker