0002255: Weapon desync regression

(0012391)
Catastrophe (reporter)
2015-05-25 18:24

Yeah, weapons like the SSG desync a lot for me when you hold fire as you are respawning. Of course only happens online.

(0012481)
Edward-san (developer)
2015-05-31 19:47

Sorry, can you explain how did you reproduce these? I see you used a ping emulator, but also other settings, like packet loss rate?

(0012482)
Torr Samaho (administrator)
2015-05-31 19:50

Thanks for the report and nice to see you again, unknownna!

Can you post a detailed description on what exactly needs to be done to reproduce the sync problems? To fix this, we'll have to identify when this broken and thus need to reproduce the issue.

(0012485)
Frits (reporter)
2015-05-31 22:13

Yes, this has been happening so often since 1.3 to me. It's random at best but if a play a session of survival on BE it's bound to happen a couple of times these days while pre-1.3 it was more of a rare occurance.

(0012486)
unknownna (updater)
2015-05-31 22:45

Quote from Torr Samaho
Thanks for the report and nice to see you again, unknownna!

Thanks, it's nice to see you again as well. I don't have as much time to play/test Zandronum these days as I used to, but I still check the tracker and play online every now and then.

Quote from Edward-san
Sorry, can you explain how did you reproduce these? I see you used a ping emulator, but also other settings, like packet loss rate?

Indeed, I'm using a ping emulator with an emulated ping of 251. No packet loss emulation enabled. I simply tap +attack while switching back and forth between the BFG and the rocket launcher, sometimes de-selecting a weapon before it has a chance to raise fully. It's incredibly easy to reproduce the issue.

I get the feeling that it might be caused by the implementation of the tic buffer and the subsequent re-ordering of packets that is now apparently taking place. But I could be wrong.

Quote from Frits
It's random at best but if a play a session of survival on BE it's bound to happen a couple of times these days while pre-1.3 it was more of a rare occurance.

Keep in mind that certain desyncs that occur with custom mods, e.g. Complex Doom, are caused by instances of A_Jump* being called in the DECORATE code. The client can't predict those due to the way it currently works.

(0012511)
Edward-san (developer)
2015-06-04 16:18

Can you check if by any chance it happens in this 1.4 build:'https://www.dropbox.com/s/k5od6l3dlelejyd/zandronum-1.4-150329-1535-891a78e-windows.zip?dl=0 [^]' ?

(0012512)
unknownna (updater)
2015-06-04 17:08
edited on: 2015-06-04 17:16

It also happens in that build.

BTW: It seems to happen particularly when picking up weapons for the first time after respawning.

(0012513)
Edward-san (developer)
2015-06-04 17:41

Ok, what about:

'https://www.dropbox.com/s/g3sjirgvbl31x2a/zandronum-1.4-141006-2032-1c72423-windows.zip?dl=0 [^]'

and

'https://www.dropbox.com/s/c0encmv43u88q8m/zandronum-1.4-141229-1233-69afd50-windows.zip?dl=0 [^]'

?

(0012514)
unknownna (updater)
2015-06-04 18:24

It happens in both of those builds as well.

(0012515)
Edward-san (developer)
2015-06-04 18:57

Can you check with this build:

'https://www.dropbox.com/s/nw1vmdrvfj1nq52/zandronum-1.4-141011-0904-c4c3c03-windows.zip?dl=0 [^]'

?

(0012516)
unknownna (updater)
2015-06-04 19:21

It also happens in that build. If it happens in 2.0 and 3.0, wouldn't it be obvious that it also happens in 1.4 as well?

(0012517)
Edward-san (developer)
2015-06-04 19:23
edited on: 2015-06-04 19:26

Except that it happens with builds referring to a few commits after 1.3, which is strange. Are you really sure it doesn't happen in 1.3?

[edit]Okay sorry, I didn't read that you could reproduce in 1.3 as well.

(0012518)
Edward-san (developer)
2015-06-04 19:36
edited on: 2015-06-04 19:42

Your ticket description says that "It's worse in 2.0 and 3.0.", so I was expecting an answer regarding if the 'worse' could happen also in 1.4, hence all these builds I linked above.

Let me ask again:

Which is worse between 1.3, this build and 2.0?

'https://www.dropbox.com/s/k5od6l3dlelejyd/zandronum-1.4-150329-1535-891a78e-windows.zip?dl=0 [^]' .

(0012519)
unknownna (updater)
2015-06-04 19:57

I'd say that 1.3 and and 1.4 feel the same with 2.0 being the worst.

(0012520)
Edward-san (developer)
2015-06-04 20:53
edited on: 2015-06-04 21:04

Alright. Now let's prioritize the 2.0 issue. Can you check these three builds:

'https://www.dropbox.com/s/egtb1ra75cmgklt/zandronum-2.0-140705-1713-8850124-windows.zip?dl=0 [^]'

'https://www.dropbox.com/s/rwe7o6qq16zcqyl/zandronum-2.0-130907-1034-45233a4-windows.zip?dl=0 [^]'

'https://www.dropbox.com/s/lzvjzpb1ivzp3go/zandronum-2.0-131012-1754-38f53d97-windows.zip?dl=0 [^]'

?

(0012521)
unknownna (updater)
2015-06-04 21:13

There's a difference between the two:

'https://www.dropbox.com/s/rwe7o6qq16zcqyl/zandronum-2.0-130907-1034-45233a4-windows.zip?dl=0 [^]'

This one feels better than 1.3 and 1.4. I couldn't desync it even once.

'https://www.dropbox.com/s/egtb1ra75cmgklt/zandronum-2.0-140705-1713-8850124-windows.zip?dl=0 [^]'

This one is broken. Not sure if it's worse than 1.3 or 1.4 though.

(0012522)
Edward-san (developer)
2015-06-04 21:20
edited on: 2015-06-04 21:20

Can you recheck the previous comment? There's also another build I added later.

(0012523)
unknownna (updater)
2015-06-04 21:28
edited on: 2015-06-04 21:38

'https://www.dropbox.com/s/lzvjzpb1ivzp3go/zandronum-2.0-131012-1754-38f53d97-windows.zip?dl=0 [^]'

~~This build is just as bad as 2.0/3.0.~~

Edit:

Scratch that, I accidentally hosted a 2.0 server and joined with the build. This build seems to be just as good as:

'https://www.dropbox.com/s/rwe7o6qq16zcqyl/zandronum-2.0-130907-1034-45233a4-windows.zip?dl=0 [^]'

(0012525)
Edward-san (developer)
2015-06-04 22:14

'https://www.dropbox.com/s/lfnvgq47ld5jcw5/zandronum-2.0-131227-1408-9e86a61-windows.zip?dl=0 [^]' ?

(0012526)
unknownna (updater)
2015-06-04 22:20

That one seems to be fine as well.

(0012527)
Edward-san (developer)
2015-06-04 22:21

'https://www.dropbox.com/s/htk3dn32qzyqyi7/zandronum-2.0-140118-2029-1bbdf6f-windows.zip?dl=0 [^]' ?

(0012528)
unknownna (updater)
2015-06-04 22:25

That one is broken.

(0012529)
Edward-san (developer)
2015-06-04 22:31

'https://www.dropbox.com/s/lcmsozy376x0o6f/zandronum-2.0-140109-0217-b1896f7-windows.zip?dl=0 [^]' ?

(0012530)
unknownna (updater)
2015-06-04 22:38

That one seems to work fine.

(0012531)
Edward-san (developer)
2015-06-04 22:42

'https://www.dropbox.com/s/3663pxa8zcox19k/zandronum-2.0-140106-2012-9c60575-windows.zip?dl=0 [^]' ?

(0012532)
unknownna (updater)
2015-06-04 22:48

That one is broken.

(0012533)
Edward-san (developer)
2015-06-04 22:51

'https://www.dropbox.com/s/vji8r3q1vxqqvje/zandronum-2.0-140111-2021-acc466d-windows.zip?dl=0 [^]' ?

(0012534)
unknownna (updater)
2015-06-04 22:57

That one works fine.

(0012535)
Edward-san (developer)
2015-06-04 23:03
edited on: 2015-06-04 23:09

'https://www.dropbox.com/s/mxy7hn6ojgt2uzs/zandronum-2.0-140106-1938-0a092be-windows.zip?dl=0 [^]' ?

(0012536)
unknownna (updater)
2015-06-04 23:08

That one seems to work fine as well.

(0012537)
Edward-san (developer)
2015-06-04 23:10

'https://www.dropbox.com/s/6u4nhkrishoti52/zandronum-2.0-140112-0921-5663cba-windows.zip?dl=0 [^]' ?

(0012538)
unknownna (updater)
2015-06-04 23:14

That one is broken.

(0012539)
Edward-san (developer)
2015-06-04 23:22

Okay, we've finished.'https://bitbucket.org/Torr_Samaho/zandronum-stable/commits/5663cbab1857fc92a158d3db052a3bb68bff4cd3 [^]' is responsible of the regression. This commit merges from the stable:

'https://bitbucket.org/Torr_Samaho/zandronum-stable/commits/8aaecb3387e1734d3dd719a8d56ea5d3890f9a90 [^]'

and

'https://bitbucket.org/Torr_Samaho/zandronum-stable/commits/35e9a7e727a59868f04049b9521cb0691c3000ae [^]'

but the second one is unlikely because it changes the authentication, so it's definitely the client movement buffer.

(0012690)
unknownna (updater)
2015-06-14 04:35

I stumbled upon an older report of mine and noticed that it actually started to break already in 1.0, which is a shame since we worked extremely hard on fixing the desyncs in the first place (the desyncs that occur without any mods loaded).

Quote from unknownna
It changed somewhere between 3287 and 3298.

I can still confirm this.

So it started to break when respawning already in 3298, then it broke when switching weapons in 1.3 with the introduction of the tic buffer, and finally, it seemingly got worse (not too sure about this) in 2.0 with the re-ordering of packets.

(0012696)
Edward-san (developer)
2015-06-14 08:01

Speaking of weapon desyncs, I noticed that with complex doom, if I switch between weapons then I fire right away, sometimes the server doesn't fire at all, but the client does, desyncing the ammo. Can you check if this issue was already reported?

(0012698)
unknownna (updater)
2015-06-14 08:10

I'm aware of the Complex Doom issues, but let's focus on the desyncs that occur without any mods loaded first, i.e., the desyncs that occur without any ACS/DECORATE. Also, let me repeat what I said earlier:

Quote from unknownna
Keep in mind that certain desyncs that occur with custom mods, e.g. Complex Doom, are caused by instances of A_Jump* being called in the DECORATE code. The client can't predict those due to the way it currently works.

(0012700)
Torr Samaho (administrator)
2015-06-14 08:31

Let me try to summarize the findings as basis to work on a fix. There seem to be (at least) three things that cause desyncs:
- something that was changed between the Skulltag SVN revisions 3287 and 3298.
- the addition of the tic buffer
- the reordering of the tic buffer

I'd say we should fix the oldest problem first. For this I could make a special binary where the tic buffer can be turned off. But can somebody go through 3287 till 3298 to isolate which of these changes caused the problem? I had a brief look at the logs and there are several things that can have an influence on the weapon sync in this range of revisions.

(0012701)
Torr Samaho (administrator)
2015-06-14 08:41

Here is a 3.0 testing binary that can disable the tic buffer with "sv_useticbuffer 0". Can you check whether this fixes the problems that we assume to be caused by the tic buffer?

(0012702)
unknownna (updater)
2015-06-14 08:49
edited on: 2015-06-14 09:00

I'm able to reproduce the desync there as well when sv_useticbuffer is set to 0. Do you have to start the server with "sv_useticbuffer 0" or can you simply toggle it as you wish?

Edit:

It still happens when starting the server with "sv_useticbuffer 0".

(0012703)
Torr Samaho (administrator)
2015-06-14 09:02

You should be able to toggle sv_useticbuffer as you wish. Ok, then let's rule out the changes in 3.0 as additional source of problems. Here is a 2.1 beta build that supports sv_useticbuffer.

(0012704)
unknownna (updater)
2015-06-14 09:12
edited on: 2015-06-14 09:13

Quote from Torr Samaho
Ok, then let's rule out the changes in 3.0 as additional source of problems.

Yeah, I must say that the weapon switching in general felt really weird and uncomfortable in 3.0.

Quote from Torr Samaho
Here is a 2.1 beta build that supports sv_useticbuffer.

Yeah, that took care of the desync caused by the tic buffer.

(0012705)
Torr Samaho (administrator)
2015-06-14 09:27

While making the tic buffer optional, I had an idea how to possibly reduce the side effects of this buffer. Can you check if this binary has less sync problems caused by the tic buffer?

(0012706)
unknownna (updater)
2015-06-14 09:40
edited on: 2015-06-14 09:47

I was able to reproduce the desync there 2 times, but the behavior has dramatically improved from the former state. It rarely desyncs now.

(0012707)
Torr Samaho (administrator)
2015-06-14 09:50

Great, so we seem to be on the right track. Meanwhile, I realized that the testing binary would process up to three movement commands per tic instead of two. Can you test this binary to check whether the fix still works if we process at most two movement commands per tic?

(0012708)
unknownna (updater)
2015-06-14 09:58
edited on: 2015-06-14 10:46

It seems to work fine. I was only able to reproduce the desync once, but it seemed to correct itself. I think the fix still works fine with 2 commands per tic.

Edit:

Managed to desync it once more. It didn't correct itself this time.

And got it to desync 2 more times. But it rarely desyncs now.

(0012710)
cobalt (updater)
2015-06-14 10:45

Issue addressed by commit 69060e7cd250: Fixed some weapon sync issues related to the client movement buffer (partially fixes 2255).
Committed by Benjamin Berkels [Torr Samaho] on Sunday 14 June 2015 12:33:44

Changes in files:

docs/zandronum-history.txt | 1 +
src/sv_main.cpp | 19 +++++++++++++------
2 files changed, 14 insertions(+), 6 deletions(-)

(0012711)
Torr Samaho (administrator)
2015-06-14 10:47

I'm not sure how much further the side effects of the tic buffer can be reduced. After all, the tic buffer just tries to balance inevitable effects of delayed or reordered movement commands between the originator of the command and the other players. From your feedback it sounds as if the compromise is not too bad now.

Can somebody compile the old Skulltag SVN revisions between 3287 and 3298 so that we can isolate the cause of the other sync problems?

(0012712)
unknownna (updater)
2015-06-14 11:16
edited on: 2015-06-14 11:23

Indeed, I'd say that the regular weapon switching works reasonably well now, but it's not perfect. If I manage to reproduce the desync reliably in the future I'll let you know. I just hope it won't affect instances of picking up weapons at spawn.

Quote from Torr Samaho
Can somebody compile the old Skulltag SVN revisions between 3287 and 3298 so that we can isolate the cause of the other sync problems?

Didn't we work on the teleporter/spawn/respawn prediction during those revisions?

(0012714)
Dusk (developer)
2015-06-14 12:50
edited on: 2015-06-14 18:38

Here are the builds for the Skulltag revisions between 3287-3298:
- r3287
- r3288
- r3289
- r3290
- r3291
- r3292
- r3293
- r3294
- r3295
- r3296
- r3297
- r3298

Note that these have the G15 stuff disabled because it interfered with the building and I cannot be bothered to figure out how to make it compile properly.

(0012723)
unknownna (updater)
2015-06-14 18:39
edited on: 2015-06-14 18:39

Ok, we found out that it started to break when respawning in r3297. IIRC, that's from when we worked on the COOP desyncs here:

0000544: Client can't fire selected weapon after "changemap" map changes in COOP when being telefragged

(0012739)
unknownna (updater)
2015-06-16 09:57

Ok, since this ticket was made specifically for the 1.3/2.0 regression caused by the tic buffer we can mark it as resolved. Let's continue working on the respawn issue in the proper ticket when ready:

0001116: Client fires weapon too early after respawning

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

Issue History
Date Modified	Username	Field	Change
2015-05-25 12:47	unknownna	New Issue
2015-05-25 12:47	unknownna	File Added: weapon_desync_1.3.cld
2015-05-25 12:47	unknownna	File Added: weapon_desync_2.0.cld
2015-05-25 13:01	unknownna	Status	new => confirmed
2015-05-25 18:24	Catastrophe	Note Added: 0012391
2015-05-31 19:47	Edward-san	Note Added: 0012481
2015-05-31 19:48	Edward-san	Status	confirmed => feedback
2015-05-31 19:50	Torr Samaho	Note Added: 0012482
2015-05-31 22:13	Frits	Note Added: 0012485
2015-05-31 22:45	unknownna	Note Added: 0012486
2015-05-31 22:45	unknownna	Status	feedback => new
2015-06-04 16:18	Edward-san	Note Added: 0012511
2015-06-04 16:56	Edward-san	Status	new => feedback
2015-06-04 17:08	unknownna	Note Added: 0012512
2015-06-04 17:08	unknownna	Status	feedback => new
2015-06-04 17:16	unknownna	Note Edited: 0012512	View Revisions
2015-06-04 17:41	Edward-san	Note Added: 0012513
2015-06-04 17:41	Edward-san	Status	new => feedback
2015-06-04 18:24	unknownna	Note Added: 0012514
2015-06-04 18:24	unknownna	Status	feedback => new
2015-06-04 18:57	Edward-san	Note Added: 0012515
2015-06-04 18:57	Edward-san	Assigned To	=> Edward-san
2015-06-04 18:57	Edward-san	Status	new => feedback
2015-06-04 18:57	Edward-san	Assigned To	Edward-san =>
2015-06-04 19:21	unknownna	Note Added: 0012516
2015-06-04 19:21	unknownna	Status	feedback => new
2015-06-04 19:23	Edward-san	Note Added: 0012517
2015-06-04 19:24	Edward-san	Note Edited: 0012517	View Revisions
2015-06-04 19:26	Edward-san	Note Edited: 0012517	View Revisions
2015-06-04 19:36	Edward-san	Note Added: 0012518
2015-06-04 19:36	Edward-san	Status	new => feedback
2015-06-04 19:42	Edward-san	Note Edited: 0012518	View Revisions
2015-06-04 19:57	unknownna	Note Added: 0012519
2015-06-04 19:57	unknownna	Status	feedback => new
2015-06-04 20:53	Edward-san	Note Added: 0012520
2015-06-04 20:53	Edward-san	Status	new => feedback
2015-06-04 21:04	Edward-san	Note Edited: 0012520	View Revisions
2015-06-04 21:13	unknownna	Note Added: 0012521
2015-06-04 21:13	unknownna	Status	feedback => new
2015-06-04 21:20	Edward-san	Note Added: 0012522
2015-06-04 21:20	Edward-san	Note Edited: 0012522	View Revisions
2015-06-04 21:28	unknownna	Note Added: 0012523
2015-06-04 21:35	unknownna	Note Edited: 0012523	View Revisions
2015-06-04 21:38	unknownna	Note Edited: 0012523	View Revisions
2015-06-04 21:43	Edward-san	Note Added: 0012524
2015-06-04 21:44	Edward-san	Note Deleted: 0012524
2015-06-04 22:14	Edward-san	Note Added: 0012525
2015-06-04 22:14	Edward-san	Status	new => feedback
2015-06-04 22:20	unknownna	Note Added: 0012526
2015-06-04 22:20	unknownna	Status	feedback => new
2015-06-04 22:21	Edward-san	Note Added: 0012527
2015-06-04 22:22	Edward-san	Status	new => feedback
2015-06-04 22:25	unknownna	Note Added: 0012528
2015-06-04 22:25	unknownna	Status	feedback => new
2015-06-04 22:31	Edward-san	Note Added: 0012529
2015-06-04 22:31	Edward-san	Status	new => feedback
2015-06-04 22:38	unknownna	Note Added: 0012530
2015-06-04 22:38	unknownna	Status	feedback => new
2015-06-04 22:42	Edward-san	Note Added: 0012531
2015-06-04 22:45	Edward-san	Status	new => feedback
2015-06-04 22:48	unknownna	Note Added: 0012532
2015-06-04 22:48	unknownna	Status	feedback => new
2015-06-04 22:51	Edward-san	Note Added: 0012533
2015-06-04 22:51	Edward-san	Status	new => feedback
2015-06-04 22:57	unknownna	Note Added: 0012534
2015-06-04 22:57	unknownna	Status	feedback => new
2015-06-04 23:03	Edward-san	Note Added: 0012535
2015-06-04 23:03	Edward-san	Status	new => feedback
2015-06-04 23:08	unknownna	Note Added: 0012536
2015-06-04 23:08	unknownna	Status	feedback => new
2015-06-04 23:09	Edward-san	Note Edited: 0012535	View Revisions
2015-06-04 23:10	Edward-san	Note Added: 0012537
2015-06-04 23:10	Edward-san	Status	new => feedback
2015-06-04 23:14	unknownna	Note Added: 0012538
2015-06-04 23:14	unknownna	Status	feedback => new
2015-06-04 23:22	Edward-san	Note Added: 0012539
2015-06-04 23:22	Edward-san	Status	new => acknowledged
2015-06-14 01:20	WaTaKiD	Target Version	=> 2.1
2015-06-14 01:21	Dusk	Assigned To	=> Torr Samaho
2015-06-14 01:21	Dusk	Status	acknowledged => assigned
2015-06-14 04:07	unknownna	Relationship added	parent of 0001116
2015-06-14 04:35	unknownna	Note Added: 0012690
2015-06-14 08:01	Edward-san	Note Added: 0012696
2015-06-14 08:10	unknownna	Note Added: 0012698
2015-06-14 08:31	Torr Samaho	Note Added: 0012700
2015-06-14 08:41	Torr Samaho	Note Added: 0012701
2015-06-14 08:49	unknownna	Note Added: 0012702
2015-06-14 09:00	unknownna	Note Edited: 0012702	View Revisions
2015-06-14 09:02	Torr Samaho	Note Added: 0012703
2015-06-14 09:12	unknownna	Note Added: 0012704
2015-06-14 09:13	unknownna	Note Edited: 0012704	View Revisions
2015-06-14 09:27	Torr Samaho	Note Added: 0012705
2015-06-14 09:40	unknownna	Note Added: 0012706
2015-06-14 09:47	unknownna	Note Edited: 0012706	View Revisions
2015-06-14 09:50	Torr Samaho	Note Added: 0012707
2015-06-14 09:58	unknownna	Note Added: 0012708
2015-06-14 09:59	unknownna	Note Edited: 0012708	View Revisions
2015-06-14 10:45	cobalt	Status	assigned => needs testing
2015-06-14 10:45	cobalt	Steps to Reproduce Updated	View Revisions
2015-06-14 10:45	cobalt	Additional Information Updated	View Revisions
2015-06-14 10:45	cobalt	Note Added: 0012710
2015-06-14 10:46	unknownna	Note Edited: 0012708	View Revisions
2015-06-14 10:47	Torr Samaho	Note Added: 0012711
2015-06-14 11:16	unknownna	Note Added: 0012712
2015-06-14 11:23	unknownna	Note Edited: 0012712	View Revisions
2015-06-14 12:50	Dusk	Note Added: 0012714
2015-06-14 14:40	Dusk	Note Edited: 0012714	View Revisions
2015-06-14 14:58	Dusk	Note Edited: 0012714	View Revisions
2015-06-14 15:05	Dusk	Note Edited: 0012714	View Revisions
2015-06-14 15:19	Dusk	Note Edited: 0012714	View Revisions
2015-06-14 15:20	Dusk	Note Edited: 0012714	View Revisions
2015-06-14 17:17	Dusk	Note Edited: 0012714	View Revisions
2015-06-14 17:36	Dusk	Note Edited: 0012714	View Revisions
2015-06-14 17:46	Dusk	Note Edited: 0012714	View Revisions
2015-06-14 18:16	Dusk	Note Edited: 0012714	View Revisions
2015-06-14 18:37	Dusk	Note Edited: 0012714	View Revisions
2015-06-14 18:38	Dusk	Note Edited: 0012714	View Revisions
2015-06-14 18:39	unknownna	Note Added: 0012723
2015-06-14 18:39	unknownna	Note Edited: 0012723	View Revisions
2015-06-14 18:51	unknownna	Relationship added	related to 0000544
2015-06-16 09:57	unknownna	Note Added: 0012739
2015-06-16 09:57	unknownna	Status	needs testing => resolved
2015-06-16 09:57	unknownna	Resolution	open => fixed
2015-06-16 09:57	unknownna	Fixed in Version	=> 2.1
2015-06-16 09:57	unknownna	Steps to Reproduce Updated	View Revisions
2015-06-16 09:57	unknownna	Additional Information Updated	View Revisions
2015-07-08 23:12	unknownna	Relationship added	related to 0002330
2018-09-30 21:37	Blzut3	Status	resolved => closed

Notes
(0012391) Catastrophe (reporter) 2015-05-25 18:24	Yeah, weapons like the SSG desync a lot for me when you hold fire as you are respawning. Of course only happens online.

(0012481) Edward-san (developer) 2015-05-31 19:47	Sorry, can you explain how did you reproduce these? I see you used a ping emulator, but also other settings, like packet loss rate?

(0012482) Torr Samaho (administrator) 2015-05-31 19:50	Thanks for the report and nice to see you again, unknownna! Can you post a detailed description on what exactly needs to be done to reproduce the sync problems? To fix this, we'll have to identify when this broken and thus need to reproduce the issue.

(0012485) Frits (reporter) 2015-05-31 22:13	Yes, this has been happening so often since 1.3 to me. It's random at best but if a play a session of survival on BE it's bound to happen a couple of times these days while pre-1.3 it was more of a rare occurance.

(0012486) unknownna (updater) 2015-05-31 22:45	Quote from Torr Samaho Thanks for the report and nice to see you again, unknownna! Thanks, it's nice to see you again as well. I don't have as much time to play/test Zandronum these days as I used to, but I still check the tracker and play online every now and then. Quote from Edward-san Sorry, can you explain how did you reproduce these? I see you used a ping emulator, but also other settings, like packet loss rate? Indeed, I'm using a ping emulator with an emulated ping of 251. No packet loss emulation enabled. I simply tap +attack while switching back and forth between the BFG and the rocket launcher, sometimes de-selecting a weapon before it has a chance to raise fully. It's incredibly easy to reproduce the issue. I get the feeling that it might be caused by the implementation of the tic buffer and the subsequent re-ordering of packets that is now apparently taking place. But I could be wrong. Quote from Frits It's random at best but if a play a session of survival on BE it's bound to happen a couple of times these days while pre-1.3 it was more of a rare occurance. Keep in mind that certain desyncs that occur with custom mods, e.g. Complex Doom, are caused by instances of A_Jump* being called in the DECORATE code. The client can't predict those due to the way it currently works.

(0012511) Edward-san (developer) 2015-06-04 16:18	Can you check if by any chance it happens in this 1.4 build:'https://www.dropbox.com/s/k5od6l3dlelejyd/zandronum-1.4-150329-1535-891a78e-windows.zip?dl=0 [^]' ?

(0012512) unknownna (updater) 2015-06-04 17:08 edited on: 2015-06-04 17:16	It also happens in that build. BTW: It seems to happen particularly when picking up weapons for the first time after respawning.

(0012513) Edward-san (developer) 2015-06-04 17:41	Ok, what about: 'https://www.dropbox.com/s/g3sjirgvbl31x2a/zandronum-1.4-141006-2032-1c72423-windows.zip?dl=0 [^]' and 'https://www.dropbox.com/s/c0encmv43u88q8m/zandronum-1.4-141229-1233-69afd50-windows.zip?dl=0 [^]' ?

(0012514) unknownna (updater) 2015-06-04 18:24	It happens in both of those builds as well.

(0012515) Edward-san (developer) 2015-06-04 18:57	Can you check with this build: 'https://www.dropbox.com/s/nw1vmdrvfj1nq52/zandronum-1.4-141011-0904-c4c3c03-windows.zip?dl=0 [^]' ?

(0012516) unknownna (updater) 2015-06-04 19:21	It also happens in that build. If it happens in 2.0 and 3.0, wouldn't it be obvious that it also happens in 1.4 as well?

(0012517) Edward-san (developer) 2015-06-04 19:23 edited on: 2015-06-04 19:26	Except that it happens with builds referring to a few commits after 1.3, which is strange. Are you really sure it doesn't happen in 1.3? [edit]Okay sorry, I didn't read that you could reproduce in 1.3 as well.

(0012518) Edward-san (developer) 2015-06-04 19:36 edited on: 2015-06-04 19:42	Your ticket description says that "It's worse in 2.0 and 3.0.", so I was expecting an answer regarding if the 'worse' could happen also in 1.4, hence all these builds I linked above. Let me ask again: Which is worse between 1.3, this build and 2.0? 'https://www.dropbox.com/s/k5od6l3dlelejyd/zandronum-1.4-150329-1535-891a78e-windows.zip?dl=0 [^]' .

(0012519) unknownna (updater) 2015-06-04 19:57	I'd say that 1.3 and and 1.4 feel the same with 2.0 being the worst.

(0012520) Edward-san (developer) 2015-06-04 20:53 edited on: 2015-06-04 21:04	Alright. Now let's prioritize the 2.0 issue. Can you check these three builds: 'https://www.dropbox.com/s/egtb1ra75cmgklt/zandronum-2.0-140705-1713-8850124-windows.zip?dl=0 [^]' 'https://www.dropbox.com/s/rwe7o6qq16zcqyl/zandronum-2.0-130907-1034-45233a4-windows.zip?dl=0 [^]' 'https://www.dropbox.com/s/lzvjzpb1ivzp3go/zandronum-2.0-131012-1754-38f53d97-windows.zip?dl=0 [^]' ?

(0012521) unknownna (updater) 2015-06-04 21:13	There's a difference between the two: 'https://www.dropbox.com/s/rwe7o6qq16zcqyl/zandronum-2.0-130907-1034-45233a4-windows.zip?dl=0 [^]' This one feels better than 1.3 and 1.4. I couldn't desync it even once. 'https://www.dropbox.com/s/egtb1ra75cmgklt/zandronum-2.0-140705-1713-8850124-windows.zip?dl=0 [^]' This one is broken. Not sure if it's worse than 1.3 or 1.4 though.

(0012522) Edward-san (developer) 2015-06-04 21:20 edited on: 2015-06-04 21:20	Can you recheck the previous comment? There's also another build I added later.

(0012523) unknownna (updater) 2015-06-04 21:28 edited on: 2015-06-04 21:38	'https://www.dropbox.com/s/lzvjzpb1ivzp3go/zandronum-2.0-131012-1754-38f53d97-windows.zip?dl=0 [^]' ~~This build is just as bad as 2.0/3.0.~~ Edit: Scratch that, I accidentally hosted a 2.0 server and joined with the build. This build seems to be just as good as: 'https://www.dropbox.com/s/rwe7o6qq16zcqyl/zandronum-2.0-130907-1034-45233a4-windows.zip?dl=0 [^]'

(0012525) Edward-san (developer) 2015-06-04 22:14	'https://www.dropbox.com/s/lfnvgq47ld5jcw5/zandronum-2.0-131227-1408-9e86a61-windows.zip?dl=0 [^]' ?

(0012526) unknownna (updater) 2015-06-04 22:20	That one seems to be fine as well.

(0012527) Edward-san (developer) 2015-06-04 22:21	'https://www.dropbox.com/s/htk3dn32qzyqyi7/zandronum-2.0-140118-2029-1bbdf6f-windows.zip?dl=0 [^]' ?

(0012528) unknownna (updater) 2015-06-04 22:25	That one is broken.

(0012529) Edward-san (developer) 2015-06-04 22:31	'https://www.dropbox.com/s/lcmsozy376x0o6f/zandronum-2.0-140109-0217-b1896f7-windows.zip?dl=0 [^]' ?

(0012530) unknownna (updater) 2015-06-04 22:38	That one seems to work fine.

(0012531) Edward-san (developer) 2015-06-04 22:42	'https://www.dropbox.com/s/3663pxa8zcox19k/zandronum-2.0-140106-2012-9c60575-windows.zip?dl=0 [^]' ?

(0012532) unknownna (updater) 2015-06-04 22:48	That one is broken.

(0012533) Edward-san (developer) 2015-06-04 22:51	'https://www.dropbox.com/s/vji8r3q1vxqqvje/zandronum-2.0-140111-2021-acc466d-windows.zip?dl=0 [^]' ?

(0012534) unknownna (updater) 2015-06-04 22:57	That one works fine.

(0012535) Edward-san (developer) 2015-06-04 23:03 edited on: 2015-06-04 23:09	'https://www.dropbox.com/s/mxy7hn6ojgt2uzs/zandronum-2.0-140106-1938-0a092be-windows.zip?dl=0 [^]' ?

(0012536) unknownna (updater) 2015-06-04 23:08	That one seems to work fine as well.

(0012537) Edward-san (developer) 2015-06-04 23:10	'https://www.dropbox.com/s/6u4nhkrishoti52/zandronum-2.0-140112-0921-5663cba-windows.zip?dl=0 [^]' ?

(0012538) unknownna (updater) 2015-06-04 23:14	That one is broken.

(0012539) Edward-san (developer) 2015-06-04 23:22	Okay, we've finished.'https://bitbucket.org/Torr_Samaho/zandronum-stable/commits/5663cbab1857fc92a158d3db052a3bb68bff4cd3 [^]' is responsible of the regression. This commit merges from the stable: 'https://bitbucket.org/Torr_Samaho/zandronum-stable/commits/8aaecb3387e1734d3dd719a8d56ea5d3890f9a90 [^]' and 'https://bitbucket.org/Torr_Samaho/zandronum-stable/commits/35e9a7e727a59868f04049b9521cb0691c3000ae [^]' but the second one is unlikely because it changes the authentication, so it's definitely the client movement buffer.

(0012690) unknownna (updater) 2015-06-14 04:35	I stumbled upon an older report of mine and noticed that it actually started to break already in 1.0, which is a shame since we worked extremely hard on fixing the desyncs in the first place (the desyncs that occur without any mods loaded). Quote from unknownna It changed somewhere between 3287 and 3298. I can still confirm this. So it started to break when respawning already in 3298, then it broke when switching weapons in 1.3 with the introduction of the tic buffer, and finally, it seemingly got worse (not too sure about this) in 2.0 with the re-ordering of packets.

(0012696) Edward-san (developer) 2015-06-14 08:01	Speaking of weapon desyncs, I noticed that with complex doom, if I switch between weapons then I fire right away, sometimes the server doesn't fire at all, but the client does, desyncing the ammo. Can you check if this issue was already reported?

(0012698) unknownna (updater) 2015-06-14 08:10	I'm aware of the Complex Doom issues, but let's focus on the desyncs that occur without any mods loaded first, i.e., the desyncs that occur without any ACS/DECORATE. Also, let me repeat what I said earlier: Quote from unknownna Keep in mind that certain desyncs that occur with custom mods, e.g. Complex Doom, are caused by instances of A_Jump* being called in the DECORATE code. The client can't predict those due to the way it currently works.

(0012700) Torr Samaho (administrator) 2015-06-14 08:31	Let me try to summarize the findings as basis to work on a fix. There seem to be (at least) three things that cause desyncs: - something that was changed between the Skulltag SVN revisions 3287 and 3298. - the addition of the tic buffer - the reordering of the tic buffer I'd say we should fix the oldest problem first. For this I could make a special binary where the tic buffer can be turned off. But can somebody go through 3287 till 3298 to isolate which of these changes caused the problem? I had a brief look at the logs and there are several things that can have an influence on the weapon sync in this range of revisions.

(0012701) Torr Samaho (administrator) 2015-06-14 08:41	Here is a 3.0 testing binary that can disable the tic buffer with "sv_useticbuffer 0". Can you check whether this fixes the problems that we assume to be caused by the tic buffer?

(0012702) unknownna (updater) 2015-06-14 08:49 edited on: 2015-06-14 09:00	I'm able to reproduce the desync there as well when sv_useticbuffer is set to 0. Do you have to start the server with "sv_useticbuffer 0" or can you simply toggle it as you wish? Edit: It still happens when starting the server with "sv_useticbuffer 0".

(0012703) Torr Samaho (administrator) 2015-06-14 09:02	You should be able to toggle sv_useticbuffer as you wish. Ok, then let's rule out the changes in 3.0 as additional source of problems. Here is a 2.1 beta build that supports sv_useticbuffer.

(0012704) unknownna (updater) 2015-06-14 09:12 edited on: 2015-06-14 09:13	Quote from Torr Samaho Ok, then let's rule out the changes in 3.0 as additional source of problems. Yeah, I must say that the weapon switching in general felt really weird and uncomfortable in 3.0. Quote from Torr Samaho Here is a 2.1 beta build that supports sv_useticbuffer. Yeah, that took care of the desync caused by the tic buffer.

(0012705) Torr Samaho (administrator) 2015-06-14 09:27	While making the tic buffer optional, I had an idea how to possibly reduce the side effects of this buffer. Can you check if this binary has less sync problems caused by the tic buffer?

(0012706) unknownna (updater) 2015-06-14 09:40 edited on: 2015-06-14 09:47	I was able to reproduce the desync there 2 times, but the behavior has dramatically improved from the former state. It rarely desyncs now.

(0012707) Torr Samaho (administrator) 2015-06-14 09:50	Great, so we seem to be on the right track. Meanwhile, I realized that the testing binary would process up to three movement commands per tic instead of two. Can you test this binary to check whether the fix still works if we process at most two movement commands per tic?

(0012708) unknownna (updater) 2015-06-14 09:58 edited on: 2015-06-14 10:46	It seems to work fine. I was only able to reproduce the desync once, but it seemed to correct itself. I think the fix still works fine with 2 commands per tic. Edit: Managed to desync it once more. It didn't correct itself this time. And got it to desync 2 more times. But it rarely desyncs now.

(0012710) cobalt (updater) 2015-06-14 10:45	Issue addressed by commit 69060e7cd250: Fixed some weapon sync issues related to the client movement buffer (partially fixes 2255). Committed by Benjamin Berkels [Torr Samaho] on Sunday 14 June 2015 12:33:44 Changes in files: docs/zandronum-history.txt \| 1 + src/sv_main.cpp \| 19 +++++++++++++------ 2 files changed, 14 insertions(+), 6 deletions(-)

(0012711) Torr Samaho (administrator) 2015-06-14 10:47	I'm not sure how much further the side effects of the tic buffer can be reduced. After all, the tic buffer just tries to balance inevitable effects of delayed or reordered movement commands between the originator of the command and the other players. From your feedback it sounds as if the compromise is not too bad now. Can somebody compile the old Skulltag SVN revisions between 3287 and 3298 so that we can isolate the cause of the other sync problems?

(0012712) unknownna (updater) 2015-06-14 11:16 edited on: 2015-06-14 11:23	Indeed, I'd say that the regular weapon switching works reasonably well now, but it's not perfect. If I manage to reproduce the desync reliably in the future I'll let you know. I just hope it won't affect instances of picking up weapons at spawn. Quote from Torr Samaho Can somebody compile the old Skulltag SVN revisions between 3287 and 3298 so that we can isolate the cause of the other sync problems? Didn't we work on the teleporter/spawn/respawn prediction during those revisions?

(0012714) Dusk (developer) 2015-06-14 12:50 edited on: 2015-06-14 18:38	Here are the builds for the Skulltag revisions between 3287-3298: - r3287 - r3288 - r3289 - r3290 - r3291 - r3292 - r3293 - r3294 - r3295 - r3296 - r3297 - r3298 Note that these have the G15 stuff disabled because it interfered with the building and I cannot be bothered to figure out how to make it compile properly.

(0012723) unknownna (updater) 2015-06-14 18:39 edited on: 2015-06-14 18:39	Ok, we found out that it started to break when respawning in r3297. IIRC, that's from when we worked on the COOP desyncs here: 0000544: Client can't fire selected weapon after "changemap" map changes in COOP when being telefragged

(0012739) unknownna (updater) 2015-06-16 09:57	Ok, since this ticket was made specifically for the 1.3/2.0 regression caused by the tic buffer we can mark it as resolved. Let's continue working on the respawn issue in the proper ticket when ready: 0001116: Client fires weapon too early after respawning