MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0001116Zandronum[All Projects] Bugpublic2012-10-10 16:272025-05-17 17:39
Reporterunknownna 
Assigned ToKaminsky 
PriorityurgentSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version1.0 
Target Version3.2Fixed in Version3.2 
Summary0001116: Client fires weapon too early after respawning
DescriptionThe client starts to fire the weapon too early after respawning, causing it to use more ammo than it should. Also happens in DM. Very easy to reproduce. Simply hold +attack immediately after pressing your bound respawn key. Most noticeable with the plasma rifle in COOP.

Although we managed to greatly improve the weapon synchronization, we still have to take care of this respawning issue since it happens all the time without any PWADs.
Steps To Reproduce1. zandronum -host -iwad doom2.wad -file wepdesync_3.0.wad
2. Connect a client to the server with an emulated ping of 160 and join the game.
3. Copy-paste "kill;wait 10;+use;wait 9;+attack;wait 38;-attack" into the console. The client will respawn and fire the plasma rifle a bit too early causing it to use more ammo than it should. What happens is that the client starts to spend ammo and animate the weapon too early, even though nothing happens on the server. No projectiles actually spawn. The ammo drops from 200/300 to 198/300.
4. "changemap map01" in the server console. When you enter the map you'll see that the ammo is 200/300 again, since you didn't actually fire the weapon on the server-end in the former map.
Additional InformationI recorded a demo of the issue with Zandronum 1.0. Notice how the ammo value corrects itself after the changemap map change.

zandronum.exe -playdemo 2012.10.10_18.15.36_doom2.cld

It started to break when respawning in 98e r3297.
TagsNo tags attached.
Relationships
related to 0002309confirmed  Ancient weapon desync after "changemap" map changes in COOP: Client fires weapon too late on client 
related to 0000534confirmed  Ammo desync if you have a high ping. Client thinks that it didn't use any ammo. 
related to 0002310resolved  Ancient weapon desync when connecting to server with cl_startasspectator 0: Client fires weapon too late 
related to 0003469resolved Kaminsky Client fires weapon too early after map resets in 3.1 
related to 0003470resolved Torr Samaho Client fires weapon too early when joining the game in 3.1 
related to 0002311confirmed  Weapon desync in (Team)Possession and (Team)LMS after win sequences: Client fires weapon too late 
related to 0003491feedback Kaminsky Berserk powerup causes weapons to desync and client to fire weapon too early 
related to 0003492resolved  Client fires weapon even earlier than before when respawning in 3.1 
related to 0001094confirmed  Clients raise morph weapons online 
related to 0003980feedback Kaminsky Desync with firing weapons with WEAPON.NOAUTOFIRE flag 
child of 0000193closed Torr Samaho Able to fire weapon before it's passed A_Raise 
child of 0000544closed Torr Samaho Client can't fire selected weapon after "changemap" map changes in COOP when being telefragged 
child of 0002255closed Torr Samaho Weapon desync regression 
Attached Files? 2012.10.10_18.15.36_doom2.cld (19,344) 2012-10-10 16:27
https://zandronum.com/tracker/file_download.php?file_id=806&type=bug
? wepdesync_3.0.wad (1,000) 2018-09-12 15:01
https://zandronum.com/tracker/file_download.php?file_id=2387&type=bug
Issue History
Date ModifiedUsernameFieldChange
2012-10-10 16:27unknownnaNew Issue
2012-10-10 16:27unknownnaFile Added: 2012.10.10_18.15.36_doom2.cld
2012-10-10 16:28unknownnaStatusnew => confirmed
2012-10-10 16:31NotIvanNote Added: 0005072
2012-10-10 16:32unknownnaRelationship addedchild of 0000193
2012-10-10 16:33unknownnaRelationship addedrelated to 0000544
2012-10-10 20:17Torr SamahoNote Added: 0005074
2012-10-10 22:46unknownnaNote Added: 0005078
2012-10-10 23:27NotIvanNote Added: 0005079
2012-10-14 08:05Torr SamahoNote Added: 0005094
2012-10-14 10:53unknownnaNote Added: 0005098
2012-10-14 11:27NotIvanNote Added: 0005101
2012-10-14 12:18Torr SamahoNote Added: 0005102
2012-10-14 12:52unknownnaNote Added: 0005105
2015-06-14 04:07unknownnaRelationship addedchild of 0002255
2015-06-16 09:59unknownnaNote Added: 0012740
2015-06-16 10:00unknownnaRelationship replacedchild of 0000544
2015-06-16 10:04unknownnaAdditional Information Updatedbug_revision_view_page.php?rev_id=7475#r7475
2015-06-16 10:28unknownnaDescription Updatedbug_revision_view_page.php?rev_id=7477#r7477
2015-06-16 10:28unknownnaAdditional Information Updatedbug_revision_view_page.php?rev_id=7478#r7478
2016-06-11 06:02MobiusNote Added: 0015069
2016-06-11 06:04MobiusNote Edited: 0015069bug_revision_view_page.php?bugnote_id=15069#r9119
2018-08-19 12:57unknownnaNote Added: 0019338
2018-08-25 01:11unknownnaNote Edited: 0019338bug_revision_view_page.php?bugnote_id=19338#r11681
2018-08-25 01:12unknownnaNote Edited: 0019338bug_revision_view_page.php?bugnote_id=19338#r11682
2018-08-25 01:13unknownnaSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=11684#r11684
2018-08-25 01:29unknownnaNote Edited: 0019338bug_revision_view_page.php?bugnote_id=19338#r11685
2018-08-27 18:50unknownnaRelationship addedrelated to 0002309
2018-08-27 18:58unknownnaRelationship addedrelated to 0000534
2018-08-27 19:12unknownnaRelationship addedrelated to 0002310
2018-08-28 02:25unknownnaRelationship addedrelated to 0003469
2018-08-28 02:27unknownnaNote Added: 0019442
2018-08-28 02:40unknownnaRelationship addedrelated to 0003470
2018-08-28 06:41unknownnaRelationship addedrelated to 0002311
2018-09-10 14:45unknownnaRelationship addedrelated to 0003491
2018-09-12 12:31unknownnaNote Added: 0019514
2018-09-12 12:56unknownnaRelationship addedrelated to 0003492
2018-09-12 14:04LeonardNote Added: 0019516
2018-09-12 14:04LeonardStatusconfirmed => feedback
2018-09-12 15:00unknownnaNote Added: 0019517
2018-09-12 15:00unknownnaStatusfeedback => new
2018-09-12 15:01unknownnaSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=11783#r11783
2018-09-12 15:01unknownnaFile Added: wepdesync_3.0.wad
2018-09-12 15:04unknownnaRelationship addedrelated to 0001094
2019-04-07 20:05Edward-sanNote Added: 0020477
2019-04-07 20:05Edward-sanStatusnew => feedback
2022-02-25 15:30KaminskyRelationship addedrelated to 0003980
2024-03-05 08:20unknownnaNote Added: 0023303
2024-03-05 08:20unknownnaStatusfeedback => new
2024-03-16 11:51unknownnaNote Edited: 0023303bug_revision_view_page.php?bugnote_id=23303#r14141
2024-05-15 15:58unknownnaSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=14201#r14201
2024-05-15 15:58unknownnaAdditional Information Updatedbug_revision_view_page.php?rev_id=14202#r14202
2024-05-26 14:31KaminskyNote Added: 0023711
2024-05-26 14:31KaminskyAssigned To => Kaminsky
2024-05-26 14:31KaminskyStatusnew => needs review
2024-05-26 14:31KaminskyTarget Version => 3.2
2024-05-27 17:51unknownnaNote Added: 0023725
2024-05-27 17:51unknownnaStatusneeds review => resolved
2024-05-27 17:51unknownnaResolutionopen => fixed
2024-05-27 17:51unknownnaFixed in Version => 3.2
2024-05-28 23:19unknownnaRelationship addedparent of 0004294
2024-06-01 19:11unknownnaRelationship deletedparent of 0004294

Notes
(0005072)
NotIvan   
2012-10-10 16:31   
This is a pain in duels, it simply gives an advantage to the player that you can easily spawn kill. I mean, by that, he can shoot you despite being "disadvantaged".
(0005074)
Torr Samaho   
2012-10-10 20:17   
Quote from NotIvan
I mean, by that, he can shoot you despite being "disadvantaged".
Can you elaborate? I'm pretty sure the server will not allow you to shoot earlier than you should. If anything the clients thinks he starts to shoot either earlier or later than he actually does.
(0005078)
unknownna   
2012-10-10 22:46   
Quote from unknownna
The client starts to fire the weapon too early after respawning, causing it to use more ammo than it should.

This also happens after map resets.
(0005079)
NotIvan   
2012-10-10 23:27   
It just feels as if you keep spamming your fire key right after you die, you will fire almost instantly when you respawn. (Assume you had an ssg on the exact spot you respawned)
(0005094)
Torr Samaho   
2012-10-14 08:05   
Quote from NotIvan
It just feels as if you keep spamming your fire key right after you die, you will fire almost instantly when you respawn.

Do you have any evidence that this is more than a client side misprediction? Are the puffs spawned when the client thinks it's firing or only later when the client should be firing?
Quote from unknownna
The client starts to fire the weapon too early after respawning
Didn't we fix this? If so, when did it return?
(0005098)
unknownna   
2012-10-14 10:53   
Quote from Torr Samaho
Didn't we fix this? If so, when did it return?

Something changed between 3216 and 3299. In 3216, the client doesn't fire the weapon too early.
(0005101)
NotIvan   
2012-10-14 11:27   
I don't know about puffs but usually I die when that happens...
(0005102)
Torr Samaho   
2012-10-14 12:18   
I uploaded numerous beta builds between 3216 and 3299. Would be nice if you can track this down further.
(0005105)
unknownna   
2012-10-14 12:52   
Quote from Torr Samaho
Would be nice if you can track this down further.

It changed somewhere between 3287 and 3298.
(0012740)
unknownna   
2015-06-16 09:59   
Quote from unknownna
Ok, we found out that it started to break when respawning in r3297. IIRC, that's from when we worked on the COOP desyncs here:

0000544: Client can't fire selected weapon after "changemap" map changes in COOP when being telefragged
(0015069)
Mobius   
2016-06-11 06:02   
(edited on: 2016-06-11 06:04)
Here is a quick demostration done on NJ

'https://www.sendspace.com/file/a07twj [^]'

after you respawn, using +prev/+next weapon while firing causes the desync
(0019338)
unknownna   
2018-08-19 12:57   
(edited on: 2018-08-25 01:29)
I had some quick DM games a few days ago and noticed this issue again when picking up the rocket launcher upon spawning. I fired the weapon and the animation was displayed and ammo was used, but no rockets came out.

This indeed confirms that the client is able to fire its weapon earlier than the server when respawning, potentially throwing your shots and timing off and costing you frags.

Considering that 3.1 is supposed to take care of a lot of unlagged and prediction issues (which I'll hopefully get to test sometime later), I'd strongly advise the team to look into this particular issue, as it can potentially happen really often due to how often you respawn in competitive modes.

And after doing some further testing, it seems that both either the client or the server are wrong sometimes and are firing the weapon too early, as you're sometimes actually able to fire in a wrong direction after respawning if you have a high enough ping (600, for testing purposes).
Something is clearly very wrong here, and should be looked into ASAP if possible.

Edit:

It seems to be dependent on the ping, and for some reason either the client or server time? Something like that, as the binds need different but consistent timings sometimes.

Using this example WAD (with deathmatch, sv_weaponstay and sv_cheats 1) and an emulated ping of 160, the following bind should reproduce the NULL rocket issue most of the time. This is the earliest you can attack with the rocket launcher using a ping of 160. This is the client firing earlier than the server:

kill;wait 30;+use;+forward;wait 25;god;+attack;-forward;wait 110;-use;-forward;-attack

If that doesn't work, try the following bind:

kill;wait 30;+use;+forward;wait 49;god;+attack;-forward;wait 110;-use;-forward;-attack

With a local connection to the server, this is the earliest you can attack with the rocket launcher. Notice the difference in tics between the binds. Unfortunately it's still broken, as the rocket comes out, but no animation is displayed, suggesting that the server fires earlier than the client in this case:

kill;wait 30;+use;+forward;wait 34;god;+attack;-forward;wait 110;-use;-forward;-attack

This could potentially happen very often under regular circumstances. The client is either firing the weapon 1 tic too early or late depending on the ping, and possibly the client/server time.
(0019442)
unknownna   
2018-08-28 02:27   
Quote from unknownna
This also happens after map resets.

I split this issue into its own ticket and made it easily reproducible: 0003469: Client fires weapon too early after map resets
(0019514)
unknownna   
2018-09-12 12:31   
After double checking this issue between 3.0 and 3.1, it turns out there's multiple separate regressions in 3.1 which causes the client to fire the weapon even earlier than before, on top of the already broken behavior since Skulltag r3297. The binds I posted above earlier only seem to work in 3.1. Sorry about that, I'll split the 3.1 issue into its own ticket like the others.
(0019516)
Leonard   
2018-09-12 14:04   
I have been slowly investigating this issue for a bit now and did notice multiple things that seem to be off about the weapon syncing.

Sorry if I missed something but the binds on this ticket don't seem to be any different from the new one you made, does this mean you have no binds that can reproduce a weapon sync issue in 3.0?
(0019517)
unknownna   
2018-09-12 15:00   
The rocket launcher binds didn't seem to work in 3.0 (though I did get a rocket launcher desync while playing on a 3.0 DM server), but it's very easy to reproduce the desync in 3.0 with the plasma rifle. I'll make a quick example and update the ticket. Sorry about the delay.

The updated example for 3.0 and new steps to reproduce the desync will be in the Steps To Reproduce section of the ticket.
(0020477)
Edward-san   
2019-04-07 20:05   
Please check with the build from 0003470:0020476 .
(0023303)
unknownna   
2024-03-05 08:20   
(edited on: 2024-03-16 11:51)
Hello there, long time no see. It's been many years, and the world changed a lot since then.. I hope you're all well.

I came by this old issue again and tested it with the build posted above, and it's still broken. I don't even need a ping emulation, though I'm on wireless internet.

Then I tried it on the official 3.1 release, and it seems fixed there without any ping emulation, but when there's some latency, it still breaks.

Following the initial "Steps To Reproduce", the client thinks that it has fired 2 plasmarifle projectiles (ammo decreased from 200 to 198), but if you use a changemap map change, the server corrects the client and tells it never fired any projectiles (ammo remains at 200).

'https://foss.heptapod.net/zandronum/zandronum-stable/-/commit/da76b2e0fd8998604e85ec44b4ecac5aecccb921 [^]'

This seems to be the commit that broke it for respawning, r3297.
I remember we were fixing "changemap" map change weapon desyncs in cooperative/survival mode that occurred due to packet losses. the client had the wrong weapons selected at map starts due to packets not arriving properly. I remember the mods were Zombie Horde and Dark 7.
(0023711)
Kaminsky   
2024-05-26 14:31   
I created a merge request to fix the weapon desync:'https://foss.heptapod.net/zandronum/zandronum-stable/-/merge_requests/122 [^]'

This, by extension, should also address'https://zandronum.com/tracker/view.php?id=3980 [^]'
(0023725)
unknownna   
2024-05-27 17:51   
Holy mackerel, you did it! Thank you! If we ever meet, drinks are on me.

The fix seems to hold up well. The plasmarifle in the example wad always fire the 2 projectiles properly again now, and thus the initial timing on weapons like the SSG are not off between the client and server anymore.

I also tested the fix on a deathmatch server with 300 ping and didn't notice any desyncs so far.

The only thing I noticed was some rare issue with bots picking up fast-firing weapons like the chaingun and plasmarifle and displaying their player PLAY E/F attack animation sprites too early before actually firing their weapon. But this is probably a separate issue and I'll let you know if I can reliably reproduce it again in the future.

So with that, I'm marking this as resolved finally after all these years.
Amazing work.