...some of them, at any rate. We shut off (1) warnings provoked by Matt
Bishop's "mn" macro package, and (2) warnings spuriously emitted by
groff 1.23 and previous when "-wall" (or "-ww") is specified.
Also update explanatory comments.
If hero survives a killing blow via saving-grace, report that to
livelog but hide it from player's own #chronicle.
Only reveal whether saving-grace was used up during end-of-game
disclosure. Omit that during enlightenment unless running in
explore mode (or wizard mode).
Sanity check failure generated by running the fuzzer, reported
by mkuoppal. The check discovered that the hero's current hit
points were greater than the maximum.
Comments by elunna pointed out where the problem most likely was,
and this attempts to fix the situation, but without a test case
I can't be sure that the fix works.
Both cases being fixed are for formerly fatal incidents (random
chance that poison is fatal, monster touch of death spell) being
'softened' to heavy HP damage (including reduction of maxHP).
The earlier commit I made (045d608) was done without having seen
the relevant comments. It didn't fix anything but did attempt
to make finding the problem(s) easier. It wasn't much help.
Fixes#1252
This quietens several warnings from GNU troff in the "range" category.
troff: backtrace: './doc/tmac.nh':92: macro 'ED'
troff: backtrace: file './doc/Guidebook.mn':5950
troff:./doc/Guidebook.mn:5950: warning: treating -120u indentation as
zero
Unfortunately, the similar `ed` macro in Bishop's "mn" package
contributes several more.
But with this change (and its forerunners in this series), the NetHack
Guidebook is now warning-free with "-wall -Wtab -Wrange" ("mn" has
problems with tab characters too), even with the increasingly fastidious
syntactical checks of the forthcoming groff 1.24 release.
The forthcoming groff 1.24 has a new diagnostic that detects ill-formed
numeric expressions. It has found one here.
I'm not positive what was intended here, but it may have been an attempt
to force interpretation of the first macro argument as a number. This
change employs a more idiomatic (but still old-school) technique.
The salient fact is that, in *roff, you can't affix a scaling unit after
a closing parenthesis (or another scaling unit).
In GNU troff the `\B` escape sequence, an extension, permits the testing
of putative numeric expressions for validity.
troff:./doc/Guidebook.mn:268: warning: expected end of line or an
auto-increment argument in register definition request; got character
'v'
See <https://savannah.gnu.org/bugs/?64240>.
* doc/Guidebook.mn: Make the Guidebook buildable from the top of the
source tree, not just inside the "doc" directory. Try to load its
"nh" macro package from the current working directory and from "doc".
* doc/tmac.nh: Allocate new register `nH` to the purpose of detecting
multiple loads, and skip file content if detected. This is the 1970s
nroff form of an "#include guard". groff's "an-ext.tmac" uses the
same technique for portability.
Also I removed a tab character. Per the groff Texinfo manual:
One possibly irritating idiosyncrasy is that tabs should not be
used to vertically align comments in the source document. Tab
characters are not treated as separators between a request name and
its first argument, nor between arguments.
Here's an example of how one groff macro package works around the
problem.
$ sed -n '402,406p' contrib/mm/m.tmac
.ds LetCN CONFIDENTIAL\" Confidential default
.ds LetSA To Whom It May Concern:\" Salutation default
.ds LetAT ATTENTION:\" Attention string
.ds LetSJ SUBJECT:\" Subject string
.ds LetRN In reference to:\" Reference string
I'm mindful of the license here, but suspect that these lines crept in
after Matt Bishop's time. Text lines in a macro package can be
insidious because they cause formatting operations to start even in the
absence of an input document. The forthcoming groff 1.24 has a new
diagnostic to help catch these situations.
The groff Texinfo manual says:
A '\"' comment on a line by itself is treated as a blank line,
because after eliminating the comment, that is all that remains.
Test
\" comment
Test
=> Test
=>
=> Test
To compensate, it is common to combine the empty request with the
comment escape sequence as '.\"', causing the input line to be
ignored.
Fixes:
$ (cd doc && groff -t -M . -mn -mnh Guidebook.mn > /dev/null)
troffrc:./tmac.n:1: text line in startup file
troffrc:./tmac.n:764: text line in startup file
\F and \f do different things.
Fixes:
$ (cd doc && cat Guidebook.mn | tbl tmac.n - | groff > Guidebook.ps)
troff:<standard input>:3468: error: no font family named 'I' exists
The 'A' ("alphabetic") and 'N' ("numeric") column classifiers were being
used to little benefit.
Since 'A' was applying to every row of the table, none was more indented
than any other, except via the inclusion of unadjustable, unbreakable
space escape sequences `\ `, which work just as well with column
classifier 'L' ("left").
In fact, even they are unnecessary; regular spaces will do.
tbl(1):
Ordinarily, a table entry is typeset rigidly. It is not filled,
broken, hyphenated, adjusted, or populated with additional inter‐
sentence space.
...so furthermore convert the escaped spaces to regular ones.
Similarly, 'N' applies several rules to manage alignment of decimal
points. This table doesn't need them. Right-alignment of integers is
just as easily achieved with the 'R' ("right") column classifier.
Comment escape sequences inside table entries can wreak havoc. Use
dummy character instead to visually indicate the deliberate trailing
spaces. Move the comment explaining why they're there closer to what
they document. It's okay to have _whole-line_ comments in table data,
because they are on control lines (lines that start with a dot '.').
Also use the dummy character to indicate deliberately empty table cells.
I don't always want to abort() on an impossible() when debug_fuzzing,
especially if the first impossible() encountered isn't related to the
bug I'm in the midst of trying to hunt down.
I often have breakpoints on impossible() anyway, and I'd like a simple
way to avoid the panic() call during a lengthy debug session.
Make iflags.debug_fuzzer an xint8 instead of a boolean.
Call abort() only if iflags.debug_fuzzer is set to 1.
That allows setting iflags.debug_fuzzer to 2 in order to bypass the
abort call, and make use of other breakpoints that have been set
to narrow down a particular issue.
First noticed this when watching someone livestream, and managed
to figure it out from there: The window that pops up when looking
at a pile of objects under you by pressing ':' is marked as a menu,
but has no selectable options. Curses still allowed you to use the
menu-search command (':') on it.
Prevent the menu search command in windows with no selectable entries.
Issue a livelog/#chronicle message if saving-grace saves the hero.
Right now it's classified as conduct for livelog filtering, because
I didn't want to implement a new category (needs update of global.h
and also the template 'sysconf') and conduct felt like the best fit
of the existing classifications.
Report whether saving-grace is available or already used, among
the attributes of magical enlightenment or end-of-game disclosure.
And move the fixes entry for it from the fixes section to the new
features section of fixes3-7-0.txt.
It seems likely that someone will want to turn not using saving-
grace into a tracked conduct. That seems like overkill to me, not
to mention inflating the N for "N conduct games".
I've been investigating issue #1252 (while the fuzzer was running,
sanity_check complained that hero's current health was greater
than maximum health) off and on for three months and haven't found
the cause.
I've checked all the places that lower maximum HP that I've managed
to find, but not spent much time looking for places that raise
current HP.
These changes might provide some more information. They don't rely
on sanity_check being enabled.
Issue #1252 is still open.
Take care of most of include/*.h. I punted on extern.h.
For both src/*.c and include/*.h, I used mismatched checks of
width > 79 to decide which files to look at and then width > 78
to decide which lines to maybe revise, so I didn't look at a bunch
of the files.
I don't plan to go back and do it right. Shortening lines that are
80 or wider to less than 80 is the significant part. Otherwise
emacs puts a backslash in column 80 and the rest of the line of text
on the next line of the screen, making things harder to read.
I recently realized that I've been editing sources in a terminal
window that was widened in order to fit curses borders for testing
something or other. That has resulted in some new wide lines in the
source. There were lots of old ones too.
This updates some source files to try to achieve the goal of 78
characters or less. As in the past, I've been inconsistent about
lines with 79 characters. Lines with 80 or more have been wrapped
or shortened (usually by trimming an end of line comment or removing
redundant parantheses, sometimes just by reducing the indentation
of the continuation portion of an already wrapped line).
I eliminated one instance of warning manipulation for non-constant
format string, and simplified stone_luck() where Ken had a silly
comment about the function argument's name.
Since wand of secret door detection now gives feedback even when it
fails to find anything, always discover it.
Some of the other zapnodir() wands had suspect discoveries.
Another byproduct of testing boulder pushing. If you kick a closed
door while polymorphed into a giant, always succeed in breaking the
door instead of maybe getting the Wham! or Thwack! failure result.
Noticed when testing boulder pushing into/out of shops yesterday:
a shopkeeper can "mutter incantations" and fracture a boulder in the
shop, transforming it to rocks. If hero owed shk for the boulder
(happens when it has been further inside the shop and then gets pushed
to the shop's free spot), it would disappear from the shop's bill and
hero would then owe for the resulting rocks (which cost more than the
boulder!). That seemed confusing, especially since neither Iu nor Ix
would show the rocks (which are on the floor rather than in invent;
the $ command reported the amount owed, but not what the item was).
When such fracturing happens move the boulder from the unpaid section
of the shop bill to the used-up section before creating the rocks,
which are no longer interesting.
The report is for 3.6.7: pushing a boulder into a general store adds
it to shop's inventory, but pushing it back out lets player remove it
for free. 3.7 has already fixed this; update its comments though.
Pull request from argrath: change a couple of places in moverock()
to use moverock_done() and return early rather than use break to fall
to the end.
Closes#1272
