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.)
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.
My compiler was understandably concerned about a potential buffer
overflow here. I don't think the string could get long enough to
cause that to happen, but it's hard to be certain. It's much safer
to limit the length of the string so that it fits in the buffer, as
done here, and if there really wasn't a problem the change will
cause no harm at all. (If there was, the string will be truncated
rather than corrupting memory. This code is in showing the
config-file version of a status highlight, something where
truncated text will probably be obvious to the user.)
Apparently some screen readers keep reading the status lines
at the bottom of the screen when parts of those change.
Add an option to prevent updates to those lines.
botl.c - unused argument in #if STATUS_HILITES code.
mkmaze.c - "clang version 7.3.0 (clang-703.0.31)", or whatever version
of gcc it's based on, warns that ''#define register /*empty*/''
hides a keyword. '-Wkeyword-macro' isn't mentioned in the recent gcc
manual I checked, but it is being enabled by specifying '-pedantic'
(rather than -Wall or -W) to the preprocessor. It could be turned
off via '-Wno-keyword-macro' but this removes all mkmaze.c's register
references instead. (Sean wanted that, and this might be why....)
Make genl_status_update behave approximately the same as basic bot2
when processing the second status line. Preferred order:
Dlvl Gold Hp(HpMax) Pw(PwMax) AC Xp Time Conditions
Alternate orders if above exceeds COLNO (note several extra spaces
get sequeezed out). First one is used if everything except time fits,
second one is used if everything except experience (which can be wide
if 'showexp' option is on) and time fits, third is last resort:
Dlvl Gold Hp(HpMax) Pw(PwMax) AC Xp Conditions Time
Dlvl Gold Hp(HpMax) Pw(PwMax) AC Conditions Xp Time
Hp(HpMax) Pw(PwMax) AC Conditions Dlvl Gold Xp Time
Basic bot2 currently has Conditions as
Stone Slime Strngl FoodPois TermIll <hunger> <encumbrance> Blind Deaf
Stun Conf Hallu Lev Fly Ride
genl_status_update has
<hunger> <encumbrance> Stone Slime Strngl FoodPois TermIll Blind Deaf
Stun Conf Hallu Lev Fly Ride
which is as close as it can get with the current field organization.
Tested by temporarily changing tty_procs.status_init and .status_update
to use genl_* instead of tty_*.
Adding deafness to the status line spurred me on to something I've
wanted to do for a long time. This adds 'Stone' and 'Strngl' as
new status conditions, and moves the five fatal ones: "Stone Slime
Strngl FoodPois TermIll" to the front of the status list since
information about them is more important than any of the others.
"Ill" has been renamed "TermIll"; "Df" has been renamed "Deaf";
"Lev", "Fly", and "Ride" are three additional new conditions, with
Lev and Fly being mutually exclusive. After the fatal ones, the
order of the rest is now
<hunger> <encumbrance> Blind Deaf Stun Conf Hallu Lev Fly Ride
To handle the longer potential status line, the basic bot2() is now
smarter. If the line is wider than the map, 'T:moves' is moved from
the middle to the end. If the line without time is still wider than
the map, then experience (HD if polyd, Xp:M/nnnnnn is showexp is on,
or Exp:M) is moved in front of time at the end. If the line without
experience and time is still wider than the map, dungeon level plus
gold is moved from the beginning to be in front of experience. The
fields are just reordered, not truncated, so if the interface code
can display lines wider than the map they'll retain the extra info.
The gist is than health and associated fields (Hp, Pw, Ac) get first
priority, status conditions get second priority, then the rest. In
the usual case where there aren't many conditions, status display is
the same as it has been in the past.
STATUS_VIA_WINDOWPORT has been updated too, and it builds for tty
and X11. But the bot2() revision to reorder sections has not been
implemented for that.
win/win32/mswproc.c has been updated but not tested.
STATUS_VIA_WINDOWPORT without STATUS_HILITES had several compile
problems; now fixed for core and tty. STATUS_VIA_WINDOWPORT with
STATUS_HILITES has not been tested.
Changes to be committed:
modified: include/botl.h
modified: include/extern.h
modified: include/wintty.h
modified: src/botl.c
modified: src/options.c
modified: src/windows.c
modified: win/tty/wintty.c
get the tty versions started
Changes to be committed:
modified: include/extern.h
modified: src/botl.c
modified: src/options.c
modified: src/windows.c
defer notification of the window port until after
proper initialization. Options are processed very
early in 3.6.0
Changes to be committed:
modified: include/botl.h
modified: src/botl.c
modified: src/windows.c
modified: win/tty/wintty.c
Move the windowport stuff out of botl.c and into windows.c
where it belongs.
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!
