MantisBT - Zandronum
View Issue Details
0002294Zandronum[All Projects] Bugpublic2015-06-08 20:462025-02-16 11:42
unknownna 
 
highmajoralways
feedbackreopened 
2.0 
3.1 
0002294: Very evident misprediction of movement on raising floors in general
I've noticed this issue for a while now and it seems that the client greatly mispredicts its movement if stepping up to a raising floor online.

In particular, this misprediction seems to occur when the player moves from a lower floor to a raising floor that is higher.

It seems to correct itself if you press +jump.
1. zandronum -file stairs_02.wad -host
2. Connect a client to the server with an emulated ping of 200.
3. Join the game.
4. Move to the floor in front of you and move in a circular pattern with +forward, +back, +moveleft and +moveright.
It's very evident even with only 145 ping, which IMO is a relatively normal ping. And I always notice this issue when playing online on regular servers.

It started to break in 1.1-alpha-r121014-1138M.

MOVINGFLOORSCREENSHAKE.wad
No tags attached.
related to 0002035closed  Less evident player desync on a gap between raising floors 
related to 0001682confirmed  Floor_Waggle produces jittery lag online. 
related to 0002293closed Edward-san Clients build stairs without any delay between steps causing unnecessary prediction issues online 
related to 0001079closed Torr Samaho Client greatly mispredicts its z position if pushed over a ledge by something else 
related to 0003334assigned Kaminsky Tickrate discrepancies between clients/servers 
has duplicate 0002165closed  Screen shaking w/ moving floors online 
related to 0002401confirmed  Floor_Waggle doesn't reset floor to its proper position online 
related to 0001131feedback  Client mispredicts its movement if moving on floors/slopes with negative height values 
? stairs_02.wad (3,168) 2015-06-08 20:46
https://zandronum.com/tracker/file_download.php?file_id=1535&type=bug
Issue History
2015-06-08 20:46unknownnaNew Issue
2015-06-08 20:46unknownnaFile Added: stairs_02.wad
2015-06-08 20:46unknownnaStatusnew => confirmed
2015-06-08 20:47unknownnaRelationship addedrelated to 0002035
2015-06-10 12:01FritsNote Added: 0012631
2015-06-10 12:42unknownnaNote Added: 0012633
2015-06-10 12:45unknownnaNote Edited: 0012633bug_revision_view_page.php?bugnote_id=12633#r7355
2015-06-10 12:45unknownnaRelationship addedhas duplicate 0002165
2015-06-10 13:08unknownnaNote Edited: 0012633bug_revision_view_page.php?bugnote_id=12633#r7356
2015-06-10 13:09unknownnaNote Edited: 0012633bug_revision_view_page.php?bugnote_id=12633#r7357
2015-06-10 14:18LeonardNote Added: 0012636
2015-06-10 19:47unknownnaNote Added: 0012641
2015-06-10 19:47unknownnaRelationship addedrelated to 0001682
2015-06-10 19:48unknownnaRelationship addedrelated to 0002293
2015-06-10 21:32unknownnaNote Edited: 0012641bug_revision_view_page.php?bugnote_id=12641#r7368
2015-06-12 21:23unknownnaNote Added: 0012666
2015-07-10 22:11unknownnaNote Added: 0012851
2015-07-10 22:11unknownnaRelationship addedrelated to 0001079
2015-07-10 22:14unknownnaAdditional Information Updatedbug_revision_view_page.php?rev_id=7574#r7574
2015-07-10 22:25unknownnaAdditional Information Updatedbug_revision_view_page.php?rev_id=7575#r7575
2015-08-12 15:46unknownnaRelationship addedrelated to 0002401
2018-08-23 05:09unknownnaRelationship addedrelated to 0001131
2024-03-07 10:57unknownnaNote Added: 0023309
2024-03-07 10:57unknownnaStatusconfirmed => closed
2024-03-07 10:57unknownnaResolutionopen => fixed
2024-03-07 10:57unknownnaFixed in Version => 3.1
2024-06-25 23:00unknownnaNote Added: 0023768
2024-06-25 23:00unknownnaStatusclosed => feedback
2024-06-25 23:00unknownnaResolutionfixed => reopened
2024-06-25 23:01unknownnaNote Edited: 0023768bug_revision_view_page.php?bugnote_id=23768#r14286
2025-02-15 23:07unknownnaNote Added: 0024213
2025-02-15 23:07unknownnaStatusfeedback => new
2025-02-15 23:07unknownnaRelationship addedrelated to 0003334
2025-02-15 23:07unknownnaStatusnew => feedback
2025-02-16 11:42unknownnaNote Edited: 0024213bug_revision_view_page.php?bugnote_id=24213#r14464

Notes
(0012631)
Frits   
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   
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   
2015-06-10 14:18   
Related?
(0012641)
unknownna   
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   
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   
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   
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   
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   
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.