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.
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.
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.
Options parsing didn't support "default" (shown by the 'O' command)
or "Default symbols" (menu entry for choosing a symbol set via the
'O' command. Symbol handling is somewhat confusing, but this seems to
do the trick. They can't be truncated, but they're case-insensitive,
and "Default" and "symbols" can be separated by dash or underscore as
well as space, or run-together with no separator.
distant_name() temporarily blinded the hero before calling xname() or
doname() in order to prevent the object being formatted from having
its dknown flag set. The Eyes of the Overworld override blindness, so
that bit got set for heros wearing them regardless of intention. This
switches to a file-scope global instead of blindness as the way that
distant_name() tells xname() not to set dknown.
This bug has been present ever since the Eyes were added (3.3.0?).
Move the 'if (wizard) { /* give feedback for named fruit */ }' code
in ^X/enlightenment into an #if DEBUG block, and expand the if (wizard)
predicate with '&& explicitdebug("fruit")' to require that 'fruit' be in
DEBUGFILES. So, build with DEBUG enabled and run via
|% DEBUGFILES='fruit' nethack
to get it back....
This isn't actually a bug fix and it isn't necessary for 3.6.1, but I
got tired of seeing ^X and end-of-game disclosure of attributes end with
three lines about fruit when I'm not doing anything with named fruit.
