0001767: Clientside prediction of sectors

Notes
(0008478) Watermelon (developer) 2014-04-03 01:45	Also, Odamex does it.

(0008479) Torr Samaho (administrator) 2014-04-03 06:12	I don't really understand the situation. Did you trigger the lift or did he?

(0008480) Watermelon (developer) 2014-04-03 13:25 edited on: 2014-04-03 13:27	Someone else triggered the lift. Though I can understand how predicting someone else having triggered it would be bad because it'd require the client to process X gametics ahead of the instruction -- and assumes it remains constant. However, clientside prediction of stuff that you press would be really useful when playing with 130+ ping. When I play on euro servers and I need to do something fast and efficient, it would help a lot in almost all situations: - In human deathmatch game modes, opening a door or lowering a lift that moves fast will result in anyone behind it seeing you before you do as you have to wait for the server command to do so. - It can be disorienting at even 120 ping if you are holding +forward and you press use on a fast door, nothing happens, and suddenly you appear in the room (this happens to me a lot in coop on German servers for new maps I don't know if I'm trying to escape a powerful monster behind me) -- which can result in me running into a pit or something dumb. If it raised clientside, I'd see it ahead of time. I'm unsure of how the server would enforce such a thing to ensure the client doesn't accidentally desync, because if it did then this feature would actually be more harmful than helpful. I believe ZDaemon does a trick where if someone presses lower on a lift, when you get the lower lift message, it processes it ahead by your gametic diff of lower_speed * gametic_since_command_sent (but this makes it look like it warped some distance). I must stress that the current system is operational and this is not some high priority that people want to see, but rather a possible convenience if it's doable without problems.

(0008485) Dusk (developer) 2014-04-03 17:22	What you really want here is unlagged for sector movers.

(0008491) Torr Samaho (administrator) 2014-04-04 06:05	Quote from Watermelon Someone else triggered the lift. Though I can understand how predicting someone else having triggered it would be bad because it'd require the client to process X gametics ahead of the instruction -- and assumes it remains constant. The only thing you can reasonably predict are effects of your own actions. Both the client side prediction and the unlagged concept are based on the fact that what you see is the state on the server half your ping ago. Quote from Dusk What you really want here is unlagged for sector movers. Sector floor and ceiling heights are already reconciled. So the situation Water described should already be covered. Of course I can't guarantee that the sector reconciliation is bug free.

(0008493) Watermelon (developer) 2014-04-04 17:16	Quote Sector floor and ceiling heights are already reconciled. Does that mean doors as well? Cause one thing I notice when playing at high ping with fast moving doors, I will open them and suddenly warp inside. It COULD be my internet though. I will not rule this out. I will try testing with a ping emulator on my computer.

(0008495) Edward-san (developer) 2014-04-04 20:16	Is'http://zandronum.com/tracker/view.php?id=706 [^]' related to this report?

(0008506) Torr Samaho (administrator) 2014-04-06 17:55	Quote from Watermelon Does that mean doors as well? Cause one thing I notice when playing at high ping with fast moving doors, I will open them and suddenly warp inside. All sector floor and ceiling planes are reconciled, so it should cover doors as well. The reconciliation should only affect hit calculations though, it shouldn't teleport you to a different position. What you describe sounds more like a client side movement misprediction. Quote from Edward-san Is'http://zandronum.com/tracker/view.php?id=706 [^]' related to this report? From the description it sounds as if the attacker was not on a moving sector. In that case 0000706 is unrelated.

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

Issue History
Date Modified	Username	Field	Change
2014-04-03 01:44	Watermelon	New Issue
2014-04-03 01:45	Watermelon	Note Added: 0008478
2014-04-03 06:12	Torr Samaho	Note Added: 0008479
2014-04-03 13:25	Watermelon	Note Added: 0008480
2014-04-03 13:26	Watermelon	Note Edited: 0008480	View Revisions
2014-04-03 13:27	Watermelon	Note Edited: 0008480	View Revisions
2014-04-03 17:22	Dusk	Note Added: 0008485
2014-04-04 06:05	Torr Samaho	Note Added: 0008491
2014-04-04 17:16	Watermelon	Note Added: 0008493
2014-04-04 20:16	Edward-san	Note Added: 0008495
2014-04-06 17:55	Torr Samaho	Note Added: 0008506
2014-06-15 16:09	Watermelon	Status	new => closed
2014-06-15 16:09	Watermelon	Resolution	open => no change required

Relationships