MantisBT - Zandronum |
| View Issue Details |
|
| ID | Project | Category | View Status | Date Submitted | Last Update |
| 0000055 | Zandronum | [All Projects] Suggestion | public | 2010-09-23 16:00 | 2018-09-30 22:55 |
|
| Reporter | unknownna | |
| Assigned To | Torr Samaho | |
| Priority | high | Severity | major | Reproducibility | always |
| Status | closed | Resolution | fixed | |
| Platform | Microsoft | OS | Windows | OS Version | XP/Vista/7 |
| Product Version | 98c | |
| Target Version | | Fixed in Version | 2.0 | |
|
| Summary | 0000055: misprediction of player position when opening doors and using lifts online |
| Description | With a ping of approximately 250ms or more, every time you open a door while running into it, it's as if the momentum of the player is mispredicted for a little while.
I don't think it's the momentum of the player that's mispredicted/desynchronized, but the amount of how much the door has opened between client/server. The player is allowed to pass through before the door actually has opened the minimum amount needed to pass through. Or that's the illusion the current behavior gives.
Lifts, and lowering floors when you're standing on top of them, are also desynchronized between the client/server.
I've included an example WAD and demo for you to see what I'm talking about. If you use 'demo_spectatefreely', you can even see how the player skips around when using doors. |
| Steps To Reproduce | |
| Additional Information | |
| Tags | No tags attached. |
| Relationships | | related to | 0000130 | closed | Torr Samaho | client prediction is sometimes wrong | | related to | 0000706 | acknowledged | TIHan | Moving down sector elevator desyncs height of spawned projectiles | | related to | 0000517 | closed | Torr Samaho | No thrust prediction for Archvile attacks & rocket jumps | | related to | 0001957 | new | | Clientside sector prediction for lines that the client activates |
|
| Attached Files |  door_lift_desync_test.wad (5,111) 2010-09-23 16:00
/tracker/file_download.php?file_id=14&type=bug
2010.09.23_17.39.23_door_lift_desync_test.cld (56,470) 2010-09-23 16:00
/tracker/file_download.php?file_id=15&type=bug
2012.10.06_11.02.16_doom2.cld (31,645) 2012-10-06 09:18
/tracker/file_download.php?file_id=784&type=bug
 Screenshot_Doom_20121007_021021_05.png (110,366) 2012-10-07 00:19
/tracker/file_download.php?file_id=786&type=bug
Screenshot_Doom_20121007_013513.png (101,027) 2012-10-07 00:20
/tracker/file_download.php?file_id=787&type=bug
2012.10.07_12.15.51_doom2.cld (22,926) 2012-10-07 10:20
/tracker/file_download.php?file_id=788&type=bug |
|
| 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 | bug_revision_view_page.php?bugnote_id=284#r121 |
| 2010-10-08 07:03 | unknownna | Note Edited: 0000284 | bug_revision_view_page.php?bugnote_id=284#r122 |
| 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 | bug_revision_view_page.php?bugnote_id=5010#r2743 |
| 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 | bug_revision_view_page.php?bugnote_id=5019#r2745 |
| 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 |
|
Notes |
|
|
|
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
|
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
|
|
|
|
|
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. |
|
|
|
|
|
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
|
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.
|
|
|
|
|
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
|
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.
|
|
|
|
|
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. |
|
|
|
|
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. |
|
|
|
|
|
Ah, I see. The misprediction only seems to happen if you release "forward" while running against a wall at a slight angle. |
|
|
|
|
|
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? |
|
|
|
|
Quote from Torr Samaho
But can you check if this doesn't break the prediction?
The door issue seems to be fine. |
|
|
|
|
|
Ok, I'd say that these issues are fixed. I'll split the wall-jitter issue to its own separate ticket. |
|