Move makeplural(body_part(FINGER)) into its own routine, with option
to substitute gloves when wearing such.
Wearing slippery gloves (ie, wearing gloves while having slippery
fingers) wouldn't let you put on a ring because you can't take the
gloves off, but removing a worn ring lacked the same restriction.
After changing that, teach prayer that slippery gloves is another
reason why a ring of levitation can't be removed.
With 3.7+ aspirations of improving savefile interoperability between 32-bit
and 64-bit builds, as well as between platforms, it is better to not have
the underlying struct/array content be conditional.
This splits off some of the MAIL code into MAIL_STRUCTURES code. In theory,
since MAIL_STRUCTURES is unconditionally included, the macro could
just go away and leave that code unconditional, but this commit doesn't
go that far.
Some worthwhile stuff from abandoned 'git stash':
is_plural() macro wasn't comprehensive;
a couple of return values where writing with a magic marker was
causing time to elapse even though nothing happened;
comment formatting for saddle being left in shop by dying steed.
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().
End of first pass, but '[&|?:][ \t]*$' doesn't catch trailing operater
followed by end-of-line comment so more needs to be done. As with the
past couple of batches, I've removed redundant parentheses from 'return'
statements but only for files that had continuation fix-ups.
I've also removed tabs from comments in some of the files, but didn't
start until part way through this subset of the sources.
Replace instances of strings split across lines which rely on C89/C90
implicit concatenation of string literals to splice them together
with single strings that are outdented relative to the code that uses
them. It's uglier but it won't break compile for pre-ANSI compilers.
This covers many files in src/ that only have one or two such split
strings. There are several more files which have three or more. Those
will eventually be '(2 of 2)'.
Noticed along the way: the fake mail message/subject
Report bugs to devteam@nethack.org.
wasn't using its format string of "Report bugs to %s.", so would have
just shown our email address. Doesn't anybody enable fake mail anymore?
I modified that format to enclose the address within angle brackets and
made a similar change for the 'contact' choice of the '?' command.
I'll push a formatting guide at some point. There may still be
outstanding changes, but please feel free to resolve those as you arrive
a them.
To the best of my knowledge, there is no changes to the actual code
content, but the formatter does have the occasional bug. If you run into
an issue, please fix it!
From a bug report, you could write scrolls
by type name ("magic mapping") if you had that type of scroll in your
discoveries list via assigning a name to an unknown scroll ("scroll
labeled FOOBIE BLETCH called foo"). Being on that list was enough to
treat the type as known when writing scrolls and books. And he fealt
that it was abusive to be able to collect and name a lot of unknown
scrolls and then write favorite ones which had good odds of being in the
collected set.
This changes it to the original intent: if your discoveries list
has FOOBIE BLETCH on it, you can write a scroll by that label (since we
decided way back when that a scroll's label was its magic, to explain how
a blind hero can read any scroll whose description is known even though
they aren't constructed in braille). If you have identified the type
("scroll of magic mapping labeled FOOBIE BLETCH") then you can write by
type or by description, but you can no longer write one by type when only
the description is known. There is a potential can-of-worms bug here:
if you walked across a "scroll labeled YUM YUM" but have not assigned it
any name, you've still learned its magic words and ought to be able to
write a scroll of YUM YUM. We don't have any mechanism to track items
which have been observed but not been put on the discoveries list. This
patch plugs one obvious hole, by scanning inventory to treat any seen
scroll labels there as an extension of the discoveries list. But the
more general case of something once seen but not named or currently held
is ignored.
This also adds writing scrolls by the user-assigned name, so if
your discoveries list has "scroll labeled FOOBIE BLETCH called foo" you
can write either foo or FOOBIE BLETCH to get the scroll. I'm not sure
the bug report advocated that--parts of it were a bit confusing, at
least to me--and I'm not completely sure that we want to have it, but it
does work. Without it, you got "no such thing as \"foo\"", which seems
counter-intuitive when "foo" is there in plain sight on your discoveries
list. The new code chooses randomly if multiple scrolls have been called
"foo". And if you've called something by an actual object name, it uses
your knowledge of that object rather than anything you've given its name
to. In other words, if you have "scroll labeled YUM YUM called magic
mapping" and try to write magic mapping, it will use your knowledge--or
lack of same--about scroll of magic mapping rather than scroll labeled
YUM YUM to decide whether you'll succeed.
There is also a minor tweak in the chance to write a completely
unknown scroll or book. Wizards almost never failed once their Luck was
5 or more; using rnl(5) instead of rnl(3) requires Luck 11 rather than
just 5 to get that ~39/40 chance of success. Non-wizards didn't change.
Lastly, this fixes an unrelated bug when writing spellbooks. The
message "the spellbook warps strangely, then turns <new description>"
works okay when <new description> is "red" or even "ragged", but not so
well when it's "vellum". A handful of book descriptions refer to the
item composition rather than the appearance of the cover, and turning
into a new composition needs different phrasing. I just tweaked it to
be "turns into vellum", which is probably suboptimal (particularly for
the book description "cloth" :-).
From a bug report, you could write a
spellbook with a magic marker while blind and were told the description
(often a color) of the resulting book. This prevents books from being
written while blind, just as they can't be read in that situation, and
it adds an extra test when attempting to write scrolls while blind.
(When you succeed in writing a scroll while blind, you're just told that
the result is ``x - a scroll'' as it's moved to its new inventory slot.)
This also removes a couple of overly hyper exclamations when writing
fails. Someday somebody ought to go through the whole program and decide
which messages actually warrant exclamation points, but I doubt that
that'll ever happen.
Most callers of dropx did not check for altars, but should have. Rather
than add such checks, I moved the check from drop to dropx. I also found
several callers of dropx that could generate out-of-order messages for some
cases (not new) and fixed them. FYI - callers of dropy don't seem to want
altar checks or already do them.
