Anonymous | Login | Signup for a new account | 2024-04-18 06:19 UTC |
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account |
View Issue Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||||
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. | ||||||||
Attached Files | door_lift_desync_test.wad [^] (5,111 bytes) 2010-09-23 16:00 2010.09.23_17.39.23_door_lift_desync_test.cld [^] (56,470 bytes) 2010-09-23 16:00 2012.10.06_11.02.16_doom2.cld [^] (31,645 bytes) 2012-10-06 09:18 Screenshot_Doom_20121007_021021_05.png [^] (110,366 bytes) 2012-10-07 00:19 Screenshot_Doom_20121007_013513.png [^] (101,027 bytes) 2012-10-07 00:20 2012.10.07_12.15.51_doom2.cld [^] (22,926 bytes) 2012-10-07 10:20 | ||||||||
Relationships | |||||||||||||||||||||
|
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 SamahoQuote from unknownna 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 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 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 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 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 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 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 Yes. Quote from Torr Samaho 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 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 |
Copyright © 2000 - 2024 MantisBT Team |