Noticed recently when a user reported that an unseen monster zapping
an unseen wand caused wand of striking to become discovered. [That was
because the zap also hit a door and the code for the latter didn't check
whether the wand had been seen, and it got fixed a couple of weeks ago.]
When the player zaps wands while the hero is blinded, it was discovering
(for the cases where the effect can be observed without sight) the wand
even though the wand's description was unknown (showed in inventory as
"a wand"). This replaces the calls to makeknown() in zap.c with calls to
new learnwand(), which checks whether the wand description is known; you
no longer discover something you've never seen. Reverse effect has also
been added: if the type of wand has been discovered earlier, zapping an
unseen wand (another of the same type, picked up when blind and zapped
while still blind) will now mark it as seen (to show up in inventory as
"a wand of <whatever>" instead of just a "a wand"). The latter aspect
really ought to be independent of prior discovery, but we currently have
no way to record "we know what this particular item does even though we
don't know what type of item it is yet". [If we add that, it would be
applicable to potions (when operating on stacks) and rings too.]
Minor change: zapping yourself with wand of opening or spell of
knock will remove attached ball&chain rather than give a "chain quivers"
message. Explicitly zapping the chain already did that; if the unlocking
magic works on the chain connected to your leg then it really should also
work on your leg connected to the chain. Zapping unlocking at yourself
probably should also scan inventory to check for carrying locked chests,
but I didn't add that. (If added, then locking magic will need to be
augmented likewise.)
This also fixes <Someone>'s recent complaint: zapping an unknown
wand of teleportation at yourself didn't make it become discovered.
Now it will be, under the same circumstances as when you're riding: if
teleport control causes you to be prompted for destination, or if random
destination moves you more than jumping distance away from your original
position. (The Stunned exception to teleport control, which was missing
in zap_steed, perhaps ought to be moved into the macro definition of
Teleport_control itself so that all code always handles it consistently.)
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.
Cut down on the excessive verbosity generated when entering a temple.
The first time you enter a particular temple (or more accurately, the
temple attended by a particular priest), you still get the three message
sequence
The <priest of foo> intones:
Pilgrim, you enter a sacred place!
You have a strange forbidding feeling...
or
You experience a strange sense of peace.
except that the last one doesn't say "strange" any more. On subsequent
visits to the same temple, you usually won't get the first introductory
message any more, often won't get the second entry one, and sometimes
won't even get the final one, depending upon how much time has elapsed
since the previous entry. The old verbosity could really be infuriating
when attempting to lug corpses to the altar before they spoil. Even
though the messages don't affect the passage of time, it always felt as
if they were slowing you down. And even when you weren't in any hurry,
it required at least one and often 2 or even 3 responses to --More--
depending upon the length of the deity's name and whether some other
message was also delivered on the same turn (fairly common in minetown).
Saving and restoring, or leaving the level and returning, resets
the priest's memory of when the messages were last given, so the next
entry after that behaves similar to the very first. This was initially
intended for cleanup prior to saving bones data, but it seemed reasonable
to have it apply to the current game too. Unattended temples now also
have a 25% chance of not giving any message when entering. That one is
random rather than based on the passage of time since last entry; there's
no priest available to track the latter data.
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.
Replace the fixes entry with one which mentions the magic word "panic".
That'll make it easier to find in the future when looking back for the
nasiest bugs (which I seem to end up doing periodically).
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.
From a bug report, "The leprechuan quickly snatches some
gold from between your feet!" doesn't make much sense when you're riding.
Fix started out simple, but "between" isn't right if you're above the floor,
and "rear hooves" for horse or "rear claws" for dragon didn't sound right
for steed (or poly'd hero), so it got a little more complex. Complicated
even more due to requiring two copies; ick.
A minor side-effect of this change is that somewhat naughty sounding
"The leprechaun quickly snatches some gold from between your rear regions!"
won't occur anymore. :-}
A bug report complained that Izchak is identifiable when the hero is
hallucinating. That's true but it wasn't particular to him; all shop
transactions were giving accurate shk name regardless of hallucination.
This is a quick fix that avoids changing shk message handling: pick some
shk name at random each time one is used. I didn't intend for it to also
force Izchak to use the general chat response instead of his set of special
messages, but that ends up happening due to randomized name not matching
his, so you really can't recognize him when hallucinating anymore.
The almost never seen names now have a chance to come into play....
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: sleeping pet could
be shown as "eating" by stethoscope. Fixing that is a one-liner since all
(or should be all; sleeping gas trap wasn't utilizing it) cases of monster
being forced into sleep go through one routine. That wasn't the situation
for paralysis, but now it is. Paralyzed pets won't continue eating either.
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?
From a bug report, eating Medusa's corpse is fatal
but devouring her whole (purple worm or poly'd hero) was not. Now it will
be. Also, being killed by swallowing a cockatrice or a Rider could have
disclosed "you went without food" if you hadn't eaten anything else prior.
This fixes that too, although it might be a little silly if it happens to
a monk since he'll feel guilty (for non-vegetarian diet) right as he dies.
From a bug report, stealing a cockatrice corpse
from a monster while polymorphed into a nymph and not wearing any gloves,
the cause of death ended up being "petrified by cockatrice corpse". It would
also have said the same thing if a stack of multiple corpses was involved.
This fixes both cases, and also hypothetical unique monsters with petrifying
touch. (Last bit tested by temporarily adding Medusa to touch_petrifies().)
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).
I left out the Guidebook updates when I checked in the number_pad
changes yesterday. I no longer have any way to preview either format but
at least LaTeX doesn't give any warnings about the TeX one. I suspect that
the list of valid settings is going to be too wide; it will likely need to
become an actual item list or table to make the descriptions wrap sensibly.
doc/Guidebook.txt hasn't been updated in a long time. Can someone
generate an up-to-date copy and check it in?
The code let you wish for trapped containers in wizard mode and tried
not to let you do so in normal mode. But it handled the trapped attribute
by overloading the poisoned one, so wishing for a "poisoned chest" would
produce a trapped chest in any mode. This fixes that by removing the
overloading. You can wish for a trapped box/chest (or tin) in wizard mode
and you can now also explicitly wish for an untrapped one in any mode.
Asking for trapped in normal mode--most likely hoping to seed a dangerous
bones file--just negates any preceding "untrapped" handled earlier within
the same wish, and specifying "poisoned" for a container no longer has any
effect.
(Nothing to do with the recent suggestion that the search command be
extended to find traps on adjacent containers.) When a crystal ball or
confused/cursed gold detection performed trap detection, it found trapped
chests on the floor but not any which were buried or carried by the hero
or by monsters. This fixes that.
Still needs fixing? The message "your toes stop itching" when the
only trap on the level is at the hero's current location is pretty strange
if that trap happens to be carried rather than stood over, but I don't
know what to change it to. I guess it's always been strange if there was
a ceiling trap rather than a floor trap involved.
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 hallucinating,
messages for affected monsters and/or hero referred to "the gas spore's
explosion" instead of supplying random monster names. This is a little bit
tricky; since it can be displayed multiple times for one explosion, it needs
to be constructed on the fly in explode(). (Caller couldn't have handled
this anyway since it's using the value for killed-by reason which mustn't
be distorted by hallucination.)
From the newsgroup: when you pick up a gray stone, you can determine
whether it is a luckstone by attempting to name it "the Heart of Ahriman".
Your "fingers slip" if it is, they don't if it isn't. That's way too
cheesy for my tastes. This patch will make the finger slipping occur for
any item that has the same description rather than just for the exact type.
Now you won't be able to name any type of gray stone "the Heart of Ahriman"
(nor an elven broadsword "Stormbringer"; however, assuming that you manage
to acquire a non-artifact runesword, you can still uselessly name it
"Orcrist" if you want).
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.
Suggested by Janet, after inhaling paint fumes. Unlike mother-in-law,
which is an entry in the hallucinating monsters list and would be pluralized
if chosen as a tin description, I think the rank title man-at-arms will only
ever go through plural/singular handling if used as a fruit name. But since
the man/men part was already implemented for pluralization, adding the -at-
part is trivial. Also adds men/man singularization for the general case
where -at- isn't involved.
From a bug report, (is that name just
a coincidence, or is it our Matt?), "this tin smells like mother-in-laws"
should be "this tin smells like mothers-in-law". That led to a small can
of worms when I tried experimenting with mother-in-law as the named fruit.
Naming your fruit "pomegranates" would result in "pomegranateses" if you had
more than one. These changes are mostly just band-aids for that; I think
the proper solution is to singularize the user's value when fruit name is
being assigned. Force it into lower case at the same time, then some other
special casing could be eliminated. There's no particular reason to keep
"grapes" and "grape" as separate entries, nor "matzot" and "MATZOT" either.
One of the non foo-in-bar changes prevents "grapefruit" from getting
a false match against named fruit "grape". (Are there any legitimate cases
where trailing text should be ignored? I couldn't think of any.) Another
results in a wish for "kumquats"--when fruit name "kumquat" exists--yielding
two instead of a random amount, the way that specifying plural works with
other sorts of objects. And if you're strange enough to name your fruit
"kumquats" in the first place, asking for "kumquat" will produce exacly one.
This patch applies cleanly to 3.4.4 but I don't think it's been tested
adequately enough to be included there.
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.
The logic in cant_revive() was a little off, so reviving a unique
corpse or statue on a bones level would recreate that unique monster instead
of making a doppelganger who's imitating it. Fixing that was simple but had
the unintended side-effect of making it impossible to deliberately create
unique monsters with ^G in wizard mode. So create_particular() has been
modified to let the user override the zombie or doppelganger conversion.
And then when not overriding, shapechangers took on random appearance, so
this also changes create_particular() to override shape changing. And that
has the side-effect of making chameleons or vampires start out as themselves
instead of as random critters or bats/fog clouds. [Better stop now! :-]
resetobjs() also needed to have extra corpse handling when saving bones
because the fix for revival wouldn't prevent you from turning to stone by
eating apparent-Medusa's corpse. Statues of uniques and corpses of special
humans like vault guards and shopkeepers didn't need anything extra; they
can retain original form until an attempt at revival is tried.
I'm not going to try to adapt this for 3.4.4.
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 a couple of problems From a bug report. Eating a Rider corpse is fatal, but eating a live Rider's
brain was not--now it will be, both for monster mind flayers and for player
poly'd into one. Also, there was no check for cannibalism when poly'd hero
eats brains--now there is. Not mentioned in the report: eating Medusa's
brains will now be fatal just like eating her corpse. And pet mind flayers
who eat the hero's brains will gain some nutrition like they do when eating
monster brains.
Creating a common eat_brains() routine turned out to be something of
a mistake; there is only a tiny amount of overlap among the u-vs-m, m-vs-u,
and m-vs-m cases.
Makefiles need a dependency update to add edog.h for eat.c.
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).
Noticed when incorporating the "vampire dancing" patch: losing a level
while polymorphed would subtract from your normal hit points but didn't
affect your monster hit points. Now they'll lose d8 from max and current,
similar to the amount they increase when gaining a level.
This also addresses an issue from the newsgroup a few weeks back:
someone mentioned an assumption that Stormbringer drained an amount other
than d8 for monsters who use some other formula for their hit points. It
wasn't true, but now it will be (approximately). Most monsters with unusual
hit points aren't subject to level drain, so it shouldn't have much impact.
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.
Fix the problem pointed out by <email deleted>
where polymorphing into a new man at level 1 could be used to approximately
double or triple your hit points and spell power. With means to drain
level back down to 1 and with amulets of life saving to survive those times
you lose levels instead of gain, you could do this repeatedly and end up
with HP and Pw values in the millions.
This uses the earlier patch that records the HP and Pw increments from
level gains. Now when polymorphing into a new man, level based HP and Pw
are removed from the current values, remainder get multiplied by 80%, 90%,
100%, or 110% (average 95%, so tend to drop slightly), then a brand new set
of level gain increments (reflecting new man's Con and Wis) are added in.
Code for calculating spell energy is moved from pluslvl() and u_init()
into new routine newpw(). It and newhp() take over responsibility for
remembering the level based increments from pluslvl() which didn't deal
with the initial amount (stored in slot [0]; earlier patch didn't need it).
