[r3969?]Speed of Doom wall glitches

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 a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is OFF
Smilies are ON
Topic review
   

Expand view Topic review: [r3969?]Speed of Doom wall glitches

Re: [r3969?]Speed of Doom wall glitches

by Graf Zahl » Sun Nov 18, 2012 6:47 pm

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.

Re: [r3969?]Speed of Doom wall glitches

by Lars2500 » Sun Nov 18, 2012 6:32 pm

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

by Gez » Sun Nov 18, 2012 6:06 pm

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 49 times

Re: [r3969?]Speed of Doom wall glitches

by Lars2500 » Sun Nov 18, 2012 5:55 pm

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

by Gez » Sun Nov 18, 2012 5:53 pm

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

by Lars2500 » Sun Nov 18, 2012 5:34 pm

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

by Gez » Sun Nov 18, 2012 5:10 pm

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

by Blue Shadow » Sun Nov 18, 2012 5:06 pm

It's the recently added compatibility in r3965 for Khorus's map08 that is causing this, weirdly.

Re: [r3969?]Speed of Doom wall glitches

by Nightfall » Sun Nov 18, 2012 1:34 pm

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

by wildweasel » Sun Nov 18, 2012 11:57 am

Could be similar to this bug.

[r3969?]Speed of Doom wall glitches

by Major Cooke » Sun Nov 18, 2012 11:14 am

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.

Top