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.
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.
Message given when you see a cursed wand explode while being zapped
by a monster got suppressed if hero was deaf, even though there's no
reference to sound in that message. Change it to ignore deafness;
also, change the alternate message when not visible (which uses
You_hear so already gets suppressed when deaf without caller worrying
about it) use "nearby" or "in the distance" with same criteria as
hearing a wand being zapped, instead of always "in the distance".
I also changed the near/far criteria: threshold to be considered
"far" shrinks from 9 steps to 5 when there's no direct line of sight.
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.
This is important for public servers. Setting the MAXPLAYERS
sysconf value to 0 (or commenting it out) constructs the lock
files with the player UID and player name, so each player may
have one game at a time.
When a stack of corpses gets zapped by undead turning, the message was
"The <foo> corpses glows iridescently." Change it to "One of the <foo>
corpses glows iridescently." since only one of the stack gets revived.
After reading a cursed scroll of genocide, explicitly choosing "none"
when asked to pick what type of monster to wipe out, you get "sent in
some <rndmonst>". But picking nothing (or something invalid) 5 times
gave "that's enough tries" without sending in random monsters. Make
the time-to-give-up behavior be the same as the don't-want-to behavior.
Also, treat picking ESC the same as "none", like blessed genocide does.
Apparently tty doesn't mind if you use add_menu() without preceding
it with start_menu(), because doclassdisco() (the new with 3.6.0 '`'
command) works for me with all four settings of menustyle.
Fix the situation where disabling PANICTRACE, which happened implicitly
when BETA got disabled, caused SYSCF option processing to complain and
quit if the 'sysconf' file contained any PANICTRACE settings.
Now accept all the PANICTRACE options (assuming SYSCF is defined) even
if PANICTRACE is not defined. Their values are recorded in the 'sysopt'
struct, but only validated when the appropriate macros (PANICTRACE,
PANICTRACE_LIB) are defined.
Change
|Bad option line: "foo
|"
to
|Bad option line: "foo"
by stripping away the input line's newline before processing it.
(This doesn't address the PANICTRACE options processing issue.)
With DEBUG suppressed, I started getting
16 warning: empty body in an if-statement
and 2 warning: empty body in an else-statement
from gcc.
Using braces for an empty block instead of just ';' avoids the warning:
if (foo)
debugpline("foo");
is bad,
if (bar) {
debugpline("bar");
}
is good. ;-)
The changes to lint.h are just precautionary.
modified:
include/lint.h
src/attrib.c, bones.c, dbridge.c, dig.c, eat.c,
makemon.c, mkmaze.c, mon.c, sp_lev.c
Shorten a function name in sp_lev.c that exceeded 31 characters.
That's a limit imposed by the VMS linker and the compiler complains
that it will be truncated.
Make all sp_lev.c functions which aren't listed in extern.h be static
and give all of them a declaration at the top of the file. I reordered
the ones already declared there in the same order as they occur in the
source, so the diff is quite a bit bigger than the actual changes.
(Once the one with the long name became static, the length of its name
no longer mattered, but I've shortened it anyway.)
Indent a couple of #pragma directives. Some pre-ANSI compiler didn't
like '#' in column 1 followed by something it didn't understand, even
when that occurred in a conditional block which was in the midst of
being excluded. (util/*_comp.y recently reminded me of that. files.c
should get a fix like this too.)
Reported by a beta tester months ago: it was possible to recognize
your god's temple on the Astral Plane by stepping into its doorway,
since #overview would show "temple of <your god>" (only if just one
temple had been entered and the altar in it was the only one you'd
seen and it was for your own god; #overview doesn't show "temple of
<other god>", just "a temple"). After this fix it will just show
"a temple" even when you can see the temple's altar, so #overview
can't be used as a shortcut to finding the right temple.
While testing the fix I discovered that amnesia wasn't handled when
forgetting the current level's map, only when other levels got
flagged as forgotten. The number of altars, fountains, and so on
are recalculated when #overview is executed, so current-level amnesia
worked for those. But data about known rooms is not recalculated,
so the number of temples and shops you'd visited on the level stayed
instead of being forgotten. The fix is a bit iffy for the case where
you only forget random spots scattered across the level's map rather
than the whole thing; this just wipes #overview memory of every room
even if parts of rooms are still remembered.
How that there's nothing left to trigger it, put in some extra quest
messge debugging code. Could be useful if new roles are added or if
any deliver-by-pline messages get changed to be deliver-by-window.
Another bit prompted by vibrating square testing:
|You see a strange vibration beneath the little dog's rear claws.
Fix up some body parts: dog, cat, and yeti-class (includes sasquatch,
monkey and ape, owlbear) already have "paws" instead of "fore claws".
Take away all 'Y' except owlbear from that list and add rodents to it.
Give them "rear paws" instead of "rear claws" for their feet; for legs,
use "foreleg" instead of "forelimb" and "read leg" instead of "rear limb".
For yeti/sasquatch/monkey/ape/carnivorous-ape, switch from paws to hands
since they have opposable thumbs, and switch to arm, leg, foot instead
of forelimb, rear limb, and rear claw. I've left "fore claw" for finger.
Noticed while testing the look-at vs vibrating square patch: I was
able to cover stairs with a trap via wizard mode wish. That wish can
achieve a lot of irregular things, but prevent this particular one.
When examining a trap with '/' or ';', show
|a trap (arrow trap)
instead of
|a trap or a vibrating square (arrow trap)
outside of Gehennom (unless the trap actually is a vibrating square,
which could happen via wizard mode wish). The extra verbosity is
distracting, and limiting mention of the vibrating square to the region
where it's relevant may give a hint to players getting that far for the
first time.
Preformat SYSCF entry 'WIZARDS' so that it can be displayed during panic
feedback without allocating memory for the formatted list at that time.
It also gets displayed for help's "support information" ('?k').
For panic(), push "it may be possible to rebuild" to a second line since
the formatted usernames might make the line long.
Mark panic() as never returning so that code analysis might be able
to do a smarter job. It required splitting done() into two routines
since the first part really can return (but not if PANICKED was the
reason it got called). done() is now much shorter and ends with a
call to new really_done(), and panic() skips done()'s might-return
part by calling really_done() directly.
Noticed in passing: the "report error to <list of SYSCF WIZARDS>"
code calls a routine which uses alloc(), which won't work very well
if the reason for panic was because malloc() ran out of memory.
On OSX 10.5, save file compression and uncompression fail when I run
under debugger control (for gdb, at least; I don't know why). I used
'#panic' to try something out. panic() calls exit_nhwindows(), then
after some messages calls dosave0(). Saving calls docompress_file()
and when that fails on tty it tries to call clear_nhwindow(WIN_MESSAGE)
but WIN_MESSAGE has been torn down already, leading to a nested panic().
Avoid the call to clear_nhwindow() if windows aren't up.
In the midst of composing a commit message about how I reorganized some
of genl_putmixed()'s code without finding any problem, I realized that
there was a problem. The character immediately after \G12345678 would
be copied directly to the output buffer without examination. If that
was the leading backslash for a second encoded sequence, the G and the
hex digits would follow their backslash as just ordinary chars, which
is not what's intended. Or if instead of a backslash the next character
was the input's terminating '\0', the latter would be copied into the
output and the pointer to the input string would be incremented, then
the next loop iteraction would examined whatever followed. If valgrind
is smart enough--and it seems to be--it would complain about accessing
a character that putmixed()'s caller hadn't initialized.
The only use of putmixed() I'm sure about is the what-is code showing
a screen symbol with its explanation, which doesn't exercise either
\G12345678\G12345678 or \G12345678\0. I didn't go hunting to see if
there was someplace that might have an encoded symbol at the end of the
string. what-is still works after this patch....
The only substantive change is adding ``continue'' but I haven't gone
back and undone the reorg that preceded it.
