Zandronum Chat on our Discord Server Get the latest version: 3.2
Source Code
My View | View Issues | Change Log | Roadmap | Zandronum Issue Support Ranking | Rules | My Account
  

View Issue Details [ Jump to Notes ] [ Issue History ] [ Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001955Zandronum[All Projects] Bugpublic2014-10-10 18:582018-09-30 23:12
ReporterArco 
Assigned ToWatermelon 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformMicrosoftOSWindowsOS VersionXP/Vista/7
Product Version2.0-beta 
Target Version1.4Fixed in Version2.0 
Summary0001955: Frozen corpse desync/teleportation
DescriptionI ran across this bug while I was testing a hexen mod online in survival. When I die to freeze projectiles, and when I respawn when the frozen corpse breaks, it seems to teleport me to where I died. I've uploaded a demo and the wad in question is here.

I thought this bug only happened on hexen but it appears to happen in doom as well.
Steps To ReproduceTo do this bug, I used a test wad from another ticket.

1. zandronum.exe -iwad doom2.wad -file FreezeHueTest.wad +survival 1 -host
2. Wait for the countdown to stop and walk on the elevated surface to summon a rocket to kill yourself.
3. When the countdown resumes, move.
Attached Files? file icon Zandronum_10.10.2014_13.48.44.cld [^] (85,593 bytes) 2014-10-10 18:58

- Relationships

-  Notes
User avatar (0010459)
Watermelon (developer)
2014-10-11 00:17

 Interetsing, this only happens for me during the countdown for the next survival round (doesn't happen on two+ lives)
User avatar (0010460)
Watermelon (developer)
2014-10-11 00:49

 Attempted fix:

'https://bitbucket.org/ChrisKOmg/zandronum-stable/commits/bed0364e7f1dc1bf67bf8307cb0b7017072e4344 [^]'


Works for me, no weird stuff going on. Everything appears to work as normal. Code review requested.
User avatar (0010473)
Torr Samaho (administrator)
2014-10-11 09:49

 This looks more like a workaround for the actual problem. I think what's going on here is that GAMEMODE_RespawnDeadSpectatorsAndPopQueue doesn't properly take care of the frozen corpses.

From a quick look I'd guess the problem could be in this block:

        if (( players[ulIdx].mo ) && ( players[ulIdx].mo->health > 0 ))
        {
            if ( NETWORK_GetState( ) == NETSTATE_SERVER )
                SERVERCOMMANDS_DestroyThing( players[ulIdx].mo );

            players[ulIdx].mo->Destroy( );
            players[ulIdx].mo = NULL;
        }

The fact that it's only done if "( players[ulIdx].mo->health > 0 )" means that this will not cover the frozen corpses.
User avatar (0010484)
Watermelon (developer)
2014-10-11 13:57
edited on: 2014-10-11 13:58

 Setting the if statement you provided to this fixes the problem when I compiled/tested it:

Quote
if (( players[ulIdx].mo ) && ( players[ulIdx].mo->health > 0 || ( players[ulIdx].mo->health < 0 && players[ulIdx].mo->flags & MF_ICECORPSE ) ))



If you like this solution, I can commit it.
User avatar (0010489)
Torr Samaho (administrator)
2014-10-11 15:31

 Are you sure that you need "players[ulIdx].mo->health < 0" and not "players[ulIdx].mo->health <= 0"?
User avatar (0010494)
Watermelon (developer)
2014-10-11 15:57

 Good catch.

Would you like me to commit the following addition:

if (( players[ulIdx].mo ) && ( players[ulIdx].mo->health > 0 || ( players[ulIdx].mo->health <= 0 && players[ulIdx].mo->flags & MF_ICECORPSE ) ))
User avatar (0010506)
Torr Samaho (administrator)
2014-10-11 18:00

 Sounds good.
User avatar (0010513)
Edward-san (developer)
2014-10-11 23:20

 imho "players[ulIdx].mo->health <= 0" is redundant, since "players[ulIdx].mo->flags & MF_ICECORPSE" is checked if "players[ulIdx].mo->health > 0" is false, ie "players[ulIdx].mo->health <= 0"..
User avatar (0010515)
Watermelon (developer)
2014-10-12 00:35
Quote
imho "players[ulIdx].mo->health <= 0" is redundant, since "players[ulIdx].mo->flags & MF_ICECORPSE" is checked if "players[ulIdx].mo->health > 0" is false, ie "players[ulIdx].mo->health <= 0"..


Do you know if it's possible with A_ChangeFlag or some other function to set MF_ICECORPSE with a >0 health? If not then I'll remove the redundant code.
User avatar (0010526)
Edward-san (developer)
2014-10-12 09:55

 That's not the point. 'a || (~a && b)' is the same as 'a || b'. b is evaluated only if a is false.
User avatar (0010532)
Torr Samaho (administrator)
2014-10-12 13:22

 Edward-san is right. "players[ulIdx].mo->health <= 0" is redundant.
User avatar (0010550)
Watermelon (developer)
2014-10-12 17:32
edited on: 2014-10-12 17:32
Quote
That's not the point. 'a || (~a && b)' is the same as 'a || b'. b is evaluated only if a is false.


Never said I disagreed with you:
My point is that later versions of ZDoom allow players to do a lot with flag settings, and we could just end up in a situation where we run into this bug again if modders can set the flag on people that have >0 health. I guess 'safety insurance' is what I'm getting at. Maybe a further question, can ACS set player health to be greater than 0 after they've been 'ice corpsed'?

Though for right now, it's redundant and pointless to have it in since it can only be set when <= 0 health, so I removed it. I guess the plan is fix it in the future if it comes up?

I'll have a pull request shortly.
User avatar (0010551)
Watermelon (developer)
2014-10-12 18:05

 So I thought about this a bit more, shouldn't this not be happening in the first place?

If the player has a valid body, pulling it to another one doesn't sound right.
User avatar (0010555)
Edward-san (developer)
2014-10-12 18:48

 I wonder if there's another flag which makes that check incomplete ... does this happen when the head is detached from the body?
User avatar (0010556)
Torr Samaho (administrator)
2014-10-12 18:49

 The problem is that GAMEMODE_RespawnDeadSpectatorsAndPopQueue creates an invalid game state by not properly treating the old body before spawning the new one. Deleting the old body is one way to fix that.
User avatar (0010604)
Watermelon (developer)
2014-10-15 23:20

 Pull request sent.

I figure if it comes up again, then we can always figure out what is going on. This only occurs during the countdown phase and doesn't majorly affect the game, so this should do for now.
User avatar (0010610)
cobalt (updater)
2014-10-16 06:21

 Issue addressed by commit 792d5dff5af9: Fixed frozen actor persisting into countdown phases and desyncing client's POV (fixes 1955).
Committed by WChrisK on Wednesday 15 October 2014 19:17:04

Changes in files:
 docs/zandronum-history.txt | 1 +
 src/gamemode.cpp | 4 +++-
 2 files changed, 4 insertions(+), 1 deletions(-)
User avatar (0010923)
Arco (updater)
2014-11-21 17:48

 Works correctly in r141117-2018.

Issue Community Support
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-10-10 18:58 Arco New Issue
2014-10-10 18:58 Arco File Added: Zandronum_10.10.2014_13.48.44.cld
2014-10-11 00:17 Watermelon Note Added: 0010459
2014-10-11 00:17 Watermelon Status new => confirmed
2014-10-11 00:49 Watermelon Note Added: 0010460
2014-10-11 00:49 Watermelon Assigned To => Watermelon
2014-10-11 00:49 Watermelon Status confirmed => needs review
2014-10-11 09:49 Torr Samaho Note Added: 0010473
2014-10-11 09:49 Torr Samaho Status needs review => feedback
2014-10-11 13:57 Watermelon Note Added: 0010484
2014-10-11 13:57 Watermelon Status feedback => needs review
2014-10-11 13:58 Watermelon Note Edited: 0010484 View Revisions
2014-10-11 15:31 Torr Samaho Note Added: 0010489
2014-10-11 15:32 Torr Samaho Status needs review => feedback
2014-10-11 15:57 Watermelon Note Added: 0010494
2014-10-11 15:57 Watermelon Status feedback => needs review
2014-10-11 18:00 Torr Samaho Note Added: 0010506
2014-10-11 18:00 Torr Samaho Status needs review => feedback
2014-10-11 23:20 Edward-san Note Added: 0010513
2014-10-12 00:35 Watermelon Note Added: 0010515
2014-10-12 00:35 Watermelon Status feedback => needs review
2014-10-12 09:55 Edward-san Note Added: 0010526
2014-10-12 13:22 Torr Samaho Note Added: 0010532
2014-10-12 13:49 Torr Samaho Status needs review => feedback
2014-10-12 17:32 Watermelon Note Added: 0010550
2014-10-12 17:32 Watermelon Note Edited: 0010550 View Revisions
2014-10-12 17:32 Watermelon Note Edited: 0010550 View Revisions
2014-10-12 18:05 Watermelon Note Added: 0010551
2014-10-12 18:05 Watermelon Status feedback => needs review
2014-10-12 18:48 Edward-san Note Added: 0010555
2014-10-12 18:49 Torr Samaho Note Added: 0010556
2014-10-12 18:51 Torr Samaho Status needs review => feedback
2014-10-15 23:20 Watermelon Note Added: 0010604
2014-10-15 23:20 Watermelon Status feedback => needs review
2014-10-16 06:21 cobalt Status needs review => needs testing
2014-10-16 06:21 cobalt Target Version => 1.4
2014-10-16 06:21 cobalt Description Updated View Revisions
2014-10-16 06:21 cobalt Steps to Reproduce Updated View Revisions
2014-10-16 06:21 cobalt Note Added: 0010610
2014-11-21 17:48 Arco Note Added: 0010923
2014-11-21 17:48 Arco Status needs testing => resolved
2014-11-21 17:48 Arco Resolution open => fixed
2014-11-21 17:48 Arco Fixed in Version => 2.0
2014-11-21 17:48 Arco Description Updated View Revisions
2014-11-21 17:48 Arco Steps to Reproduce Updated View Revisions
2018-09-30 23:12 Blzut3 Status resolved => closed




Questions or other issues? Contact Us.

Links

Copyright © 2000 - 2025 MantisBT Team
Powered by Mantis Bugtracker