Negative AC needed one extra change to support >-N since there was
a place in the code that assumed 0 was the lowest possible value.
(My earlier testing was with <-N which didn't have that issue.)
Make '/<N/' work as 'val < N' instead of 'val <= N', and />N/ work
as 'val > N' instead of >=. The <= and >= behavior might have been
intentional but the only support for that I could find was that
the 'O' menu used "N or less" for '<' and "N or more" for '>' when
setting up 'absolute' rules. If we actually want <= and >= (and we
probably do...), we should add them as more relationship operators
instead of misusing < and >.
Simplify the is_ltgt_percentnumber() case when parsing options
since input has been fully validated by the point that that test
passes. Among other things, /<-0/ and />-0' are now accepted (as
synonums for 0; -0 doesn't mean anything special) instead of being
silently rejected and then discarding the rest of the config file.
(That bad behavior is a separate issue not dealt with here.)
The code to choose a likely target when applying a polearm was
basing its decision on visible spots which contained monsters,
so could expose the location of a hidden monster if there was
only one such spot within polearm range. Not mentioned in the
report: it also wouldn't pick remembered, unseen monster unless
there was a monster still at that spot.
I've changed it to choose candidate location based on the glyphs
shown rather than on the presence of monsters.
Orc heroes get an extra food item ("to compensate for generally
inferior equipment") and it could randomly be lembas wafers (or
cram rations), and Ranger heroes always started with cram rations
even when they're orcs. Fixing the latter was simple, but the
normal race-based substitutions weren't applied to randomly
generated items, so the fix for the former required a bit of code
reorganization in ini_inv().
Elf heroes already get lembas instead of cram; do the reverse for
dwarves (although I don't think this case can happen--no role gets
lembas wafers and only orcs and always-human tourists get random
food); give orc heroes tripe instead of either lembas or cram.
> [1. perm_invent is kept in flags so persists across save/restore, but
> perm_invent capability can change if player restores with a different
> interface--or same one running on a different-sized display--so it
> ought to be in iflags instead.]
Not addressed here.
> 2. perm_invent window does not get updated when charging a wand (or
> other chargeable item presumably), with a scroll of charging.
Most scrolls rely on useup() -> update_inventory(), but charging uses up
the scroll early so that it will be gone from inventory when choosing an
item to charge. It needed an explicit update_inventory() after charging.
> 3. update_inventory(), is called from setworn(), which is called from
> dorestore(), when loading a save. Segfaults have been observed in
> variants based on this code (though not yet in vanilla 3.6.1), so it's
> possible this may be unsafe. The update_inventory() call in setworn()
> could be protected with "if (!restoring) ..."
tty doesn't support perm_invent, so this might be a win32 issue.
I've made the suggested change, but a better fix would be to turn off
perm_invent as soon as options processing (new game) or options restore
(old game unless/until #1 gets changed) has finished setting things up,
then turn it back on at the end of moveloop()'s prolog when play is
about to start.
= =
Most of the read.c change is reordering prototypes to match the order
of the corresponding functions. I did this when adding a new static
routine, then ended up discarding that routine.
Locally I've committed to NetHack-3.6.0 and haven't yet pulled from
upstream to get the branch rename. I expect this commit to be
rejected but it could conceivably go through to the new name.
There was a prior report about this but I can't find it; maybe it
didn't go through the web contact form. Anyway, status_hilite
threshold numeric values wouldn't accept a minus sign before the
digits, preventing negative AC values from being tracked.
With TEXTCOLOR disabled, compiler warnings about term_start_color()
and term_end_color() not being declared were followed by link failure
because they weren't available.
This tries to simplify color handling in the tty status code without
resorting to #if TEXTCOLOR (the proper fix, but somewhat intrusive).
For the usual case where TEXTCOLOR is defined, there were instances
of
if (color != NO_COLOR && color != CLR_MAX)
term_start_color();
...
if (color != NO_COLOR)
term_end_color();
and also of
if (color != NO_COLOR)
term_start_color();
...
if (color != NO_COLOR)
term_end_color();
I've changed both types to be
if (color != NO_COLOR && color != CLR_MAX)
term_start_color();
...
if (color != NO_COLOR && color != CLR_MAX)
term_end_color();
so that start/end pairing will always be consistent.
Also, ((color_and_attr & 0xFF00) >> 8) might not work as intended if
using 16-bit int and color_and_attr happened to have its sign bit set.
Change to ((color_and_attr >> 8) & 0x00FF) to ensure just the desired
bits.
Also also, a couple more formatting bits.
Started by removing two or three unused variables, ended up cleaning
up a lot of formatting (tabs, trailing spaces, indentation, a few
wide lines, 'if (test) return' on same line). Marked some static
functions as static in their definitions instead of leaving it hidden
in their prototypes. Moved a pair of short-circuit checks to skip
several initializations.
the cursor position correctly. This is needed to handle raw printing
correctly. Added check for when we might be running off the bottom
of the screen when handling msmsg(). Added runtime checks to keep
cursor always within bounds.
