0002607: Weapon sync regression in 3.0

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

Does anybody know in which revision of 3.0 this started?

(0014704)
WaTaKiD (updater)
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 (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).

(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.

(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:'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 (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' ).

(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?

(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?

(0014810)
WaTaKiD (updater)
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 (updater)
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 (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.

(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:'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 (developer)
2016-05-04 08:45

Can you try again with this changeset?

(0014815)
WaTaKiD (updater)
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 (developer)
2016-05-04 16:16

Urgh okay ... can you try this:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/65c9f13389dfe211a602647c8df0fd89cc3c350a [^]' ?

(0014817)
WaTaKiD (updater)
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 (developer)
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 (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?

(0014839)
Edward-san (developer)
2016-05-08 20:51

A workaround was added with this changeset:'https://bitbucket.org/Torr_Samaho/zandronum/commits/2ad9d0af90838a40076af4e7367f9954ab303d9c [^]' .

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

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

I'd like to know which mods are breaking, just for curiosity.

(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.

(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.)'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 (developer)
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 (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:'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 (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?

(0015044)
Edward-san (developer)
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 (developer)
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 (updater)
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 (administrator)
2016-06-07 18:54

Do you have the server console log that corresponds to this demo?

(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):'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 (updater)
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 (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..

(0015053)
WaTaKiD (updater)
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 (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.

'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 (developer)
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 (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.

(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.

(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.

(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?

(0018841)
Leonard (developer)
2017-11-09 11:26

Yup, you could make a PR right away if you want.

(0018845)
Edward-san (developer)
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 (developer)
2017-11-13 17:56

It could be nice if somebody else could test the patch in 0002607:0018845 before merging it.

(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.

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

Notes
(0014297) Torr Samaho (administrator) 2016-02-02 07:10	Does anybody know in which revision of 3.0 this started?

(0014704) WaTaKiD (updater) 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 (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).

(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.

(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:'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 (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' ).

(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?

(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?

(0014810) WaTaKiD (updater) 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 (updater) 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 (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.

(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:'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 (developer) 2016-05-04 08:45	Can you try again with this changeset?

(0014815) WaTaKiD (updater) 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 (developer) 2016-05-04 16:16	Urgh okay ... can you try this:'https://bitbucket.org/zandronum/zandronum-sandbox/commits/65c9f13389dfe211a602647c8df0fd89cc3c350a [^]' ?

(0014817) WaTaKiD (updater) 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 (developer) 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 (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?

(0014839) Edward-san (developer) 2016-05-08 20:51	A workaround was added with this changeset:'https://bitbucket.org/Torr_Samaho/zandronum/commits/2ad9d0af90838a40076af4e7367f9954ab303d9c [^]' .

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

(0015032) Edward-san (developer) 2016-06-06 00:59	I'd like to know which mods are breaking, just for curiosity.

(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.

(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.)'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 (developer) 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 (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:'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 (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?

(0015044) Edward-san (developer) 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 (developer) 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 (updater) 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 (administrator) 2016-06-07 18:54	Do you have the server console log that corresponds to this demo?

(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):'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 (updater) 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 (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..

(0015053) WaTaKiD (updater) 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 (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. '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 (developer) 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 (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.

(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.

(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.

(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?

(0018841) Leonard (developer) 2017-11-09 11:26	Yup, you could make a PR right away if you want.

(0018845) Edward-san (developer) 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 (developer) 2017-11-13 17:56	It could be nice if somebody else could test the patch in 0002607:0018845 before merging it.

(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.