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.
Another one from 4.5 years ago: the Tsurugi of Muramasa ought to
be able to split puddings in keeping with its special attack effect
of slicing things in two. The suggestion was more extreme: always
split instead of kill. This generalizes the less extreme version;
METAL weapons (scalpel and tsurugi) can now split puddings like IRON
weapons do even though their user faces no risk of having the weapon
become rusty. Sam's quest artifact receives no special treatment.
Bashing puddings with wielded iron-tipped projectiles was splitting
them. This prevents that (and also for metal-tipped ya).
Every role has a specific spell that they having an easier time
casting. Samurai's special spell is clairvoyance but samurai is
restricted in divination spells. Requested about 4.5 years ago:
allow samurai to achieve basic skill in divination.
Similar for barbarian, special spell is haste self but escape spells
are restricted. All the other roles can already get at least basic
in their special spell's category.
There were several choices:
1) leave things as they are;
2) give those two roles different special spells;
3) allow them to reach basic in the spell category of the existing
special spell;
4) #2 for one of those roles, #3 for the other.
I went with #3. To compensate, reduce attack spell skill limit from
skilled to basic for both. (#4 might be better, since the reason to
want divination enhanced is most likely identify and magic mapping,
not interest in clairvoyance.)
I upgraded from OSX 10.5.8 via 10.6.3 to 10.6.8, plus Xcode to whatever
version was on the 10.6 dvd, and ended up with a more recent version of
gcc that is configured to use 64 bit longs and 64 bit pointers (by
default; presumably that can be changed if necessary). It triggered
several warnings about converting int to pointer of different size or
vice versa even when explicit casts were in use, and a couple of other
things.
Based on a bug report from beta testers in 2010. mintrap()
already had partial checks for this (now fire vortex also burns
a web, as per suggestion in the bug report) but mfndpos()
lacked checks so mintrap() code was almost never exercised.
Most shop messages use shkname() to give the shopkeeper's accurate
name (or hallucinatory substitute) even if he or she can't be seen.
stolen_value() was using mon_nam(), which calls shkname() if the
monster is a shopkeeper who can be seen, but produces "it" when not
seen. Change it to use shkname() like the rest of the shop routines.
Also, replace Monnam() (quite a few instances) with new Shknam() to
do the same duty when the name is at the start of a sentence.
There was also a very obscure bug where if you could see two
shopkeepers at the same time, you could probe the map one spot at
a time with repeated use of the 'p' command to locate monsters in
general and other shopkeepers in particular. Very tedious and not
very useful, but now fixed.
Attempting to read a cursed spellbook fails with a nasty effect. But
a non-cursed book can become cursed while being read (malignant aura
after Wizard has been killed). Assuming no interruption for other
reasons, the read would finish, the spell be learned, and then the
nasty effect would be given. This changes things so that if the book
being read becomes cursed and the hero notices (book's bknown flag is
set), the read-in-progress will be interrupted. Resuming will take
the attempting-to-read-a-cursed-book path. Unfortunately, if the
hero doesn't notice, the old behavior still applies. Maybe the new
behavior should happen even if bknown isn't set (but then player
won't be told why the interruption occurred).
After the recent shopkeeper fix, I wanted to find out what happens if
you turn to stone in the spot inside the shop door. It didn't go too
well--a change of mine from three weeks ago caused a crash due to
passing a null pointer to strcmp(). Death from being turned to stone
or from starvation when there was no while-helpless reason (probably
not possible for starving) triggered it. This fixes that.
As far as the test goes, the shopkeeper takes your inventory and moves
it all the way into the shop, and a statue of the petrified hero is
left without contents in the spot in front of the door. That shk was
awfully quick....
Post-3.6.0 bug, so no fixes entry.
read_config_file() has used a buffer of size (4 * BUFSZ) since 3.4.x
so parse_config_line() needs a buffer of the same size to avoid
buffer overrun. Allows my old .nethackrc to work again.
Globs on the floor used different criteria (anything goes) than globs
in inventory (mostly requiring same ownership when in shops and same
curse/bless state--other stuff generally isn't applicable) when
deciding whether two globs should merge. That was okay as long as
the globs on the floor were from being left behind when a pudding or
ooze was killed, but not if the player had picked some up, dipped
them in holy or unholy water, and dropped them again. This changes
things so that globs on the floor use the same criteria as globs in
inventory when deciding whether to coallesce.
Also, my earlier fix was modifying globs in the mergeable() test (to
make bknown and rknown match) rather than during actual merge, which
would be a problem if the merger didn't take place for some reason.
The report that a tame Archon got two "<pet>'s long sword is not
affected" messages thought there was some duplication error when a
flaming sphere exploded, which was incorrect. Since an Archon has
two weapon attacks, getting that message twice just meant that both
attacks hit. However, the player has only 1/6 chance to suffering
passive fire damage to weapon, where monster-on-monster or monster-
on-polyd-hero was inflicting that for every successful hit, so
there was a bug here after all. Give monsters the same 1/6 chance.
Also, add even more verbosity to that message--now that it won't be
delivered so often--to mention what didn't affect the item.
While investigating this, I noticed that hitting a steam vortex
with a flammable weapon was doing fire damage to that weapon. Fire
damage in the steam vortex definition makes some sense in that it
allows fire resistance to give protection, but dishing out actual
fire damage makes no sense and is now prevented for passive counter-
effects.
The code to handle monsters fleeing up the upstairs on level 1 was
expecting those stairs to be normal upstairs but they are actually
sstairs like the ones down into the mines. So monsters fled to the
Plane of Earth instead of escaping the dungeon as intended.
When destroy_item() or destroy_mitem() burned up a glob of green slime,
they had the message index and damage amount reversed. This could give
a nonsense message ("the glob of green slime freezes and shatters") or
go out of array bounds and wreak havoc. Even if the message index had
been correct, fatal damage would have produced an incorrect cause of
death since it would have used a potion or scroll string.
Now globs will boil and explode like potions, and damage will be
proportional to the size (weight) of the glob, which seems to be the
original intent.
I noticed that my paniclog had a "Query truncated" entry from testing
the post-3.6.0 changes to #dip prompting. For
"What do you want to dip <the object> into? [xyz or ?*] "
the use of safe_qbuf() didn't account for getobj() appending the list
of choices, so wasn't ensuring that the formatted object name combined
with the other text couldn't overflow QBUFSZ.
I had a more elaborate fix than this that still used safe_qbuf(), but
the extra complexity just wasn't worth it. This potentially truncates
the formatted object description more severely than necessary but is
simple enough to be comprehensible.
No fixes36.1 entry. This is updating a post-3.6.0 revision.
From a July 2011 report listing multiple movement anomalies, fix one
of the easier ones. If you polymorph from a fast from into a slow
one, pending movement points can let the slow form get in some moves
it shouldn't.
I've deliberately avoided adjusting pending movement when you change
into a faster form, which will get it's own movement boost on the
next turn.
From a followup to #H2247, April 2011... Physical damage from a mind
flayer attack was inflicted in the AD_DRIN case for hitmu(), then
being inflicted again in the common code after the switch statement.
The new comment explaining the reason for non-standard damage is just
a guess.
Suppress the "you climb/fly up the stairs/ladder" message if the
'verbose' option is off (unless punishment is going to augment the
message by "with great effort").
Bug report subject was "menu interface things" but this isn't related
to menus, just getobj(). Make the requested change to not list worn
suit as a likely candidate for T (and R) if a worn cloak is going to
prevent it from being removed. (Suit can still be picked, but the
take-off operation for it will be refused, same as when it was being
listed as a candidate.)
In discussion about the request, there was a separate suggestion that
cloaks shouldn't interfere with removing things underneath since
they're generally sleeveless. I haven't done that; I think it is
better to keep the layering as it is.
The bug report also asked for the likely candidates when writing with
a magic marker to exclude non-blank scrolls and books. That has been
implemented already (post-3.6.0).
Chameleon impersonating a vampire and vampire subject to protection
from shape changers weren't the only ways to have a vampire monster
which isn't a vampshifter. One-shot polymorph could produce that too.
For !menu_tab_sep, the boolean options were formatted with a different
width than the compound and 'other' options when the menu for 'O' was
active. Use the same format string for all of them, consider them all
when constructing it, and construct it just once instead of every time.
Reported directly to devteam, with patch: tipping corpses out of an
ice box wasn't restarting their rot timers, producing corpses that
would last indefinitely.
Instead of just using 'random' as the default choice if the user hits
<return> when picking role, race, gender, or alignment, flag it as
pre-selected in the menu so that it can be seen to be the default.
Someday somebody is going to have to fix up the interaction between
PICK_ONE menu and pre-selected choice....
When a chameleon/doppelganger/sandestin took vampire or vampire lord
shape, it stopped taking on new shapes. Vampire shapeshifting was
being applied to all vampires rather than just to is_vampshifter().
When is_vampshifter() is false, the vampire is some other shapeshifter
or Protection_from_shape_changers is in effect, so vampire shifting
doesn't apply.
While testing, I noticed that vampires/lords only turned into bats/
wolves during initial creation. They did turn into fog clouds in
order to pass closed doors but the other alternate forms were ignored.
That's fixed too.
This is more robust than the previous hack. The issue of whether to
use it in other places is still unexplored. Ultimately it's the user's
fault if overzealous message suppression hides something important.
[For an eerie game, try 'MSGTYPE=hide .'.]
User had
MSGTTYPE=norep "You see here"
and complained that once the message had been given while walking
over an object, using ':' to intentionally look at something would
end up doing nothing if its feedback was a repeat of "You see here".
Trying to classify which actions should deliberately override
no-repeat (or no-show) will be an ordeal. This fixes the case for
the ':' command where the user obviously expects feedback. I think
it could be done better but am settling for something quick and easy.
Rename the option for adding coordinates to autodescribe feedback for
the '/' and ';' commands from 'getpos_coord' to 'whatis_coord', after
the '/' command that uses it instead of after the internal routine
that implements it. The 'whatis' name was only in dat/hh as far as I
could find, so this changes it to 'what-is' and also updates dat/help
and the Guidebook to mention the name too.
Add a 'screen' choice to the option to show coordinates as row,column
rather than x,y or compass direction(s). Revise the /m, /M, /o, /O
operations of 'what-is' to honor the whatis_coord option (mostly; a
value of 'none' gets overridden by 'map' to force coordinates).
Also, update the description of the functionality of the '/' command
in the Guidebook. The .mn version is tested, the .tex one isn't.
Chatting with Death doesn't always deliver a tribute Death Quote but
when it does, it wasn't giving each of them once before reusing them
even though they should have been treated the same as passage
selections from a novel. I'm still not sure why it wasn't working
as intended, but after some revision to the tribute parsing code, now
it is. If you #chat with Death enough times to get 20 tribute quotes,
you will see each of the 20 quotes once (in random order), then
further chatting will give them again (in different random order).
There have been several comments on IRC how the Wizard is a very
light sleeper now; aggravate cast by monsters makes him wake up
and come out of the tower. So, lets limit aggravate to either
outside or inside of the tower, depending on which side the player is.
