|Anonymous | Login | Signup for a new account||2017-09-22 04:38 UTC|
|My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003085||Zandronum||[All Projects] Bug||public||2017-04-23 21:50||2017-05-14 20:57|
|Target Version||Fixed in Version|
|Summary||0003085: Weapon causes client to completely desync from server|
|Description||This weapon, based off of Russian Overkill's Petrovec (which also causes the bug to occur), when used in multiplayer, completely causes the Zandronum Client to desync from the server.|
I mostly need to know if this bug is happening to anyone else. The server still stays perfectly intact, but the client experience stops being at all playable.
Reproducibility is always for me.
Tested on Zandronum 3.0 Alpha r170416-0710
|Steps To Reproduce||Either:|
1. Try Playing "[TSPG] Painkiller: Bouncing Projectile Zandronum Testing"
1. Download BouncingTester.wad, which has a weapon called "BounceTester".
2. Host a server with that online.
3. Use weapon.
4. Watch client completely fail to keep updated with the server.
|Additional Information||When I say the client completely desyncs, I mean completely; I legitimately had a player that was dead according to the server, but hadn't had his death update on the client. I also had two clients (from the same IP) which were somehow on different maps. To the best of my knowledge, this should not be possible in any circumstance.|
|Attached Files|| BouncingTester.wad [^] (8,974 bytes) 2017-04-23 21:50|
BounceTester_NoSetScale.wad [^] (9,050 bytes) 2017-04-24 18:33
Torr Samaho (administrator)
|Is it working any better in 2.1.2? If the example is not compatible with 2.1.2, can it be made compatible while keeping the bug in 3.0?|
The Weapon is not compatible with 3.0 off the bat due to A_SetScale calls. However, after removing all 38 A_SetScale calls (which makes it Zandronum 2.1.2 compatible), the bug still occurs online in 3.0.
By testing with 2.1.2, I found something out: Using the weapon's altfire (which produces more reliable desyncs) in 2.1.2 causes the client to repeatedly drop more and more packets until eventually kicking the user for missing more than 1024 of them.
For some reason, Zandronum 3.0 fails to register the packet loss and does not kick the client; which results in the erroneous non-synchronous behaviour when the client should, for all intents and purposes, no longer be connected.
Torr Samaho (administrator)
|I tested this on a local 3.0 server and it seemed to work fine, but it generates huge traffic spikes. Please tell me what exactly is necessary to get the client permanently out of sync.|
edited on: 2017-04-30 23:10
I've figured it out. It turns out that my version of Russian Overkill (and thus, this, as a derivative weapon) forgot to put +CLIENTSIDEONLY on the effects, so network traffic is simply absurd due to sheer actor overload; this is what causes the packet loss.
So, with that in mind, I've found a NEW bug, which is that Packet Loss doesn't seem to have a 100% chance of actually registering to the client; sometimes my client simply desyncs without disconnecting to the point where it really is no longer updating with the server, but the client doesn't report the packet loss, which normally earns it a disconnect.
Torr Samaho (administrator)
Quote from Untitled
Can you reproduce this? That sounds like a serious bug we need to fix, but there is not much I can do if it can be reproduced.
edited on: 2017-05-08 17:58
In general, a quick guide is that it seems to happen when there's a frankly insane amount (as in, a mod should never ever induce this much) of network traffic, to the point where my client can't actually stay synchronized with the server.
The testing weapon, if the altfire is relentlessly abused (testing in a map with high monster density really helps here), it generates network traffic at a rate higher than any mod should; but it makes a good baseline for measuring this. If my client can't keep up with the server, it works about equally badly in both 2.1.2 and 3.0; the /only/ difference is that I don't disconnect in 3.0, even when I clearly should.
With that in mind, this does make testing significantly harder; I've had the advantage of using TSPG for this, which means I actually have some amount of network lag; I'd imagine if you're the host of all network traffic you can't desync (since as far as I know you can't desync with yourself).
This bug was mostly discovered because of my originally horrifically un-optimized build of Russian Overkill, which caused this kind of thing (due to horrifically large amounts of network traffic), so it's definitely network traffic related. Also, for posterity, the horrific build of RO in question:http://allfearthesentinel.net/download?file=ro_pb_2.4_zan3.0_fixed.pk3 [^]
Torr Samaho (administrator)
|Can anybody reproduce this on a local server? I need to reproduce the problem to debug it.|
edited on: 2017-05-11 16:51
Alright, sorry for the late reply (dealing with other things), but I have a server hosted on TSPG called 'Zandronum Server Traffic Desync Test', which runs 12-in-1 with a horrifically unoptimized Russian Overkill on TAT03, which can consistently obliterate clients with server traffic due to being based on it's laggiest weaponry; I SHOULD packet out as soon as I start shooting, but sometimes the disconnect fails to happen. I'll leave this server up for at least a few days.
At this point, I feel the ticket should be renamed to "Zandronum client occasionally fails to recognize missing packets", because at this point, that's as much as I can figure out.
|I was unable to reproduce this on a local server using the Bouncing Tester wad, I also joined that TSPG server earlier today and was unable to desync from the server while messing with the various weapons.|
|Alright, at this point I'm convinced that this bug isn't being experienced by anyone else; I think at this point it's safe to mark it as "could not reproduce", especially since this only seems to occur in situations that should not be happening anyway.|
edited on: 2017-05-14 20:57
<WaTaKiD>alrighty so i spammed for roughly 15 seconds, got stuck in connection interrupted for roughly 6 minutes before finally recovering
<WaTaKiD>peak was 1.9 mb/s and stayed there until i finally recovered
<WaTaKiD>https://pastebin.com/cqLdpaiv [^] dumptrafficmeasure, if it matters
<Torr_Samaho>Wow, 1.9 mb/s for 6 minutes while you were doing nothings? Now that's a lot of traffic.
<WaTaKiD>yep, every minute or so i would hear the gun fire, or an imp would take a step forward, very very slowly trying to get back in sync
<WaTaKiD>my chat didnt show up until i recovered, but showed up instantly in the server log
8mb demo: https://www.dropbox.com/s/fv48cq1gkcwlmyf/2017.05.14_13.32.29_bouncingtester.zip?dl=0 [^]
binary used was 3.0-r170416-0710
doom2.wad and BouncingTester.wad are the only wads used
sv_maxpacketsize was 1024
sv_maxpacketspertick was 64
|Only registered users can voice their support. Click here to register, or here to log in.|
|Supporters:||No one explicitly supports this issue yet.|
|Opponents:||No one explicitly opposes this issue yet.|
|2017-04-23 21:50||Untitled||New Issue|
|2017-04-23 21:50||Untitled||File Added: BouncingTester.wad|
|2017-04-24 06:14||Torr Samaho||Note Added: 0017305|
|2017-04-24 06:14||Torr Samaho||Status||new => feedback|
|2017-04-24 18:33||Untitled||Note Added: 0017310|
|2017-04-24 18:33||Untitled||Status||feedback => new|
|2017-04-24 18:33||Untitled||File Added: BounceTester_NoSetScale.wad|
|2017-04-29 17:30||Torr Samaho||Note Added: 0017423|
|2017-04-30 15:43||Torr Samaho||Status||new => feedback|
|2017-04-30 23:10||Untitled||Note Added: 0017474|
|2017-04-30 23:10||Untitled||Status||feedback => new|
|2017-04-30 23:10||Untitled||Note Edited: 0017474||View Revisions|
|2017-05-07 10:12||Torr Samaho||Note Added: 0017564|
|2017-05-07 10:12||Torr Samaho||Status||new => feedback|
|2017-05-08 17:58||Untitled||Note Added: 0017607|
|2017-05-08 17:58||Untitled||Status||feedback => new|
|2017-05-08 17:58||Untitled||Note Edited: 0017607||View Revisions|
|2017-05-09 06:10||Torr Samaho||Note Added: 0017614|
|2017-05-09 06:11||Torr Samaho||Status||new => feedback|
|2017-05-11 16:49||Untitled||Note Added: 0017625|
|2017-05-11 16:49||Untitled||Status||feedback => new|
|2017-05-11 16:51||Untitled||Note Edited: 0017625||View Revisions|
|2017-05-12 05:10||jdagenet||Note Added: 0017628|
|2017-05-12 21:47||Untitled||Note Added: 0017631|
|2017-05-14 19:46||Torr Samaho||Relationship added||related to 0001469|
|2017-05-14 20:57||WaTaKiD||Note Added: 0017694|
|2017-05-14 20:57||WaTaKiD||Note Edited: 0017694||View Revisions|
Questions or other issues? Contact Us.
|Copyright © 2000 - 2017 MantisBT Team|