From a bug report, the placement
of random doors by the code that loads special levels would attempt to
evaluate rn2(0) and either get a divide by zero crash (normal build) or an
impossible warning (DEBUG enabled when compiing rnd.c, done automatically
when BETA is defined). The problem was only noticable for random door in
a 1x1 room; none of our distributed levels specify such a thing so regular
users won't have encountered this bug. It's a one line fix.
Altar placement in temples also had a quirk of a similar nature. It
wouldn't trigger rn2(0) problems but would always place the altar to left
of mid-point in rooms with even width and above the center point in ones
with even height. Now the placement is randomized so that sometimes it'll
be to the right and/or below mid-point in such cases.
This also simplifies a couple other instances of similar expressions
that I spotted.
I noticed this a while back while inspecting an unrelated report.
It seems to me the breath of a dragon is more like broiling than baking
and thought the message wasn't consistent with this.
From a bug report: while hero
was blinded, monster zapped him with a not-yet-discovered wand of striking
and the wand type became discovered. The report was slightly off; the
described case is already handled correctly. However, if the zap happened
to hit a door, the wand would incorrectly be made known even when not seen.
From a bug report: dwarvish mattock was
subject to breaking when attempting to force a lock, because it is treated
as a bladed weapon. So is pick-axe; they're both defined as blunt (WHACK
attack mode), but the definition of is_blade() erroneously includes them
since P_PICK_AXE falls between P_DAGGER and P_SABER. That skill should be
renumbered, but I haven't investigated what else might happen when that's
done so this fix uses a special case instead.
I noticed that there was an unnecessary old check for rubber hose;
it's excluded along with whip by the skill > P_LANCE test. When fixing
that up, I realized that the obscure feature of forcing via statue was
broken; it always failed the skill < P_DAGGER test. Also, I took away the
exception for aklys; even though designed as a throwing weapon, it is used
as a club. I wasn't sure about the exception for flail; it is perfectly
capable of bashing things but the code apparently excludes it for use as
a prying implement. Switching its check to P_FLAIL catches grappling hook
along with it.
When looking at name_to_mon() to teach it how to cope with possessive
suffices, I discovered that it already knows how. But while looking at
it, I remembered a newsgroup complaint from a while back by someone who
accidentally committed suicide by attempting to genocide "master mindflayers"
(when he meant "master mind flayers"). name_to_mon() didn't recognize that
misspelling but it did match "master" as a role title. Unfortunately for
the player, his character was a monk; the game allowed him to genocide his
own role and he died. That's kind of harsh for such a likely misspelling.
(I don't think a monk is very likely to ever use "master thief" as a mistake
for "master of thieves", but catch that one too just in case. Conversely,
recognize "master of assassins" as an alternate for "master assassin".)
Also, wishing for "the <something>" strips off "the" and finds (or not)
<something>, but genociding didn't. You could specify "a wolf" to wipe out
all wolves, but "the wolf" yielded "such creatures don't exist", and ^G had
similar unfriendly behavior. This extends name_to_mon() to handle it.
From a bug report, "You have summoned it!" (when human
sacrifice brings a demon which you can't see) is poorly worded, to put it
mildly. I'm sure there are plenty of other places where "it" seems odd,
but this one is now fixed....
From a bug report, amorphous creatures can fit underneath
closed doors but could still be considered too big to fit through diagonal
gaps. Let them and several other shapeless or flexibly shaped critters
squeeze through provided that they pass the not-carrying-too-much check.
From a bug report: the Call command's
prompt is careful not to include "of <deity>" when asking what name to give
a high priest on the Astral level, but the resulting rejection message of
"the <unique monster> doesn't like to be called names" did not, resulting
in feedback of "the high priest of <deity>" and giving away which temple it
is from afar.
Forwarded from the newsgroup by Michael: giving a count before '.' to
rest many turns wouldn't be interrupted by having levitation end (despite
autopickup taking place at the time, which is what the thread is about but
not all that relevant to this particular issue). Stopping counted activity
is easy, so that's all I've done. Stopping a timed occupation would be a
lot harder due to message sequencing; I'm not going to attempt it.
While testing some killer_xname() changes, I noticed that it was
feasible to avoid having some gear destroyed by causing a hangup after
getting the destruction message. And while testing the fix for that, I
stumbled across a panic situation (not caused by my changes). If you
survive entering lava while wearing water walking boots (and aren't fire
resistant yourself, and don't have enough hit points to survive 6d6
damage, and your boots aren't fireproofed...), having those boots be
destroyed will dump you back into the same lava recursively (lava_effects
-> Boots_off -> spoteffects -> lava_effects). And if you survive that
(wizard/explore mode or life-saving), there will be a panic when finishing
deletion of the boots (useupall) because the recursive call will have
already done it (since they aren't worn anymore when inner call handles
them, no additional recursion gets triggered and object deletion happens).
Some of the other stuff I was working on is mixed in here because
this is the configuration I ended up using to test the panic fix.
Several Makefiles are missing the dependency for context.h (post-3.4.3
revision). If yours is, then you'll need to force a full rebuild after
applying this or you'll end up with havoc. (Mine was, but I noticed that
the expected full build wasn't happening and interrupted it to fix that.)
From a bug report: playing mastermind
with the castle drawbridge yields a sequence of "you hear tumblers click and
gears turn" messages when the notes are partly right, but no sound when all
notes are right and you succeed in opening the bridge. Blinded hero won't
know that it has opened and could reasonably expect to have heard 5 gears
turning. This gives a general gears turning message (for any bridge changed
by any means, not just castle's tune) when it opens or closes out of view of
the hero. So, you get a message about seeing it open when that is the case,
or about hearing gears if you can hear but not see, or no feedback if you
can't see it or hear it (You_hear() is a no-op when you're deaf).
Also, scatter some iron chains when a drawbridge gets destroyed. Iron
chain seems to be the only really suitable item available for bridge debris.
Another one from <email deleted>: freezing spheres have the NOTAKE
attribute but flaming and shocking spheres don't. That means that tame
critters of the latter two types will pick up and drop things. I only saw
it happen with single gold pieces in my limited testing; I guess they're
really weak.
This one sounds sort of familiar; I think it might have been reported
before. The fix is so trivial I don't know why it didn't happen.
From a bug report, bribeable demons will demand money when
hero has fainted from lack of food and hero can pay while unconscious. I
decided to just borrow from vault guard behavior and have the hero regain
consciousness. It turns out that reset_faint() has been broken since a
long ago (before my time...) change to nomul() [nomul(0) is a no-op while
fainted since multi is negative then]. Now fixed; both bribe-demanding
demons and vault guards will cause fainted hero to wake up when they arrive.
If hero can't move for some reason other than fainting, demons will skip
the bribe demand and immediately become hostile (vault guard in that case
goes away after saying that he'll return). There is no deafness handling;
perhaps the bribe demand is accompanied by sufficient pantomiming for the
hero to figure it out? ;-)
Also fix an unintended potential alignment hit against the player if
bribeable demon is killed after becoming hostile due to misjudging displaced
hero's location.
From a list of bugs sent by <email deleted>, the initial message for
the knight quest included the phrase "looking closer" which isn't suitable
if the hero is blind at the time. Also, one samurai guardian message used
"ninja" (assassin, more or less) where it ought to have been using "ronin"
(samurai without any master, a disgrace).
The archeologist and tourist quests' initial messages had similar
blindness problems with "look". (There are still at least 3 other places
which use "appear"; I've left those alone.)
A couple of items pointed out by <Someone>: the killer reason
when hit by mis-return of thrown Mjollnir would vary depending upon whether
it was fully identified, unlike several other death-by-missile cases which
force the object to be described as if fully ID'd. Also, the killer reason
when death is caused by kicking an object would give way too much detail
about the object if it was ID'd. Fix both by switching to killer_xname().
Now "killed by a war hammer named Mjollnir" becomes "killed by Mjollnir"
(same as when already ID'd), and "killed by kicking 5 cursed poisoned -1
orcish arrows" becomes "killed by kicking orcish arrows" whether ID'd or not.
[Trunk only] question? Should being hit by returning Mjollnir really
be receiving half-physical-damage reduction when hero has that attribute?
It ignores the fact that Mjollnir is also dishing out lightning damage.
Are other artifact hits ignoring such things too?
Allow rubbing any object against any touchstone even when the latter
is known so only gems make sense. Also, propagate an earlier fix which
allowed rubbing gold against known touchstones to the branch (it had been
trunk only).
From a bug report: cancelling objects
in a shop doorway or one step inside would cause the shopkeeper to brand you
a thief. The relevant code is trying to handle the case where you're inside
one shop and zap a wand or spell from there into another one; it didn't cope
with being in the neutral area of a single shop.
From a bug report: fix a typo for mouse
position handling in set_button_values(). I have no way to test this,
nor can I tell whether it could have ever impacted anyone. The old code
clearly had a mistake and the fix is obvious.
From a bug report: when a guard who's
leading the character out of a vault comes across gold (from mineralize()
usually, but a player could deliberately seed the area in xorn form), the
message "the guard calms down and picks up the gold" was given even though
the guard wasn't angry. Pick up such gold as soon as temporary corridor
reaches it so that on his next move the guard won't mistakenly think that
the hero has just dropped it.
From a bug report, the "you stagger"
message when a trapped chest releases a cloud of gas shouldn't include the
inaccurate phrase "and your vision blurs" if hallucination is blocked by
Grayswandir. Suppress it in that case.
From a bug report, you'd get the message
"the corridor disappears" whenever a vault guard was killed, even if the
temporary vault corridor was already gone due to leaving its vicinity. This
fix seems to work ok, but I don't pretend to understand how the convoluted
vault code actually works.
Spotted when fixing the Rogue level digging/phasing bug: pet movement
was setting up the wrong flag for pets who happened to be carrying a key.
This wasn't particularly noticeable because they tended to drop keys right
after picking them up. And apparently the checks elsewhere in movement
prevented that wrong flag from having any effect; once I changed it so that
pets would hang on to keys, I never saw them break a door down with one.
Now they'll keep keys, similar to unicorn horns and pick-axes, and use them
properly. The door unlocking message needed a tweak because it assumed
that the opener was on the far side trying to reach you and looked quite
odd when you could see the action taking place.
I've put this into the fixes file as a new feature rather than a fix.
From a bug report, 2003: a
pet who normally would dig could pass through walls and solid rock on the
Rogue level without leaving a tunnel in its wake. Monsters are explicitly
prohibited from digging on the Rogue level, but pet movement ignored that
and specified that locations accessible via digging were valid destinations;
actual movement bypassed the digging step so it acted like passthru.
From a bug report, the probing/stethoscope code assumed that all Angels
(the specific monster type, not the whole 'A' class) used the epri extension
to hold alignment, but that's not true for randomly generated ones. So
monster status feedback gave erroneous results, and it would vary based on
pet behavior if the random Angel had been tamed. Also, touch_artifact()
didn't know about special alignment handling for Angels and aligned priests
so always used their default alignment.
There are other problems with Angels--such as whether they should even
be allowed to be generated randomly in the first place--that this doesn't
attempt to address. The patch for that was starting to sprawl all over the
place so I pulled this simpler bit out for a first cut. Probing now shows
the Wizard of Yendor as unaligned instead of lumping him in with chaotics.
Another Makefile update needed: pline.[c,o] no longer needs epri.h.
Fix the problems From a bug report. So having
OPTIONS=IBMgraphcs
OPTIONS=noDECgraphics
would yield an ASCII display instead of showing IBMgraphics, but IBMgraphics
flag in the Options list would falsely show as on. Manually toggling it off
put things back into sync.
Avoiding the false setting is completely trivial. And fixing the
inappropriate override turns out to be easy too, unless I've bungled this.
One thing it does not do is try to warn about attempts to set conflicting
options like
OPTIONS=IBMgraphcs
OPTIONS=DECgraphics
Fixing that seems to be too messy to bother with, particularly since the
game runs ok (leaving the setting handled last in place).
From a bug report, applying a
mirror at sleeping Medusa yielded "too tired to look at your mirror" even
even though the item being used was listed in inventory as "looking glass".
Several other messages and any target monster would produce similar things.
Perhaps they should auto-ID when applied, but I changed messages to use
the description if real name isn't known.
This also treats incubi identically to succubi regarding mirrors:
they like to see their own image and will take the mirror away when one is
applied at them.
From the newsgroup three or four weeks ago: sleeping or pararlyzed
unicorns would catch thrown gems despite being unable to move. Now they'll
magically dodge instead--in other words, thrown gems will always simply
miss the target (and land at its feet) when a unicorn is unable to move.
The unicorn won't be angered or awakened by the attempt.
From a bug report. Pushing one
boulder from a location which had more than one would open up line of sight
at that spot as if all boulders there were gone.
From a bug report: #M30: 3.4.2 bugs and ideas); describe
flyers (poly'd hero or riding flying steed) as flying when they use ladders
or jump down holes. This also gives feedback when using the stairs in the
ordinary up or down case, where no message was previously given.
From a bug report, player's character inflicted
with lycanthropy doesn't gain level drain resistance when in normal form
even though lycanthrope monsters do have it when in their human form. The
report claimed that the character didn't gain it when in beast form either,
but the code--and testing--suggests otherwise.
The same resist_drli() call used for monsters is used for the hero,
but the is_were() check there isn't able to recognize a lychanthrope hero
since youmonst->data doesn't track that when in human/normal form. This
adds another more specific check to handle that case.
Fix the crash caused by division by zero (attempt to compute rn2(0))
when deciding prayer boon for a character whose Luck went negative during
the course of the prayer. <email deleted> triggered it
by killing a shopkeeper with the ongoing damage from a scroll of stinking
cloud; his non-chaotic character was branded a murderer and lost two points
of Luck after the prayer was already in progress. (Prayers fail when Luck
is already negative, so the code to pick a boon expects non-negative values;
the fact that is always adds at least +2 leads to me to suspect that someone
already realized that luck timeout on Friday 13th could result in Luck of -1
at the end of a successful prayer--that value doesn't trigger this crash.)
For "the hair on the back of your neck stands up" or "the hair on
your head seems to stand up" make subject and verb agree when poly'd into
forms where "hair" is replaced by something explicitly plural like "scales"
or "cilia".
Fix the problem From a bug report. Presumeably the corpse exclusion at <u.ux,u.uy>
was intended to be for killing your way out of an engulfer, but there wasn't
any comment to that effect. The exclusion still applies if you were inside
the monster when it died; ridden steed is the only other way I can think of
to have a monster die at your location, so it should be the only case which
gets affected. Neither steed nor engulfer is allowed to generate a random
item when upon death; you already know what was carried in those cases.
The bulk of the diff is from reorganizing the relevant `if' and
subsequent indentation changes.
When lit due to being wielded by a monster, Sunsword continued to emit
light after that monster was killed. This was fixed by <Someone> in 3.4.1 but a
change I made for 3.4.3 broke that fix. When mdrop_obj() was split out of
relobj(), relevant unwielding code ended up only being executed for monsters
who were still alive.
Fix the reported bug about an inappropriate space in the message
"For you, scum ; only N zorkmids for that foo."
when an angry shopkeeper quotes a price for an item which has just been
picked up. Also, suppress "only" in that case; just include it when the shk
isn't angry. And the word "zorkmids" was actually missing, so I added it.
I think the semi-colon should actually be a comma, but I've left that as is.
From <Someone>, half a year or so ago:
> When you've already entered the Castle, I think your God shouldn't be
> giving you the two Castle-related messages anymore.
>
> This might be difficult to track, I realise that.
It already suppressed the tune delivery feedback if you had opened the
drawbridge with music or if that drawbridge had been destroyed. And if
you've entered the castle by the back door or via wand of opening/spell of
knock, learning the tune could still be useful, so I didn't try to extend
dungeon tracking to the point of "entered the castle". However, if you've
already passed beyond the valley below then you most likely no longer have
much interest in the drawbridge, so add a check for that to the prayer
feedback suppression.
<Someone>'s real concern was probably more about the message phrasing
than the "useless" prayer boon (since it says "to enter the castle" rather
than "to open the castle drawbridge"), and that does make the god sound a
bit silly if you've already entered the building. It would make sense to
skip the first of the two messages if you make it inside without opening or
destroying the bridge, but this patch doesn't attempt to address that.
When you first attempt to walk down the stairs from the Valley of the
Dead to the second level of the Gehennom branch, the game prompts you about
whether you really want to proceed. But if wasn't keeping track of whether
you had previously level teleported past that point (which is possible when
starting from the Valley rather than from higher up), so would still issue
that once-only prompt if you used the stairs later. Mark the prompt as if
it has already given whenever you reach a Gehennom level beyond the Valley.
From a bug report: the invulnerability conferred
during the multi-turn delay for a successful prayer was not protecting
against damage inflicted by hostile mind flayer's "wave of mental energy".
I think being asleep or unconscious ought to override vision the way
that being blinded does, but that's a more ambitious change than I care to
tackle. This replaces You("see ...") with You_see("..."), comparable to
You_hear(). It catches the reported door case and several variations of
light sources burning out while on the floor rather than in inventory, but
it probably misses some other cases. zap_over_floor() in particular is
highly suspect.
From a bug report. <Someone> as slashem-Bugs-883643 on 1/24/2004. To avoid
using the possibly invalid object pointer after calling bhit(), changed as
suggested to add another level of indirection allowing bhit to null the
object pointer before returning. Callers that are affected update their
object pointers after bhit returns.
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.]
<Someone> recently reported that after lieutenants had been genocided,
he saw a sergeant drink a potion of gain level and then vanish, leaving
behind its gear but no corpse. The message about growing into a lieutenant
and subsequently dropping dead would only be given if the monster could
be sensed via telepathy, not when it occurred in plain sight. I'm not
absolutely sure that this was unintentional, since sensing the dying
monster's mind might be giving additional information about what was
happening. But there was no comment stating that and I think such behavior
violates the principal of least surprise, so seeing it happen will now give
the message too.
Because the description seen by the player is "you have never changed
form" rather than "you have never polymorphed yourself", make death by fully
turning into green slime (even if that death is avoided via lifesaving)
violate the conduct. Suggested by <Someone> 9-Dec-2004. Likewise, eating
a mimic corpse and temporarily turning yourself into a pile of gold also
violates that conduct. Mentioned by someone--probably <Someone>, or possibly in
the newsgroup--a long time ago.
<email deleted>, attempting to #chat
with quest leader who was raised from the dead yielded "impossible: invalid
quest character". The code attempted to handle that but the conditional
logic for preserving the m_id field was backwards. 3.4.3 only dealt with
the corpse revival case; dev code tried to support it for statue animation
too but still had the same problem.
Several apparent bugs remain: if the leader is angry (perhaps hero
killed him before reviving him) he won't give an angry response if the
player initiates #chat rather than wait for adjacent leader to do so. If
it's an archeologist reviving the statue of petrified Lord Carnarvon, hero
gets a rather ironic message about feeling guilty for destroying historic
statue. Lastly, shouldn't there be a comparable quest_status.nemesis_m_id
so that if one player lugs the corpse or statue of his quest nemesis back
into the main dungeon and another one revives that, it won't start behaving
like 2nd player's nemesis? Live nemesis is explicitly kept out of bones
but I don't think the corpse or statue of one is blocked and its monster
behavior after revival is based on mon->data->msound==MS_NEMESIS rather
than on m_id of current game's active nemesis monster.
1) in the autopickup exception sub-menu from 'O', change the selector for
"exit" from 'e' to 'x' so that the entries occur in alphabetical order.
Also frees up 'e' for some hypothetical future "edit" entry (I'm not
planning on attempting to implement anything along those lines though).
-1) I wanted to make 'x' start out preselected to show that it's the default
choice, but that doesn't work correctly--at least for the tty interface.
PICK_ONE menus don't know how to deal with having a preselected item and
in this case it ended up returning 'x' no matter what choice I made.
Even if that aspect gets fixed, it might have trouble with explicitly
picking the preselected entry since that would probably be toggled off
in the process. So the preselection bit of this menu is commented out.
2) at the prompt for adding new exceptions, quit adding instead of giving
"invalid syntax" warning if user enters empty input.
3) allow <ESC> in the "list" or "remove" submenu to quit all the way out of
the upper menu too.
4) simplify the way magic numbers are used for action_titles[] menu setup.
5) greatly simplify return value of special_handling().
6) avoid a potential for getlin() or strcat() buffer overflow if getlin()
were ever to be changed to return BUFSZ-1 characters instead of COLNO or
whatever its narrower current limit is.
I'm pretty sure that I've run into the issue of being unable to have a
preselected entry in a PICK_ONE menu before, but I can't recall if I ever
mentioned it. Fixing that looks like it'd be pretty messy and would need
to be done for all the interfaces. Ick.
