inappropriate lit_corridor check

To reproduce: disable lit_corridor, enter a corridor, read a scroll of
light, then read a cursed scroll of light.  The corridor won't darken again.
A test of flags.lit_corridor in newsym was at fault.  I'm guessing this was
never noticed because lit_corridor is on by default on Windows and the
default lit and unlit corridor symbols are the same on most other platforms.
This commit is contained in:
cohrs
2003-10-23 06:49:22 +00:00
parent 7ad89fbbdd
commit f7a681a139
2 changed files with 5 additions and 3 deletions

View File

@@ -68,6 +68,8 @@ fix an impossible rndmonst: bad `mndx' bug
pets should not try to go after objects that they can't reach
cutting a shopkeeper polymorphed in to a long worm would generate strange
messages and could cause a crash
reading a cursed scroll of light in a corridor wouldn't display correctly
if lit_corridor option was disabled
Platform- and/or Interface-Specific Fixes

View File

@@ -746,14 +746,14 @@ newsym(x,y)
* Note: If flags.lit_corridor is set, then corridors act like room
* squares. That is, they light up if in night vision range.
* If flags.lit_corridor is not set, then corridors will
* remain dark unless lit by a light spell.
* remain dark unless lit by a light spell and may darken
* again, as discussed above.
*
* These checks and changes must be here and not in back_to_glyph().
* They are dependent on the position being out of sight.
*/
else if (!lev->waslit) {
if (flags.lit_corridor && lev->glyph == cmap_to_glyph(S_litcorr) &&
lev->typ == CORR)
if (lev->glyph == cmap_to_glyph(S_litcorr) && lev->typ == CORR)
show_glyph(x, y, lev->glyph = cmap_to_glyph(S_corr));
else if (lev->glyph == cmap_to_glyph(S_room) && lev->typ == ROOM)
show_glyph(x, y, lev->glyph = cmap_to_glyph(S_stone));