> Getting a sewer rat from a sink when not blind, but can't see it
> (because of boulders, etc.) gives "Eek! There's it in the sink!"
> [<email deleted>]
> Receiving Excalibur from a fountain while blind doesn't update the
> display (i.e. the missing fountain) immediately.
Various other topology changes had the same problem. The display
was only being updated if the hero was invisible on the assumption that
it wouldn't matter otherwise, but a blind character who moved off the
affected location would still have the old map info (fountain, trap, &c)
shown--until he walked back onto that spot or searched next to it or
regained sight--even though the player is told about the map change as
it happens.
Pat forwarded a message from the newsgroup in March that the town guards
enforce rules even outside the town proper. Fix: On room-based town levels,
check if the location is in a room containing subrooms (roomno will often
have a subroom id instead). On the other levels (e.g. minetn-5), there are
no subrooms, so the whole level is fair game. Currently, this is valid.
If fancier towns are added in the future, more flags or use of regions may
be required to tell where the town border actually is. These checks are done
in a new in_town function.
<Someone> writes:
Why do you "feel transparent" when you gain see invisible from a
fountain when blind and _not_ invisible? Transparency usually refers
to _being_ invisible.
Another try.
<Someone> writes:
Why do you "feel transparent" when you gain see invisible from a
fountain when blind and _not_ invisible? Transparency usually refers
to _being_ invisible.
Good point. I think this may have been what was intended, but it's
been like this for quite a while.
<Someone> writes:
I can accept that losing gold into a fountain recharges it to make it
possible to find a gem in it in future (however weird that is). What
_does_ seem wrong is that receiving a warning about a Minetown
fountain prevents finding gems and gold there.
When using a fountain or throne, getting a --More-- prompt
usually means that you're about to be told that it has just dried
up or vanished. But since that topology change didn't occur until
after the message, players could cheat by forcing SIGHUP instead
of answering the prompt; the resulting save file would retain the
original topology. So change the dungeon prior to telling the user
about it.
The `fixes' entry possibly belongs in the tty-specific category
but since the change is to core code I put it in the general section.
<Someone> reported that dowaternymph and dowaterdemon did not print a message
when their G_GONE checks failed. Now they do. I wasn't feeling
imaginative, so the the dowaterdemon message is the same as for no snakes.
This patch, based on code sent to us by <Someone> well over a year ago, addresses
bugs recently resurfaced. Namely, that lava does not generally do anything
to monsters or objects that land in java. Newly renamed minliquid() handles
both water and lava, and new fire_damage() is used similar to water_damage().
