0001957: Clientside sector prediction for lines that the client activates

Notes
(0010523) Watermelon (developer) 2014-10-12 03:10	To expand on the prediction idea, if we know its deterministic (ex: no ACS scripts), we can safely predict sectors. For example, if the line is from a Doom or Hexen map, we have everything we need to predict. Another hacky way around this is to do a lump check to see if StrParam exists, or if a sector changer is used in ACS -- if one is used, then we can't predict because it could affect anything. Yet another idea is to smooth out lifts using the new gametic unlagged (like nudging lifts, similar to the nudging projectiles ticket).

(0010542) ZzZombo (reporter) 2014-10-12 15:07	Quote For example, if the line is from a Doom or Hexen map, we have everything we need to predict. Sorry, buddy, but then there is xlat, that can change any action into virtually anything, and ACS libraries, that can do some non-obvious stuff.

(0010543) Dusk (developer) 2014-10-12 15:43	Quote there is xlat, that can change any action into virtually anything Xlat defines how a Doom map's line actions are interpreted. Internally they're all Hexen-format action specials. Since the map is already loaded by the time it's being played (in case you didn't know), xlat is obviously irrelevant in this matter. ACS libraries cannot be predicted but they don't create movers nearly as often as predictable line actions do.

(0010545) Torr Samaho (administrator) 2014-10-12 16:21	I think this suggestion is phrased too vaguely and doubt that it is feasible to implement this in a way that is as general as the suggestion is phrased. Also, some of this kind of prediction is already done, see here for example. To get something manageable chose a specific situation (with minimal example wad) where prediction is needed and we can discuss whether a prediction can be achieved in the case in question.

(0010559) Watermelon (developer) 2014-10-12 21:11 edited on: 2014-10-12 21:16	To expand from IRC discussion: Quote <Torr_Samaho> Water, the prediction may be quite tricky and probably error prone. If the client wrongly predicts a button press, you're in for really bad sync issues. Let's discuss this more in the ticket. Wouldn't hurt to have a minimal example wad at hand for this. I propose the following as a possible idea: 1) Only target line specials that are not ACS_Execute-like commands, or anything that can be even remotely undeterministic. 2) When the client presses it, it will lower automatically for him and go into a list of sectors that have been predicted by the client and when. 3) The client will discard the lift-lower/raise command if it finds out it was the one from the server that pressed it. This would most likely require adding a byte to who is the activator of lift lowering/raising if it's not already. 4) If the client gets a msg back saying that someone else pressed it, then reset it to it's normal height (this would be marked in a struct from (2)) and then carry on as per normal. This is the cost of a client wanting to predict sectors (by default this setting would be off). I believe this is the best way to handle this kind of desync. Usually this wont happen anyways because a body is often blocking the life that activates it. In such rare cases, that is the cost the client takes for wanting to get prediction. 5) If the client has not heard from the server is X amount of tics (lets say 2 times the ping? What's reasonable, 35 tics cap?) then assume it was not pressed and reset it. Thus, the client must accept that they have a bad connection (and they will have to deal with that since it's not the server's fault). As in (4), if the client has an unstable/volatile connection, they shouldn't be predicting. The goal here is to handle desyncs properly, and maybe ignore (by ignore, I mean do not attempt to predict) obnoxious cases like lifts that raise/lower at a certain speed that could terminate before the client even gets the message. I think if I read what I got from Blzut correctly, the lifts can't just be changed mid movement. Therefore predicting should not affect any commands that come after... since prediction must start and end before or equal to the server sending the message, which means the lift will be done predicting before any further lift messages will arrive.

(0010570) Watermelon (developer) 2014-10-13 15:29	I thought about this more, and one thing that probably needs to be done first is make sure all platform bugs are fixed. I know there's still a few laying around, and these would need to all be fixed before even attempting this, as this would require no platform issues between the client and server. Right now there already is some synchronization issues, so I'll be going after those in another ticket.

Only registered users can voice their support. Click here to register, or here to log in.
Supporters:	Karakurt
Opponents:	unknownna

Issue History
Date Modified	Username	Field	Change
2014-10-12 03:06	Watermelon	New Issue
2014-10-12 03:10	Watermelon	Note Added: 0010523
2014-10-12 03:10	Watermelon	Assigned To	=> Watermelon
2014-10-12 03:10	Watermelon	Status	new => assigned
2014-10-12 03:10	Watermelon	Status	assigned => new
2014-10-12 14:01	Torr Samaho	Relationship added	related to 0000055
2014-10-12 14:02	Torr Samaho	Relationship added	related to 0000706
2014-10-12 15:07	ZzZombo	Note Added: 0010542
2014-10-12 15:43	Dusk	Note Added: 0010543
2014-10-12 16:21	Torr Samaho	Note Added: 0010545
2014-10-12 21:11	Watermelon	Note Added: 0010559
2014-10-12 21:13	Watermelon	Note Edited: 0010559	View Revisions
2014-10-12 21:14	Watermelon	Note Edited: 0010559	View Revisions
2014-10-12 21:15	Watermelon	Note Edited: 0010559	View Revisions
2014-10-12 21:16	Watermelon	Note Edited: 0010559	View Revisions
2014-10-12 21:16	Watermelon	Note Edited: 0010559	View Revisions
2014-10-13 15:28	Watermelon	Assigned To	Watermelon =>
2014-10-13 15:29	Watermelon	Note Added: 0010570
2014-10-13 15:29	Watermelon	Summary	Clientside sector prediction => Clientside sector prediction for lines that the client activates
2014-12-31 12:18	Torr Samaho	Product Version	1.4 => 1.3
2015-01-01 17:28	Torr Samaho	Target Version	1.4 =>