Zandronum Chat @
Get the latest version: 3.0
Source Code

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002607Zandronum[All Projects] Bugpublic2016-02-01 00:212018-04-20 07:09
Assigned ToEdward-san 
PlatformOSOS Version
Product Version3.0-beta 
Target Version3.1Fixed in Version3.1 
Summary0002607: Weapon sync regression in 3.0
DescriptionSorry for opening up another can of worms here, but the weapon synchronization is badly broken in 3.0 again. IIRC, we fixed this in 2.1.2, but there were some issues with 3.0 that we put on hold.
Steps To Reproduce* Gamer's Proxy : combined ping at 140

1. zandronum -iwad doom2.wad -host +sv_cheats 1 +sv_nomonsters 1 +sv_infiniteammo 1
2. Connect a client to the server with an emulated ping of 140
3. Join the game.
4. "give all" in the console.
5. Select between the chaingun and rocket launcher using weapprev/weapnext while rapidly pressing +attack, sometimes allowing the rocket launcher to fire a rocket. It will desync very quickly.


zandronum -iwad doom2.wad -playdemo 3.0_weapondesync.cld
Additional InformationI tested this with Zandronum 3.0-alpha-160131-2023.
Attached Files? file icon 3.0_weapondesync.cld [^] (46,325 bytes) 2016-02-01 00:21
? file icon 3.0_wepdesync_predict-off.cld [^] (59,643 bytes) 2016-04-15 06:58
? file icon 3.0_wepdesync-71e5da2.cld [^] (108,836 bytes) 2016-06-07 01:13
? file icon 3.0_wepdesync-473098b.cld [^] (127,064 bytes) 2016-06-07 01:14
? file icon 3.0_wepdesync-756ec0a.cld [^] (284,106 bytes) 2016-06-07 16:39
? file icon 3.0_wepdesync-756ec0a-predict-off.cld [^] (180,222 bytes) 2016-06-07 18:22
log file icon serverlog.txt__2016_06_07-12_05_36.log [^] (1,785 bytes) 2016-06-07 19:08

- Relationships
parent of 0002748resolvedEdward-san Changset 9556:54c5571372c0 Isn't supposed to affect A_GunFlash, but it does. 

-  Notes
User avatar (0014297)
Torr Samaho (administrator)
2016-02-02 07:10

Does anybody know in which revision of 3.0 this started?
User avatar (0014704)
WaTaKiD (updater)
2016-04-13 01:38

ive narrowed it down to this commit as the cause: [^]
User avatar (0014705)
Edward-san (developer)
2016-04-13 10:17
edited on: 2016-04-13 10:28

I guess the problem is caused by this specific commit. I'd like to mention that graf partially reverted that with this commit (which is, the standard weapons are fixed. not the customized ones).

User avatar (0014717)
Torr Samaho (administrator)
2016-04-15 06:30
edited on: 2016-04-15 06:31

Can you check whether the desync still happens if you set "cl_predict_players 0" on the client? If not, it's very likely that our player prediction needs to be adjusted to the ZDoom fix in question.

Would also be great if you record a client side demo of the effect with the latest 3.0 version, i.e. changeset c4104ac76a0549c2bcb039384d7cb8bdc9b75b0b.

User avatar (0014718)
WaTaKiD (updater)
2016-04-15 07:00
edited on: 2016-04-15 07:00

attached a roughly 30 sec demo using changeset c4104ac (build here: [^] )

the server had sv_useticbuffer 1 and the client had cl_predict_players 0, desync was still reproducable

User avatar (0014775)
Edward-san (developer)
2016-04-30 17:02

The fix was ported in zandronum-zdoom-sync with this changeset, but the change must be propagated to the function A_CustomFireBullets ( probably with a new bool parameter 'calledbystockdoomweapon' ).
User avatar (0014808)
Torr Samaho (administrator)
2016-05-03 19:18

After a closer look, I'm not sure whether this fix applies to our handling of the stock weapons. A_CustomFireBullets does not even call P_SetPsprite. Our way should be equivalent to replacing the stock weapon function, e.g. A_FireShotgun, with A_FireBullets followed by A_GunFlash. Does the latter combination work properly in ZDoom?
User avatar (0014809)
Edward-san (developer)
2016-05-04 00:18

No idea, but then I saw the A_GunFlash code and tried this approach. Does this commit help at all with the desync?
User avatar (0014810)
WaTaKiD (updater)
2016-05-04 00:18

i dont know if its too early or not, but since [^] was added, i went and tested it anyways

with cl_predict_players 0 or 1, the desync was still reproducable

i can provide the build used and demos, if necessary
User avatar (0014811)
WaTaKiD (updater)
2016-05-04 05:08

i tested [^] with cl_predict_players 0 and 1, and desync was still reproducable
User avatar (0014812)
Torr Samaho (administrator)
2016-05-04 05:59

Thanks for checking!

Is there any background information on the original ZDoom fix? Like a bug report? Currently, I'm considering to simply deactivate the whole fix for the time being.
User avatar (0014813)
WaTaKiD (updater)
2016-05-04 06:28
edited on: 2016-05-04 06:31

i believe this is the thread for the original fix: [^]

and this is for the 'revert' commit: [^]

User avatar (0014814)
Edward-san (developer)
2016-05-04 08:45

Can you try again with this changeset?
User avatar (0014815)
WaTaKiD (updater)
2016-05-04 15:29

with [^] and cl_predict_players 0/1 i was still able to desync
User avatar (0014816)
Edward-san (developer)
2016-05-04 16:16

Urgh okay ... can you try this: [^] ?
User avatar (0014817)
WaTaKiD (updater)
2016-05-04 16:52

with [^] i was unable to desync with cl_predict_players 0 or 1, i even cranked up the emulated ping from 140 to 300 and ran a couple more tests and while it was expectedly laggy, it still did not desync
User avatar (0014818)
Edward-san (developer)
2016-05-04 17:00

Of course, that contains the revert of the whole fix. We should try fixing the problem, though.
User avatar (0014824)
Torr Samaho (administrator)
2016-05-05 19:12

The only possible explanation I have so far is that the fix affects the timing on clients and server differently. Can somebody try to come up with an example wad based on the stock weapons that still has the sync problems, but reveals whether the flash state on server and client have effectively the same length?
User avatar (0014839)
Edward-san (developer)
2016-05-08 20:51

A workaround was added with this changeset: [^] .
User avatar (0015019)
StrikerMan780 (reporter)
2016-06-05 06:57
edited on: 2016-06-05 21:54

I hope this can get solved without disabling the fix altogether, as this is breaking mods. (Most mods depend on the new behavior of allowing 1-tic flashes, otherwise we get misaligned flashes or flashes not showing at all, also fucking up timing for codepointers on the flash state).

User avatar (0015032)
Edward-san (developer)
2016-06-06 00:59

I'd like to know which mods are breaking, just for curiosity.
User avatar (0015034)
Torr Samaho (administrator)
2016-06-06 06:04

Unfortunately, ZDoom puts us in a difficult situation here. Since ZDoom's fix breaks backwards compatibility, this means we either break backwards compatibility with existing mods or we break compatibility with mods that rely on ZDoom's new behavior. Not to mention that we still don't know why the fix breaks c/s weapon sync yet.
User avatar (0015035)
StrikerMan780 (reporter)
2016-06-06 06:21
edited on: 2016-06-06 22:40

Keep in mind Graf *partially* reversed the fix to keep vanilla Doom behavior where it counts, while keeping the new behavior for A_GunFlash (Which, is MUCH preferred... the weird-ass behavior of old was infuriating in a lot of situations for modders.)

EDIT: Edward-San, it Basically affects every mod designed for ZDoom 2.7.1 and later.

By the way, this is the original code submission, dunno if there's anything that may hint what may have been overlooked. (Perhaps the stuff about BT_ATTACK? Or perhaps the behavior after A_Refire and such in the spoiler.) [^]

Someone should test if the de-synch happens right on the first shot, or only after consecutive shots while holding the fire button.

User avatar (0015041)
Edward-san (developer)
2016-06-07 00:29

Okay, I made a back out commit on top of the latest 3.0 upstream changeset: [^]

and on top of this I made this debug changeset: [^] .

Essentially it prints on the screen what the server and the client know about the player's sprite status. Torr, do you think it's feasible like this?
User avatar (0015042)
WaTaKiD (updater)
2016-06-07 01:13
edited on: 2016-06-07 01:14

as requested, here is a build with edward-san's backed out commit: [^]

and a demo using it: [^]

and here is a build with the debug changeset: [^]

and a demo using it: [^]

User avatar (0015043)
Torr Samaho (administrator)
2016-06-07 05:58

Quote from Edward-san

Essentially it prints on the screen what the server and the client know about the player's sprite status. Torr, do you think it's feasible like this?

You may also want to include the current gametic in the output. I tried something similar locally a while back, but didn't get differing output on client and server. Does this show discrepancies?
User avatar (0015044)
Edward-san (developer)
2016-06-07 09:10
edited on: 2016-06-07 10:21

The demo [^] shows that when the processPending checking in P_MovePsprites is reached, the client has always its processPending 1 (I verified this with a conditional breakpoint never reached), while the server does not.

I tried with my local DOOM2 server, I didn't do anything else than switching between the pistol and the fist and indeed the client's processPending printed value is always 1.

[edit] I modified the code to run also offline, the player's processPending is the same as the client.

[edit2] You can also reproduce the discrepancy by getting both the shotgun and the supershotgun, then press continuously '3'.

User avatar (0015045)
Edward-san (developer)
2016-06-07 10:34
edited on: 2016-06-07 10:35

Improved the message with this changeset: [^] . A new build must be done and also a new demo must be created with the new build.

User avatar (0015047)
WaTaKiD (updater)
2016-06-07 16:39
edited on: 2016-06-07 18:23

heres a build with the improved message: [^]

demo: [^]

edit: heres a demo with cl_predict_players 0: [^]

User avatar (0015049)
Torr Samaho (administrator)
2016-06-07 18:54

Do you have the server console log that corresponds to this demo?
User avatar (0015050)
WaTaKiD (updater)
2016-06-07 19:10

i do not, but here is a server log from a new demo ive recorded (also with cl_predict_players 0): [^]

if needed, i can provide said demo, and even a client log, although to me it doesnt seem like theres any useful info in either of the logs, just me connecting, give all, and disconnecting
User avatar (0015051)
WaTaKiD (updater)
2016-06-07 19:43

edward-san made this: [^]

and my results:
<WaTaKiD>tested with both cl_predict_players 0 and 1
<WaTaKiD>after trying for a minute and a half with each, i didnt desync
User avatar (0015052)
Edward-san (developer)
2016-06-07 19:50
edited on: 2016-06-07 20:21

I'll try to explain that: when trying to switch weapons, after increasing the gametic, the server can call P_PlayerThink (which calls P_MovePsprites) from ClientMoveCommand::process before P_NewPspriteTick is called (from P_Ticker).

I guess the proper solution is to move the P_NewPspriteTick call in SERVER_Tick.. [edit] and nope, it doesn't fix the problem. Investigating further..

User avatar (0015053)
WaTaKiD (updater)
2016-06-07 21:16

edward-san made another: [^]

we did some testing on a server, and while we did not see ourselves desync, we did see eachother desync while f12ing

also, the ps_flash debug messages werent working correctly if there was more than 1 client
User avatar (0015054)
StrikerMan780 (reporter)
2016-06-07 21:56
edited on: 2017-02-15 17:06

Here's a mod that can be used to test. Weapons of Saturn. The minigun depends on the new flash behavior of 2.7.1. [^]

You'll still see a flash on the minigun, but it won't show the proper animation like in 2.7.1. Frames are missing.

User avatar (0015057)
Edward-san (developer)
2016-06-08 11:04

also, the ps_flash debug messages werent working correctly if there was more than 1 client [^] and [^] makes the debug messages work for two clients (I wish I could reduce the font size even more ...).
With these changesets, the eachother desync makes the client and server messages inconsistent (like the client showing the ps_flash and the server doesn't and viceversa).

Anyways, we tested also latest 3.0 beta and the eachother desync with f12 happened there, too.
User avatar (0015411)
StrikerMan780 (reporter)
2016-07-26 21:47
edited on: 2017-01-31 08:15

Any progress, or an idea what may be causing the de-synch?

The fact this ticket is stagnating is worrying... The current behavior in Zandronum is breaking a shitload of 2.7.1+ mods, including my own.

User avatar (0016866)
StrikerMan780 (reporter)
2017-02-15 16:41
edited on: 2017-02-17 19:24

@Edward-san I'd personally move the P_MovePsprites call instead of moving P_NewPspriteTick, because P_MovePsprites is the only function that makes use of the psp->ProcessPending variable in any meaningful way.

OR, try putting player->psprites[ps_flash].processPending = false; under the "P_SetPsprite (player, ps_flash, flash);" call in A_GunFlash instead of putting it inside P_SetPsprite iteslf.

Also, question: Do both the client and server execute A_GunFlash codepointers, not only for themselves, but everyone else? If not, I could see where problems could arise.

It seems the way the server and client execute the states are inconsistent, because offline, with the way things are, the 1st tic is skipped for a flash, but online, the client doesn't skip the 1st tic (at least most of the time, it's kind of random), but the server does.

User avatar (0018833)
Leonard (developer)
2017-11-08 23:58
edited on: 2017-11-08 23:59

@Edward: I pulled your commits, rebased them and adapted the last one to the recent changes introduced by 0003315.

By the way, an easy way to reproduce this issue is to emulate ping spikes (which will force the use of the ticbuffer).
Using the settings described in 0002330:0012884 and an alias, I can reproduce this issue 100% of the time (given the fix for 0002748 is applied of course) unless your fix is applied.

Here's the alias I'm using:
use rocketlauncher;wait 28;+attack;wait;-attack;weapnext

As for the desync occuring when spying on other players, I think this is a different issue that should be discussed in a separate ticket.

Edit: here's the link to the commits.

User avatar (0018838)
Edward-san (developer)
2017-11-09 08:54

I re-rebased by updating my credentials: link, so the previous one can be stripped away.

So, Leonard, you confirm that my patch works fine, correct?
User avatar (0018841)
Leonard (developer)
2017-11-09 11:26

Yup, you could make a PR right away if you want.
User avatar (0018845)
Edward-san (developer)
2017-11-09 18:01 [^]
User avatar (0018877)
Edward-san (developer)
2017-11-13 17:56

It could be nice if somebody else could test the patch in 0002607:0018845 before merging it.
User avatar (0019172)
StrikerMan780 (reporter)
2018-04-18 06:48

I haven't been able to reproduce the desync in the latest 3.1 build. Used gamer proxy with pings of 140, and 200.

Since it seems related to the other A_GunFlash issue, which is now fixed, also fixed this.

Issue Community Support
This issue is already marked as resolved.
If you feel that is not the case, please reopen it and explain why.
Supporters: Combinebobnt Ivan
Opponents: No one explicitly opposes this issue yet.

- Issue History
Date Modified Username Field Change
2016-02-01 00:21 unknownna New Issue
2016-02-01 00:21 unknownna File Added: 3.0_weapondesync.cld
2016-02-01 00:22 unknownna Status new => confirmed
2016-02-01 00:22 unknownna Description Updated View Revisions
2016-02-01 00:24 unknownna Steps to Reproduce Updated View Revisions
2016-02-01 09:08 Edward-san Product Version 3.0 => 3.0-beta
2016-02-02 07:10 Torr Samaho Note Added: 0014297
2016-04-10 19:08 Torr Samaho Target Version => 3.0
2016-04-13 01:38 WaTaKiD Note Added: 0014704
2016-04-13 10:17 Edward-san Note Added: 0014705
2016-04-13 10:28 Edward-san Note Edited: 0014705 View Revisions
2016-04-15 06:30 Torr Samaho Note Added: 0014717
2016-04-15 06:30 Torr Samaho Assigned To => Torr Samaho
2016-04-15 06:30 Torr Samaho Status confirmed => feedback
2016-04-15 06:31 Torr Samaho Note Edited: 0014717 View Revisions
2016-04-15 06:58 WaTaKiD File Added: 3.0_wepdesync_predict-off.cld
2016-04-15 07:00 WaTaKiD Note Added: 0014718
2016-04-15 07:00 WaTaKiD Note Edited: 0014718 View Revisions
2016-04-30 17:02 Edward-san Note Added: 0014775
2016-05-03 19:18 Torr Samaho Note Added: 0014808
2016-05-04 00:18 Edward-san Note Added: 0014809
2016-05-04 00:18 WaTaKiD Note Added: 0014810
2016-05-04 05:08 WaTaKiD Note Added: 0014811
2016-05-04 05:59 Torr Samaho Note Added: 0014812
2016-05-04 06:28 WaTaKiD Note Added: 0014813
2016-05-04 06:29 WaTaKiD Note Edited: 0014813 View Revisions
2016-05-04 06:31 WaTaKiD Note Edited: 0014813 View Revisions
2016-05-04 08:45 Edward-san Note Added: 0014814
2016-05-04 15:29 WaTaKiD Note Added: 0014815
2016-05-04 16:16 Edward-san Note Added: 0014816
2016-05-04 16:52 WaTaKiD Note Added: 0014817
2016-05-04 17:00 Edward-san Note Added: 0014818
2016-05-05 19:12 Torr Samaho Note Added: 0014824
2016-05-08 20:51 Edward-san Note Added: 0014839
2016-05-08 20:51 Edward-san Status feedback => needs testing
2016-06-05 06:57 StrikerMan780 Note Added: 0015019
2016-06-05 10:31 Dusk Relationship added parent of 0002748
2016-06-05 21:53 StrikerMan780 Note Edited: 0015019 View Revisions
2016-06-05 21:54 StrikerMan780 Note Edited: 0015019 View Revisions
2016-06-05 21:54 StrikerMan780 Note Edited: 0015019 View Revisions
2016-06-06 00:59 Edward-san Note Added: 0015032
2016-06-06 06:04 Torr Samaho Note Added: 0015034
2016-06-06 06:21 StrikerMan780 Note Added: 0015035
2016-06-06 06:22 StrikerMan780 Note Edited: 0015035 View Revisions
2016-06-06 22:32 StrikerMan780 Note Edited: 0015035 View Revisions
2016-06-06 22:35 StrikerMan780 Note Edited: 0015035 View Revisions
2016-06-06 22:36 StrikerMan780 Note Edited: 0015035 View Revisions
2016-06-06 22:38 StrikerMan780 Note Edited: 0015035 View Revisions
2016-06-06 22:39 StrikerMan780 Note Edited: 0015035 View Revisions
2016-06-06 22:40 StrikerMan780 Note Edited: 0015035 View Revisions
2016-06-07 00:29 Edward-san Note Added: 0015041
2016-06-07 01:13 WaTaKiD Note Added: 0015042
2016-06-07 01:13 WaTaKiD File Added: 3.0_wepdesync-71e5da2.cld
2016-06-07 01:14 WaTaKiD File Added: 3.0_wepdesync-473098b.cld
2016-06-07 01:14 WaTaKiD Note Edited: 0015042 View Revisions
2016-06-07 01:14 WaTaKiD Note Edited: 0015042 View Revisions
2016-06-07 05:58 Torr Samaho Note Added: 0015043
2016-06-07 09:10 Edward-san Note Added: 0015044
2016-06-07 09:46 Edward-san Note Edited: 0015044 View Revisions
2016-06-07 10:21 Edward-san Note Edited: 0015044 View Revisions
2016-06-07 10:34 Edward-san Note Added: 0015045
2016-06-07 10:35 Edward-san Note Edited: 0015045 View Revisions
2016-06-07 16:39 WaTaKiD File Added: 3.0_wepdesync-756ec0a.cld
2016-06-07 16:39 WaTaKiD Note Added: 0015047
2016-06-07 18:22 WaTaKiD File Added: 3.0_wepdesync-756ec0a-predict-off.cld
2016-06-07 18:23 WaTaKiD Note Edited: 0015047 View Revisions
2016-06-07 18:54 Torr Samaho Note Added: 0015049
2016-06-07 19:08 WaTaKiD File Added: serverlog.txt__2016_06_07-12_05_36.log
2016-06-07 19:10 WaTaKiD Note Added: 0015050
2016-06-07 19:43 WaTaKiD Note Added: 0015051
2016-06-07 19:50 Edward-san Note Added: 0015052
2016-06-07 19:50 Edward-san Note Edited: 0015052 View Revisions
2016-06-07 20:21 Edward-san Note Edited: 0015052 View Revisions
2016-06-07 21:16 WaTaKiD Note Added: 0015053
2016-06-07 21:56 StrikerMan780 Note Added: 0015054
2016-06-08 11:04 Edward-san Note Added: 0015057
2016-07-26 21:47 StrikerMan780 Note Added: 0015411
2017-01-31 08:15 StrikerMan780 Note Edited: 0015411 View Revisions
2017-02-15 16:41 StrikerMan780 Note Added: 0016866
2017-02-15 16:41 StrikerMan780 Note Edited: 0016866 View Revisions
2017-02-15 16:42 StrikerMan780 Note Edited: 0016866 View Revisions
2017-02-15 16:47 StrikerMan780 Note Edited: 0016866 View Revisions
2017-02-15 16:48 StrikerMan780 Note Edited: 0016866 View Revisions
2017-02-15 17:06 StrikerMan780 Note Edited: 0015054 View Revisions
2017-02-15 17:18 StrikerMan780 Note Edited: 0016866 View Revisions
2017-02-15 17:18 StrikerMan780 Note Edited: 0016866 View Revisions
2017-02-17 19:24 StrikerMan780 Note Edited: 0016866 View Revisions
2017-04-27 01:47 Ru5tK1ng Status needs testing => feedback
2017-10-29 17:55 Edward-san Target Version 3.0 => 3.1
2017-11-08 23:58 Leonard Note Added: 0018833
2017-11-08 23:59 Leonard Note Edited: 0018833 View Revisions
2017-11-09 00:02 Leonard Status feedback => assigned
2017-11-09 00:02 Leonard Assigned To Torr Samaho => Edward-san
2017-11-09 08:54 Edward-san Note Added: 0018838
2017-11-09 11:26 Leonard Note Added: 0018841
2017-11-09 18:01 Edward-san Note Added: 0018845
2017-11-09 18:01 Edward-san Status assigned => needs review
2017-11-13 17:56 Edward-san Note Added: 0018877
2017-11-13 17:56 Edward-san Status needs review => needs testing
2018-04-18 06:48 StrikerMan780 Note Added: 0019172
2018-04-20 07:09 Dusk Status needs testing => resolved
2018-04-20 07:09 Dusk Fixed in Version => 3.1
2018-04-20 07:09 Dusk Resolution open => fixed

Questions or other issues? Contact Us.


Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker