Jump to content
Search In
  • More options...
Find results that contain...
Find results in...
Maes

Plutonia MAP12: Thing 225

Recommended Posts

I was checking my latest Mocha Doom builds (with sound) and decided to try jumping through random maps in various WADs, including plutonia.wad, MAP12 "Speed".

At first, the results weren't very encouraging: Mocha Doom crashed with two errors: one was the player being found in a special sector of type 8 (which is simply glowing light) but the linuxdoom code would cause that to default and exit with an error.

So what gives here? Sector type 8 is not supposed to be a player-checkable special (what for?) and so the error is in the map, or is that a mistake in the linuxdoom code?

The other is that I got a crash on Thing 225 at X,Y: 1600, -3104, which is of type 0 (DoomBuilder lists it as "unknown") and it causes a crash at P_SpawnMapThing, because its type (0) is then decremented by one in playerstarts[mthing.type-1] and of course breaks the bounds, before it's even checked as a valid map thing.

Couldn't find anything about this bug in the wiki. My Plutonia WAD is fresh off the the Replay Final Doom edition CD, and it passes the SHA1 and MD5 checks.

The net result, in Vanilla or bound-ignoring ports of Doom (pretty much every other but mine, hah!) would be to "spawn" a deathmatch start at position ... -1 of the playerstarts array, including spawning a phantom player on the map (in a single-player game, mind you) which is never visible.

// check for players specially
if (mthing.type <= 4)
{
// save spots for respawning in network games
DM.playerstarts[mthing.type-1] = mthing;
if (!DM.deathmatch)
  SpawnPlayer (mthing);
Of course I am adding safeguards against this type of problem (negative or zero mapthing type numbers may end up evaluating positively as players by P_SpawnMapThing, which is not correct behavior anyway). What puzzled me was that how ZDoom, Vanilla Doom etc. just "swallowed" this gross mapping error, and how it went unreported all these years.

Share this post


Link to post
Maes said:

So what gives here? Sector type 8 is not supposed to be a player-checkable special (what for?) and so the error is in the map, or is that a mistake in the linuxdoom code?


Sector type 8 is not supposed to last through level init. Normally it should be cleared in P_SpawnGlowingLight while the sector specials are initialized.

Maes said:

The other is that I got a crash on Thing 225 at X,Y: 1600, -3104, which is of type 0 (DoomBuilder lists it as "unknown") and it causes a crash at P_SpawnMapThing, because its type (0) is then decremented by one in playerstarts[mthing.type-1] and of course breaks the bounds, before it's even checked as a valid map thing.


With the original EXE it just overwrote the variable that's right before 'playerstarts' in memory.

I have no mapfile so I can't be sure but the variable that comes right before it in the source is 'deathmatch_p' which is not critical to be overwritten in a singleplayer game. So if that's indeed the variable that gets trashed a thing type 0 essentially is a no-op, as most ports handle it. In deathmatch it will be skipped like the other singleplayer start points by preceding code (unless there's more than 10 DM starts but that's not the case in this map.)

Share this post


Link to post
Sigvatr said:

Who drinks mocha anyway?



Share this post


Link to post

Boom silently fixed it:

if (mthing->type <= 4 && mthing->type > 0)  // killough 2/26/98 -- fix crashes
Apparently it just didn't cause any problems in the DOS exe. From log_lee.txt
2/26/98:

Fixed problem which caused linux version (and all DOS ports based on it) to
crash on Eternal MAP25 -- Thing type #0 was not being handled as a no-op,
and so memory was being corrupted. The symptoms were delayed, and bore
little relation to the cause (something common in these types of bugs <g>).
Incidentally, even Chocolate Doom includes a similar check.

Also, well done for not removing the bad taste quit messages ;-)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×