MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003085Zandronum[All Projects] Bugpublic2017-04-23 21:502017-05-14 20:57
ReporterUntitled 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusnewResolutionopen 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version3.0-beta 
Target VersionFixed in Version 
Summary0003085: Weapon causes client to completely desync from server
DescriptionThis 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 ReproduceEither:
1. Try Playing "[TSPG] Painkiller: Bouncing Projectile Zandronum Testing"
OR:
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 InformationWhen 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.
TagsNo tags attached.
Relationships
related to 0001469needs testing Torr Samaho Problem connecting to slaughtermaps 
Attached Files? BouncingTester.wad (8,974) 2017-04-23 21:50
https://zandronum.com/tracker/file_download.php?file_id=2076&type=bug
? BounceTester_NoSetScale.wad (9,050) 2017-04-24 18:33
https://zandronum.com/tracker/file_download.php?file_id=2079&type=bug
Issue History
Date ModifiedUsernameFieldChange
2017-04-23 21:50UntitledNew Issue
2017-04-23 21:50UntitledFile Added: BouncingTester.wad
2017-04-24 06:14Torr SamahoNote Added: 0017305
2017-04-24 06:14Torr SamahoStatusnew => feedback
2017-04-24 18:33UntitledNote Added: 0017310
2017-04-24 18:33UntitledStatusfeedback => new
2017-04-24 18:33UntitledFile Added: BounceTester_NoSetScale.wad
2017-04-29 17:30Torr SamahoNote Added: 0017423
2017-04-30 15:43Torr SamahoStatusnew => feedback
2017-04-30 23:10UntitledNote Added: 0017474
2017-04-30 23:10UntitledStatusfeedback => new
2017-04-30 23:10UntitledNote Edited: 0017474bug_revision_view_page.php?bugnote_id=17474#r10503
2017-05-07 10:12Torr SamahoNote Added: 0017564
2017-05-07 10:12Torr SamahoStatusnew => feedback
2017-05-08 17:58UntitledNote Added: 0017607
2017-05-08 17:58UntitledStatusfeedback => new
2017-05-08 17:58UntitledNote Edited: 0017607bug_revision_view_page.php?bugnote_id=17607#r10579
2017-05-09 06:10Torr SamahoNote Added: 0017614
2017-05-09 06:11Torr SamahoStatusnew => feedback
2017-05-11 16:49UntitledNote Added: 0017625
2017-05-11 16:49UntitledStatusfeedback => new
2017-05-11 16:51UntitledNote Edited: 0017625bug_revision_view_page.php?bugnote_id=17625#r10583
2017-05-12 05:10jdagenetNote Added: 0017628
2017-05-12 21:47UntitledNote Added: 0017631
2017-05-14 19:46Torr SamahoRelationship addedrelated to 0001469
2017-05-14 20:57WaTaKiDNote Added: 0017694
2017-05-14 20:57WaTaKiDNote Edited: 0017694bug_revision_view_page.php?bugnote_id=17694#r10628

Notes
(0017305)
Torr Samaho   
2017-04-24 06:14   
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?
(0017310)
Untitled   
2017-04-24 18:33   
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.
(0017423)
Torr Samaho   
2017-04-29 17:30   
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.
(0017474)
Untitled   
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.
(0017564)
Torr Samaho   
2017-05-07 10:12   
Quote from Untitled

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.

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.
(0017607)
Untitled   
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 [^]'
(0017614)
Torr Samaho   
2017-05-09 06:10   
Can anybody reproduce this on a local server? I need to reproduce the problem to debug it.
(0017625)
Untitled   
2017-05-11 16:49   
(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.
(0017628)
jdagenet   
2017-05-12 05:10   
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.
(0017631)
Untitled   
2017-05-12 21:47   
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.
(0017694)
WaTaKiD   
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