[r3969?]Speed of Doom wall glitches

Bugs that have been investigated and resolved somehow.

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.
Post Reply
User avatar
Major Cooke
Posts: 8170
Joined: Sun Jan 28, 2007 3:55 pm
Preferred Pronouns: He/Him
Location: QZDoom Maintenance Team

[r3969?]Speed of Doom wall glitches

Post by Major Cooke »

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.
User avatar
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

Post by wildweasel »

Could be similar to this bug.
User avatar
Nightfall
Posts: 555
Joined: Thu Aug 06, 2009 4:00 am
Location: Finland

Re: [r3969?]Speed of Doom wall glitches

Post by Nightfall »

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.
Blue Shadow
Posts: 4949
Joined: Sun Nov 14, 2010 12:59 am

Re: [r3969?]Speed of Doom wall glitches

Post by Blue Shadow »

It's the recently added compatibility in r3965 for Khorus's map08 that is causing this, weirdly.
Gez
 
 
Posts: 17833
Joined: Fri Jul 06, 2007 3:22 pm

Re: [r3969?]Speed of Doom wall glitches

Post by Gez »

Do they somehow all have the exact same MD5 sum? Because if not, then it really cannot be that.
Lars2500
Posts: 66
Joined: Sat Jul 14, 2012 8:45 am

Re: [r3969?]Speed of Doom wall glitches

Post by Lars2500 »

Gez wrote:Do they somehow all have the exact same MD5 sum? Because if not, then it really cannot be that.
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
 
 
Posts: 17833
Joined: Fri Jul 06, 2007 3:22 pm

Re: [r3969?]Speed of Doom wall glitches

Post by Gez »

Found the problem:

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);
}
The issue is that file is NULL.
Lars2500
Posts: 66
Joined: Sat Jul 14, 2012 8:45 am

Re: [r3969?]Speed of Doom wall glitches

Post by Lars2500 »

According to http://en.wikipedia.org/wiki/MD5, D41D8CD98F00B204E9800998ECF8427E is actually the checksum of a zero-length string.
Gez
 
 
Posts: 17833
Joined: Fri Jul 06, 2007 3:22 pm

Re: [r3969?]Speed of Doom wall glitches

Post by Gez »

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 48 times
Lars2500
Posts: 66
Joined: Sat Jul 14, 2012 8:45 am

Re: [r3969?]Speed of Doom wall glitches

Post by Lars2500 »

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.
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.

Just curious.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49056
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: [r3969?]Speed of Doom wall glitches

Post by Graf Zahl »

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.
Post Reply

Return to “Closed Bugs [GZDoom]”