Page 1 of 1

[r3969?]Speed of Doom wall glitches

Posted: Sun Nov 18, 2012 11:14 am
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.

Re: [r3969?]Speed of Doom wall glitches

Posted: Sun Nov 18, 2012 11:57 am
by wildweasel
Could be similar to this bug.

Re: [r3969?]Speed of Doom wall glitches

Posted: Sun Nov 18, 2012 1:34 pm
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.

Re: [r3969?]Speed of Doom wall glitches

Posted: Sun Nov 18, 2012 5:06 pm
by Blue Shadow
It's the recently added compatibility in r3965 for Khorus's map08 that is causing this, weirdly.

Re: [r3969?]Speed of Doom wall glitches

Posted: Sun Nov 18, 2012 5:10 pm
by Gez
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

Posted: Sun Nov 18, 2012 5:34 pm
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.

Re: [r3969?]Speed of Doom wall glitches

Posted: Sun Nov 18, 2012 5:53 pm
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.

Re: [r3969?]Speed of Doom wall glitches

Posted: Sun Nov 18, 2012 5:55 pm
by Lars2500
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

Posted: Sun Nov 18, 2012 6:06 pm
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.

Re: [r3969?]Speed of Doom wall glitches

Posted: Sun Nov 18, 2012 6:32 pm
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.

Re: [r3969?]Speed of Doom wall glitches

Posted: Sun Nov 18, 2012 6:47 pm
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.