0000055: misprediction of player position when opening doors and using lifts online

Notes
(0000231) Torr Samaho (administrator) 2010-10-03 11:02	I can confirm that this happens. It's not really a bug though but more a missing feature, i.e. client side lift/floor prediction. Unfortunately, this is a non-trivial feature and I doubt it will be worth the effort. BTW: I'll edit this report to be a feature request rather than a bug report to point out that the current behavior is normal.

(0000284) unknownna (updater) 2010-10-07 03:47 edited on: 2010-10-08 07:03	Very well. I can imagine how it must feel like a tedious chore, but believe me, it would definitely be worth it in the long run. The netcode would feel a lot more "complete". But it's not a necessity for the time being, though. If you someday would like to add more client-side prediction to Skulltag, I'd suggest for you to look into jump pads, i.e. 'ThrustThing(Z)' and then teleporters/respawning, as they are very important aspects in a competitive setting. Maps with steep heignts in particular. When you respawn, the client doesn't predict falls and such and the viewpoint shakes a lot (a small example of this would be the D5M1 green bean spawn). In the worst case it becomes unplayable. Then there's the collision issue where the prediction of your movement gets shut off for a little while whenever you bump into another player (actors in general) and skip from the location of the bump to your true one based on your ping ms. This one makes close combat quite disorienting. Then there's the rest, e.g. 'A_Recoil', doors/lifts/ceilings/floors and such. Even the new client-side prediction of crouching made a great difference. EDIT: Also, bridge things and FLOAT+NOGRAVITY monsters, i.e Cacodemon/Pain Elemental/Lost Soul

(0004980) unknownna (updater) 2012-10-06 09:17	Most of the issues in the note above have been fixed. Quote from Torr Samaho Quote from unknownna On a side note, I noticed that the client prediction for doors was a lot better in ZDaemon. You don't jitter there compared to Zandronum. Feel free to make a new suggestion ticket for this (in case there is no ticket yet). I hate to bother you with these prediction issues, but do you think that we could possibly to improve this behavior like we did with the other z desync recently? I recorded a small demo of the door issue that is present in Zandronum, but not in ZDaemon.

(0005005) Torr Samaho (administrator) 2012-10-06 18:13	Ok, for this to work the client would actually either have to locally open the door on its own instead of waiting for the server to confirm that the door is opening (which would introduce even more severe sync problems) or the server would have to "unlag" the doors in the sense that the movement of a player is based on the door positions at the client's time, i.e. the positions that were used "ping" ago.

(0005010) unknownna (updater) 2012-10-07 00:18 edited on: 2012-10-07 00:38	Quote from Torr Samaho [...] or the server would have to "unlag" the doors in the sense that the movement of a player is based on the door positions at the client's time, i.e. the positions that were used "ping" ago. That sounds like the most sober thing to do. I don't know if ZDaemon handles it like this. You still teleport between 2 points when opening doors, but there's no jitter or any z mispredictions there. How come the client thinks that it's on the lower floor even in this binary? You can see in the demo (also attached screenshots) that the client drops down to the water sector, but then suddenly teleports to the proper position. You're not even supposed to touch that floor. I think that this is the main difference between ZDaemon and Zandronum when compared side by side, both with an emulated ping of 603.

(0005016) Torr Samaho (administrator) 2012-10-07 08:35	Quote from unknownna That sounds like the most sober thing to do. I don't know if ZDaemon handles it like this. You still teleport between 2 points when opening doors, but there's no jitter or any z mispredictions there. I started to experiment with this. While it seems to completely fix the problem when running against opening doors, it causes serious problems on moving floors. Also thinking more about it, I fear players would hate its inevitable side effects, like players seemingly going through closed doors, because the door was still open on their end. Quote from unknownna How come the client thinks that it's on the lower floor even in this binary? That's a side effect of the workaround that keeps the movement on moving floors smooth. This hopefully fixes this problem.

(0005019) unknownna (updater) 2012-10-07 09:46 edited on: 2012-10-07 09:47	Quote from Torr Samaho This hopefully fixes this problem. Most impressive, Torr. ZDaemon and Zandronum are nearly identical to one another now when compared side by side. But I noticed a client-side misprediction that is not present in ZDaemon. You jitter when bumping into every wall in Zandronum. And the client thinks that it lags when joining the game with a high ping (603). This doesn't happen in ZDaemon. The wall-jitter is very important to have fixed since it can potentially affect the movement when you pass through doors. Quote from Torr Samaho While it seems to completely fix the problem when running against opening doors, it causes serious problems on moving floors. Also thinking more about it, I fear players would hate its inevitable side effects, like players seemingly going through closed doors, because the door was still open on their end. If you manage to fix the wall-jitter issue, we shouldn't have to bother with this since the latest testing binary seems to be working as desired.

(0005021) Torr Samaho (administrator) 2012-10-07 10:02	Quote from unknownna Most impressive, Torr. ZDaemon and Zandronum are nearly identical to one another now when compared side by side. Thanks! It's very encouraging to hear that we are on a good way :). Can you make a demo of the wall-jitter issue? And does cl_ticsperupdate have any effect on this? I suspect that "cl_ticsperupdate 1" sometimes does more harm than good.

(0005024) unknownna (updater) 2012-10-07 10:20	Quote from Torr Samaho Can you make a demo of the wall-jitter issue? Yes. Quote from Torr Samaho And does cl_ticsperupdate have any effect on this? I suspect that "cl_ticsperupdate 1" sometimes does more harm than good. It seems that it doesn't have any effect on this.

(0005028) Torr Samaho (administrator) 2012-10-07 10:53	Ah, I see. The misprediction only seems to happen if you release "forward" while running against a wall at a slight angle.

(0005041) Torr Samaho (administrator) 2012-10-07 17:35	The wall-jittering issue is really tough. It seems that the client is sometimes mispredicting how much the player is sliding against a wall, but only if the player changes his movement. While investigating I found a bug in the clipping code. Unfortunately the fix for this bug doesn't seem to effect the wall-jittering issue. But can you check if this doesn't break the prediction?

(0005045) unknownna (updater) 2012-10-07 23:37	Quote from Torr Samaho But can you check if this doesn't break the prediction? The door issue seems to be fine.

(0012606) unknownna (updater) 2015-06-08 20:51	Ok, I'd say that these issues are fixed. I'll split the wall-jitter issue to its own separate ticket.

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

Issue History
Date Modified	Username	Field	Change
2010-09-23 16:00	unknownna	New Issue
2010-09-23 16:00	unknownna	File Added: door_lift_desync_test.wad
2010-09-23 16:00	unknownna	File Added: 2010.09.23_17.39.23_door_lift_desync_test.cld
2010-10-03 11:02	Torr Samaho	Note Added: 0000231
2010-10-03 11:02	Torr Samaho	Status	new => confirmed
2010-10-03 11:02	Torr Samaho	Category	Bugs => Suggestion
2010-10-07 03:47	unknownna	Note Added: 0000284
2010-10-08 04:40	unknownna	Note Edited: 0000284	View Revisions
2010-10-08 07:03	unknownna	Note Edited: 0000284	View Revisions
2011-07-18 06:36	unknownna	Relationship added	related to 0000130
2012-04-29 17:19	TIHan	Relationship added	related to 0000706
2012-10-06 09:17	unknownna	Note Added: 0004980
2012-10-06 09:18	unknownna	File Added: 2012.10.06_11.02.16_doom2.cld
2012-10-06 10:37	unknownna	Priority	low => high
2012-10-06 10:37	unknownna	Severity	minor => major
2012-10-06 18:13	Torr Samaho	Note Added: 0005005
2012-10-07 00:18	unknownna	Note Added: 0005010
2012-10-07 00:19	unknownna	File Added: Screenshot_Doom_20121007_021021_05.png
2012-10-07 00:20	unknownna	File Added: Screenshot_Doom_20121007_013513.png
2012-10-07 00:38	unknownna	Note Edited: 0005010	View Revisions
2012-10-07 08:35	Torr Samaho	Note Added: 0005016
2012-10-07 09:46	unknownna	Note Added: 0005019
2012-10-07 09:47	unknownna	Note Edited: 0005019	View Revisions
2012-10-07 10:02	Torr Samaho	Note Added: 0005021
2012-10-07 10:20	unknownna	File Added: 2012.10.07_12.15.51_doom2.cld
2012-10-07 10:20	unknownna	Note Added: 0005024
2012-10-07 10:53	Torr Samaho	Note Added: 0005028
2012-10-07 17:35	Torr Samaho	Note Added: 0005041
2012-10-07 23:37	unknownna	Note Added: 0005045
2012-10-12 23:03	unknownna	Relationship added	related to 0000517
2012-10-12 23:15	unknownna	Assigned To	=> Torr Samaho
2014-10-12 14:01	Torr Samaho	Relationship added	related to 0001957
2015-06-08 20:51	unknownna	Note Added: 0012606
2015-06-08 20:51	unknownna	Status	confirmed => resolved
2015-06-08 20:51	unknownna	Resolution	open => fixed
2015-06-08 20:51	unknownna	Fixed in Version	=> 2.0
2018-09-30 22:55	Blzut3	Status	resolved => closed