Noticed when testing tty menucolor changes recently, using the 'O'
command to interactively add a new entry would accept one and then
quit, unlike remove which accepts multiple at a time and then goes
back to the menu where you could choose 'remove' all over again.
Adding is still done one entry at a time, but instead of finishing,
it goes back to the menu where you can choose to add another.
After some permutation of commands which displayed items, the 'd'
command presented a prompt with the list of letters scrambled (in
loot order or pack order rather than invlet order), so explicitly
sort when getobj operates. Done for ggetobj too.
For menustyle:Traditional, ',' followed by 'm' presented a pickup
list in pile order even when sortloot was 'l' or 'f'. That was an
unintentional change during the 'revamp'.
Reported directly to devteam for recent git code, the "sortloot
revamp" patch could trigger an object lost panic after calling
query_objlist() when menustyle was full or partial and player
picked up a subset of available items. Modified head-of-list was
not being propagated to its source in pickup(). Use an extra layer
of indirection.
Reported directly to devteam (for 3.4.3 but still present in 3.6.0):
an unseen landmine explosion which caused scatter() to break a
boulder or statue would give feedback as if the hero could see the
boulder or statue being destroyed.
Also, a couple of landmine explosion messages didn't take deafness
into account.
This one had been intended for longer than several years, but I
hadn't gotten around to it. When consorting with succubi and
incubi, very high Cha+Int no longer guarantees that a positive
outcome will occur.
Chance of positive outcome is still quite high and most of the
negative outcomes are pretty easy to repair, so this isn't likely
to make a significant impact. However, the possibility of losing
spell power will matter for some players....
This was sitting around for several years. When positive luck
lessens a negative effect from sitting on a throne, reduce luck so
that repeated occurances will eventually get the intended result.
Most of the humanoid species have Lords and several have Kings,
but none of them have Ladies or Queens. When a female grows up
to reach that level of monster, she changes into male. This fix
gives an alternate message acknowledging that change rather than
prevent taking on the stronger form. A better fix would be to
add ogre ladies and dwarf queens as separate monsters, but doing
so will break 3.6.0 save file compatibility.
(I started out with an alternate fix, adding mons[].fname for the
dozen or so creatures which warrant an alternate name for females.
But that requires statues, figurines, corpses, tins, and maybe
even eggs to track gender [some statues already do, and corpses
and statues with attached mtraits also implicitly do] and to not
stack with equivalent ones of the opposite gender. Plus glyphs
to track them, and new tiles. It was becoming too complicated
for such a relatively unimportant feature. Separate monsters is
the way to go, deferred until save file format changes again.)
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
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.
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.
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.)
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.
Death Quotes have reached the current limit of 30 passages per 'book'.
Instead of increasing that, change the selection code to be able to
operate on a subset (dropped from 30 down to 20) at a time while
keeping the excess available for later selection.
Chatting with Death (more than 20 times since he also delivers non-
tribute messages) should cycle through 20 of his 30 passages without
repeating. After that, another subset of 20 out of the 30 will be
chosen, independent of the first set so might contain all, some, or
none of the 10 that left out before.
Sometimes you can see a hidden monster without bringing it out of
hiding (wand of probing, blessed potion of monster detection) but
look_at wasn't mentioning the fact that the monster was hidden and
probing described mimics accurately but lumped all hiders together
as "concealed". Describe all hidden monsters more consistently.
Reported directly to devteam, the 'R' command would let you take off
a suit from under a cloak or a shirt from under a suit and/or a cloak,
and it didn't require any extra turns. 'T' doesn't allow either of
those. ('A' lets you take off a suit from under a cloak, adding in
extra turns to implicitly take the cloak off and put it back on,
but doesn't allow the same for shirt.)
'R' also let you attempt to take off embedded dragon scales if you
were wearing 2 or more accessories (or just 1 with paranoid_confirm
set for takeoff/remove), which triggered impossible "select_off:
<scales object> (embedded in skin)???".
Changes to be committed:
modified: doc/fixes36.1
modified: src/pager.c
fix bug bz54; this bug had no web ID
Report:
For /, asking via cursor can't find special named entries like "Hachi"
because the entry for the monster type like "dog" gets used instead.
Change:
Instead of "More info?", when applicable it will now do:
More info about "hachi"? [yn] (n) n
More info about "little dog"? [yn] (n)
Changes to be committed:
modified: include/extern.h
modified: src/allmain.c
modified: src/detect.c
modified: src/display.c
Bug bz22 (no corresponding web id) reported quite some time ago.
Reported:
Warning stays on when a "lurker above" is co-located with a
boulder, even when you are adjacent to the spot. Even though
you see the warning symbol and not the boulder, an attempt
to move in that direction tries to move the boulder, rather
than attack the creature you know to be there. What's more,
you can get the
"You hear a monster on the other side of the boulder..."
preventing anything from happening if there is a monster on
the other side of the spot. The player doesn't necessarily
even know there is a boulder there at the time (because
warning trumps the boulder display) so it can all be somewhat
confusing.
Change:
- Split off a section of the search0() code for monsters into
a separately callable function, arbitrarily named mfind0(),
which takes a special arg for this particular scenario.
- If you have Warning and you get adjacent to an unseen hider
such as a lurker above with the Warning glyph still displayed,
a specific search is carried out for the obviously present monster.
- The boulder concerns in the original report should become moot
after this.
Another OS upgrade (OSX 10.6.8 -> 10.8.5) with different toolset,
another change in compiler behavior. Earlier 'gcc -Wwrite-strings'
didn't complain about passing string literals as 'char *' paremeters
if there was no prototype in scope. This one found one or two of
those in options.c and several in makedefs.c (fix coming soon in a
separate commit...). This adds some missing prototypes and reorders
the existing ones to match their order within the file. There were
also several functions which were declared static in their advance
declarations but not in the definitions, which can be confusing when
reading the source.
Force a screen redraw if the tiled_map option is toggled via the 'O'
command. The X11 interface switches map modes even without this, but
conceptually it's something that must be done when the option setting
is changed.
weight() didn't know how to calculate a glob's weight. When one glob
absorbs another, that isn't used, but when the hero eats part of a
glob, it is, and the result was incorrect.
Setting CHECK_PLNAME to 1 makes WIZARDS, EXPLORERS, and SHELLERS
check the player name instead of the user's login name.
This is mostly useful for public servers which have external
login system and don't create user accounts for players.
