From a bug report, polymorph of self due to
breaking a wand also polymorphed various items that were dropped in the
process, unlike the case of zapping polymorph at monsters which excludes
dropped items from being poly'd. This polymorphs the pile at the hero's
feet before polymorphing the hero. I first tried to handle it using
obj->bypass like with monsters, but that didn't work. Post-3.4.3, the
bypass handling is also used for polyself (by retouch_equipment()) and
it was getting reset at an inconvenient time.
He also complained that he failed to get "you feel shuddering
vibrations" when some polymorphed objects got destroyed. That message
is issued by weffects() which do_break_wand() doesn't call. It ought to
be fixed, but this patch doesn't address it.
Lastly, add code to prevent objects guarded against polymorph via
obj->bypass from getting used up when creating polypile golems.
Inventory formatting for a single slime mold object would be strange
if the user entered a plural word or phrase for fruit name. Forcing the
user-specified value to be singular as it's being set up as current fruit
avoids that. [Something like <Someone>'s "bunch of grapes" is unaffected;
it's already singular and correctly handled as such by makesingular().]
This may have a side-effect of limiting the creativity of some players
who try to trick others via bones files gimickery, but I think the extra
consistency in object naming during ordinary play is worth it.
According to the cvs log info, this issue was actually mentioned in
a patch I made ("fix M203...") in October, 2005. I have no recollection
of that at all....
From the newsgroup: if no co-aligned artifacts are available when
attempting to give the first divine gift for an offered corpse, nothing
would be given. Since the gift counter stayed at 0, subsequent attempts
to select one would still treat it as first gift and always fail again.
The first divine gift from offering corpses must match the hero's
alignment; after that, nonaligned artifacts (Frost Brand, Giant Slayer, &c)
are added to the pool of choices for further divine gifts. It's pretty
easy for a chaotic character to use up the co-aligned artifacts before
getting any divine gift. There aren't many chaotic ones and some are
inelgible due to being race-specific items. Wishing for Stormbringer--or
loading a bones file which contains it--and creating Sting and Orcrist
via naming will do the trick for an elven hero.
This patch expands the pool of candidates to include nonaligned
artifacts during first gift selection if no co-aligned ones are available.
From a bug report, wearing
(or removing) an amulet of restful sleep was overriding permanent
sleepiness which had been obtained previously via eating another amulet.
The setting of timeout clobbered the non-timeout bits for that intrinsic.
This also adds the timeout counter for sleepiness to enlightenment
feedback in wizard mode. Unrelated: rephrase enlightenment feedback for
adornment to more accurately describe what that does.
Reported recently by <Someone>: probing feedback while engulfed
shouldn't claim that the monster is not carrying anything when the hero
is inside of it. The simple case where it's not carrying anything else
was a trivial one line change; handling inventory plus hero was trickier
and I wouldn't have bothered if I'd realized what it was going to take.
But it's done now; trivial case
The purple worm is not carrying anything besides you.
and harder case
The purple worm's possessions:
Weapons
a - an uncursed dagger
Swallowed Creature
> - human archeologist called wizard
Implement something <Someone> suggested a long time ago: eating a
disenchanter corpse has a chance to remove an intrinsic. Uses the same
routine as nighttime gremlin attacks, which chooses an intrinsic randomly
and attempts to remove it, so has no effect if it chooses one the hero
lacks. This can be used to remove "aggravate monster" but is much more
likely to target something the player wants to keep. [By the way, a lot
of potential candidates are missing: sleep, shock, and disintegration
resistance and teleport control come immediately to mind.]
Also, it has been bugging me that you can get both strength and
fire/cold/shock resistance from the same fire/frost/storm giant corpse.
The code prevents mind flayer corpses from conferring both intelligence
and telepathy, so strength handling was inconsistent (even though it
predated mind flayers...). This causes strength boosting to be treated
as an extra candidate when selecting an intrinsic to confer, so you'll
either get strength or resistance (which might be a no-op) but not both
from those giants. And it special cases the other giants to have the
same 50% chance for boosting strength, even though the alternative in
their case is to do nothing instead of trying to confer something else.
Lastly, it now gives a message when you succeed in gaining strength.
From a bug report: an exposed eel in an isolated
pool--swamp rooms sometimes produce those--would never re-hide no matter
how long you left its vicinity. Re-hiding is part of post-move handling
and an eel with no adjacent water to move into would never reach that bit
of code since it didn't move anywhere. The code used to re-hide monsters
when you return to a previous level was ignoring eels altogether. Give
unhidden eels a chance to hide earlier during monster movement and also
when the hero returns to their level.
Also a really minor bit to slow down hit point loss of eels out of
water. I don't think anybody reverse genocides krakens to get experience
any more since they don't provide a big bonus when they're out of water,
so this change won't have much of an affect.
Three years ago <email deleted> reported that
stepping off the end of inventory via typing space to go to the next menu
page wasted his identify scroll. He suggested that some people might do
that because they don't know how to back up in a multi-page menu. I
pointed out the Guidebook section that describes < and ^ to go back one
page or back to start and left things at that. However, traditional mode
reprompts if you step through all of inventory without choosing something,
so this changes identify-via-menu to do likewise. You can dismiss the
menu with ESC to really avoid choosing anything.
This also makes identification of N items when you're carrying N or
fewer unID'd things behave the same as identify all: identify everything
without any prompting.
I'm not a contender to win any spelling bees. (Mimicker does't
seem to even be a real word; I'm not sure if it ought to end in "or"
instead of "er". But changing it to "mime" would be too weird.)
Augment killer reason when slain by a shapechanged creature:
"killed by a foo" becomes "killed by a chameleon immitating a foo" or
"killed by a vampire in foo form" or "killed by the Wizard of Yendor
disguised as a foo" (after double-trouble, when the clone starts out
mimicking something).
I put the fixes entry in the new features section.
I was testing something with #monpolycontrol enabled and got a
series of "Change it into what kind of monster? [type the name]" prompts
when I went to a new level. It was asking about monsters that were being
created (in this case, multiple vampires for top level of Vlad's Tower)
and naturally I couldn't see them since the level wasn't finished yet.
This switches to noit_mon_nam() to at least be informed about the type
of creature you're being asked to specify a shape for, and adds the map
coordinates so that it doesn't appear to be reprompting for the same
monster over and over when multiple similar ones are being created.
In the process I discovered that #monpolycontrol would let you give
any type of monster for the shape of vampires. Unlike chameleons, they
don't change into arbitrary shapes so that was inappropriate. [And
trying to test the fix for this is what led to the previous ^G patch.]
Three years ago <Someone> reported that even though exercise of
attributes other than wisdom is suppressed while the hero is polymorphed,
attribute gains or losses due to pre-existing exercise can still take
place in that situation. Since it's an entirely different set of attrs
which will be replaced upon rehumanizing, there's not much point. (The
same is actually true for wisdom, but I didn't change how exercise works
for it.) Adopt his one-liner fix: old exercise won't cause attribute
changes while polymorphed; it will silently fade as it does when its
magnitude is insufficient to trigger a change.
While checking that out, I noticed that exerchk() was using `/= 2'
to fade out old exercise/abuse. That will produce platform-dependent
results for negative values (ie, for the abuse case) since C's integer
division doesn't specify whether to truncate towards zero or towards
negative infinity. In particular, -1 / 2 could yield -1 rather than 0
as the code expected. (Its impact on play was negligible though.)
This reduces the code for displaying the messages which accompany
attribute gain/loss. A few were repharsed in order to simplify that.
Picking up and putting on a +1 ring of protection while blind
resulted in having a "+1 ring (on {left|right} hand)" in inventory and
having ring of protection show up in the discoveries list. The problem
is the same as the one for wands which has been previously addressed
(but not 100% fixed...): when using an item whose effect is observable,
the item's type became discovered based upon that observation even if the
item itself had never been seen.
The code for removing ring of protection lacked its break statement
and fell into the case for removing ring of protection from shapechangers,
but didn't cause any noticeable problem.
From a bug report, putting on a helm of opposite
alignment wipes out divine protection (regardless of which god originally
bestored it) but leaves piety level towards the old god in place for the
new one. Reset alignment record to 0 when changing alignment type. Yes,
that means that the helm can now be used to clear a negative alignment,
which I think is in keeping with having subtle positive uses for bad items.
Permanent alignment change did try to tweak alignment record, but
I'm not sure that it worked as intended. Lawfuls changing away from law
got a bonus for their new alignment, neutrals retained their old record,
and chaotics changing away from chaos took a penalty to their record, all
without regard to what the new alignment became. The magnitude of the
bonus or penalty was half the record limit (which gradually increases with
turn count) so could be very big, but I don't think it made much sense.
Reset alignment record to 0 for permanent conversion same as for temporary
conversion. It's simpler and reflects the fact that you haven't yet done
anything to bolster or weaken your new alignment.
Replace the old ^X output with integrated enlightenment feedback.
Expands enlightenment output into four sections: Background and
Characteristics in addtion to previous Status and Attributes. Final
disclosure and ^X in wizard or explore modes show all four; potion/wand
of enlightenment and throne insight show the last two to give traditional
enlightenment, near enough; and ^X in normal mode shows the first three,
encompassing the 3.4.x ^X display in streamlined form plus providing
details about bottom line information.
I think I'm done with enlightenment for the time being, except for
the desire to move it (plus associated conduct feedback) to end.c or
perhaps its own file. It has grown very long and doesn't particularly
fit in cmd.c; I don't think it ever belonged there at all unless wizard
mode ^X predates potion of enlightenment.
During some recent newsgroup discussion, <Someone> posted an entry from
his personal bug list: energy draining damage from ordinary attacks is
implemented even though there are no monsters with that capability and it
was not implemented for engulf attacks even though energy vortices have
the capability. This implements energy drain engulf attacks against the
hero and also both modes of energy drain attacks for monsters and poly'd
hero against spellcasting monsters. Since monsters don't have energy,
they lose access to their special abilities (their spells, that is) for a
few turns, same as a post-3.4.3 change done for anti-magic traps.
From the newsgroup: when a monster throws a potion at the hero and
it hits a long worm's tail, you'd get "The bottle|flask|&c crashes on the
long worm's _head_ and breaks into shards." The relevant code changes
"head" to "body" when appropriate, but monster throwing wasn't setting up
`notonhead' so that alteration only kicked in for player throwing.
build system.
Anyone who wants to do a build from sys/unix and doesn't want to figure this
out just needs to do:
sh setup.sh hints/unix
instead of:
sh setup.sh
and then continue on as usual.
New files:
sys/unix/NewInstall.unx - the new directions
sys/unix/hints/* - the hints files. There will be more later.
sys/unix/mkmkfile.sh - helper for setup.sh
Summary of changes:
see NewInstall.unx for info on the new build system
introduction of various preprocessor symbols to turn options off that
are defaulted on historically
comment out nethackrc (and similar) entries that still use the old symbol
syntax.
commenting out of Makefile.* lines that now come from hints/unix
GAMEDIR is replaced with HACKDIR so the Makefiles and the C source agree.
Note that I have NOT changed the docs and/or Makefiles for be, msdos, os2,
vms, or winnt. If port maintainers don't then I will, but I can't test
those ports.
nethack.sh now handles the font path automatically
In the newsgroup about three weeks ago someone described trying to
use the Bell of Opening to find the magic portal on the Plane of Water
and not succeeding. It's supposed to work like a wand of secret door
detection to mark nearby traps as known. And does, but it turns out
that the wand wasn't working as expected there either. They both require
line of sight, and since the water outside of the bubbles blocks that
they only found the portal if it was within the same bubble as the hero.
(Clouds on the Plane of Air posed a similar problem, although monster
activity usually reveals the portal on that level so this wasn't much of
an issue there.) Since the detection magic doesn't require the hero to
see the traps--wand and Bell both work while blind--this patch overrides
the line of sight requirement on the Planes of Water and Air. As long as
hero is within the detection magic's range, the portals on those levels
will get marked as having been seen and when the hero gets into the right
bubble or out of the clouds the portal traps will be shown on the map.
The line-of-sight override code is simple-minded and lets players
find traps through boulders when/if those are present (but the found
traps won't be seen yet since vision still controls the map display).
Also, it assumes that only water/air/cloud terrain is present so could
potentially yield strange results if any other terrain gets introduced on
either of those two levels.
From a bug report, attempting to open or close
a door while blind didn't always update the map display after telling the
player that a remembered-closed door was already open or a remembered-open
door was already closed. And in the cases where it did update the map to
reflect a change in door state, it didn't use up a turn. Now always update
the display and use up a turn when 'o' or 'c' reveals any new information.
From a bug report, wizard mode's sanity_check
option has a check for container contents but wasn't using it recursively
for nested containers, so the contents of the latter weren't checked.
This fixes that, and also adds a check for objects carried by migrating
monsters. And it now formats objects and monsters fully even if the hero
happens to be blind or hallucinating at the time.
Tested by using a debugger to poke in various bits of invalid data.
Newsgroup discussion about the devnull tournament which started
today has pointed out that ``d4294967296$'' would cause getobj() to create
a gold piece object with quantity 0 which then got dropped to the floor.
(It's specific to gold; other types of objects don't behave that way.)
Also, wrapping which went past negative and zero all the way to positive
again (like 429496729*10+7, yielding 1) wasn't detected.
Newsgroup discussion points out that a chameleon which starts out
in nymph form also starts out with nymph's inventory (50% chance each for
mirror and potion of object detection). That's not right; shapechanging
shouldn't manufacture items. Also, the post-3.4.3 code to initialize
vampires was overly complicated in order to preserve chameleon behavior,
but the old chameleon initialization which used rndmonst() instead of
selecting a preferred shape was just that way by accident (says the
person who implemented preferred shapes however long ago and completely
overlooked that at the time...).
This is tricky to test; ^G these days forces a created shapechanger
to start out in its natural form. That's a bit odd to begin with (a side-
effect of transforming requests for uniques and other special monsters
into doggelgangers), but downright strange when monpolycontrol is enabled;
a prompt to pick monster shape is issued, then the player's choice gets
overridden. I'm not sure which aspect, if any, of all this should be
changed to fix a wizard mode quirk.
"You can see invisible" is misleading when you can't see anything,
so use alternate phrasing for See_invisible when blind. Also, add extra
wizard mode feedback when blindness is overridden by the monk's Eyes
artifact, when invisibility is blocked by worn mummy wrapping, and when
clairvoyance is blocked by worn cornuthaum. And fix end-of-game disclosure
for blindness; it was only being shown if/when caused by worn blindfold.
Prevent monsters who kill other monsters to obtain the Amulet from
targetting a priest inside his temple. Blocks players from just staying
on the Sanctum stairs while a teleporting arch-lich or Asmodeus fetchs the
Amulet from Moloch's high priest for them. A previous post-3.4.3 change
prevented monsters from targetting the Wizard; this extends that (and
assumes that we can ignore the possibility of other temple priests ever
handling the Amulet). The earlier patch went into the branch code, but
inhistemple() isn't available there so this one is trunk only.
From a bug report, unseen pet sensed by
telepathy was referred to as "it" in the message given when it ate food.
This code is subtly convoluted and has now been changed at least four or
five times over the years. This patch changes the terse comment to try to
spell out the intent. Whether or not the new code actually matches that
intent remains to be seen....
From the newsgroup:
The tin opens like magic!
<some interruption occurs>
You stop opening the tin.
Either it opens immediately or it doesn't, so the "opens like magic"
message is inaccurate. Rather than simply changing the phrasing, this
gives blessed tins a 50% chance to really open immediately so that their
contents are available for eating on the same turn, and 50% to behave as
before but with a message which is suitable for the single turn delay.
Hero poly'd into a metalivore always gets the same-turn case when eating
any tin. Use of a tin opener has a chance to do so (always when blessed,
50/50 for same-turn vs 1 turn delay when uncursed, 33/33/33 same-turn or
1 or 2 turn delay when cursed).
Overall, blessed tins are better than they used to be, since half
of the time you'll save a turn, but they're still not reliable to eat in
the midst of combat since sometimes you'll need another turn and will be
likely to get interrupted in that situation. Uncursed tin openers still
give the same behavior as opening blessed tins, so are also better than
they used to be. Blessed tin openers are now superior, and cursed ones
are slightly inferior in addition to being welded to hero's weapon hand.
From a bug report, when ice on the Valkyrie
quest home level was melted and a boulder filled the resulting pool, that
pool was described as a moat. This was actually a terrain issue rather
than a formatting glitch, so instead of tweaking waterbody_name() with an
extra special case, extend the level compiler to allow specifying ice as
frozen pool instead of always being frozen moat. There's no provision
for having both types of ice on the same level, just a level-wide flag to
control which of the two applies for ice on that level.
This change has a side-effect for the V quest levels: once ice has
been melted, a second blast of fire will now boil away the pool and leave
a pit. The unfrozen water locations on the home level already behaved
that way (ie, they are pools rather than moats) so this should be ok. I
also added <Someone>'s suggestion to make one of the two drawbridges
on the goal level start in random state instead of always being open.
Using F prefix when trying to move into a wall or closed door yielded
"you attack thin air". Like the recently fixed F-vs-boulder case, give
more appropriate feedback. Also like F-vs-boulder, initiate digging if
wielding a pick-axe. (Also handles axes versus trees and closed doors).
One thing which isn't handled but possibly should be: F vs closed
door when not wielding a pick or other axe might attempt to force the door.
(Right now it gives "you harmlessly attack the door".)
From the newsgroup: objects created when killing a monster over
water weren't being affected by falling into the water. The objects were
being created directly on the floor instead of being dropped as if they'd
been in the monster's inventory. This fixes the random "treasure drop"
item, but special items--like dragon scales and the miscellaneous golem
remains--produced by make_corpse() are still put directly onto the floor.
The check to prevent small monsters from dropping big objects was
overly complex, possibly due to the 3.1.x weight threshold bug which was
just recently fixed. Food rations and leashes pass the weight test so
don't need to be special cased; spears, polearms, and morning stars fail
the weight test. (Javelins are an exception; they pass the weight test
so are allowed to be dropped by small monsters now since spears aren't
special cased any more.)
Followup to yesterday's "you attack thin air" fix for when there's a
boulder at the target location: if wielding a pick-axe or mattock and you
use F to explicitly try to attack a boulder, dig the boulder to break it.
Also, treat statues like boulders: F at them gets "you harmlessly attack
a statue" for non-pick weapon, or digs/breaks statue when wielding a pick.
Classified as a new feature in the fixes file.
This is another item from "#Q397: List of Bugs from #nethack" sent
in Janurary by <email deleted> and containing a list
of things collected from the IRC channel associated with nethack.alt.org's
public server. Using F prefix and moving toward a boulder would give
"You attack thin air." Now that'll be "You harmlessly attack a boulder."
This is one of the items from "#Q397: List of Bugs from #nethack" sent
in Janurary by <email deleted> and containing a list
of things collected from the IRC channel associated with nethack.alt.org's
public server. Moving diagonally between segments of a worm tail is
conceptually passing right through the worm's body. This patch prevents
moving in such a fashion for both the hero and monsters (it's still
possible to fight in that position though). It only applies when the two
tail segments are consecutive.
|...... In the diagram here, where tail segments are represented by
|.w1?.. digits indicating relative sequence number, the @ can still
|..@2.. move between segments 2 and 5 to reach !, but can no longer
|.65!3. move between 1 and 2 to reach ?. [However, if there is a
|...4.. monster at the ? spot, it can still hit @ and vice versa.]
Missiles and wand zaps still pass through such diagonals without
noticing or affecting the worm. I'm not sure whether this ought to be
extended to change that--it might get pretty messy since it would need
to be considered during monsters' targetting as well as during the path
traversal itself.
From a bug report, reading a scroll
of mail violates illiterate conduct and he requests that it not do so.
I didn't go that far, since unlike needing to read the Book of the Dead
to be able to finish the game, reading scrolls of mail is completely
voluntary and someone attempting voluntary challanges can choose not to
do it. Instead, this issues a prompt to require confirmation if reading
such a scroll will be the first violation of that conduct. Ordinary
players can answer no and then use '!' to read mail from a shell. I'm not
sure what'll happen to players on public servers who aren't given access
to a shell. Usually they wouldn't be able to get mail either, so more
elaborate servers like the one at nethack.alt.org which allow players to
use mail to communicate with each other will have to come up with their
own solution (perhaps by providing a mail-reader-only shell).
From a bug report, you could swap places with a pet grid bug when
you're making a diagonal move. Now you can't. [Completely ignored: it
is possible to swap places with pets which are incapable of movement....]
This imposes the same restriction on the astral Riders when they're
exchanging places with monsters in their way.
More tuning to throttle pudding farming (plus endgame Rider farming).
Earlier changes made cloned black puddings less likely to leave corpses,
to cut down on sacrifice fodder a bit, and cloned anything less likely to
drop random items when killed; this one makes killing cloned or revived
monsters be worth less experience as the number killed goes up, to cut
down on final score inflation. [With several boulders and magic missile
or a polearm, it's possible to kill any of the Riders repeatedly with
virtually no risk of even getting hit, much less of getting killed. Now
if you kill Pestilence 240 times it will be worth 62720 points instead of
297840 (not including doubling bonus for ascension), with an additional
19 points per kill instead of 1241 after that, requiring a couple orders
more magnitude of abuse--excuse me, superhuman "patience"--to get the
score to reach the overflow threshold.]
While testing this, I got "The Famine's corpse glows iridescently."
This fixes that too. Also, previously unused kill count for experience()
had an off by one error; was including ``+ 1'' even though mvitals[].died
has already been incremented by the time that that code uses it.
It's possible for the player to put escape sequences into strings via
dogname/catname/fruit options (or probably interactively by using "\233"
instead of "\033["--the two character 7-bit version wouldn't work because
its leading ESC gets treated as player's request to abort current input,
but the 8-bit version probably works, I just can't test it because I don't
know how to type such things with this terminal emulator). Such sequences
can do funny things like clear the screen and say "game over" (or worse
with creative abuse of some terminals' "answer back" capability--when
reproducing the reported situation, I kept things simple and had my dog's
name underlined and fruit name blinking; they displayed correctly but
nethack was confused about how long they were since it doesn't expect to
be given characters which don't advance the cursor). This fix still lets
users experiment with such stuff during their own games, but it replaces
suspect characters while loading bones data, so if one player creates a
bones file with suspect strings in it, another can--I hope--be able to
use that file safely.
Monster and object names, engravings, and named fruits are handled.
For the last, if uncensored string matches one already present then it
leaves that alone, so bones data created with same OPTIONS=fruit:whatever
as being used in the current game will continue to keep the same value.
Someone in the newsgroup accidentally dipped the wrong item into a
fountain and wants the second prompt to be "Dip <obj> into the fountain?"
instead of just "Dip _it_ into the fountain?", hoping that he would have
noticed that he had selected the wrong object. I think he's fooling
himself there, but this gives a brief object name for fountain, pool, and
potion prompts.
From the newsgroup: drowning on the Plane of Water gave cause of
death as "drowned in a moat". There was already some post-3.4.3 code to
handle naming of moat on Juiblex level as "swamp", but it wasn't used for
drowning's cause of death and we were still getting "drowned in a moat"
there too. Now the Plane of Water yields "drowned in deep water" and
Juiblex's level yields "drowned in a swamp".
Wizard mode's $WIZKIT can specify an unlimited number of items to
add to starting inventory and they'd be put there without regard to the
number of slots in use, potentially resulting in an arbitrary number of
'#' slot items. Cap at 52 slots, same as when picking up, and put any
excess items at the hero's feet. It's slightly tricky because the level
hasn't been created yet at the time the wizkit gets processed.
For GOLDOBJ configuration, relax the 52 object limit for inventory
when gold uses the special $ slot instead of a letter. Takes care of an
old buglist entry from the beta testers. [It will need to be revisited
if we ever implement multiple coin types that can't all fit in one slot.]
Also for GOLDOBJ, prevents nymphs and monkeys from stealing coins,
since allowing that made their steal-item attack be a complete superset
of leprechaun's steal-gold attack.
Reported to us by <email deleted>:
'You are beginning to feel hungry. You trip over it.'
and also recently in the newsgroup by "<Someone>":
There is ice here. *You see here an electric eel corpse.*
Bib hits the electric eel. Bib misses the electric eel.
Bib misses the electric eel. The electric eel misses Bib.
The electric eel misses Bib. *You trip over it.*
slip_or_trip() was oversimplifying things by assuming that if there
is one object at the hero's location, a message about what that object is
has just been given. Any timeout message which precedes Fumbling (lots
of candiates besides hunger) could intervene, as could monster activity
between the hero's move and timeout handling. Aside from the reported
cases, that code hadn't been updated to account for the new pile_limit
option which could be set to 1 and force a popup display instead of the
usual "you see <an item> here". This fix adds a flag that can be used
to track the most recent message. It is cleared by pline for every
message, so pline's caller sets it _after_ the message of interest has
been displayed.
From newsgroup discussion, reproduced with current dev code (the
missing capitalization is a post-3.4.3 buglet):
The orc tries to wield a halberd.
the orc's bow is welded to her hand!
The orc thrusts a halberd. You are almost hit by a halberd.
Caused by overloading polearm attacks with throwing. The monster throwing
code didn't enforce that a polearm must be successfully wielded.
From another many year old news posting: if you picked up a stack
of potions of oil in a shop and then applied them, one potion was split
off and started burning but you were forced to pay for all of them.
Split the to-be-lit one off first so that the remainder of the stack
stays as ordinary unpaid shop goods.
This also fixes an old bug with bill_dummy_object sometimes charging
a different price than the player got quoted when an object was picked up.
From a four year old news posting: hero was levitating via #invoke
on the Heart of Ahriman, then dropping that artifact yielded:
You drop a gray stone named The Heart of Ahriman.
You float gently to the floor.
A gray stone named The Heart of Ahriman hits the floor.
That might be strictly correct, assuming that both hero and stone fall at
the same speed; if the stone was dropped from perhaps waist height then
the hero's feet would touch first. But it looks strange, like a cartoon
where something hangs in midair until someone notices that it should fall.
Removing the artifact from inventory causes the #invoke property to
toggle off. Unfortunately it has to be done here before the object can
be placed at its destination. Modifying message order seemed unviable;
this fix fiddles with the Levitation property in order to defer hero's
descent until after object handling is finished. Now same setup gives:
You drop a gray stone named The Heart of Ahriman.
A gray stone named The Heart of Ahriman hits the floor.
You float gently to the floor.
You see here a gray stone named The Heart of Ahriman.
