Anonymous | Login | Signup for a new account | 2024-04-20 01:23 UTC |
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||||||
ID | Project | Category | View Status | Date Submitted | Last Update | ||||||||
0001116 | Zandronum | [All Projects] Bug | public | 2012-10-10 16:27 | 2024-03-16 11:51 | ||||||||
Reporter | unknownna | ||||||||||||
Assigned To | |||||||||||||
Priority | urgent | Severity | major | Reproducibility | always | ||||||||
Status | new | Resolution | open | ||||||||||
Platform | OS | OS Version | |||||||||||
Product Version | 1.0 | ||||||||||||
Target Version | Fixed in Version | ||||||||||||
Summary | 0001116: Client fires weapon too early after respawning | ||||||||||||
Description | The 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 Reproduce | 1. 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 Information | I 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 | 2012.10.10_18.15.36_doom2.cld [^] (19,344 bytes) 2012-10-10 16:27 wepdesync_3.0.wad [^] (1,000 bytes) 2018-09-12 15:01 | ||||||||||||
Relationships | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Notes | |
(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". |
(0005074) Torr Samaho (administrator) 2012-10-10 20:17 |
Quote from NotIvanCan 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 (updater) 2012-10-10 22:46 |
Quote from unknownna This also happens after map resets. |
(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) |
(0005094) Torr Samaho (administrator) 2012-10-14 08:05 |
Quote from NotIvan 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 unknownnaDidn't we fix this? If so, when did it return? |
(0005098) unknownna (updater) 2012-10-14 10:53 |
Quote from Torr Samaho Something changed between 3216 and 3299. In 3216, the client doesn't fire the weapon too early. |
(0005101) NotIvan (reporter) 2012-10-14 11:27 |
I don't know about puffs but usually I die when that happens... |
(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. |
(0005105) unknownna (updater) 2012-10-14 12:52 |
Quote from Torr Samaho It changed somewhere between 3287 and 3298. |
(0012740) unknownna (updater) 2015-06-16 09:59 |
Quote from unknownna |
(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 |
(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. |
(0019442) unknownna (updater) 2018-08-28 02:27 |
Quote from unknownna I split this issue into its own ticket and made it easily reproducible: 0003469: Client fires weapon too early after map resets |
(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. |
(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? |
(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. |
(0020477) Edward-san (developer) 2019-04-07 20:05 |
Please check with the build from 0003470:0020476 . |
(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. |
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 |
Copyright © 2000 - 2024 MantisBT Team |