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.
Add
--showpaths
early option to show where NetHack is expecting to find certain files
without starting up a game. It exits afterwards.
Windows sample (for illustration only, locations may differ for you):
Variable playground locations:
[hackdir ]="C:\Users\JohnDoe\NetHack\3.6\"
[leveldir ]="C:\Users\JohnDoe\AppData\Local\NetHack\3.6\"
[savedir ]="C:\Users\JohnDoe\AppData\Local\NetHack\3.6\"
[bonesdir ]="C:\ProgramData\NetHack\3.6\"
[datadir ]="C:\personal\nhdev\363\test\binary\"
[scoredir ]="C:\ProgramData\NetHack\3.6\"
[lockdir ]="C:\ProgramData\NetHack\3.6\"
[sysconfdir]="C:\ProgramData\NetHack\3.6\"
[configdir ]="C:\Users\JohnDoe\NetHack\3.6\"
[troubledir]="C:\Users\JohnDoe\NetHack\3.6\"
Your system configuration file (in sysconfdir):
"C:\Users\JohnDoe\NetHack\3.6\sysconf"
Your system symbols file (in sysconfdir):
"C:\Users\JohnDoe\NetHack\3.6\symbols"
Your personal configuration file (in configdir):
"C:\Users\JohnDoe\NetHack\3.6\.nethackrc"
Linux (for illustration only, locations may differ for you):
Your system configuration file:
"/home/johndoe/nh/install/games/lib/nethackdir/sysconf"
Your system symbols file:
"/home/johndoe/nh/install/games/lib/nethackdir/symbols"
Your personal configuration file:
"/home/johndoe/.nethackrc"
Slippery fingers would transfer from bare hands to gloved hands if
you put gloves on. The reverse, transfering from gloves to bare
hands when taking gloves off, was already being prevented for
directly taking them off, but still allowed the slipperiness to
transfer when gloves were lost. This prevents putting on gloves
when fingers are slippery and attempts to handle cases where gloves
get unworn by ways other than 'T' (or 'R') or 'A'.
There's no slippery attribute for objects (way too much work for too
little value); slippery gloves is just the combination of wearing
gloves and having slippery fingers (which now has to have happened
while already wearing those gloves). This changes inventory to use
"(being worn; slippery)" when applicable and much of the patch deals
with funnelling Glib changes through new make_glib() to try to make
sure that persistent inventory adds or removes "; slippery" right
away when changes happen.
If gloves are taken off involuntarily (shapechange to a form that
can't wear them, destruction via scroll of destroy armor or monster
spell of same or via overenchantment, theft), slippery fingers ends
right away instead of the usual few turns later.
When I expanded the Guidebook's sample configuration file I added
several status_hilite options. I decided that I'd better test what
was written and discovered that if Xp had an up or changed rule as
well as one or more percentage rules, it was showing bogus changes
whenever the integer value of the percentage changed. The fix
turned out to be simple but it took a while to figure out.
I ultimately left the status_hilite settings out of the sample
options, because they tended to be too wide for Guidebook.txt's
formatting rather than because they weren't working as expected.
Expand the sample configuration file a little and prevent it from
going past the right margin in Guidebook.txt.
Replace all instances of "config file" with "configuration file".
Reformat the "notes" at the end of the table of map symbols.
Unfortunately Guidebook.pdf from Guidebook.ps from Guidebook.mn
puts a page break between the header line "notes" and the two
actual notes.
Value 1 for 'mouse_support' was not just exceeding the margin of
Guidebook.txt but wrapping to the next line. Shorten it.
Guidebook.tex had a typo "in the foler" (where 'folder' was meant)
and Guidebook.mn didn't have that phrase at all.
Remove a few trailing spaces.
Noticed that "multiple" was misspelled for entry about menu action
':' misbehaving under curses, but the phrasing for whole entry was
difficult to comprehend so try to word it better.
[This one is in the highlights list with the old wording.]
Reported directly to devteam, the POSIX_TYPES subset (most? all
these days?) of Unix that defines USE_FCNTL was unlocking lock file
'perm' when done with it but wasn't explicitly closing it unless
the unlocking failed. Triggered a valgrind complaint and could have
posed a problem if restart gets implemented for this configuraiton.
Feedback when playing music while hallucinating misspelled
"butterflies".
Other bits in the same code (not part of #H9407):
All feedback messages while impaired gave "You produce <something>"
which was immediately followed by many of the instruments giving
their own "You produce <some other thing>." Change the verb for the
playing-while-impaired messages to avoid having two consecutive
"you produce" ones.
Also, multiple impairments (two or more of stunned, confused, and
hallucinating) always gave the generic "what you produce is far
from music" message. Have them sometimes ignore excess impairments
to give the message for one of those.
Symbol set changes...
curses:
S_tree (use plus-or-minus sign instead of accidental horizontal line);
S_bars (switch from default '#' to not-equals sign);
DECgraphics:
S_altar (switch from default '_' to 'pi');
S_bars (switch from 'pi' to not-equals sign);
DECgraphics_2: get rid of this commented out set since its contents are
now folded into DECgraphics.
(The IBMgraphics one is just whitespace; delete a <space> that precedes
a <tab>.)
Flag existing occurrences of "You hear" as "Deaf-aware" so
that a grep for that string in the future doesn't need to
trigger further investigation of those.
Something I realized while following up a newsgroup post. If you
knew an item's bless/curse state and dipped it into water while
blind, the bknown flag stayed set and you learned the item's new
bless/curse state without seeing any "glows blue/black/&c" feedback.
Clear the flag unless you know that the potion being dipped into is
water (or is clear if not water has not been discovered) and also
know the water potion's own bless/curse state.
