Issue reported by Meklon2007: some theft feedback during nymph
attacks refers to the attacker as "she" and others as "it" if hero
is blind.
The "she" references are intentional. However, mixing them with
"it" references when a series of messages occurs is jarring. This
changes "it" to "someone", which is still different from "she" but
hopefully enough less so to be tolerable.
That resulted in monkeys also being referred to as "someone" because
they're classified as humanoid. Change x_monnam()'s AUGMENT_IT
handling, which chooses between "someone" and "something" when the
monster is not seen, to override humanoid for animals (affects 'Y'
class) and for mindless (affects zombies, mummies, and golems).
So an unseen monkey will be "it" again.
The final message for current item was relying on a cached monster
name value. If an unseen nymph or monkey stole a worn blindfold
so that hero's vision was restored: "It <stole> item" before the
changes and "Someone|Something <stole> item" after. So update the
cached name if sight gets regained, to give "<Mon> stole <item>."
(If the item is worn armor and the thief is a nymph, it was and
still is "She stole <item>".)
The message for having any worn item be stolen, which got split
into two parts within the past year, was giving "<Mon> takes off
<alt weapon>". When not dual-wielded, the alternate weapon isn't
really worn. Rather than suppress it outright, change the message
for uwep/uswapwep/uquiver to say "disarms" instead of "takes off".
For accessories, change "takes off" to "removes". Those are more
or less interchangeable these days but "removes" matches R instead
of T.
While testing, my pet evidently killed a nymph (I was blinded and
couldn't see it happen) while she stole my gloves and the next
message I got was "You finish taking off your suit." The gloves
weren't worn anymore so equipname() defaulted to suit. Get rid of
equipname() altogether and switch to armor_simple_name() which
doesn't rely on the worn-armor pointers.
Fixes#1257
Implement a couple of missing bits for wall of lava terrain. It was
immune to being distorted by hallucination, unlike molten lava and
wall of water. And the presence of wall of lava made molten lava,
after being shortened to "lava", no longer be listed as something
represented by the "}" character.
I started to renumber S_water, which would eliminate some hackery
from farlook's do_screen_description(), but that will require an
EDITLEVEL increment and make it necessary to reorder/renumber the
corresponding tiles so I stopped short.
This adds NHDT tags to the first line of defsym.h.
If the quest leader observes the hero attacking a peaceful monster,
only become angry if that peaceful monster is a quest guardian. And
when becoming angry, stop waiting for the hero to approach.
If a quest guardian observes the hero attacking any peaceful monster,
don't run away.
When using #loot to put items into a shop-owned container on a shop's
floor, you are asked "Sell it? [ynaq] (n)" for each item, but the 'a'
and 'q' choices only worked as y or n for the current item. By the
next one, the preferred answer had been reset to default and ynaq was
asked again.
Set a flag in use_container() to have in_container() set the sell vs
don't sell state for the first item but not for any others. Reset
the state at the end of use_container() instead of after each item in
in_container().
This bug was present in 3.6.x, also in 3.4.3, and probably earlier.
Finish shop changes begun in 2674a9904d.
Fix the longstanding bug where shop paying with itemized buying would
reveal container contents if any unpaid items were inside containers,
regardless of whether the containers' contents were known yet, even
when the container was a locked box/chest or a cursed bag of holding.
Paying by menu made that be more noticeable but it has been present
ever since itemized paying was introduced. I can't find any old bug
reports for it though. I did find an old message of mine that claims
it's in bugzilla with a "#Hnnnn" tag.
This changes how buying containers and their contained items behaves.
It's now an all or nothing operation. Itemized billing will list
the container but not contents, and to buy what is inside you need
to pay for the whole thing as a single unit. If the container itself
is unpaid then its price is part of that item's total cost. If it is
hero-owned than it is listed as an item to buy but doesn't increase
the cost derived from its unpaid contents. (If you decline to pay,
hero will still own the container and still owe for unpaid contents.)
This took me a while to track down. I noticed it while drinking
unpaid potions but didn't expect the issue to be potion-specific.
Affects paying shop bill in addition to examining [former] inventory.
Start with a stack of 3 unpaid potions.
Iu
a - 3 potions of healing (unpaid)
Ix
no used up items
Drink one.
qa
Iu
a - 2 potions of healing (unpaid)
Ix
x - potion of healing
So, far everything's normal. Note that 'x' is an arbitrary letter
used for expended items when shown in inventory style rather than an
inventory letter or menu choice.
Drink another.
qa
Iu
a - a potion of healing (unpaid)
Ix
x - potion of healing
x - potion of healing
Drink the last one.
qa
Iu
no unpaid items
Ix
x - potion of healing
x - potion of healing
x - potion of healing
In 3.4.3, these last two Ix cases would have had single lines of
'x - 2 potions of healing' and 'x - 3 potions of healing', respectively.
After this fix, they will again--unless potion stack 'a' was wielded,
readied as alt-weapon, or quivered.
Reported by ars3nly as "#1250: Repeating #sit causes a sitting loop",
with a followup comment describing how to reproduce easily, and by
Umbire as "#1229: Curses and extended command menus". Repeat count
from previous command carried over to current command when ^A was
used to re-run the current one.
Reset 'last_command_count' every time a repeat count is obtained,
even when the new one is 0. This is a much simpler fix than what
was used with several previous attempts, but it seems to be working.
The do-again code is convoluted, but the tricky bit was the fact
that this problem only happened when number_pad was On with repeat
counts entered as 'n<digits>'. I still don't understand that aspect,
but it wasn't happening for count of simple '<digits>', making
reproducing it by someone who doesn't use number_pad be difficult....
Closes#1229Closes#1250
While testing a potential fix for issue #1250, I discovered that
using the altmeta option, to simulate typing Alt+x to get M-x via
typing 'ESC x', didn't work after a count prefixed by 'n' when in
number_pad mode. It did work as intended for !number_pad when a
repeat count prefix is entered via digits without 'n'.
This doesn't solve #1250, which also occurs for number_pad but not
for !number_pad.
Add a theme room with multiple visible teleportation traps
which will always teleport to specific locations in the same level.
Teleport trap change from xNetHack by copperwater <aosdict@gmail.com>.
if Wizard escapes the dungeon
Reported by vultur-cadens: a fix to prevent quest feedback when quest
nemesis is removed from the game during bones creation introduced a
regression for an earlier fix that kept context.no_of_wizards up to
date if the Wizard of Yendor escapes the dungeon without dying.
Change 'wizdead()' to 'wizdeadorgone()' and call it from m_detach()
for mongone() as well as for mondead().
Fixes#1256
Restoring was hiding unhidden mimics and if that chose an object
other than boulder of gold pieces, it called mkobj() before an
array used by that routine was initialized. The result was warning
"rnd(0) attempted" when NH_DEVEL_STATUS wasn't set to 'released' or
divide by 0 crash if it was set to that.
Restore should not be catching up for lost time when unpacking a
save file into individual level files, and if it hadn't done that
it wouldn't hide mimics who aren't currently hidden.
In addition to avoiding that, this also moves the initialization of
the offending mkobj array sooner.
[3.6 didn't use that array so wasn't susceptible to this. It is
hiding unhidden mimics during what should be a strictly bookkeeping
operation though.]
Issue reported by chadministratorwastaken: were-creature that was
ignoring Elbereth while in human form would make one more attack
after changing into creature form.
Have new_were() make an onscary() check when changing to beast form
while next to the hero. Do likewise for polymorphing creature.
Fixes#1253
Fetching a value of DEBUGFILES from the environment to enable
debugpline() messages was intended to operate in wizard mode only
but that wasn't enforced.
Issue reported by Umbire: if hero dies by drowning on the Plane
of Water, cause of death was reported as "drowning in a limitless
water".
Reported for livelogging but applied to tombstone and logfile too.
Omit the article "a" in this situation.
For 3.6.7, it would have started as "drowning in a water" and been
updated on the fly to be "drowning in deep water". 3.7 changed
terrain type WATER to be "wall of water", where "a" is expected,
and also added "limitless water" for Plane of Water, but it was
neglecting to include a similar fixup for the latter. The "deep
water" fixup is still present but doesn't get triggered anymore.
Fixes#1248
Issue reported by chadministratorwastaken: persistent inventory
window didn't update if reading a spellbook caused that book to fade
to blank paper.
Issue was reported for 'curses' but it was general. The core made
the possibly-revised book type become discovered but that wouldn't
update perm_invent unless the type of book hadn't been discovered.
So if plain spellbook wasn't known yet, the persistent inventory
window did update as intended, but if spellbook of blank paper was
already discovered, the window continued to show the old book type
instead of changing to reflect the revised type (until subsequent
activity triggered another perm_invent update).
Fixes#1246
Coming up to medusa-3 from the level below revealed that Perseus's
statue was not there. It was placed randomly in one of the three
chambers where Medusa might be rather than in the one where she
actually was. Medusa-4 behaved similarly.
Initially I was forcing the statue to be adjacent to Medusa rather
than on her spot, but medusa-1 and medusa-2 don't do that so I've
gone with a simplified revision.
Wake up a sleeping target that gets hit by chain lightning. Also,
bring mimics and hiders out of hiding.
Don't let chain lightning pass into the water on Plane of Water (or
water-wall elsewhere); not sure whether that makes sense physics-wise
but it would have feedback problems due to visibility issues. Do let
it pass over lava.
For curses, behave like tty by keeping a count of messages issued via
raw_print, then if that is non-zero issue a prompt and require the
player to acknowledge them before it erases the screen. Mainly so
that complaints during RC file processing will be seen.
For tty, force getret() to be an unconditional routine instead of
sometimes a routine, sometimes a macro which calls another routine.
This may be useful for some build environments to avoid parallel make
issues, and artificially-concocted order dependencies, leaving the ordering
up to that specified in the Makefile.
The related makedefs options are now:
‐s Generate the bogusmon , engrave and epitaph files.
‐1 Generate the epitaph file.
‐2 Generate the engrave file.
‐3 Generate the bogusmon file.
Also resolves an existing issue encountered in doc/makedefs.6 where "and epitaphfiles"
was being produced in the result.
Issue reported by Shrigis1: the tile for Ixoth depicts a demon that
resembles Nalzok but it ought to be a red dragon.
The issue entry included a binary tile attachment. Rather than try
to deal with that, I've cloned red dragon and included the old tile's
eyes. The issue describes them as green but they look gray to me.
(Ordinary red dragon has white eyes.)
3.4.3 had same issue. I don't remember whether Ixoth was originally
a demon but his tile seems to have always shown one.
Fixes#1239
overcharging when using up a stack instead of single item
Pull request by entrez: shop bill was being inflated by item count
if more that one unpaid item got used up at once. Lighting N unpaid
candles charged N * N * single_candle_price instead of the intended
N * single_candle_price.
This PR was in response to issue #1236 by Xdminsy: usage fees for
applying more unpaid candles are multiplied by amount once more.
Closes#1237Closes#1236
underneath gets boiled away
Pull request by disperse: when a water walking hero zaps a wand of
fire downward and it boils away the water, hero should fall into the
resulting pit.
The PR commit didn't handle monsters (who don't zap wands downward
but could be on/in water that's boiled out from under them). And
while testing it I noticed that the existing code had message
sequencing issues (being enveloped in a cloud of steam before seeing
the water evaporate). This ended up redoing the fix rather than
using the commit.
Fixes#1238
Fix a FIXME added for issue #1233. When engraving, if the writing
implement is a stack of cursed weapons which are welded to the hero's
hand, just write in the dust rather than engrave in the floor, in
order to keep the whole stack welded.
Only applies when the stack is actively welded. Other stacks of
cursed weapons will have one split from the stack to perform the
engraving, otherwise engraving could be used to determine whether a
stack is cursed without the risk of wielding it.
Issue reported by NetSysFire: engraving with a stack of multiple
weapons dulls the whole stack where it ought to only dull one of them.
This was actually trickier than it ought to have been, and will need
a lot more testing. When engraving with a stack, split one off and
use just that one. If inventory is full, it will be dropped (after
writing the first 2 characters and becoming duller). I've avoided
moving it into the overflow slot, otherwise engraving repeatedly with
an arbitrarily large stack could be used to produce an arbitrary
number of overflow items.
Engraving with a weapon of known enchantment us somewhat more verbose
than it used to be.
From the report:
" It would be a great quality of life change if only one item of the
" specified stack was used, as with #forceing open chests.
One person's improved quality of life is another's outrage. Players
who want to dull a stack of +6 daggers down to +5 in order to have
another try of enchanting to +7 are not going to like this....
Closes#1233
When a camera flash hit a mimic which was posing as something, the
feedback mentioned the mimic but didn't bring it out of hiding.
Change to make light pass over a mimic impersonating an object but
unhide one impersonating furniture. Ones impersonating some other
monster are woken up but wakeup doesn't force it back to mimic shape.
Trying to get the messages right brought on more code changes than
antipated. I changed one of the arguments to mhidden_description()
so had to change its callers; fortunately there aren't very many.
The big typos fix commit changed the misspelling "wharever" to
"wherever" but it should have been "whatever".
Plus a punctuation bit I had sitting around.
For tty, make hitpointbar blink if current HP falls to the critical
HP threshold. Doesn't require status highlighting. Not changed:
when status highlighting is active, use the HP color but force the
attribute to be inverse (plus blink if the criterium is met) rather
than whatever the HP highlight specifies.
For curses, do the same thing. It used to honor HP attribute for
hitpointbar, now it behaves the same as tty: always inverse, maybe
combined with blink. The new code assumes that inverse and color
can be turned off without turning off active blink in the process.
I had intended to make hitpointbar be a full-fledged status field
(which happens to be rendered on top of title) so that it could be
highlighted differently from hit points (mainly so that one could
highlight up and down changes while the other showed percentages).
This is less versatile than that but much simpler.
If a tame or peaceful monster was trapped and blind hero hadn't seen
the trap yet, attempting to swap places would report that the monster
couldn't "move out of that trap". And if the 'tips' option was True,
the game would suggest attempting #untrap. But #untrap would report
that the hero wasn't aware of any trap at the spot, and fail.
Change the original message to "move out of that <type-of-trap>" and
if hero hasn't seen it yet, map it and vary the wording slightly
"... a|an <type-of-trap>". If #untrap is attempted, it will now be
dealing with a known trap.
