MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000540Zandronum[All Projects] Bugpublic2011-07-30 13:322018-08-27 21:30
Reporterunknownna 
Assigned ToLeonard 
PrioritynormalSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version98d 
Target VersionFixed in Version3.1 
Summary0000540: Weapon selection is desynced between clients
DescriptionAfter some heavy testing I found another nasty player sprite and/or a coop spy issue and managed to reproduce it. Sometimes your client will think that other clients are firing their weapons when they truly aren't firing them. The weapon selection is desynced between the clients. It can look like your opponent is firing his chaingun when it's actually being selected on his end. You don't hear any attack sounds or see any bullet puffs, but decals are spawned. I recorded a demo of it with 3287.
Steps To ReproduceI alternate between selecting the fist and chaingun while repeatedly tapping +attack in a fast manner. I sometimes allow my client to attack with the fist before selecting the chaingun, but I never allow my client to attack with the chaingun. I make sure that I lower the chaingun before it's fully raised on my end. After a while, the other client will start to think that the chaingun fully raised on your end.
Additional Information
TagsNo tags attached.
Relationships
related to 0000193closed Torr Samaho Able to fire weapon before it's passed A_Raise 
related to 0000423closed  "switchonpickup" alias desyncs the coop spy/info for newly connected clients 
has duplicate 0002356closed  Coopspy desyncs 
related to 0000553confirmed  SSG A_CheckReload coop spy desync 
related to 0001041resolved Leonard +attack desync between clients causes ammo values to desync 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2011-07-30 13:32unknownnaNew Issue
2011-07-30 13:32unknownnaStatusnew => confirmed
2011-07-30 13:35unknownnaNote Added: 0002017
2011-07-30 13:40unknownnaRelationship addedrelated to 0000193
2011-07-30 15:56unknownnaRelationship addedrelated to 0000423
2011-08-07 17:17unknownnaRelationship addedrelated to 0000553
2012-06-09 13:22Torr SamahoCategoryGeneral => Bug
2013-02-09 18:35WatermelonNote Added: 0005974
2015-07-21 12:46unknownnaRelationship addedhas duplicate 0002356
2018-08-27 06:53unknownnaRelationship addedrelated to 0001041
2018-08-27 17:55unknownnaNote Added: 0019438
2018-08-27 17:56unknownnaAssigned To => Leonard
2018-08-27 17:56unknownnaStatusconfirmed => resolved
2018-08-27 17:56unknownnaResolutionopen => fixed
2018-08-27 17:56unknownnaFixed in Version => 3.1
2018-08-27 21:30LeonardNote Added: 0019441

Notes
(0002017)
unknownna   
2011-07-30 13:35   
Demos recorded with build 3287:

* 2011.07.28_14.55.39_player_sprite_desync_test.cld
* player_sprite_desync_3287.zip
(0005974)
Watermelon   
2013-02-09 18:35   
I have a demo of de-sync. It seems like when there's packet loss going to the server, the client goes out of sync.

Furthermore when this happened, when I reached 0 rockets it fired another one shortly thereafter, which can be very glitchy.


Thus, a solution is maybe every so often re-transmit the ammo from the server to the client?
(0019438)
unknownna   
2018-08-27 17:55   
This interestingly enough seems to have been fixed in 3.1 with the unlagged fixes and the addition of a "movement regulator buffer?". I could reproduce it in 3.0 on a local server very quickly, but not in the latest 3.1 alpha build, even when double checking.
(0019441)
Leonard   
2018-08-27 21:30   
The movement buffer regulator shouldn't miraculously fix weapon sync issues as the only thing it does is change the way the buffer itself empties.
This is most likely due to 0002607 getting fixed, which was a bit before I introduced the movement buffer regulator.