pnessutt@nis.UUCP (Robert A. Monio) (03/16/87)
In the recent posting of the rogue source a bug exists which causes a core dump when you read a aggravate monster scroll. ("High Pitched Humming Noise") I have not seen any postings from anyone concerning this problem so I figured I would post this fix. 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: In monster.c, module aggravate()'s while loop looks like this in the original posting : while (monster) { wake_up(monster); monster->m_flags &= (~IMITATES); monster = monster->next_monster; if (rogue_can_see(monster->row, monster->col)) { mvaddch(monster->row, monster->col, monster->m_char); } To correct the updating problem (and thus get rid of the core dump), you should correct the block to look like this : while (monster) { wake_up(monster); monster->m_flags &= (~IMITATES); if (rogue_can_see(monster->row, monster->col)) { mvaddch(monster->row, monster->col, monster->m_char); monster = monster->next_monster; } Note that the monster pointer is now being updated after the if block and that the null pointer will now be caught by the while loop. I hope this helps anyone who has run into the same problem I have. For anyone who is interested, I have this running on a NCR Tower XP running SYS VR2 NCR Release 3.01. All of the previous patches (SYS V updates and the fix to the unpack_armor routines) are installed. I've encountered no other problems with this rogue source. Good luck with this and Happy Hunting! -Bob -- Robert A. Monio UUCP: ihnp4!meccts!nis!pnessutt Systems/Analyst - Technical Services ATT: (612) 894-9494 National Information Systems, Inc. "These Proceedings are Closed!"
tims@zeus.TEK.COM (Tim Stoehr) (03/18/87)
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)); }