Kicking a monster as a monk or samurai or while wearing kicking
boots might make it "reel from the blow" and be knocked back a step.
If that knock back put it into a trap which killed it, the kicking
code would kill it an extra time, then the player would get a warning
about dmonsfree finding the wrong number of dead monsters.
[ I didn't keep a copy of the message which reported this
so don't have any reference number for it. ]
If you used '/' to look at multiple items one after another,
then looking at floor or other item represented by the same '.' as
venom could result in subsequent things being falsely categorized as
possibly venom. The subsequent items needed to have less than two
possible descriptions, and the triggering item needed to be a plain
dot rather than the graphic dot used for floor with IBMgraphics and
DECgraphics.
Suggested by <Someone>: when examining an `@' monster, only include
"or you" in the description if you might reasonably expect to be seen
as something else. So if you're playing as a human or an elf, or if
you're polymorphed regardless of race, the ordinary description of
"human or elf" doesn't need to add "or you". And the setting of the
`showrace' option only matters if the `@' comes from prompting the
user instead of picking a symbol from the map.
Paper golems destroyed by fire traps won't leave any scrolls
of blank paper behind. (There's still no handling of other forms
of fire attack against such critters.)
Don't suppress hallucination on/off messages when blind.
This fixes the case where you might be observing hallucinatory
monsters via telepathy yet not be told that perception was back
to normal when hallucination timed out. It does not fix the
case where temporary hallucination times out while the effect is
being blocked (in which case successful application of a unicorn
horn yields no feedback), nor the hypothetical cases where timed
hallucination starts or ends while also hallucinating for some
other reason (which could happen via polymorph someday if a
monster which is always hallucinating--the way that bats are
always stunned--ever gets introduced).
Make throwing things through iron bars by the player and
by monsters behave consistently with each other. Also prevent
stone-to-flesh'd boulders and wands from passing through.
Warwick's plname files.c addition broke the
build on both win32 and CE because NAMES_MAX
wasn't defined.
In win32 it was defined in limits.h, but only
when _POSIX_ was defined.
In CE it just didn't exist in any of the
header files. Since it was also complaining
about strdup(), I #ifdef'd Warwick's code out
under CE.
Move get_saved_games() functionality to files.c
Use moved get_saved_games() functionality in Qt windowport.
[also some non-enabled perminv code in Qt windowport]
Allow single character variations in player names
to remain unique in file names by encoding rather
than substituting.
"plnam one", "plnam_one", and "plnam~one" at the
"Who are you?" prompt get unique filenames after this patch.
> It's probably best to empty
> mswin_update_inventory() in win\win32\. If I
> remember correctly there is some code in there now
> which probably behaves badly if perm_invent is
> switched on
Implement a suggestion by <Someone> that turns spent in
"hungry" state exercise wisdom for monk characters; also make
turns spent in "satiated" state abuse it instead.
for now at least, until there is more time to look into it.
<email deleted>
> Yet more nitpicking about potions of oil being lit by sparks from axed
> statues, I'm afraid.
>
> Konosja's potions of oil catch light!
> "That will cost you 66 zorkmids (Yendorian Fuel Tax)."
> "That's in addition to the cost of Konosja's potions of oil themselves, of
> course."
> You snuff the lit potion.
>
> a) why is the Fuel Tax on (in this case) six potions the same as on one?
>
> b) if you a)pply-light a potion, it's just "in addition to the cost of
> the potion". Is Yname2() the right name-function for catch_lit() to
> be using? It's odd for Konosja to be talking about herself in the
> third person.
>
> c) Grammar on the snuffing message is wrong for multiple potions.
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.
Paper golems take 100% damage in a fire trap. Straw is very flammable
unless tightly packed, but straw golems have a lot of surface area, so give
them 50% damage.
On mazelike levels, containers had to be listed before their objects. But,
for roomfilled levels, containers had to be listed _after_ the objects. All
our current levels that use containers with objects are mazelike, so I
changed the room behavior, updating the comment in lev_comp.y to match.
Other items/monsters are still processed in reverse on roomfilled special
levels, but I think this is OK.
Since -s doesn't function properly under the WIN32
graphical interface as yet, disable it altogether.
Also clean up nhusage() so that it does work with
the WIN32 graphical interface.
<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.
This does not fix a reported bug where you
can't attack a hidden creature that is
co-located with a boulder, but it might
assist the player in understanding what is
going on.