Zandronum Chat on our Discord Server Get the latest version: 3.1
Source Code
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001116Zandronum[All Projects] Bugpublic2012-10-10 16:272024-03-16 11:51
Reporterunknownna 
Assigned To 
PriorityurgentSeveritymajorReproducibilityalways
StatusnewResolutionopen 
PlatformOSOS Version
Product Version1.0 
Target VersionFixed in Version 
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.
3. Join the game.
4. Copy-paste "kill;wait 10;+use;wait 9;+attack;wait 38;-attack" into the console. The client will fire the plasma rifle a bit too early causing it to use more ammo than it should in addition to the projectiles disappearing.
5. Re-enter the bind to reproduce the desync every time.

1. zandronum.exe -playdemo 2012.10.10_18.15.36_doom2.cld
Additional InformationI recorded a demo of the issue with Zandronum 1.0. Notice how the ammo value corrects itself after the changemap map change.

It started to break when respawning in 98e r3297.
Attached Files? file icon 2012.10.10_18.15.36_doom2.cld [^] (19,344 bytes) 2012-10-10 16:27
? file icon wepdesync_3.0.wad [^] (1,000 bytes) 2018-09-12 15:01

- 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 0002310confirmed Ancient weapon desync when connecting to server with cl_startasspectator 0: Client fires weapon too late 
related to 0003469resolvedKaminsky Client fires weapon too early after map resets in 3.1 
related to 0003470resolvedTorr 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 0003491confirmed 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 0003980assignedKaminsky Desync with firing weapons with WEAPON.NOAUTOFIRE flag 
child of 0000193closedTorr Samaho Able to fire weapon before it's passed A_Raise 
child of 0000544closedTorr Samaho Client can't fire selected weapon after "changemap" map changes in COOP when being telefragged 
child of 0002255closedTorr Samaho Weapon desync regression 

-  Notes
User avatar (0005072)
NotIvan (reporter)
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".
User avatar (0005074)
Torr Samaho (administrator)
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.
User avatar (0005078)
unknownna (updater)
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.
User avatar (0005079)
NotIvan (reporter)
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)
User avatar (0005094)
Torr Samaho (administrator)
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?
User avatar (0005098)
unknownna (updater)
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.
User avatar (0005101)
NotIvan (reporter)
2012-10-14 11:27

 I don't know about puffs but usually I die when that happens...
User avatar (0005102)
Torr Samaho (administrator)
2012-10-14 12:18

 I uploaded numerous beta builds between 3216 and 3299. Would be nice if you can track this down further.
User avatar (0005105)
unknownna (updater)
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.
User avatar (0012740)
unknownna (updater)
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
User avatar (0015069)
Mobius (reporter)
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
User avatar (0019338)
unknownna (updater)
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.
User avatar (0019442)
unknownna (updater)
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
User avatar (0019514)
unknownna (updater)
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.
User avatar (0019516)
Leonard (developer)
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?
User avatar (0019517)
unknownna (updater)
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.
User avatar (0020477)
Edward-san (developer)
2019-04-07 20:05

 Please check with the build from 0003470:0020476 .
User avatar (0023303)
unknownna (updater)
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.

Issue Community Support
Only registered users can voice their support. Click here to register, or here to log in.
Supporters: Tux unknownna StrikerMan780 Mobius Combinebobnt jdagenet
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2012-10-10 16:27 unknownna New Issue
2012-10-10 16:27 unknownna File Added: 2012.10.10_18.15.36_doom2.cld
2012-10-10 16:28 unknownna Status new => confirmed
2012-10-10 16:31 NotIvan Note Added: 0005072
2012-10-10 16:32 unknownna Relationship added child of 0000193
2012-10-10 16:33 unknownna Relationship added related to 0000544
2012-10-10 20:17 Torr Samaho Note Added: 0005074
2012-10-10 22:46 unknownna Note Added: 0005078
2012-10-10 23:27 NotIvan Note Added: 0005079
2012-10-14 08:05 Torr Samaho Note Added: 0005094
2012-10-14 10:53 unknownna Note Added: 0005098
2012-10-14 11:27 NotIvan Note Added: 0005101
2012-10-14 12:18 Torr Samaho Note Added: 0005102
2012-10-14 12:52 unknownna Note Added: 0005105
2015-06-14 04:07 unknownna Relationship added child of 0002255
2015-06-16 09:59 unknownna Note Added: 0012740
2015-06-16 10:00 unknownna Relationship replaced child of 0000544
2015-06-16 10:04 unknownna Additional Information Updated View Revisions
2015-06-16 10:28 unknownna Description Updated View Revisions
2015-06-16 10:28 unknownna Additional Information Updated View Revisions
2016-06-11 06:02 Mobius Note Added: 0015069
2016-06-11 06:04 Mobius Note Edited: 0015069 View Revisions
2018-08-19 12:57 unknownna Note Added: 0019338
2018-08-25 01:11 unknownna Note Edited: 0019338 View Revisions
2018-08-25 01:12 unknownna Note Edited: 0019338 View Revisions
2018-08-25 01:13 unknownna Steps to Reproduce Updated View Revisions
2018-08-25 01:29 unknownna Note Edited: 0019338 View Revisions
2018-08-27 18:50 unknownna Relationship added related to 0002309
2018-08-27 18:58 unknownna Relationship added related to 0000534
2018-08-27 19:12 unknownna Relationship added related to 0002310
2018-08-28 02:25 unknownna Relationship added related to 0003469
2018-08-28 02:27 unknownna Note Added: 0019442
2018-08-28 02:40 unknownna Relationship added related to 0003470
2018-08-28 06:41 unknownna Relationship added related to 0002311
2018-09-10 14:45 unknownna Relationship added related to 0003491
2018-09-12 12:31 unknownna Note Added: 0019514
2018-09-12 12:56 unknownna Relationship added related to 0003492
2018-09-12 14:04 Leonard Note Added: 0019516
2018-09-12 14:04 Leonard Status confirmed => feedback
2018-09-12 15:00 unknownna Note Added: 0019517
2018-09-12 15:00 unknownna Status feedback => new
2018-09-12 15:01 unknownna Steps to Reproduce Updated View Revisions
2018-09-12 15:01 unknownna File Added: wepdesync_3.0.wad
2018-09-12 15:04 unknownna Relationship added related to 0001094
2019-04-07 20:05 Edward-san Note Added: 0020477
2019-04-07 20:05 Edward-san Status new => feedback
2022-02-25 15:30 Kaminsky Relationship added related to 0003980
2024-03-05 08:20 unknownna Note Added: 0023303
2024-03-05 08:20 unknownna Status feedback => new
2024-03-16 11:51 unknownna Note Edited: 0023303 View Revisions




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2024 MantisBT Team
Powered by Mantis Bugtracker