[r3969?]Speed of Doom wall glitches
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
- Major Cooke
- Posts: 8176
- Joined: Sun Jan 28, 2007 3:55 pm
- Preferred Pronouns: He/Him
- Location: QZDoom Maintenance Team
[r3969?]Speed of Doom wall glitches
This is noticeable on several maps, in particularly such as MAP09 - Depredation. When encountering these, the player tends to get "stuck" and is unable to move.
To replicate, go to map09. Turn to your right and go down that corridor. Open the first door on the right hand side of this corridor into the small room with a switch. Run up against the wall opposite the switch.
You'll notice how you are suddenly stuck, as if glued to it. Noclipping results in the player being flung forward, and if using the automap with colored triggered lines, you'll see that wall in particular has a trigger on it. I'm not sure when this occurred, but this didn't happen some time before.
Throughout SoD, there are more of these walls occurring as well.
To replicate, go to map09. Turn to your right and go down that corridor. Open the first door on the right hand side of this corridor into the small room with a switch. Run up against the wall opposite the switch.
You'll notice how you are suddenly stuck, as if glued to it. Noclipping results in the player being flung forward, and if using the automap with colored triggered lines, you'll see that wall in particular has a trigger on it. I'm not sure when this occurred, but this didn't happen some time before.
Throughout SoD, there are more of these walls occurring as well.
- wildweasel
- Posts: 21706
- Joined: Tue Jul 15, 2003 7:33 pm
- Preferred Pronouns: He/Him
- Operating System Version (Optional): A lot of them
- Graphics Processor: Not Listed
- Contact:
Re: [r3969?]Speed of Doom wall glitches
Could be similar to this bug.
Re: [r3969?]Speed of Doom wall glitches
I've noticed this too, I've had it happen in the lights-out room in Doom 2 MAP28. I had to noclip to get out.. but not before getting thrusted right after I activated the no clipping mode.
EDIT: Here is a demo: https://dl.dropbox.com/u/66055976/stuck_demo.lmp.zip
Recorded with r3966. Perfectly reproducable.
EDIT: Here is a demo: https://dl.dropbox.com/u/66055976/stuck_demo.lmp.zip
Recorded with r3966. Perfectly reproducable.
-
- Posts: 4949
- Joined: Sun Nov 14, 2010 12:59 am
Re: [r3969?]Speed of Doom wall glitches
It's the recently added compatibility in r3965 for Khorus's map08 that is causing this, weirdly.
Re: [r3969?]Speed of Doom wall glitches
Do they somehow all have the exact same MD5 sum? Because if not, then it really cannot be that.
Re: [r3969?]Speed of Doom wall glitches
Something seems to be broken with checksum calculation in the latest SVNs, actually. A "mapchecksum" on the console returns a value of D41D8CD98F00B204E9800998ECF8427E for all maps. This is also the checksum that has been put into compatibility.txt for Khorus map08.Gez wrote:Do they somehow all have the exact same MD5 sum? Because if not, then it really cannot be that.
Re: [r3969?]Speed of Doom wall glitches
Found the problem:
The issue is that file is NULL.
Code: Select all
void MapData::GetChecksum(BYTE cksum[16])
{
MD5Context md5;
if (file != NULL)
{
if (isText)
{
Seek(ML_TEXTMAP);
md5.Update(file, Size(ML_TEXTMAP));
}
else
{
if (Size(ML_LABEL) != 0)
{
Seek(ML_LABEL);
md5.Update(file, Size(ML_LABEL));
}
Seek(ML_THINGS);
md5.Update(file, Size(ML_THINGS));
Seek(ML_LINEDEFS);
md5.Update(file, Size(ML_LINEDEFS));
Seek(ML_SIDEDEFS);
md5.Update(file, Size(ML_SIDEDEFS));
Seek(ML_SECTORS);
md5.Update(file, Size(ML_SECTORS));
}
if (HasBehavior)
{
Seek(ML_BEHAVIOR);
md5.Update(file, Size(ML_BEHAVIOR));
}
}
md5.Final(cksum);
}
Re: [r3969?]Speed of Doom wall glitches
According to http://en.wikipedia.org/wiki/MD5, D41D8CD98F00B204E9800998ECF8427E is actually the checksum of a zero-length string.
Re: [r3969?]Speed of Doom wall glitches
And here is a fix. Includes both a corrected p_setup.cpp so that the map's file isn't NULL anymore, but also a fixed checksum for Khorus MAP08.
- Attachments
-
- mapchecksumfix.zip
- (671 Bytes) Downloaded 52 times
Re: [r3969?]Speed of Doom wall glitches
Do you have an idea what broke it or since when this bug is around? It seems quite a few revisions back and searching through the changelog I cannot find anything that seems related to checksum calculation.Gez wrote:And here is a fix. Includes both a corrected p_setup.cpp so that the map's file isn't NULL anymore, but also a fixed checksum for Khorus MAP08.
Just curious.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49073
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: [r3969?]Speed of Doom wall glitches
patch applied.
This broke when blzut3 unified the map loading code that was present in various places, if I'm not mistaken. That would be r3897.
This broke when blzut3 unified the map loading code that was present in various places, if I'm not mistaken. That would be r3897.