Blindness due to face covered by pie was ignored for several cases
of magically curing blindness--cleaning the face seems better than
adjusting timeout to account for u.ucreamed for those cases. A few
instances of taking stun or confusion damage overrode existing stun
or confusion rather than increasing it. Plus a copy/paste mistake
for dual stun+confusion when casting an expired spell.
There was also a suggestion that vomiting when already nauseated
should decrement the timer instead of increasing it. But there is a
negative effect for as long as it's in effect, so I left that as is.
Fix some typos in the sort-by-invlet code and a logic error in the
lately added subclass sorting for sort-by-pack. Regular inventory
display only works correctly for the latter if invlet is the tie-
breaker within object classes. When helmet/gloves/boots/&c and
ammo/launcher/missile/&c sub-categories already break ties for armor
and weapon classes, inventory ended up out of alphabetical order.
When removing items from a container via menu, list gold as '$'
instead of 'a' when it is the first item. Requested during beta
testing last year....
When gold isn't first ('sortpack' false, or custom 'inv_order[]'),
it uses the next letter in sequence instead of '$', otherwise it
would be the only item out of sequence.
Change the sortloot option to use qsort() instead of naive insertion
sort. After sorting, it reorders the linked list into the sorted
order, so might have some subtle change(s) in behavior since that
wasn't done before.
pickup.c includes some formatting cleanup.
modified:
include/extern.h, hack.h, obj.h
src/do.c, do_wear.c, end.c, invent.c, pickup.c
To test:
1. Get a level layout with two shops facing each other, e.g. minetn-4.
2. Sell a fragile object to one of the shops.
3. Dig a pit in the other shop's door space so its shopkeeper stays out
of the way.
4. Pick up an object in that other shop so it appears on your bill.
5. Zap a wand of striking at the first shop to break the fragile
object.
6. 'p'ay for the object picked up.
Expected result: Object gets the standard prompt to pay for it.
Actual result: "Paid object on bill??" followed by "Program in disorder
perhaps you'd better #quit." followed by the object being given to the
player for free.
The cause? This comment going all the way back to 2002:
> /* FIXME: object handling should be limited to
> items which are on this particular shk's bill */
Originally reported by PaRaD0xx in FreeNode's #NetHack IRC channel
whilst playing NAO343.
Based on DynaHack commit d995ed1 (Fix paid object on bill when angering
another shkp) by me.
It's obviously supposed to be the latter and not the former.
Interesting note: This same bug was found and fixed in NitroHack commit
4973ce4 (static checker day: fixes for scan-build and PVS warnings).
This fixes a bug where the hero could accidentally donate the contents
of their bag to a shopkeeper if they put it in another bag on the shop
floor that also belonged to the hero. To reproduce:
1. Drop a sack on the floor, but don't sell it.
2. Get another sack and put in hero-owned objects.
3. Put the sack with objects into the sack on the shop floor.
4. Take out the sack with the objects from the sack on the shop floor.
The shopkeeper will claim you owe them for the objects in the sack, and
view the contents of the sack will show them as belonging to the
shopkeeper.
This fix is what those previous fixes for `SELL_DONTSELL` were for.
Based on DynaHack commit f91ce0b (Fix billing/credit when hero nests
their containers on a shop floor) by me.
There's no capacity for the shop logic to handle gold without also
changing the credit/debit within it, so gold must always be handled in
`sellobj()`, even when the state of it is set to `SELL_DONTSELL`.
This is needed for an upcoming bug fix.
Based on DynaHack commit b0784c5 (Credit/debit gold in containers even
in sellobj_state SELL_DONTSELL) by me.
For a shop to NOT charge for an object, two conditions apply:
1. The object's `no_charge` flag must be set.
2. That `no_charge` flag must be set regardless of whether or not the
shop typically sells the object in question.
There are two places in `sellobj()` which ignore the second condition,
thus transferring object ownership from the player to the shop without
the player's consent:
1. A container is dropped in a shop that typically sells such
containers and `sellobj_state` is `SELL_DONTSELL`.
2. A zero-cost container holding nothing but gold is dropped in a shop
that typically sells such containers.
Neither occurs currently in NetHack: the latter because NetHack has no
zero-cost containers, but the former is needed for an upcoming bug fix.
This may be related to SC343-21: "Accounting is incorrect for containers
dropped in a shop that does not sell them."
Based on DynaHack commit 4e79b6a (Don't shop-donate non-empty bags
dropped in sellobj_state SELL_DONTSELL) by me.
Accept "male" or "female" when specifying monster type for ^G.
Groundwork for testing and hopefully eventually fixing "female
gnome" grows up into "gnome lord" and becomes male.
This fixes a bug where hundreds of turns are wasted by the travel system
moving the player back and forth when the player targets an unreachable
space and sight-blocking obstacles occur in certain formations
in-between. The player will only be stopped if they're interrupted
externally, e.g. growing hungry or being hit by a monster. See the
comment in the code for full details.
Based on DynaHack commit 02da53e (Fix travel moving player back and
forth repeatedly) by me.
Polyself with gender change into a creature with fixed gender
would deliver a message containing "a <creature>" regardless of
whether "an" was warranted.
(Into any creature which supports both genders it yielded
"a male <creature>" or "a female <creature>" so "an" was never
needed. And when no gender change was involved, it used an()
so got "a <creature>" or "an <creature>" as applicable.)
There have been two or three reports on getting feedback about
amulets rusting. Object formatting doesn't display erosion for
them, so being told about damage then not seeing that damage
feels like a bug. Even if damage was displayed, it has no effect
on them so would still feel somewhat strange. It does display
erosion for wands and rings, which is strange too.
This limits erosion damage--and its feedback--to items which are
actually impacted by erosion: armor, weapons and weapon-tools;
also heavy iron balls and iron chains since they've traditionally
shown rust even though it has little effect.
A side-effect of this change is that flammable items (other than
armor and weapons) which don't burn up immediately will no longer
become burnt, then very burnt, thorougly burnt, and finally be
destroyed. Since the player couldn't see or possibly repair the
erosion state, it seemed incomplete. It could be reinstated by
making other flammable items be subject to erosion and displayed
as such by xname() & co.
Wishing now avoids applying erosion and erosion-proofing to items
that aren't affected by it, regardless of material. It also now
allows wishing for "rusty rustproof <iron-object>" which used to
suppress "rusty" in that combination and triggered a couple of
old bug reports.
Heavy iron balls and iron chains can have rust repaired and can
be made rustproof by wielding, then reading enchant weapon while
confused, as if they were weapons.
Pt 1 was about the wrong message delivered when a high priest
rejects being given a name by the player, and was fixed weeks ago.
Pt 2 is about zaps on the Elemental Plane of Air which reach the
edge of the map not having their temporary display effect removed
after "the <zap> vanishes in the aether". There was a 'goto' in
use which bypassed the tmp_at(DISP_END) call. I guess Dijkstra
earns an "I told you so" here.
"Looting many containers via menu cannot be stopped". When the
player uses #loot command at a location with multiple containers,
a menu of which ones to loot is presented and player can pick any
or all of them. But if you terminate the looting of a particular
container with ESC, it goes on to the next selected one rather than
stopping the loot action because that's what the 'q' choice does.
The simplest fix would be to allow choosing only one container
from the "loot which?" menu, but this retains the ability to loot
multiple containers on a pile in one turn. It makes looting
stoppable by extending the ":iobrsq or ?" prompt, adding 'n' for
"next container" and changing 'q' from "done with this container"
to "done looting" (with ESC still a synonym for 'q'). When just
one container is being looted, or when on the last of N containers,
'n' is not shown but is still accepted (and treated as 'q').
Also, use_container() was using a menu for ":iobrsq" if player had
menustyle set to Full when it was intended to be for Partial (name
confusion...). This switches Partial to use menu for loot action,
and leaves Full with that since that's how 3.6.0 has been behaving.
Traditional and Combination use the prompt string and single char
response.
The bug report was actually about letting monsters use fire horns
without checking whether they could actually use wind instruments.
The previous fix probably handled most cases by excluding animals
and mindless creatures, but this is a more specific fix for MUSE
of fire and frost horns--they must pass the same test as the hero
and it's not limited to stopping being turned into slime.
There was no check for being capable of using items when an attempt
to cure being turned into green slime picked scroll, wand, or horn
of fire.
Also, implement a 'TODO' in the same section of code. Monsters
can enter fire traps to cure themselves from slime. I made that
be for monsters smart enough to use items too, even though there's
no actual item involved.
Umpteenth revision of the X11 extended command menu. Add a new
resource to NetHack.ad to control its initial size.
I still hope there's a better way to do this, but this is my last
shot at it.
Let monsters who have a weapon attack for non-physical damage dish
out physical damage instead of doing the drain life or drain
strength they usually do if they happen to be wielding cockatrice
corpses or a couple of particular aritfacts that do more harm
than just level drain. (Other artifacts are candidates, but I
don't think it's worth checking for them since the monsters
involved have such a small chance of acquiring and wielding them.)
Also switch to physical if monster's ability has been cancelled.
Only barrow wight, Nazgul, and erinys are affected. Yeenoghu and
the Master Assassin have a weapon attack for physical damage and
another one for non-physical damage (not necessarily delivered in
that order). They haven't been changed--only the physical damage
attack has a chance to apply their weapon's special damage.
While looking at #H4265 ("Bug - Monsters opening doors" about
feedback naming the unseen monster who opened a door), I didn't
find the the problem. But I did notice a couple of suspicious
constructs. Fix an assignment that gave a boolean variable a
value of 16, and add parentheses around 'a & b' in (a & b && c).
The latter isn't incorrect, it just looks strange.
Report states that using OSX Xcode IDE results in use of 'clang
Modules', whatever those are, and role.c's 'filter' struct ends up
conflicting with a function declared by <curses.h> (or possibly
<ncurses.h> since one includes the other). src/role.c does not
include <curses.h>, so this smacks of the problems caused by using
precompiled headers on pre-OSX Mac.
Instead of trying to import nethack into Xcode, I temporarily
inserted '#include <curses.h>' at the end of unixconf.h. gcc did
complain about 'filter' in role.c (but not in invent.c, despite
-Wshadow), and then complained about termcap.c using TRUE when it
wasn't defined (after in had been #undef'd, where there's a comment
stating that it won't be used in the rest of that file), and also
complained about static function winch() in wintty.c conflicting
with external winch() in curses.
This renames 'filter' and 'winch()' to things that won't conflict.
Also, our winch() is a signal handler but had the wrong signature
for one. And the troublesome use of TRUE was in code that was
supposed to be dealing with int rather than boolean.
Lawful angels deliver taunt messages from a pool of messages which
might mention the lawful god; demons and non-lawful angels draw from
another pool which doesn't mention any gods. Since it is odd for a
'renegade' angel to claim to be operating for its god, choose taunts
from the other pool of messages for renegade lawful angels.
Not related: some formatting fixups in include/mextra.h.
One entry among many in #H4216: make shuriken be a pre-discovered
item for monk role. The word "shuriken" comes from Japanese and
martial-arts monk is primarily Chinese, but shuriken/throwing-star
is a martial-arts type of weapon and monks get a multi-shot bonus
for it (even though they can't advance its skill beyond basic...).
Two different reports complaining that having the Wizard steal the
hero's quest artifact is a bad thing. This doesn't change that,
but it does make all quest artifacts become equal targets so that
wishing for other roles' artifacts doesn't offer such a safe way to
have whichever special attributes they provide.
Quest artifacts are actually higher priority targets for theft than
the Amulet. I suspect that probably wasn't originally intended,
but I left things that way. Taking quest artifacts leaves the hero
more vulnerable to future thefts, and once they're gone the Amulet
has priority over the invocation tools.
When using a stethoscope or wand of probing on a long worm, report
the number of segments it has in the feedback given.
Some of the extra bhitpos and/or notonhead assigments may not be
necessary. They were added when I was trying to figure out the
question of why probing of a tail segment revealed a long worm's
inventory even though the code explicitly prevents that. (Answer:
it didn't; I had misinterpreted bz 12 to think that that was what
was being reported. You need to use wand of probing--or "insigtful"
Magicbane hit--on the head in order to see its inventory or be told
"not carrying anything".)
I initially misunderstood this bug report about a nymph who was
polymorphed into a long worm while carrying a cursed figurine.
It wasn't about a long worm having inventory or about probing of
the worm's tail revealing that it had inventory, it was about the
message given when the cursed figurine activated itself. If that
happened while the head was out of view but at least one tail
segment was visible, the message about the new monster emerging
from the long worm's backpack implied that that pack was carried
by the tail segment.
Only give the emerge-from-backpack message when the worm's head
is visible. Likewise if a carried egg hatches.
Requested during beta testing last year, include a menu entry of
"- - your bare hands" (or "your gloved hands") for wielding,
"- - empty quiver" for readying quiver,
"- - your fingertip" for engraving, or
"- - your fingers" for applying grease
if the user responds with '?' or '*' at the
"What do you want to {wield|ready|write with|grease}? [- abc or ?*]"
getobj prompt. (First dash is inventory selector 'letter', second
dash is menu separator between the letter and its choice description.)
I'm not sure whether I'll do the same for Guidebook.tex.
Guidebook.txt wasn't up to date. I've got some substantive (but minor)
changes coming so am not checking in an updated one yet.
Even out the summoning distribution by adding more lawful candidates.
There used to be only 4; now there are 10. Chaotics have 14, so are
still more likely to get "neutral or own alignment" and stop, but the
difference is now pretty small once you factor in the 18 neutral ones.
In theory nasty() could summon 200 critters at a time, although the
chance seems fairly remote. But it was biased towards having lawfuls
summon more critters than others since there are fewer lawfuls in the
nasties[] list. This puts a cap of 8 successful makemon() calls,
enough to completely surround the hero. More than 8 monsters can be
generated, if any of the makemon() calls produces a group. (I think
fire giants are the only thing in nasties[] that ever come in groups.)
It's still biased toward lawful summoners trying more times hoping to
produce a lawful creature and generating chaotic ones in the process.
The bug report also thought there was some problem between chaotic
and unaligned or with the Wizard, but unaligned is treated as if it
were chaotic (due to use of sgn() in the two or three places where
alignment type is manipulated) so that isn't an actual problem.
