MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002607Zandronum[All Projects] Bugpublic2016-02-01 00:212018-04-20 07:09
Reporterunknownna 
Assigned ToEdward-san 
PriorityurgentSeveritymajorReproducibilityalways
StatusresolvedResolutionfixed 
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.

Demo

zandronum -iwad doom2.wad -playdemo 3.0_weapondesync.cld
Additional InformationI tested this with Zandronum 3.0-alpha-160131-2023.
TagsNo tags attached.
Relationships
parent of 0002748resolved Edward-san Changset 9556:54c5571372c0 Isn't supposed to affect A_GunFlash, but it does. 
Attached Files? 3.0_weapondesync.cld (46,325) 2016-02-01 00:21
/tracker/file_download.php?file_id=1718&type=bug
? 3.0_wepdesync_predict-off.cld (59,643) 2016-04-15 06:58
/tracker/file_download.php?file_id=1788&type=bug
? 3.0_wepdesync-71e5da2.cld (108,836) 2016-06-07 01:13
/tracker/file_download.php?file_id=1820&type=bug
? 3.0_wepdesync-473098b.cld (127,064) 2016-06-07 01:14
/tracker/file_download.php?file_id=1821&type=bug
? 3.0_wepdesync-756ec0a.cld (284,106) 2016-06-07 16:39
/tracker/file_download.php?file_id=1822&type=bug
? 3.0_wepdesync-756ec0a-predict-off.cld (180,222) 2016-06-07 18:22
/tracker/file_download.php?file_id=1823&type=bug
log serverlog.txt__2016_06_07-12_05_36.log (1,785) 2016-06-07 19:08
/tracker/file_download.php?file_id=1824&type=bug
Issue History
Date ModifiedUsernameFieldChange
2016-02-01 00:21unknownnaNew Issue
2016-02-01 00:21unknownnaFile Added: 3.0_weapondesync.cld
2016-02-01 00:22unknownnaStatusnew => confirmed
2016-02-01 00:22unknownnaDescription Updatedbug_revision_view_page.php?rev_id=8621#r8621
2016-02-01 00:24unknownnaSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=8623#r8623
2016-02-01 09:08Edward-sanProduct Version3.0 => 3.0-beta
2016-02-02 07:10Torr SamahoNote Added: 0014297
2016-04-10 19:08Torr SamahoTarget Version => 3.0
2016-04-13 01:38WaTaKiDNote Added: 0014704
2016-04-13 10:17Edward-sanNote Added: 0014705
2016-04-13 10:28Edward-sanNote Edited: 0014705bug_revision_view_page.php?bugnote_id=14705#r8905
2016-04-15 06:30Torr SamahoNote Added: 0014717
2016-04-15 06:30Torr SamahoAssigned To => Torr Samaho
2016-04-15 06:30Torr SamahoStatusconfirmed => feedback
2016-04-15 06:31Torr SamahoNote Edited: 0014717bug_revision_view_page.php?bugnote_id=14717#r8911
2016-04-15 06:58WaTaKiDFile Added: 3.0_wepdesync_predict-off.cld
2016-04-15 07:00WaTaKiDNote Added: 0014718
2016-04-15 07:00WaTaKiDNote Edited: 0014718bug_revision_view_page.php?bugnote_id=14718#r8913
2016-04-30 17:02Edward-sanNote Added: 0014775
2016-05-03 19:18Torr SamahoNote Added: 0014808
2016-05-04 00:18Edward-sanNote Added: 0014809
2016-05-04 00:18WaTaKiDNote Added: 0014810
2016-05-04 05:08WaTaKiDNote Added: 0014811
2016-05-04 05:59Torr SamahoNote Added: 0014812
2016-05-04 06:28WaTaKiDNote Added: 0014813
2016-05-04 06:29WaTaKiDNote Edited: 0014813bug_revision_view_page.php?bugnote_id=14813#r8970
2016-05-04 06:31WaTaKiDNote Edited: 0014813bug_revision_view_page.php?bugnote_id=14813#r8971
2016-05-04 08:45Edward-sanNote Added: 0014814
2016-05-04 15:29WaTaKiDNote Added: 0014815
2016-05-04 16:16Edward-sanNote Added: 0014816
2016-05-04 16:52WaTaKiDNote Added: 0014817
2016-05-04 17:00Edward-sanNote Added: 0014818
2016-05-05 19:12Torr SamahoNote Added: 0014824
2016-05-08 20:51Edward-sanNote Added: 0014839
2016-05-08 20:51Edward-sanStatusfeedback => needs testing
2016-06-05 06:57StrikerMan780Note Added: 0015019
2016-06-05 10:31DuskRelationship addedparent of 0002748
2016-06-05 21:53StrikerMan780Note Edited: 0015019bug_revision_view_page.php?bugnote_id=15019#r9058
2016-06-05 21:54StrikerMan780Note Edited: 0015019bug_revision_view_page.php?bugnote_id=15019#r9059
2016-06-05 21:54StrikerMan780Note Edited: 0015019bug_revision_view_page.php?bugnote_id=15019#r9060
2016-06-06 00:59Edward-sanNote Added: 0015032
2016-06-06 06:04Torr SamahoNote Added: 0015034
2016-06-06 06:21StrikerMan780Note Added: 0015035
2016-06-06 06:22StrikerMan780Note Edited: 0015035bug_revision_view_page.php?bugnote_id=15035#r9087
2016-06-06 22:32StrikerMan780Note Edited: 0015035bug_revision_view_page.php?bugnote_id=15035#r9095
2016-06-06 22:35StrikerMan780Note Edited: 0015035bug_revision_view_page.php?bugnote_id=15035#r9096
2016-06-06 22:36StrikerMan780Note Edited: 0015035bug_revision_view_page.php?bugnote_id=15035#r9097
2016-06-06 22:38StrikerMan780Note Edited: 0015035bug_revision_view_page.php?bugnote_id=15035#r9098
2016-06-06 22:39StrikerMan780Note Edited: 0015035bug_revision_view_page.php?bugnote_id=15035#r9099
2016-06-06 22:40StrikerMan780Note Edited: 0015035bug_revision_view_page.php?bugnote_id=15035#r9100
2016-06-07 00:29Edward-sanNote Added: 0015041
2016-06-07 01:13WaTaKiDNote Added: 0015042
2016-06-07 01:13WaTaKiDFile Added: 3.0_wepdesync-71e5da2.cld
2016-06-07 01:14WaTaKiDFile Added: 3.0_wepdesync-473098b.cld
2016-06-07 01:14WaTaKiDNote Edited: 0015042bug_revision_view_page.php?bugnote_id=15042#r9102
2016-06-07 01:14WaTaKiDNote Edited: 0015042bug_revision_view_page.php?bugnote_id=15042#r9103
2016-06-07 05:58Torr SamahoNote Added: 0015043
2016-06-07 09:10Edward-sanNote Added: 0015044
2016-06-07 09:46Edward-sanNote Edited: 0015044bug_revision_view_page.php?bugnote_id=15044#r9105
2016-06-07 10:21Edward-sanNote Edited: 0015044bug_revision_view_page.php?bugnote_id=15044#r9106
2016-06-07 10:34Edward-sanNote Added: 0015045
2016-06-07 10:35Edward-sanNote Edited: 0015045bug_revision_view_page.php?bugnote_id=15045#r9108
2016-06-07 16:39WaTaKiDFile Added: 3.0_wepdesync-756ec0a.cld
2016-06-07 16:39WaTaKiDNote Added: 0015047
2016-06-07 18:22WaTaKiDFile Added: 3.0_wepdesync-756ec0a-predict-off.cld
2016-06-07 18:23WaTaKiDNote Edited: 0015047bug_revision_view_page.php?bugnote_id=15047#r9110
2016-06-07 18:54Torr SamahoNote Added: 0015049
2016-06-07 19:08WaTaKiDFile Added: serverlog.txt__2016_06_07-12_05_36.log
2016-06-07 19:10WaTaKiDNote Added: 0015050
2016-06-07 19:43WaTaKiDNote Added: 0015051
2016-06-07 19:50Edward-sanNote Added: 0015052
2016-06-07 19:50Edward-sanNote Edited: 0015052bug_revision_view_page.php?bugnote_id=15052#r9112
2016-06-07 20:21Edward-sanNote Edited: 0015052bug_revision_view_page.php?bugnote_id=15052#r9113
2016-06-07 21:16WaTaKiDNote Added: 0015053
2016-06-07 21:56StrikerMan780Note Added: 0015054
2016-06-08 11:04Edward-sanNote Added: 0015057
2016-07-26 21:47StrikerMan780Note Added: 0015411
2017-01-31 08:15StrikerMan780Note Edited: 0015411bug_revision_view_page.php?bugnote_id=15411#r10100
2017-02-15 16:41StrikerMan780Note Added: 0016866
2017-02-15 16:41StrikerMan780Note Edited: 0016866bug_revision_view_page.php?bugnote_id=16866#r10182
2017-02-15 16:42StrikerMan780Note Edited: 0016866bug_revision_view_page.php?bugnote_id=16866#r10183
2017-02-15 16:47StrikerMan780Note Edited: 0016866bug_revision_view_page.php?bugnote_id=16866#r10184
2017-02-15 16:48StrikerMan780Note Edited: 0016866bug_revision_view_page.php?bugnote_id=16866#r10185
2017-02-15 17:06StrikerMan780Note Edited: 0015054bug_revision_view_page.php?bugnote_id=15054#r10187
2017-02-15 17:18StrikerMan780Note Edited: 0016866bug_revision_view_page.php?bugnote_id=16866#r10188
2017-02-15 17:18StrikerMan780Note Edited: 0016866bug_revision_view_page.php?bugnote_id=16866#r10189
2017-02-17 19:24StrikerMan780Note Edited: 0016866bug_revision_view_page.php?bugnote_id=16866#r10201
2017-04-27 01:47Ru5tK1ngStatusneeds testing => feedback
2017-10-29 17:55Edward-sanTarget Version3.0 => 3.1
2017-11-08 23:58LeonardNote Added: 0018833
2017-11-08 23:59LeonardNote Edited: 0018833bug_revision_view_page.php?bugnote_id=18833#r11317
2017-11-09 00:02LeonardStatusfeedback => assigned
2017-11-09 00:02LeonardAssigned ToTorr Samaho => Edward-san
2017-11-09 08:54Edward-sanNote Added: 0018838
2017-11-09 11:26LeonardNote Added: 0018841
2017-11-09 18:01Edward-sanNote Added: 0018845
2017-11-09 18:01Edward-sanStatusassigned => needs review
2017-11-13 17:56Edward-sanNote Added: 0018877
2017-11-13 17:56Edward-sanStatusneeds review => needs testing
2018-04-18 06:48StrikerMan780Note Added: 0019172
2018-04-20 07:09DuskStatusneeds testing => resolved
2018-04-20 07:09DuskFixed in Version => 3.1
2018-04-20 07:09DuskResolutionopen => fixed

Notes
(0014297)
Torr Samaho   
2016-02-02 07:10   
Does anybody know in which revision of 3.0 this started?
(0014704)
WaTaKiD   
2016-04-13 01:38   
ive narrowed it down to this commit as the cause:'https://bitbucket.org/Torr_Samaho/zandronum/commits/b42e043b67dd74442f4f5a293f3a8e89afead53b [^]'
(0014705)
Edward-san   
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).
(0014717)
Torr Samaho   
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.
(0014718)
WaTaKiD   
2016-04-15 07:00   
attached a roughly 30 sec demo using changeset c4104ac (build here:'https://www.dropbox.com/s/udt5f65qz6pt2ek/zandronum-3.0-r160403-2002-c4104ac-windows.zip?dl=0 [^]' )

the server had sv_useticbuffer 1 and the client had cl_predict_players 0, desync was still reproducable
(0014775)
Edward-san   
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' ).
(0014808)
Torr Samaho   
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?
(0014809)
Edward-san   
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?
(0014810)
WaTaKiD   
2016-05-04 00:18   
i dont know if its too early or not, but since'https://bitbucket.org/Torr_Samaho/zandronum/commits/54c5571372c0d03577509efb0da9f7f45aac080a [^]' 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
(0014811)
WaTaKiD   
2016-05-04 05:08   
i tested'https://bitbucket.org/zandronum/zandronum-sandbox/commits/55ee9c1edec102e84625c89940e8b956b3576858 [^]' with cl_predict_players 0 and 1, and desync was still reproducable
(0014812)
Torr Samaho   
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.
(0014813)
WaTaKiD   
2016-05-04 06:28   
(edited on: 2016-05-04 06:31)
i believe this is the thread for the original fix:'http://forum.zdoom.org/viewtopic.php?f=7&t=31689 [^]'

and this is for the 'revert' commit:'http://forum.zdoom.org/viewtopic.php?f=7&t=50308 [^]'
(0014814)
Edward-san   
2016-05-04 08:45   
Can you try again with this changeset?
(0014815)
WaTaKiD   
2016-05-04 15:29   
with'https://bitbucket.org/zandronum/zandronum-sandbox/commits/e26addcb0345d4a5753c97bdf43d3f924e40b374 [^]' and cl_predict_players 0/1 i was still able to desync
(0014816)
Edward-san   
2016-05-04 16:16   
Urgh okay ... can you try this:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/65c9f13389dfe211a602647c8df0fd89cc3c350a [^]' ?
(0014817)
WaTaKiD   
2016-05-04 16:52   
with'https://bitbucket.org/zandronum/zandronum-sandbox/commits/65c9f13389dfe211a602647c8df0fd89cc3c350a [^]' 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
(0014818)
Edward-san   
2016-05-04 17:00   
Of course, that contains the revert of the whole fix. We should try fixing the problem, though.
(0014824)
Torr Samaho   
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?
(0014839)
Edward-san   
2016-05-08 20:51   
A workaround was added with this changeset:'https://bitbucket.org/Torr_Samaho/zandronum/commits/2ad9d0af90838a40076af4e7367f9954ab303d9c [^]' .
(0015019)
StrikerMan780   
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).
(0015032)
Edward-san   
2016-06-06 00:59   
I'd like to know which mods are breaking, just for curiosity.
(0015034)
Torr Samaho   
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.
(0015035)
StrikerMan780   
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.)'http://forum.zdoom.org/viewtopic.php?f=2&t=31689 [^]'

Someone should test if the de-synch happens right on the first shot, or only after consecutive shots while holding the fire button.
(0015041)
Edward-san   
2016-06-07 00:29   
Okay, I made a back out commit on top of the latest 3.0 upstream changeset:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/71e5da2d57a9a7e3bb0545ac6034cb3000dcad0b [^]'

and on top of this I made this debug changeset:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/473098beccbbad53041a1e780ae0365335efc092 [^]' .

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?
(0015042)
WaTaKiD   
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:'https://www.dropbox.com/s/hpiwu3myt6mn7xo/zandronum-3.0-r160606-2046-71e5da2-windows.zip?dl=0 [^]'

and a demo using it:'http://zandronum.com/tracker/file_download.php?file_id=1820&type=bug [^]'

and here is a build with the debug changeset:'https://www.dropbox.com/s/5cjfz581ib9lgme/zandronum-3.0-r160607-0020-473098b-windows.zip?dl=0 [^]'

and a demo using it:'http://zandronum.com/tracker/file_download.php?file_id=1821&type=bug [^]'
(0015043)
Torr Samaho   
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?
(0015044)
Edward-san   
2016-06-07 09:10   
(edited on: 2016-06-07 10:21)
The demo'http://zandronum.com/tracker/file_download.php?file_id=1821&type=bug [^]' 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'.
(0015045)
Edward-san   
2016-06-07 10:34   
(edited on: 2016-06-07 10:35)
Improved the message with this changeset:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/756ec0afbd20c4a3f8711bef521a21c3ed5899cf [^]' . A new build must be done and also a new demo must be created with the new build.
(0015047)
WaTaKiD   
2016-06-07 16:39   
(edited on: 2016-06-07 18:23)
heres a build with the improved message:'https://www.dropbox.com/s/rfo8cnm8if7g12d/zandronum-3.0-r160607-1031-756ec0a-windows.zip?dl=0 [^]'

demo:'http://zandronum.com/tracker/file_download.php?file_id=1822&type=bug [^]'

edit: heres a demo with cl_predict_players 0:'http://zandronum.com/tracker/file_download.php?file_id=1823&type=bug [^]'
(0015049)
Torr Samaho   
2016-06-07 18:54   
Do you have the server console log that corresponds to this demo?
(0015050)
WaTaKiD   
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):'http://zandronum.com/tracker/file_download.php?file_id=1824&type=bug [^]'

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
(0015051)
WaTaKiD   
2016-06-07 19:43   
edward-san made this:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/a083e70be4e93e0966b639d6b84685c915de93af [^]'

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
(0015052)
Edward-san   
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..
(0015053)
WaTaKiD   
2016-06-07 21:16   
edward-san made another:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/405521e792e71ee9a52f46952853b7ea3eb0a383 [^]'

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
(0015054)
StrikerMan780   
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.

'http://www.mediafire.com/download/4x5o69vpp5bq0b1/weapons_of_saturn.pk3 [^]'

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.
(0015057)
Edward-san   
2016-06-08 11:04   
Quote
also, the ps_flash debug messages werent working correctly if there was more than 1 client


'https://bitbucket.org/zandronum/zandronum-sandbox/commits/e0d95cad9594d44b821bd2838ecc9b36599edfd6 [^]' and'https://bitbucket.org/zandronum/zandronum-sandbox/commits/c7ab864a2f31bfb51c5fdeb46fca9f6f63e60012 [^]' 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.
(0015411)
StrikerMan780   
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.
(0016866)
StrikerMan780   
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.
(0018833)
Leonard   
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.
(0018838)
Edward-san   
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?
(0018841)
Leonard   
2017-11-09 11:26   
Yup, you could make a PR right away if you want.
(0018845)
Edward-san   
2017-11-09 18:01   
'https://bitbucket.org/Torr_Samaho/zandronum-stable/pull-requests/64/fix-of-old-30-weapon-desync-caused-by/diff [^]'
(0018877)
Edward-san   
2017-11-13 17:56   
It could be nice if somebody else could test the patch in 0002607:0018845 before merging it.
(0019172)
StrikerMan780   
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.