0002294: Very evident misprediction of movement on raising floors in general

Notes
(0012631) Frits (reporter) 2015-06-10 12:01	related'http://zandronum.com/tracker/view.php?id=2165 [^]' it's been a while but iirc it's the same for lowering floors too? (not sure)

(0012633) unknownna (updater) 2015-06-10 12:42 edited on: 2015-06-10 13:09	Yeah, it's pretty much the same issue. And no, it's not quite the same for lowering floors (though it'll still mispredict if you jump). The jitter is very evident with rising floors in general. It doesn't jitter on rising floors if you stand on them when they start to move (though you can still make it mispredict by running on the ledges or by jumping), but if you move to them from a floor that is lower in height, the jitter will appear.

(0012636) Leonard (developer) 2015-06-10 14:18	Related?

(0012641) unknownna (updater) 2015-06-10 19:47 edited on: 2015-06-10 21:32	I'd say that they're kind of related without being the same issue. Quote from Torr Samaho While predicting, the client assumes that sector heights do not change during the prediction window. There are some additions that take care of moving floors, but these workarounds cannot cover the case where a moving floor changes its direction during the prediction window. The difference between Floor_Waggle and this issue is that the rising floors never change direction here.

(0012666) unknownna (updater) 2015-06-12 21:23	This worked fine in 1.0 and started to break in 1.1 so it's another regression.

(0012851) unknownna (updater) 2015-07-10 22:11	It started to break in 1.1-alpha-r121014-1138M. 'http://zandronum.com/tracker/view.php?id=1079#c5103 [^]' 'http://www.mediafire.com/?713iii3x3yggx2y [^]'

(0023309) unknownna (updater) 2024-03-07 10:57	I can't reproduce this anymore in 3.1. The client quickly corrects itself now. It muse have been fixed by something else. Thanks!

(0023768) unknownna (updater) 2024-06-25 23:00 edited on: 2024-06-25 23:01	After testing some other wads, I noticed this issue still happens. But there's a difference in 3.1 and beyond: If you get a certain tick sync it doesn't glitch up. And strangely enough it doesn't glitch when you get what I would consider a "bad" tick sync with lots of jitter. Getting a clean tick sync causes it to break. And another observation is that playing with cl_capfps 0 might cause the client to correct itself, whereas with capped FPS it breaks completely until the floor has risen fully.

(0024213) unknownna (updater) 2025-02-15 23:07 edited on: 2025-02-16 11:42	I gave this another test using the newer clock sync build, and can confirm that the issue is caused by the tickrate desync between the client and server, in particular the tick offset the client's time lands on. Assuming that you connect with a ping of 160 with stairs_02.wad, using the movebuffer with "cl_usemovebuffer 1" masks the underlying issue, but when you use "cl_usemovebuffer 0" to check how good the tick sync really is, you always have to offset the client's time manually up by approx. 4-6 milliseconds to make the sync work right and prevent the desync from occurring. This suggests that the current clock sync algorithm either isn't aggressive enough, or that it currently aims to land at the wrong spot, i.e., it currently aims to land at the middle of a server tick instead of the beginning or something. What do you think? Edit: Or maybe the client prediction is simply making a wrong assumption somewhere.

**Issue Community Support**
Only registered users can voice their support. Click here to register, or here to log in.
Supporters:	Leonard unknownna
Opponents:	No one explicitly opposes this issue yet.

Issue Community Support

Only registered users can voice their support. Click here to register, or here to log in.

Supporters:

Leonard unknownna

Opponents:

No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2015-06-08 20:46	unknownna	New Issue
2015-06-08 20:46	unknownna	File Added: stairs_02.wad
2015-06-08 20:46	unknownna	Status	new => confirmed
2015-06-08 20:47	unknownna	Relationship added	related to 0002035
2015-06-10 12:01	Frits	Note Added: 0012631
2015-06-10 12:42	unknownna	Note Added: 0012633
2015-06-10 12:45	unknownna	Note Edited: 0012633	View Revisions
2015-06-10 12:45	unknownna	Relationship added	has duplicate 0002165
2015-06-10 13:08	unknownna	Note Edited: 0012633	View Revisions
2015-06-10 13:09	unknownna	Note Edited: 0012633	View Revisions
2015-06-10 14:18	Leonard	Note Added: 0012636
2015-06-10 19:47	unknownna	Note Added: 0012641
2015-06-10 19:47	unknownna	Relationship added	related to 0001682
2015-06-10 19:48	unknownna	Relationship added	related to 0002293
2015-06-10 21:32	unknownna	Note Edited: 0012641	View Revisions
2015-06-12 21:23	unknownna	Note Added: 0012666
2015-07-10 22:11	unknownna	Note Added: 0012851
2015-07-10 22:11	unknownna	Relationship added	related to 0001079
2015-07-10 22:14	unknownna	Additional Information Updated	View Revisions
2015-07-10 22:25	unknownna	Additional Information Updated	View Revisions
2015-08-12 15:46	unknownna	Relationship added	related to 0002401
2018-08-23 05:09	unknownna	Relationship added	related to 0001131
2024-03-07 10:57	unknownna	Note Added: 0023309
2024-03-07 10:57	unknownna	Status	confirmed => closed
2024-03-07 10:57	unknownna	Resolution	open => fixed
2024-03-07 10:57	unknownna	Fixed in Version	=> 3.1
2024-06-25 23:00	unknownna	Note Added: 0023768
2024-06-25 23:00	unknownna	Status	closed => feedback
2024-06-25 23:00	unknownna	Resolution	fixed => reopened
2024-06-25 23:01	unknownna	Note Edited: 0023768	View Revisions
2025-02-15 23:07	unknownna	Note Added: 0024213
2025-02-15 23:07	unknownna	Status	feedback => new
2025-02-15 23:07	unknownna	Relationship added	related to 0003334
2025-02-15 23:07	unknownna	Status	new => feedback
2025-02-16 11:42	unknownna	Note Edited: 0024213	View Revisions