Zandronum Chat @ irc.zandronum.com
#zandronum
Get the latest version: 3.0
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
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.
Attached Files? file icon BouncingTester.wad [^] (8,974 bytes) 2017-04-23 21:50
? file icon BounceTester_NoSetScale.wad [^] (9,050 bytes) 2017-04-24 18:33

- Relationships
related to 0001469needs testingTorr Samaho Problem connecting to slaughtermaps 

-  Notes
User avatar (0017305)
Torr Samaho (administrator)
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?
User avatar (0017310)
Untitled (reporter)
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.
User avatar (0017423)
Torr Samaho (administrator)
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.
User avatar (0017474)
Untitled (reporter)
2017-04-30 23:10
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.

User avatar (0017564)
Torr Samaho (administrator)
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.
User avatar (0017607)
Untitled (reporter)
2017-05-08 17:58
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 [^]

User avatar (0017614)
Torr Samaho (administrator)
2017-05-09 06:10

Can anybody reproduce this on a local server? I need to reproduce the problem to debug it.
User avatar (0017625)
Untitled (reporter)
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.

User avatar (0017628)
jdagenet (reporter)
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.
User avatar (0017631)
Untitled (reporter)
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.
User avatar (0017694)
WaTaKiD (updater)
2017-05-14 20:57
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


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

- Issue History
Date Modified Username Field Change
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.

Links


Copyright © 2000 - 2017 MantisBT Team
Powered by Mantis Bugtracker