Bug bz14, no web id.
Steps to reproduce:
- have a stethoscope handy.
- place an amulet in a doorway and move one square outside the room's door.
- create and lead an invisible stalker to be on top of amulet, with you
just outside the room beside the door square.
- zap the stalker asleep with a wand of sleep.
- put on a blindfold.
- quaff a potion of object detection.
- amulet shows in the doorway.
- save the game and keep the savefile for ease of returning to this point.
Bug 1 observed (remember that you're blind due to blindfold):
- zap a wand of death at the stalker that you know to be on top of
the amulet, but that the game gives no indication of.
- if the stalker left a corpse, and you apply a stethoscope to the
doorway, the game tells you that "You determine that that unfortunate
being is dead" yet no being or corpse is displayed, still just the amulet.
Fix that by calling map_object(corpse, TRUE) in its_dead() under these circumstances.
The circumstances in the original report were also reproduced, specifically:
If a stethoscope finds an unseen monster on a square with an
object-detected object while blind, after killing the monster, the
object isn't remembered.
That remains unfixed because the I (invis monster glyph) aleady overwrote the
detected object glyph, so it is a much tougher situation.
This is a fix for H4101, bz192.
add non-audio (felt) outcome to yelp()
This also add #wizintrinsic command because testing this was a pain
without a simple, straightforward way to go deaf that didn't time-out
before the situation being tested recurred.
Suppress a couple of 'dead increment' diagnostics from the clang static
analyzer. The assignments are dead, but keeping the variable up to date
is more valuable (in case someone someday changes the code to use the
affected variable somewhere farther along in that function) than changing
the code to avoid the assignments in order to prevent the diagnostic.
This will only work to suppress the analyzer's diagnostic messages if
either FORCE_ARG_USAGE or GCC_WARN is defined when compiling makemon.c.
Avoid the possibility of a user-supplied name interfering with killer
reason truncation. A monster named ", while" that killed the hero
would result in "killed by <mon-type> called " being displayed on the
tombstone after stripping while-helpless reason to shorten the text.
If a character dies with 'multi' at a non-zero value, the reason for
helplessness is appended to the cause of death. But that was taking
place in writeentry(), which is used for every score entry while
rewriting 'record' when a new high score is added. So whenever a new
score with helplessness was added, all existing entries got corrupted
by having the newest game's reason for helplessness tacked on.
Append the helplessness reason while formatting the cause of death
instead of when writing out score and logfile entries. xlogfile is
handled a little differently in case the cause of death plus reason
for helplessness is too long so truncated for record and logfile.
Full reason is still put into xlogfile.
Changes to be committed:
modified: doc/fixes36.1
modified: src/ball.c
I looked up the original bug report that led to bug page C343-20
"When dying immediately on entering a level, the map may show you dying on the previous level."
It was received public report U891:
> When one is being punished and goes down a staircase and dies because the
> ball and chain fell on their head, one gets the message about their death
> while the old level is still being displayed. I wasn't sure whether this
> was a bug or not because on one hand it wouldn't make much sense to
> generate a new level if the character is going to die anyway. However,
> that being said it does make a difference if the character is about to go
> down into a level where one cannot leave bones files, ie medusa or the
> first level of the mines (if i remember correctly). So, if your character
> dies from this does the bones file get left on the level you were on
> (which is still displayed at the time of death) or the level you died as
> soon as you got to (but was never displayed)? Thanks!
Pat had remarked in response: "So this is just a display issue; game play works as intended
(for the program; I imagine you weren't planning to get killed."
A debug trace in wizard mode 3.6.1 beta shows that the relevant code path is this:
NetHack.exe!done(int how) Line 908
NetHack.exe!losehp(int n, const char * knam, char k_format) Line 2678
NetHack.exe!drag_down(...) Line 823
NetHack.exe!goto_level(d_level * newlevel, char at_stairs, char falling, char portal) Line 1316
NetHack.exe!next_level(char at_stairs) Line 1157
NetHack.exe!dodown(...) Line 954
NetHack.exe!rhack(char * cmd) Line 3416
NetHack.exe!moveloop(char resuming) Line 464
NetHack.exe!main(int argc, char * * argv) Line 104
This patch clears the display for the situation in drag_down(),
so the old level is not shown.
If player specified all four facets of role: role, race, gender, and
alignment, via command line or option settings, the tty interface still
asked the player to confirm whether the character's role/&c was ok?
Skip that confirmation when all four things have already been chosen.
Like the just fixed naming for discoveries list, there are several
other add_menu() calls which specify <space> instead of 0 as a useless
selector on separator lines. These others are all for role selection,
where menus don't get big enough to need next-page.
I don't know what I was thinking at the time, although it must have
seemed like a good idea for some reason....
The menu for picking an item to name when using the "on discoveries list"
choice for #name or C when that list spanned multiple pages was exiting
for <space> instead of advancing to next page. Space was being assigned
as the selection letter for class header lines, which made no sense.
Make a fix suggested during beta testing: you can read scrolls while
blind if you know the label, and you can write a scroll with a magic
marker while blind, but the result was flagged as description unknown
so you couldn't read the newly written scroll until regaining sight
or obtaining object identification. So change writing a previously
discovered scroll while blind to set dknown since a successful write
always yields the type of scroll requested. Getting lucky while
attempting to write an undiscovered scroll--which has to be done by
scroll's type name (for instance "food detection") rather than by its
label ("YUM YUM")--still leaves the description flagged as unknown
since hero hasn't seen the what sort of label the new scroll has.
Along the way I got side-tracked by the possibilty of writing a scroll
of mail. It's allowed and yielded the same result as finding such a
scroll in bones, or wishing for one: when read, it was junk mail from
Larn. Make one written via marker give different feedback since it
comes from creation of a stamped scroll without any stamps available.
Also, suppress an "argument not used" warning for readmail().
A couple of reports asked what weird unit of measure was used for the
'realtime' value in xlogfile. It was just seconds, but was accumulating
incorrectly whenever game-state got saved for the checkpoint option.
Now it really is seconds, or rather whatever unit you get for the delta
of two time_t values; usually seconds but not guaranteed to be that.
60: getpos() doesn't report the offending keystroke accurately when
rejecting M-something as a movement keystroke while moving the cursor;
61: typing M-N as a command keystroke produces
|Unknown command 'M-
| '.
where the '.' on the second line clobbers the top line of the map.
I can't reproduce the first one without extending the altmeta hack
[a run-time option to treat two char sequence ESC c as M-c] to getpos()
and nh_poskey(), which I've done for testing but am not including here.
I can't reproduce the second as it's described, but M-^J produces
|Unknown command 'M-
|'.--More--
and this fixes that, with a general fix that applies to any meta char.
The diffs include some cleanup/groundwork for maybe extending altmeta.
When I updated recover.6 last week, I was under the mis-impression that
the INSURANCE compile-time option had been made unconditional. It has
not, and after undoing that, there was no substantive change, so put it
back to how it was at release.
Passage 1 of the Colour of Magic: 'bazaars' was misspelled 'bazarrs'.
There were a couple of other things that didn't match the paperback copy
I recently recovered from loan: 'radiation' should be 'radiations', and
'dark' was omitted from 'a tall dark figure'.
Unlike the later Harper editions, the early Signet ones retain British
spelling (at least for 'colour'). I failed to find the second passsage
via flipping through the pages, so wasn't able to proof-check that one.
Changes to be committed:
modified: doc/fixes36.1
modified: src/dogmove.c
A bug reporter wrote:
> comments:
> "You sense a little dog appear where Poes was!"
>
> seems strange to me, perhaps it should be "appearing", or the hero shouldn't
> notice at all if it's out of sight.
>
> Not sure it was out of sight, anyway, because I saw the d from the shop
> doorway.
>
Change the wording to:
"You sense that a little dog has appeared where Poes was!"
Author: PatR <rankin@nethack.org>
Date: Sun Dec 13 06:06:58 2015 -0800
fix #H4066 - bug eating ring of protection
Intrinsic protection of 0 (usually from having a gremlin steal divine
protection, but also possible by eating a +0 ring of protection) does
not contribute to "magic cancellation", the defense attribute that
makes some special attacks fail. That's intended. Negative intrinsic
protection (not possible from having divine protection, but turns out
to be possible from eating negatively enchanted/charged rings of
protection), did contribute. That wasn't intended, so stop it.
(Positive intrinsic protection gives a magic cancellation of 1 if worn
armor doesn't provide any MC.)
High priests used a different message to refuse accepting a user-supplied
name than regular temple priests because they're flagged as unique. The
effect was cosmetic; it didn't reopen the hole that let you recognize
which high priest was which via the 'C' command on the Astral Plane.
[I never received the mail for #H4062 but saw it in bugzilla.]
Dip the scroll labeled LEP GEX VEN ZEA into the fountain?
Your scroll called light fades.
The first prompt deliberately avoided 'called', 'named', and other
attributes to keep it short, but the discrepancy here is blatant, so
increase the verbosity in order to have the reminder that's included
in the prompt be the same as object name in the followup message.
Bonus fix, noticed while testing it: water_damage() was reporting
the "{blank,unlabeled} scroll fades" even though blank scrolls are
already as faded as they can get. Likewise for blank spellbook.
Entered in bugzilla prior to release: "slice of birthday cake" became
"slouse of birthday cake" when made plural. "slice of pizza" used to
work, but adding an entry for "louse" <-> "lice" to one of the special
handling lists for singular/plural broke "slice" since only a trailing
substring match is performed for entries in that particular list.
In 3.4.3, reading an uncursed scroll of enchant armor while wearing
a piece of cursed armor performed an uncurse as well as raising
enchantment. A fairly big patch to redo how pending shop bills were
affected by altering the items on the bill accidentally took away
the uncurse part when modifying the scroll code to use the bless()/
uncurse()/curse() functions instead of manipulating the armor's
blessed and cursed flags directly.
Requested by a beta tester back in June: naming Sting or Orcrist
violates illiterate conduct. I left it at that; any object naming
could be construed as being literate, but I don't think breaking
conduct for doing such would be a good idea.
Vampires who were currently shape-shifted into a fog cloud, bat, or wolf
became an unkillable fog could, bat, or wolf if the player genocided
vampires. When such a creature was killed, the attempt to transform it
back into a vampire failed, but the monster continued to be resurrected
anyway.
Changes to be committed:
modified: sys/share/pcmain.c
modified: sys/winnt/nttty.c
modified: sys/winnt/stubs.c
Bug 123 Report 4030:
Minor thing I've noticed - if I quit the game, at the "Hit <Enter> to end."
prompt, if I close the window rather than pressing Enter, I get the following:
Bug 138 - #H4045:
"nethack -s" leads to "-s is not supported for the Graphical Interface".
That's wrong.
(The Graphical Interface comes with "nethackw".)
