[ Caveat: compiles ok on branch code but only play tested on trunk code;
the do_wear.c diff is a lot different between the two variants and the
trunk one includes some whitespace cleanup. ]
<email deleted> reported that having a spellcasting monster
destroy some armor while you're in the midst of using 'A' to take that
armor off would result in a crash. The problem was actually more
widespread than that: having a nymph steal worn items (accessories as
well as armor), or a succubus remove them, or being interrupted by monster
activity and then reading a scroll of destroy armor prior to resuming 'A'
could all produce a similar crash. 'A' relied on stale context and could
attempt to manipulate an equipment slot which had become empty, ultimately
leading to an attempt to dereference a null pointer.
The 'R' command didn't have this problem since any accessory gets
removed immediately. The 'T' command already had handling for this:
there's only one item to deal with and multi-turn take off only applies
to some of the slots; the donning() check followed by cancel_don() took
care of those. Only 'A' was vulnerable to the problem and it wouldn't
necessarily need to be interrupted and resumed; loss of the current
multi-turn item or any pending item would be enough--but I'm not sure
whether such item loss could occur without also interrupting the current
activity, so resumption of previous 'A' was probably a requirement for
triggering the crash.
This makes shield and shirt handling be similar to other types of
armor instead of relying on the fact that none of them need to have any
attribute adjustments when put on or taken off. However, there are
still assumptions (the `cancelled_don' stuff) that some slots don't have
any eligible items requiring more than a single turn to use; that should
probably be changed.
External names longer than 31 characters trigger a compiler warning
for me about truncation, and that causes make to quit. So shorten the
two long names. Also, call the cleanup routine for the FREE_ALL_MEMORY
configuration.
From the newsgroup: when invisible and unable to see invisible,
if successful prayer results in being given a spellbook you'll get the
message "an object appears at your feet" but the spellbook won't show on
the map. Add a newsym() to force its location to be updated. (I didn't
try to figure out why spellbooks use place_object() when all other divine
gifts use dropy() but that's why only this case has the display glitch.)
This also fixes up the message vs map update sequencing for a couple
of other "at your feet" cases so that all of them use the same ordering:
first the message is given, then the object drops.
[Timing is the only reason not to put this simple change into 3.4.3.]
Some newsgroup discussion recently pointed out that source comments
for scrolls of charging didn't match the actual charge increase performed
by that magic. This bumps the values a little bit
(uncursed: comment said 5 to 15, actual amount was 10 to 14, now 10 to 20;
blessed: comment said 10 to 25, actual amount was 16 to 25, now 15 to 30)
and adjusts the comments to match the code.
Barbarians start with either a two-handed sword and an ordinary axe
or a battle-axe and a short sword. The latter combination was the only
one among all the roles where the player couldn't enhance skills for
starting weapons to expert. Fix that by allowing barbarians to become
expert in short swords; reduce potential capability with pick-axe/mattock
from expert down to skilled to compensate for the increase.
This also addresses an earlier complaint that monks are no better in
martial arts than samurai even though the latter have lots of choices for
good weapon skills. Reduce the martial arts limit on samurai from grand
master to just master; likewise with bare-handed combat for barbarians
and cavemen. In this case there didn't seem to be any need to bump the
limit on anything else as compensation.
I still think non-rogues shouldn't be allowed to become expert in
daggers (which means that ranger and valkyrie starting gear would need
to change slightly) due to how powerful throwing them is, but I haven't
included that change here.
For the skills which have lower upper limits than before, existing
characters who have #enhanced their skills high enough with the previous
code will retain their higher-than-max skill ranking with the new code.
Characters who have exercised enough to advance to the old max but
haven't done so yet will be limited to the new max.
Using
gcc -Wall -Wshadow -Wpointer-arith -Wwrite-strings \
-Wmissing-braces -Wmissing-prototypes
with an old version of gcc.
mhitu.c: In function `hitmu':
mhitu.c:1176: warning: declaration of `buf' shadows previous local
options.c: In function `special_handling':
options.c:2712: warning: initialization discards `const' from pointer target type
options.c:2745: warning: initialization discards `const' from pointer target typ
trap.c: In function `dotrap':
trap.c:1111: warning: `saddle' might be used uninitialized in this function
The first one is no longer present in the trunk code. The last one is
bogus as its wishy-washy wording suggests.
Fix the reported bug of problems after casting stone-to-flesh spell
on self while wielding a statue. Pointers for worn items weren't kept in
sync and various potential symptoms could occur (most easily visible one
being that ')' falsely reported the no longer existing statue as still
wielded; report stated that one crash was observed). This bug predates
3.4.2 and was probably present ever since stone-to-flesh got introduced.
Described in the newsgroup a while back and recently reported: if
you had reflection and were invisible and had esp and were blind, Medusa
would turn herself to stone by looking at you. When you're invisible,
she shouldn't be able to see your source of reflection so shouldn't be
affected by the gaze; that's how things work when you aren't blind but
the relevant code was being skipped when you are.
Now esp is irrelevant for this and she'll see her reflected gaze
only when she can see you, regardless of whether you see it happen.
Prevent succubi from being fully restored via cycles of petrifying
and reviving. It wasn't just a matter of saving traits; cancellation is
one of the monster traits which is explicitly reset when a monster gets
revived. I think that probably makes sense, but this will override it
for succubi and incubi to prevent abuse; if they were cancelled at time
of petrification they'll remain cancelled when reanimated. Likewise for
nymphs; even though the abuse facter isn't present, the cancel effect is
pretty similar for them so keep revivals similar too.
This saves monster traits for every monster that gets turned into a
statue. Unlike with corpses there's no stacking involved to make players
notice that each has become unique, so all such statues might as well all
reanimate just like they were instead of as new replacment monsters.
Noticed when trying out the "heck patch", where the name of the file
for the sanctum level was changed and I neglected to update my Makefile to
reflect that: nothing was noticed if any files were missing when loading
them into a dlb container. Populating the playground directory for the
non-dlb configuration suffered a similar problem. Now the VMS playground
setup will issue a warning message if this happens (but not abort the
installation; perhaps it ought to do that as well...).
Other ports have the same problem. For example, Unix Makefile.top
relies on file globbing to build the dlb container; if a wildcard pattern
matches no files, dlb won't notice because the shell will have eaten the
offending pattern. Likewise for its non-dlb configuration, where cp won't
notice. However, this isn't a very interesting bug because it won't hit
when the distributed Makefiles correspond with the needed data files.
Make a sleeping or paralyzed shopkeeper wake up if you drop something
he's interested in buying (covers the recently reported case where dropping
gold failed to add credit, but picking it back up increased shop dept) or
if you use the 'p'ay command while owing money. Sleeping shopkeeper is not
affected if you drop something he doesn't care about, or use 'p'ay when
there is no debt, or pick up shop goods (latter case is handled normally--
you'll owe money for the item even though the shk remains asleep).
This makes shopping become a little easier--you aren't stuck waiting
for the shopkeeper to wake up if you actually want to pay for something--
in the rare case where the shopkeeper has been put to sleep, but it's an
awful lot simpler than any other reasonable way I could think of to deal
with the [lack of] credit problem.
This makes the snoring message handling moot--it no longer exists.
(It wasn't very reasonable to begin with, because the program can't tell
whether mon->mfrozen is for timed sleep or timed paralysis so avoided
giving that message for temporary sleep. There ought to be two separate
counters; probing is another case where vague messages are given because
the program can't tell the reason why a monster can't move.)
Guard against the pathological cases of ", <anything>" and
" called <anything>" strings that a user could type in to indirectly
trigger impossible(). Now they'll yield "no info about such things".
From newsgroup discussion: prevent monsters from level teleporting
to Moloch's Sanctum level unless the invocation ritual has already made it
accessible (same restriction player's character already has). Otherwise a
monster could pick up one of the invocation items and effectively take it
into limbo, making it become impossible for the player to reach that level.
Add missing handling for trapped containers and for Schroedinger's Cat
to the #tip command. Also, after tipping out the contents of a cursed bag
of holding, its weight would still reflect any items destroyed during the
process.
Releasing Schroedinger's Cat from a box which is being carried would
place the monster at the coordinates of wherever the box was last on the
floor instead of adjacent to the current location.
Also, the message sequence
The housecat inside the box is still alive!
The large box is empty.
seemed a little strange. This makes it say "is now empty" when a cat has
just been released.
Fix the reported problem of combat messages referring to Orcus as
"it" when the data.base entry uses "he"; extend use of gender-specific
pronouns to named and other unique monsters as well as to humanoids.
If any of those should stay as "it", they'll need to be M2_NEUTERed....
And prevent level followers from chasing you across levels if they
are fleeing at the time. It's an old change I've been sitting on which
is not related but happens to be right next to the pronoun code.
From the newsgroup: prevent monsters from level teleporting out of
the quest into the main dungeon. The player can't do that and monsters
weren't supposed to be able to, but from time to time the quest nemesis
has seemingly vanished after reading a cursed scroll of teleportation.
His disappearance was due to ending up on a random level between the
quest entrance and the top of the dungeon.
This also fixes an obscure bug that I noticed while trying to
reproduce that problem: uncontrolled level teleports by the player in
the quest had 80% or thereabouts chance of ending up on the quest home
level. All 12-15 main dungeon levels above quest entrance were included
in the random range of 1 thru current+3, then any choice which tried to
pick one of those was converted to quest level 1. (Monster destination
wasn't getting that adjustment.)
Mostly `gcc -Wwrite-strings' complaining about passing string
literals to safe_qbuf(). `gcc -Wformat' didn't catch the type mismatch
of formatting the return value of strlen() with %d, presumeably because
size_t is defined as unsigned int on this system and it treats int and
unsigned int as interchangeable as far as printf/scanf checking goes.
I'm not sure whether the sizeof() values being passed to safe_qbuf()
ought to have casts. Any system where size_t isn't the same width as
unsigned int is bound to support prototypes, but might possibly warn about
the implicit conversion of unsigned long (or even unsigned long long these
days) to unsigned int.
If the player gives the 'T' command while not wearing any armor,
don't suggest "use 'R' to remove accessories" unless the character is
actually wearing accessories. Likewise for 'R' while not wearing any
accessories, don't suggest "use 'T' to take off armor" unless wearing
some.
Add missing amulet case to the silly_thing() handling for 'W' and
'T'. Also handle boots, gloves, and lenses as plural in the message
there. silly_thing() has been simplified a little bit in the process.
Even though the in game help now lists the actual disclosure values
instead of "all" as the default value, implement support for "all" (also
for "none") since doing so is trivial.
Create an empty paniclog file during playground creation, so that it
starts with the same permissions as other writeable files. Without this,
it's liable to end up being owned by the first random user who triggers
a panic or impossibility rather than by the playground owner and probably
wouldn't be writable by any other user.
1) killer reason for scattered land mine shrapnel used "a" or "an" prefix
even when multiple projectiles hit as a group -- one of various things
From a bug report.oextra field) --
noticed while investigating #1 and later From a bug report.4.0 due to an unintentional side-effect of missile killer reason
handling in 3.4.1 (removal of redundant "poisoned" prefix by m_throw()
confused the poison handling routine) -- noticed while investigating #3.
From the newsgroup: leash found inside a bones level shop was flagged
as "in use". 3.4.0 had a fix for that which works for most cases, but not
when the shopkeeper has taken the dead character's inventory just before
saving the bones file.
This also adds an entry to the branch copy of fixes34.2 to synchronize
it with the trunk copy.
Noticed when investigating one of the killer reason bugs recently
reported: a land mine explosion shouldn't create a concealed pit trap;
make a revealed pit instead. And while testing that, I noticed that the
"Kaboom" message given when pushing a boulder onto a land mine was given
while the map still showed the boulder at its original location even
though it had actually been moved already. It's a little odd that you
get hit by shrapnel at your original position--as if you're shoving the
boulder ahead of you and then pausing a moment before stepping into its
former location--but that's trickier to fix; sometimes you won't advance
due to there being multiple boulders present (in that case you evidently
do shove the boulder instead of performing a steady push, so maybe the
current behavior is fine as it is).
"List of game options" from `? f' misaligns the entries for runmode
and scroll_amount (at least for tty display). Shorten their descriptions
so that they fit without squeezing out spaces.
Make exploding bags of holding be less mysterious, and perhaps cut
done on the number of claims that they've vanished for no reason. There
wasn't any feedback other than the explosion message itself; in particular,
the message about putting something into the bag didn't occur since that's
handled by the didn't-explode case.
Recently discussed in the newsgroup, and it sounded familiar so may
have been reported directly earlier:
You fly through the trap door. You fly down along the stairs.
when polymorphed into a flying creature or riding a flying steed. It
only happens at the castle, and only happens because the go-down code is
explicitly setting the arrival point to be the Valley stairs. That's how
the castle trap doors used to work as traps too, but they were changed to
dump you randomly near the stairs quite some time ago. Fix it by making
intentional triggering work the same now; this also prevents the false
feedback (even if you happen to arrive on the stairs by coincidence).
Another fix to address the complaints about two-handed weapons being
rendered useless by 3.4.1's change to require free hands in order to apply
containers. Some players now fear to wield two-handed weapons because a
curse would make accessing their bag impossible, which is doubly nasty if
that's where they have scrolls of remove curse or potions of holy water
intended to deal with cursed items. The same situation applies for cursed
one-handed weapon combined with cursed shield, so some are now claiming
that 3.4.1 has made two-weapon combat be even more attractive than before.
This implements #tip, a new command that causes a container at the
current location or carried in inventory to have its contents emptied
onto the floor. Hero's hands don't need to be free at the time but tipping
a floor container requires limbs; tipping an inventory container doesn't
need hands or even limbs. The contained items don't pass through inventory
during the process, so don't cause objects (loadstones, crysknives, scrolls
of scare monster?) to go through their special handling unless it's part of
normally dropping to the floor. Tipping a bag of tricks behaves the same
as applying it (one monster is released, and it only becomes empty if
that happened to be the last charge) and items tipped out of a cursed bag
of holding have their normal cursed bag chance (1/13) of being destroyed.
Tipping an inventory container while levitating or during unskilled riding
behaves similar to normal drop--from a height, so some fragile items break.
Players have wanted this feature to get gray stones out of chests or
heavy corpses out of ice boxes but I didn't care much about that; losing
access to your bag is more significant. I'm pretty sure that there was a
user patch to do something like this floating around at one time, but I
couldn't find it when I looked, so I implemented #tip totally from scratch.
Bug? Extended commands which lack meta-key shortcuts are not listed
in the help files displayed by the '?' command....
Move a couple of instances of container contents manipulation into
their own routines. Behavior for items disappearing from cursed bags of
holding isn't quite identical but is effectively the same. I think its
use of stolen_value (or simply the behavior of the latter) is buggy, but
I haven't tried to fix that. (Cursed bag of holding destroying a player
owned bag containing shopped owned items definitely doesn't work well.)
Fix the reported bug of artifacts created via wizard mode WIZKIT
being "forgotten" and possibly duplicated during play. Perform artifact
initialization before $WIZKIT processing; role info needed by the former
is already sufficiently set up by that point.
> "The magic-absorbing blade scares the erinys! The erinys resist!
> The erinys are stunned. You kill the erinys!"
vtense() already has code to handle "erinys", but it didn't work as
intended when the caller uses "the erinys" for the subject string.
> Receiving Excalibur from a fountain while blind doesn't update the
> display (i.e. the missing fountain) immediately.
Various other topology changes had the same problem. The display
was only being updated if the hero was invisible on the assumption that
it wouldn't matter otherwise, but a blind character who moved off the
affected location would still have the old map info (fountain, trap, &c)
shown--until he walked back onto that spot or searched next to it or
regained sight--even though the player is told about the map change as
it happens.
1) make two-weapon combat perform two attacks instead of always either
hitting twice or missing twice;
2) address <Someone>'s report of weapon skill to-hit adjustment being ignored
for bare-handed and martial arts attacks;
3) address newsgroup complaints about the intrusive "your armor is rather
cumbersome" message given every time a monk wearing a suit attacks;
this implements the suggestion that it only occur for those times where
you miss because of the penalty involved, suppressing it when you miss
due to other reasons and when you successfully hit;
4) bonus fix: a side-effect of #3 is that the order of the messages "your
armor is cumbersome" and Stormbringer's "bloodthirsty blade attacks" is
inverted, making a sensible sequence instead of implying precognition.
3.4.1 included a change which requires you to be able to use hands
in order to manipulate containers; that makes sense but has introduced
an unintended side-effect. It has become much harder to uncurse a
two-handed weapon or combination of a one-handed weapon and a shield
because you can't get scrolls or potions out of your bag. This adds a
new major trouble for prayer to address that, escalating it above the
normal minor cursed item trouble. It also removes a nonsensical check
for combination of two-handed weapon and shield that I added long ago.
Not related, but same file: add the missing artifact touch checks
for putting on accessories (quest amulets and lenses). I can't remember
if this was From a bug report.
The recent bones panic included "program initialization failed"
during final rundown. The cause of the panic has already been fixed;
this fixes the silly message that was delivered with it.
Also, disclose the contents of carried statues along with normal
containers when the game ends.
Add <Someone>'s suggestion for the expected input value to the prompt for
playing a tune, and implement handling for alternate note "H" which seems
to be used as a variation of "B" by some Europeans. The Amiga part is
untested but "can't be wrong"(tm).
> Why does warning work normally while hallucinating? I'd like to see
> random numbers.
It's just a one-liner, although it has pointed out problems in the
symbol lookup code. "0" won't work at present, so this doesn't use it,
but warning symbols "1" through "5" also have trouble--regardless of
hallucination--if someone overloads them to represent any feature aside
from warning.
'+' is not a valid argument to resist(), although it still works
since the default case catches it. Make the spell class explicit,
although I don't think having the effectiveness of scrolls of confuse
monster depend on the character's level makes much sense.
Reported last spring and again last week: monsters who teleport to
your location (named demons, master liches, and so forth) continue to do
that even if they've just used a scroll or wand of teleportation to get
away from you. This doesn't prevent that situation but does make it be
much less likely to occur.
The previous changed ended up discarding the begining portion of
excessively long lines and keeping the end. It's unlikely that either
part is going to be valid, but reporting the ending portion as a failed
wish would make tracking down and fixing the situation trickier.
Make wielding Werebane confer defense against catching lychanthropy
from monster bites. It doesn't protect against catching that from eating
lycanthrope corpses and might blast the character if wielded at such time.
Also fix artifact handling to recognize the character as lycanthrope
while in normal human/elf/whatever form--rather than only when in beast
form--just like it does for monsters.
Treat strangling a pet with a cursed leash like a regular monster
kill; you'll get experience, lose pacifism conduct, and suffer various
pet-killer effects. Also do some minor damage and reduce tameness for
the case where the pet is described as being choked but isn't killed.
Try to fix the reported bug of not waking up if sleeping on ice
that gets melted out from under you. This fixes the straightforward
case but I suspect there are other permutations that it doesn't cover.
Teleporting out of water is now blocked if asleep; waking up occurs
after the chance for that has passed.
Update the comments to [try to] more accurately describe the behavior.
Also add hallucination handling and make the probe effect be more likely
to occur (or to put it another way, make the stun effect be less likely
since one or the other always takes place--except when stun is superseded
by something more severe).
Revamp the Magicbane code so that it won't result in "<monster>
turns to flee" followed by "the magic-absorbing blade scares <monster>".
In the process I noticed that resistance checks for its scare and purge
effects were based on the character's experience level regardless of who
was wielding it or who its target was.
I didn't try to retain the exact behavior it had before, but the
new behavior is pretty close. The main differences are that the "purge"
effect is now called "cancel" and that the stun effect will be less
common now and always gives feedback when it occurs. It used to combine
stun with scare and/or purge in some cases, now it won't; and it used to
always scare when purging, now it will pick one or the other.
To fix Magicbane's message sequencing, its code needs to be redone
substantially. These changes make that easier.
cancel_monst() let caller know whether cancellation succeeds
resist() give artifact weapons a resistance attack rating
vtense() handle monster names and "you" as subjects; checking against
object names and descriptions pointed out a couple of other
words that would have ended up being miscategorized.
I don't know whether there were any other odd situations besides moving
onto known traps being caused by the out of date value in flags.run; several
places do check to see whether it's 8.
Monks get a big penalty to hit when wearing a suit; otherwise they
get a bonus when not wielding a weapon. But as reported, that lets them
have their martial arts bonus even while wearing a shield which does seem
rather unexpected. This change makes them only get their to-hit bonus
while shieldless as well as weaponless. Impact on play balance is likely
to be quite small; late game characters hardly ever miss due to high luck
bonus and very early game ones won't have found a shield yet.
Shouldn't the "your armor is cumbersome" message be ``if (verbose)''?
From the newsgroup: wishing for a "Scorpius egg" succeeds;
fortunately the resulting egg will never hatch. Turn such eggs into
normal scorpion eggs instead.
Prevent #rub from wielding an item that is already being worn
(which should narrow things down to the various types of eyewear;
other tools and weapons that go through wield_tool() can't be worn).
Fix up the wield_tool message spacing in the process.
This moves wield_tool() from apply.c to wield.c. Some plural
handling for messages is included; it is feasible to try to #rub a
"pair of lenses" or a stack of N candles.
Breaking a boomerang while bashing with it didn't work right when
there was a stack of more than one involved. The message given had a
grammar buglet and the remaining boomerangs became unwielded. (This
issue wasn't present in 3.4.0 because the boomerang bashing code never
got called there.)
hold_another_object() will try to quiver the object being held if
it's a weapon (or gem/rock ammo) and the autoquiver option is enabled and
the quiver is empty. It was doing that even if the object had just merged
with primary or secondary weapon, resulting in it being equipped in two
slots at once. (Easiest way to reproduce it is via wish+wield+wish for
similar item, but it could also occur when stealing while in nymph form.)
This also addresses one of the old items on <Someone>'s list: if you
carry a sling equipped in the alternate weapon slot, include gems and
rocks as likely candidates for quivering same as when wielding a sling.
This extends that to autoquivering; ammo appropriate for your alternate
is now given preference over arbitrary weapons (ammo for your wielded
weapon and arbitrary missiles still take precedence over alternate ammo).
Bug? pickup_object() is not autoquiver aware, hence autopickup isn't
either.
Bug too (perhaps moot if the above is changed)? Snagging a monster's
weapon with a bullwhip uses hold_another_object() so possibly autoquivers;
snagging an object off the floor with a grappling hook uses pickup_object()
so doesn't.
This makes all unique monsters resist being given a name. Aside
from the Oracle, the four high priests are the only monsters affected
that weren't already being covered by the old tests. They might as well
decline to receive names too.
This also fixes a longstanding quirk that prevented you from
calling a type of object something if the representative sample of it
had been picked up while blind and you hadn't explicitly examined your
inventory since regaining sight. There's not much point in requiring
an extra 'i' command or use of '?' or '*' at the "what do you want to
call?" prompt, particularly since that makes gameplay be slightly
different depending on whether perm_invent is available and in use.
From the newsgroup recently: cause of death on tombstone and in
log file was "slipped while mounting a saddled Stockholm" (with horse
named after city). This fix will produce "slipped while mounting a
saddled horse called Stockholm" in that case.
Move the "tame <monster>", "peaceful <monster>", "hostile <monster>"
handling for <ctrl/G> so that it works when <monster> is a class letter as
well as when it names a monster type.
Wizard mode monster creation underwent several changes for 3.4.0
(explicitly create "tame <monster>", create a monster by class letter,
repeat the creation for N monsters) and one of them rendered the check
to prevent creating orphaned shopkeepers, temple priests, vault guards,
and worm tails inoperative. Put that back, and extend the control to
allow you to specify "peaceful <monster>" and "hostile <monster>" too.
For the bribery check that lets you get away with offering a little
bit less than what was demanded, never treat an offer of 0 as acceptible.
Also, add some missing set_malign() calls.
Another vintage compiler (not as old as the previous one...) didn't
like the assignment `nlp = shkgeneral;' when nlp had been declared using
array syntax. It didn't used to mind that, until an extra `const' was
inserted by the "move stuff to read-only area" patch submitted by someone
a while back. The prototype is already using pointer syntax here.
The heros_fault() macro added to region.h relatively recently causes
a K&R vintage compiler to choke on the heros_fault variable in dothrow.c.
Although the latter has been around longer, changing it was a little bit
simpler.
Hitting with a wielded boomerang was supposed to have a chance to
break it, but the code was located in a spot that would never be reached
when bashing with a missile weapon. Also, its rnl() usage would have
made the bad effect--losing your weapon--be more likely to occur when
you had good luck and less likely when you had bad luck. And it wasn't
setting `unweapon', so you wouldn't have gotten a bashing with barehands
message on the next attack after the weapon had been destroyed.
Building with an old version of gcc with various warnings enabled
generated a lot of noise. Most of it was due to not guarding string
literals with `const', but there were a couple of actual problems too.
Some recent newsgroup discussion claiming that a pet ki-rin was
wearing a helmet (I think poster was hallucinating) caused me to look
at some of the hat handling code. There were a couple of noticeable
problems and one latent one in code added for 3.4.1. Polymorphing
into a minotaur pushes hard helmets off hero's head, but nothing
prevented you from putting one right back on. Helmet wearing monsters
who polymorphed into minotaurs weren't affected at all. And message
handling always assumed multiple horns even though we have some singled
horned monsters, but since all those have no hands they can't wear any
armor and that potential pluralization issue wasn't noticeable.
Fix the problem From a bug report. An earlier fix (3.3.1)
made them be listed during final disclosure, but the points shown for
them actually got left out of the total due to misplaced brackets.
Rather than just fixing the brackets, merge the two inventory scanning
loops so that both passes will always be synchronized with each other.
Various damage types which wouldn't work when a cancelled monster
attacks the player were working when it attacked other monsters instead.
Besides attempting to fix that, this also makes cloaks and other magic
blocking armor ("magic cancellation factor") work for monsters similar
to the way it works for the player.
Most types of damage appear to revert to physical damage when the
attacker is cancelled; I'm not sure that's appropriate in many of the
instances. The leg-pricking case was clearly wrong, since it gives
messages about the attack failing yet still hurt the character.
This really needs a lot more testing than I have energy for. I've
tried to clean up various inconsistencies and may have made some typos
in the process.
Add the caveman, healer, and monk data.base entries supplied by
<Someone>, plus the healer one from <Someone>'s list of outstanding bugs and
requests. Every role now has its own entry. I left "dwarven caveman"
and "gnomish caveman" pointing at the generic dwarf and gnome entries
respectively, because the caveman quote feels to me to be more human-
specific than the earlier role ones have been.
I added blank lines to the monk quote to break it into paragraphs,
and made two minor tweaks to the text. I hope we can find or invent a
separate entry for Master Kaen though. Getting a quote that refers to
Buddhism for him seems wrong to me, but leaving the generic human one
now that there's a monk-specific one didn't feel right either.
I've moved a few quest guardians around this time. Deciding which
of them should yield the corresponding role entries and which shouldn't
involves judgement calls and I don't claim that the current situation
is now perfect.
Post 3.4.0 bug: "Your a lance (weapon in hand) shatters on impact!"
Use xname() instead of doname() to get "lance" instead of "a lance" here.
It also wasn't giving "you start bashing with your bare/gloved hands" on
the next attack after losing the weapon.
Invoking the archeologist's Orb of Detection gave "you feel a surge
of power, but nothing seems to happen" if you were able to see invisible,
but various other ways of toggling invisibility give fade/unfade messages
in that situation. Also, you would get false reports of invisibility
changes if you invoked the artifact while temporarily invisible due to
potion or spell or while wearing a mummy wrapping.
Add the wizard entry submitted by <Someone>. It doesn't fit
perfectly but seems better than getting the generic human (or other
race) entry. It pointed out that "gnomish wizard" is ambiguous between
a type of monster and a player character race/role combination. I had
to add a special case to the code to make that work out right.
This also makes all the roles that have the their entry match any
race; conversely, match the race's monster for roles that don't have an
entry (caveman, healer, monk, priest, and samurai; we really should get
them their own). Previously many of the non-human ones yielded "I don't
have any information on such things" and at least one (elven priest)
yielded the generic human entry.
Prevent a demon who is carrying the Amulet of Yendor from being
removed from the game when player meets his demand for a bribe since
that was effectively destroying the Amulet. There are various ways
to accomplish this; I chose to make the bribe demand be for an amount
that the player cannot possibly satisfy in that case.
Make timeout of temporary invisibility consistent with other
forms of toggling that state: you notice it even when you are able
to see invisible. (Invoking the archeologist's quest artifact is
still inconsistent in this regard.)
> Zapping a wand of digging at trees in ranger's quest gives a message
> "rock glows then fades".
There was code to handle this, but it didn't work due to the
definition of IS_TREE making checks for STONE be sensitive to code
ordering (STONE was checked first in this case).
#define IS_TREE(typ) ((typ) == TREE || \
(level.flags.arboreal && (typ) == STONE))
Why is it defined this way? Shouldn't STONE simply be converted
into TREE when arboreal levels get created?
Menu styles `partial' and `full' will let you remove any type of
item from the three weapon slots via the 'A' command, but `traditional'
and `combination' would only do that for the primary weapon slot. For
the alternate weapon and quiver slots, the item in question had to be
one which can normally be wielded or worn, otherwise when choosing the
object class letter you'd be told that it was "Not applicable." And
for wearable items, you needed to be really wearing one of that class
(besides the quivered one) or else you'd get "not wearing any amulet"
or similar.
Ahe 'A' command would not let you remove a cursed item from the
quiver or alternate weapon slot. But other commands such as drop or
quiver would let you get rid of such things since they aren't considered
to be welded in place the way a wielded weapon is.
This seemingly minor bug is more significant than first appears
because it opens a loophole to allow you determine whether any held item
is cursed: quiver it, try to remove it with 'A' and possibly be told
that it's cursed, really remove it with 'Q' if so.
Make sure the three instances of special fire effects stay
synchronized in the future by moving the relevant code into its own
routine.
Shouldn't fire vortices and fire elementals also yield "already
on fire"? How about ice vortices "melting"?
nethack.rankin