From a bug report: zapping force
bolt broke an adjacent potion of blindness (possibly carried by the monster
he was attacking) which caused "it suddently gets dark" but further course
of the bolt resulted in now blinded hero recieving "a door appears in the
wall". make_blinded() was deferring vision recalculation until next pass
through moveloop() (or until next pline()--if the "gets dark" message had
been delivered after the call to make_blinded() instead of before, this
wouldn't have been noticeable). Fix is trivial: just recalculate vision
immediately when temporary blindness is toggled. [It might also be needed
for involuntary blindfold removal, although I suspect that that is always
accompanied by corresponding pline() which gets vision back into synch.]
If you dug in a pit next to a sleeping, angry monster, you'd stop every
turn due to a complex check at the end of dochugw. It turned out this
was due to a long-standing bug in the special case vision code that failed
to set the COULD_SEE bit for the locations where it set the IN_SIGHT bit.
It looks like the underwater code had the same problem (it didn't set the
bit, obviously there are no pits underwater). However, the same could
occur if you see the angry, sleeping monster with Xray vision. In this
case, setting COULD_SEE is not appropriate, so added a mcanmove check to
the complex check in dochugw.
- new iflags.vision_inited to determine if vision is ready to go.
- the flag is set the first time vision_reset() completes, actually every time
- vision_recalc() checks the flag before doing anything.
