Fix the situation <Someone> reported where requesting information about
the not too unlikely word "offering" would match the "ring" quote. I didn't
add a new quote for it but made "offer[ing]" and "sacrific[e|ing]" match the
existing altar quote. I also added one small quote I've had laying around
for a while.
Disable processing of double-click messages if the first click
causes map to scroll. The problem is that if the first click scrolls
the map the second click is going to scroll it even further
(before it is redrawn) which is very confusing for the user.
>If you hit a cockatrice with a weapon that immediately breaks
>(like a potion, mirror, or cockatrice egg) you get stoned,
Add a parameter to passive() to make it possible to pass
additional information that indicates that the weapon was
there at the start of the turn, but destroyed during the turn.
Fix the bug From a bug report. Subsequently removing
the item caused those attributes to be returned to an incorrect value
which was higher than the character started out with.
<Someone> wrote:
> You have much trouble removing u - a helmet.
> You have much trouble lifting a plate mail. Continue? [ynq] (q)
> You have much trouble removing R - a plate mail.
> You have much trouble removing N - a leather cloak.
> Why am I told that I have trouble "lifting" a plate mail?
1. Add strsubst() routine to hacklib to replace a word or phrase in a string in place.
2. Correct the inconsistency reported.
- as requested by ESR, remove the use of parentheses from the usage
summary, it confused some man page conversion tool he has
- updated documentation for the -p option to mention the word "role"
so anyone search for role in the man page will still find it
- removed use of .UC, it is listed as deprecated in all the current man
documentation I could find, when it was even documented at all
- other minor spelling and formatting (hyphenation) changes
<Someone> reported that dipping acid in a fountain did not always destroy
the acid. It might be best to have get_wet call useup in this case, but
that would require more work.
Reported to the list back in November: scaring a mimicing mimic will
produce a "turns to flee" message, but the mimic does not unmimic nor
does it flee. The latter behavior made sense to me as a defense mechanism,
so I changed monflee to avoid printing the message in this case.
Change pit behavior to always mark a non-flying poly'd player as trapped in
a pit, even when Passes_walls is set. This allows players polymorphed into
xorns to descend into pits and pick things up. In this case, any attempt
to move out of the pit now takes a turn but always succeeds. Also fixed
a related bug (w/o ID) that a player could become trapped as if in a pit
when leaving xorn form because u.utrap wasn't checked, and simplified the
code since the extra Passes_walls checks are no longer needed. Also
updated code in sit.c that duplicated uteetering_at_seen_pit.
<Someone> reported back in December of an invisible monster using an amulet of
lifesaving and looking much better. While the comment in the code says the
amulet is visible, this does not mean the monster is. Add a secondary check.
Both the reported tombstone message and the initial message could be
grammatically incorrect for eating identified artifacts. This begs the
question whether artifacts should be so easy to destroy.
<Someone> drew attention to the silly message in the newsgroup
Since I'm not sure if the act of polymorphing has a sound,
I opted to use a new usmellmon() routine to put out a
message based on the smell of the resulting monster
under those circumstances.
Not every monster has a recognizable smell, so no
message at all is given in that case.
olfactory(youmonst.data) will determine whether
you are capable of detecting smells.
There is lots of room for enhancement, and some of the
existing smell-related messages in the source should perhaps
be checking olfactory(youmonst.data) too, but this patch
doesn't go that far.
Implement the patch sent by <email deleted>
to make responding with '?' at the "what direction?" prompt ask again
after giving the `cmdassist' direction display. I did it slightly
differently than was done in the submitted patch but the result is the
same except that it also suppresses the message about how to disable
cmdassist in this case.
Fix the recently reported problem:
" If there is a corpse in a pit, you have to enter the pit in order to pick
" it up, however you are can eat it without being in the pit.
If pit bottoms aren't reachable, then can_reach_floor() needs to know
about it. I suspect that this change is likely to create some other
bugs though.
Fix the recently reported bug about the wording of trap messsages
when hero's steed has a name but hallucination prevents that name from
being used, yielding "You lead poor wombat into a pit!" and the like.
I accidentally deleted the message so can't reply to the sender.
[Before applying this patch, take a look at the POLY_TRAP case of the
switch statement in steedintrap(). A misplaced brace has drawn the
default case into one of its `if' statements. Evidently it's valid C
syntax, but someone among us must have access to a compiler or lint
checking tool which is capable to diagnosing such things.]
"You push the boulder into the pool" should be "Your steed pushes
the boulder into the pool" if done while riding since that's how other
boulder pushing messages are handled.
<email deleted> wrote:
> Not sure what exactly should occur, but this seems funny: If
> you escape a pit and there is an object in the pit, you can
> not reach it to pick it up. Nor can you go down into the pit
> to get it, but sitting gives the message "you sit on the
> (object) it's not very comfortable. How can the character sit
> on it if it's in the bottom of the pit?
Mentioned in passing in the newsgroup: level teleporting in the
endgame--which is only possible in wizard mode--can crash if you're
confused. The change to make confusion sometimes override teleport
control means that sometimes a random destination will be chosen, and
the routine to choose a random level can call rn2() with a value less
than 1 in the endgame, possibly resulting in attempt to divide by 0.
There's something fishy about the min_/max_depth stuff for the
endgame, but I haven't attempted to figure that out. This just makes
the random destination always be the current level when in the endgame
so that the problem can't come up.
