MantisBT - Zandronum |
View Issue Details |
|
ID | Project | Category | View Status | Date Submitted | Last Update |
0001955 | Zandronum | [All Projects] Bug | public | 2014-10-10 18:58 | 2018-09-30 23:12 |
|
Reporter | Arco | |
Assigned To | Watermelon | |
Priority | normal | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | |
Platform | Microsoft | OS | Windows | OS Version | XP/Vista/7 |
Product Version | 2.0-beta | |
Target Version | 1.4 | Fixed in Version | 2.0 | |
|
Summary | 0001955: Frozen corpse desync/teleportation |
Description | I 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 Reproduce | To 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. |
Additional Information | |
Tags | No tags attached. |
Relationships | |
Attached Files | Zandronum_10.10.2014_13.48.44.cld (85,593) 2014-10-10 18:58 /tracker/file_download.php?file_id=1306&type=bug |
|
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 | bug_revision_view_page.php?bugnote_id=10484#r5686 |
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 | bug_revision_view_page.php?bugnote_id=10550#r5739 |
2014-10-12 17:32 | Watermelon | Note Edited: 0010550 | bug_revision_view_page.php?bugnote_id=10550#r5740 |
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 | bug_revision_view_page.php?rev_id=5780#r5780 |
2014-10-16 06:21 | cobalt | Steps to Reproduce Updated | bug_revision_view_page.php?rev_id=5782#r5782 |
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 | bug_revision_view_page.php?rev_id=5993#r5993 |
2014-11-21 17:48 | Arco | Steps to Reproduce Updated | bug_revision_view_page.php?rev_id=5994#r5994 |
2018-09-30 23:12 | Blzut3 | Status | resolved => closed |
Notes |
|
|
Interetsing, this only happens for me during the countdown for the next survival round (doesn't happen on two+ lives) |
|
|
|
|
|
|
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. |
|
|
(0010484)
|
Watermelon
|
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.
|
|
|
|
Are you sure that you need "players[ulIdx].mo->health < 0" and not "players[ulIdx].mo->health <= 0"? |
|
|
|
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 ) )) |
|
|
|
|
|
|
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".. |
|
|
|
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. |
|
|
|
That's not the point. 'a || (~a && b)' is the same as 'a || b'. b is evaluated only if a is false. |
|
|
|
Edward-san is right. "players[ulIdx].mo->health <= 0" is redundant. |
|
|
|
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.
|
|
|
|
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. |
|
|
|
I wonder if there's another flag which makes that check incomplete ... does this happen when the head is detached from the body? |
|
|
|
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. |
|
|
|
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. |
|
|
(0010610)
|
cobalt
|
2014-10-16 06:21
|
|
|
|
(0010923)
|
Arco
|
2014-11-21 17:48
|
|
Works correctly in r141117-2018. |
|