MantisBT - Zandronum
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0000764Zandronum[All Projects] Bugpublic2012-04-12 03:072012-04-15 22:11
Reporterunknownna 
Assigned ToTIHan 
PrioritylowSeveritytrivialReproducibilityalways
StatusfeedbackResolutionopen 
PlatformOSOS Version
Product Version98d 
Target VersionFixed in Version 
Summary0000764: View bobs after being affected by A_Stop + PROP_FROZEN
DescriptionAnother movebob issue online.
Steps To Reproduce1. skulltag.exe -file stop_frozen_01.wad -host
2. Connect a client to the server with an emulated ping of 100 and join the game.
3. Press +attack while holding +forward.
Additional InformationThis also happens in 98e.
TagsNo tags attached.
Relationships
related to 0000484closed Dusk View bobs after being affected by Thing_Stop online 
related to 0000309closed Torr Samaho View bobs after teleporting online (movebob) 
related to 0000744closed Torr Samaho View bobs after unmorphing online 
related to 0000778confirmed  A_BishopMissileWeave behaves oddly when used on players online 
Attached Files? stop_frozen_01.wad (2,222) 2012-04-12 03:07
https://zandronum.com/tracker/file_download.php?file_id=532&type=bug
Issue History
Date ModifiedUsernameFieldChange
2012-04-12 03:07unknownnaNew Issue
2012-04-12 03:07unknownnaFile Added: stop_frozen_01.wad
2012-04-12 03:07unknownnaStatusnew => confirmed
2012-04-12 03:08unknownnaRelationship addedrelated to 0000484
2012-04-12 03:08unknownnaRelationship addedrelated to 0000309
2012-04-12 03:09unknownnaRelationship addedrelated to 0000744
2012-04-12 03:09TIHanAssigned To => TIHan
2012-04-12 03:09TIHanStatusconfirmed => assigned
2012-04-13 02:04TIHanNote Added: 0003230
2012-04-13 02:04TIHanStatusassigned => feedback
2012-04-14 17:49Torr SamahoNote Added: 0003247
2012-04-14 18:19TIHanNote Added: 0003248
2012-04-14 18:29TIHanNote Edited: 0003248bug_revision_view_page.php?bugnote_id=3248#r1727
2012-04-14 18:48Torr SamahoNote Added: 0003249
2012-04-14 19:08TIHanNote Added: 0003250
2012-04-14 19:18Torr SamahoNote Added: 0003251
2012-04-15 22:11TIHanRelationship addedrelated to 0000778
2012-06-09 13:22Torr SamahoCategoryGeneral => Bug

Notes
(0003230)
TIHan   
2012-04-13 02:04   
Fixed.
'https://bitbucket.org/TIHan/tst/changeset/e014fe666079 [^]'
(0003247)
Torr Samaho   
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   
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   
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   
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   
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.