🚀 go-pugleaf

In article <197@nis.UUCP>, pnessutt@nis.UUCP (Robert A. Monio) writes:
> The problem exists in the file monster.c.  The aggravate() routine
> uses a while loop to "aggravate" the monsters on the level that the
> player is currently on.  While looping through the list of monsters on
> that level, the pointer to the next monster is updated and the monster
> is referenced before the pointer can be checked correctly.  To fix
> this problem, do the followng:

Yes, this bug was reported to me several months ago, and the fix posted.
Here, however, is a brand-new, never-before-seen bug that I just stumbled
upon today.

The code below is intended to ensure that party rooms have at least one
trap in them.  However, I forgot about the possibility of party-mazes, and
there can be no trap inside of a maze, not even a party-maze.  There was
also a '|' where there should have been a '&'  Tsk, tsk.  As a result, I
mysteriously teleported out of a party-maze.  Rare, but it can happen.

In the file trap.c, in the routine add_traps(): you have:

do {
	row = get_rand((rooms[party_room].top_row+1),
			(rooms[party_room].bottom_row-1));
	col = get_rand((rooms[party_room].left_col+1),
			(rooms[party_room].right_col-1));
	tries++;
} while ((dungeon[row][col] | (OBJECT | STAIRS | TRAP)) &&
		(tries < 15));
if (dungeon[row][col] & (OBJECT | STAIRS | TRAP)) {
	get_rand_row_col(&row, &col, (FLOOR | MONSTER));
}

Replace this with:

do {
	row = get_rand((rooms[party_room].top_row+1),
			(rooms[party_room].bottom_row-1));
	col = get_rand((rooms[party_room].left_col+1),
			(rooms[party_room].right_col-1));
	tries++;
} while ((dungeon[row][col] & (OBJECT | STAIRS | TRAP | TUNNEL)) &&
		(tries < 15));
if (dungeon[row][col] & (OBJECT | STAIRS | TRAP | TUNNEL)) {
	get_rand_row_col(&row, &col, (FLOOR | MONSTER));
}