Eliminate two minor anomalies in the behavior of the rnl() function
which returns a random number that is modified by the hero's Luck attribute.
Integer division by 3 on requests for small ranges and the fact that the
chance of making a modification was lower for good luck than for bad luck
meant that highest luck did not produce best chance to avoid worst result.
The actual effect on game play is sure to have been negligible. More
troubling is that the program has several rnl(3) and rnl(4) calls. These
practically guarantee a result of 0 when the hero has maximum luck. The
rnl() function really shouldn't be used for such tiny ranges (unless the
actual intent is that high level characters are expected to almost always
have the 0 outcome...).
<Someone> Cced from rgrn:
<email deleted> (<Someone>) writes:
[killed by a boulder trap, left bones]
> Then I realized... there's no boulder. Did the boulder disappear
> because I died from the attack, thus bypassing the code that moves the
> boulder to its intended destination? Did the creation of the bones
> file destroy the boulder? Do boulder traps sometimes get
> "deactivated" when bones files are loaded?
The first of these. If you look at launch_obj(), there's an
obj_extract_self() early on, then all the tracking its trajectory,
then a place_object() when it comes to rest; since the thitu() call
kills you during the trajectory part, the boulder never gets re-placed
onto the map. This is, I think, a bug (and one that will apply to any
monster-thrown object that kills you, as well); reported to the
DevTeam.
A user pointed out that you lose pacifism conduct if you kill your
pet by displacing it into a trap but you don't gain any experience in
the process. Make this consistent with killing monsters in other ways:
if you get blamed for it then you should also get credit for it.
Probably minliquid() and mintrap() should take another argument so
they can call killed() instead of mondead() when necessary, but I didn't
go to that much effort....
From a bug report: fracture_rock() was unintentionally propagating
the boulder or statue's dknown flag to the resulting rocks, producing a
trivial but noticeable difference in description of "rock" vs "stone" if
the source object had been seen up close prior to being broken and the
rocks are then examined remotely or while blind.
The curse/bless state is propagating too, but this seems reasonable
so I've left it alone.
User reported the following incorrect feedback:
You drop Medusa's corpse. corpse falls down the stairs.
and apparently thought that the problem was a glitch in the middle of the
sentence; the actual problem is that the second sentence lacks its start.
This fix isn't perfect. You'll now get
Medusa's corpse falls down the stairs.
for the second sentence, but
The Oracle corpse falls down the stairs.
when dealing with a unique monster who doesn't have a personal name.
Either form seems acceptable to me, but mixing them appears inconsistent.
Probably all the uses of corpse_xname() (and its callers back up the
chain cxname(), aobjnam(), yobjnam()) need to be reviewed for usage. I
don't have the energy for that.
Fix the reported problem of being able to safely stand on lava after
taking off fireproofed water walking boots. The situation was more wide-
spread than that; the same thing happened when non-fireproofed boots were
burned off while walking over the lava in the first place. Now you'll
fall in and end up getting stuck (you have to have fire resistance for any
of this to happen and that resistance makes falling in be survivable).
Fix the situation <Someone> reported where the "You disturbed me, fool!"
result when releasing a djinni from a cloudy potion sometimes produced a
peaceful djinni for neutrals due to the usual randomness in how monsters
react to characters of the same alignment. Explicitly force it to be
hostile for that outcome.
Also, for the "it's about time" result, suppress the "It vanishes"
message when the character doesn't see the djinni depart.
Fix the situation <Someone> reported where a shopkeeper removing a trap
from the shop doorway yielded "you see the shop door reappear" instead of
reporting about the trap. It made sense if the door had been destroyed
but not when intact.
For trunk only, try to fix up the shop repair message situation when
multiple repairs occur at the same time. Some things were being treated
as mutually exclusive when they aren't. This part needs more testing,
probably using a debugger to force multiple pending repairs to all occur
on the same turn. At any rate, using wizard mode and hoping for some
simultaneous activity was ineffective.
<Someone> wrote:
>It seems silly to have two flags being used for counting djinn and
>ghosts, now that there's mvitals.born...
This does not break save and bones compatibility in the 3.4.x branch,
it changes the code, but leaves the obsolete fields in flags.
"<Someone>" on January 8, 2004, wrote:
> A Valkyrie on the Quest home level, wearing an
> amulet of magical breathing, enters a fire trap
> out on the ice:
>
>> A tower of flame erupts from the ice!
>> The ice crackles and melts.
>> You fall into the water. You sink like a rock.
>> But you aren't drowning. You touch bottom.
>> A cascade of steamy bubbles erupts from the bottom!
>
>Should the trap really be being triggered twice, once on ice and
>once underwater, when I've only moved onto the location once?
As From a bug report, if you couldn't see a rolling boulder
fall into a pit, you only heard the sound if you were blind.
Also fixes the article used in the message.
<Someone> reported:
>> The marilith wields 5 daggers!
>> The marilith thrusts her dagger. The marilith misses.
> Shouldn't she thrust her daggerS?
Change to:
"The marilith thrusts one of her daggers." in that case.
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.
