[Fixed] [r3969?]Speed of Doom wall glitches

Bugs that have been investigated and resolved somehow.

Moderator: Developers

[r3969?]Speed of Doom wall glitches

Postby 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.
User avatar
Major Cooke
That's how my uncle stole christmas three times in a row in a single year. -DBT
 
Joined: 28 Jan 2007

Re: [r3969?]Speed of Doom wall glitches

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

Could be similar to this bug.
User avatar
wildweasel
referee is tired of your shit
 
Joined: 15 Jul 2003
Location: america, home of the world's most expensive public education system

Re: [r3969?]Speed of Doom wall glitches

Postby 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.
User avatar
Nightfall
 
Joined: 06 Aug 2009
Location: Finland

Re: [r3969?]Speed of Doom wall glitches

Postby 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.
User avatar
Blue Shadow
 
Joined: 14 Nov 2010

Re: [r3969?]Speed of Doom wall glitches

Postby 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.
Gez
 
Joined: 06 Jul 2007

Re: [r3969?]Speed of Doom wall glitches

Postby 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.
Lars2500
 
Joined: 14 Jul 2012

Re: [r3969?]Speed of Doom wall glitches

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

Found the problem:

Code: Select allExpand view
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.
Gez
 
Joined: 06 Jul 2007

Re: [r3969?]Speed of Doom wall glitches

Postby 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.
Lars2500
 
Joined: 14 Jul 2012

Re: [r3969?]Speed of Doom wall glitches

Postby 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 17 times
Gez
 
Joined: 06 Jul 2007

Re: [r3969?]Speed of Doom wall glitches

Postby 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.
Lars2500
 
Joined: 14 Jul 2012

Re: [r3969?]Speed of Doom wall glitches

Postby 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.
User avatar
Graf Zahl
 
Joined: 19 Jul 2003
Location: Germany


Return to Closed Bugs

Who is online

Users browsing this forum: No registered users and 1 guest