0000764: View bobs after being affected by A_Stop + PROP_FROZEN

Notes
(0003230) TIHan (reporter) 2012-04-13 02:04	Fixed. 'https://bitbucket.org/TIHan/tst/changeset/e014fe666079 [^]'

(0003247) Torr Samaho (administrator) 2012-04-14 17:49	With your patch, the handling of A_Stop seems to get inconsistent. Usually clients skip the execution of code pointers where the server tells the clients of the outcome, this is different in your patch (and it only tells the affected client not all clients). Are you doing this intentionally? If so, can you elaborate why?

(0003248) TIHan (reporter) 2012-04-14 18:19 edited on: 2012-04-14 18:29	> With your patch, the handling of A_Stop seems to get inconsistent. Usually clients skip the execution of code pointers where the server tells the clients of the outcome, this is different in your patch (and it only tells the affected client not all clients). Are you doing this intentionally? If so, can you elaborate why? I am doing this intentionally. My intention was to save bandwidth. I don't think we need to inform other clients as the server will update the player accordingly to those clients anyway. However, I may be missing an important concept here - the reason why we should inform all clients. Edit: I forgot to mention that I think it is 'ok' that the client executes A_Stop for prediction purposes.

(0003249) Torr Samaho (administrator) 2012-04-14 18:48	I'm looking on this based on Skulltag's general concept on how code pointers are handled. Speaking very generally (as always, there are exceptions), if clients can determine the outcome of a code pointer on their own, they just execute the code pointer and the server doesn't inform them about anything. If clients can't determine the outcome, the clients skip the code pointer and the server tells all clients about the outcome. This can be refined in multiple ways, for instance there are code pointers where the client can determine the outcome for the consoleplayer and thus executes (parts of) the code pointer and the server skips informing that client. Or some other code pointers where the clients play a sound (and skip the rest of the code pointer) and the server doesn't inform the clients about the sound. Your handling doesn't fall in either case. You let the clients execute the code pointer on their own, but still let the server inform one player about the outcome. So in this case, for that player the momentum is zeroed twice. Once by the client itself and once when the clients executes the server command.

(0003250) TIHan (reporter) 2012-04-14 19:08	I think it is fine for the client to execute A_Stop as it can absolutely determine the outcome. If that's the case, we shouldn't even send information about the momentum change to the client. Thanks for clearing that up. Looking at this a little further. PROP_FROZEN isn't set by the client, but by the server. That means A_Stop executes on the client, but the client doesn't set his property to PROP_FROZEN right then; the server will inform the client of that. Two ways to handle this: 1. Make A_Stop completely handled by the server and notify client of the momentum change. 2. Allow client to change his property to PROP_FROZEN when SetPlayerProperty is activated by the him.

(0003251) Torr Samaho (administrator) 2012-04-14 19:18	> Looking at this a little further. PROP_FROZEN isn't set by the client, but by the server. That means A_Stop executes on the client, but the client doesn't set his property to PROP_FROZEN right then; the server will inform the client of that. That makes perfect sense. So it's a timing issue and possibly a good reason to go for your suggestion #1 (although I better don't imagine how many wads rely on the current behavior...). Note that PlayIdle needs special attention, the server automatically informs everybody but the player himself about this.

Only registered users can voice their support. Click here to register, or here to log in.
Supporters:	No one explicitly supports this issue yet.
Opponents:	No one explicitly opposes this issue yet.

Issue History
Date Modified	Username	Field	Change
2012-04-12 03:07	unknownna	New Issue
2012-04-12 03:07	unknownna	File Added: stop_frozen_01.wad
2012-04-12 03:07	unknownna	Status	new => confirmed
2012-04-12 03:08	unknownna	Relationship added	related to 0000484
2012-04-12 03:08	unknownna	Relationship added	related to 0000309
2012-04-12 03:09	unknownna	Relationship added	related to 0000744
2012-04-12 03:09	TIHan	Assigned To	=> TIHan
2012-04-12 03:09	TIHan	Status	confirmed => assigned
2012-04-13 02:04	TIHan	Note Added: 0003230
2012-04-13 02:04	TIHan	Status	assigned => feedback
2012-04-14 17:49	Torr Samaho	Note Added: 0003247
2012-04-14 18:19	TIHan	Note Added: 0003248
2012-04-14 18:29	TIHan	Note Edited: 0003248	View Revisions
2012-04-14 18:48	Torr Samaho	Note Added: 0003249
2012-04-14 19:08	TIHan	Note Added: 0003250
2012-04-14 19:18	Torr Samaho	Note Added: 0003251
2012-04-15 22:11	TIHan	Relationship added	related to 0000778
2012-06-09 13:22	Torr Samaho	Category	General => Bug