The curses interface wouldn't build with HILITE_STATUS disabled. I
started adapting it to handle genl_status_update() but that was taking
too much effort with each niggling detail leading to another. This
goes the opposite direction: forcing the old STATUS_VIA_WINDOWPORT
behavior without having that #define available. That dragged along a
bunch of unexpected changes too.
I've overhauled the status display for curses. Horizontal layout
supports both 2 lines and 3 lines which can be changed dynamically
via using 'O' to set 'statuslines'. Fields are spread out a little
more than they used to be, making it more readable--at least to me--
but the extra spaces get squeezed out when lines become too long.
If 'showexp' is on and either conditions or hunger+encumbrance go
off the right edge, experience points are suppressed (but the option
is left on, so they'll come back once there is room).
For traditional 2-line hozizontal status, if hunger+encumbrance+
conditions go off the right edge even after experience points are
knocked out, there will be a '+' in the rightmost column if there
are any conditions that are all the way off. At present it doesn't
use the tty method of switching to abbreviated condition names to
reduce their legnth. I'll probably tackle that eventually if no one
beats me to it.
For 3-line horizonal status, there was an older implementation (but
disabled via #if 0) with gold and score moving to the third line.
(I'm not sure how status conditions were handled.) This one ignored
that and modified 2-line from scratch, moving alignment from line one
to line 2 and level description, time, and conditions from line 2 to
line 3. It looks like this (view with a fixed-width font...).
Wizard the Hatamoto St:16 Dx:15 Co:18 In:8 Wi:11 Ch:7 S:25
Lawful $:21 HP:25(25) Pw:6(6) AC:4 Xp:2/21 Hungry Burdened
Dlvl:1 T:36 Blind Lev
Score is actually right aligned with the edge but I've deleted several
spaces to keep the line shorter here. The status conditions line up
with the hunger slot as that shifts due to changes in gold/HP/power/AC/
experience, and conditions prefer that column even when hunger and/or
encumbrance are blank. Howver, if the number of conditions increase to
the point where they would go off the edge, the whole list shifts left
instead of trying to stay lined up with hunger. (It's just coincidence
that the lefthand parts of lines 2 and 3 seem to line up in this sample.
In general, they don't.)
The vertical layout has reordered most of the fields and now has a few
blank lines to separate those fields into some groups for readability.
Lines have the form of
Field-name : Value
and when highlights apply, now they only affect the value portion.
Single digit characteristics are padded with a leading space so that
all six of them line up (for "18/xx", "/xx" protrudes to the right).
HP and Pw are aligned with each other. Hunger and encumbrance share a
line. When there are more than three conditions, they're shown three
per line instead of wrapping across lines. And if too many lines are
present, it will squeeze out enough blank ones to fit.
To see the vertical status, you need a display size of at least 106
columns with 'windowborders' explicitly off, or 110 with them on; also
set option 'align_status' to 'right' or 'left'. (With borders on,
including the default 'auto' setting, the vertical status appears at
width of 108 columns, but does so by hiding 2 columns of the map; using
110 columns avoids that.) Resizing from outside the game or changing
align_status via 'O' both cause dynamic reconfiguration of the layout;
there's no need to save, make config changes, then restore.
This adds BL_RESET to status_update to send a flag to a window
port that every field should be updated because something has
happened in the core to make current values shown to be
untrustworthy or potentially obliterated.
That is now distinguished from BL_FLUSH, which now has no
bearing on whether every field needs to be redone, and instead
can be used by a window port indicator that it is time to render
any buffered status field changes to the display.
tty port now sets WC2_FLUSH_STATUS indicator for BL_FLUSH support
and now does one rendering per bot() call, instead of up to 22.
Side note: The tty hitpoint bar code was relying on the old
behavior of redrawing everything upon BL_FLUSH apparently, so it
initially had some color change lag issues, corrected by marking
BL_STATUS as dirty (in need of updating) in tty_status_update()
whenever BL_HP was marked as dirty.
Add threshold relationships <= and >= so that the change to make <
and > perform their expected comparison can be resolved. "Point
release shouldn't force players to update their config files" does
not carry sufficient weight given that they already had to do that
to turn on status highlighting when going from 3.6.0 to 3.6.1. The
3.6.2 release notes can warn them about the need to update their
status highlight options if they're currently using '<' and/or '>'.
Entering new hilite rules via the 'O' command accepted '=' prefix
for numbers, but rules from config files did not. Now they do.
The '=' prefix is optional in both situations.
With 'O', percent rules and absolute rules had separate menu entries
so picking one was already choosing the rule type, but entering a
numeric value without percent sign (for percent) or with one (for
absolute) would change the type on the fly. If someone has already
picked percentage they shouldn't be required to append '%' to the
digits, so that is now optional. If explicitly included with the
number after having picked absolute, the value is rejected. It is
trivial to back up in those menus and choose the alternate type if
someone changes his/her mind part way through.
If a status field has both persistent (percent, absolute, always)
and temporary highlights (up, down, changed), give the temporary one
precedence when the value has changed. To do that with 3.6.1, the
rules for temporary had to follow the ones for persistent highlights
since whichever matched last was the one used. Now their order
relative to each other doesn't matter. If a value increases and
there is both an 'up' rule and a 'changed' rule, the more specific
'up' takes precedence, regardless of their relative order; likewise
for decreases and 'down' vs 'changed'.
There were a couple more tweaks needed to support negative values;
I overlooked the 'O' menu handling before. >-1% and <101% now work
for both the config file and interactive adding via 'O' methods of
defining highlight rules, although new >=0% and <=100% will be
clearer to anyone examining a rule set.
'enum relationship' was forcing LT_VALUE to be -1 but that fact was
never utilized anywhere, and the code was using magic number -2 to
mean "no relationship yet". This adds NO_LTEQGT to replace the
latter and gives it value -1. EQ_VALUE is still 0 so effectively
the default if a highlight hasn't been fully set up yet. LT_VALUE
is now just another positive value along with GT_VALUE, LE_VALUE, &c.
The Guidebook hasn't caught up with the code yet.
The rule choosing code used when deciding how to highlight something
only supports 'int' fields and relies on 'long' having the same bits.
It needs to be extended to support 'long' properly. Fixing should
be straightforward (except maybe for the initialization of min/max
best fit handling) but this doesn't address that. Also, data type
for encumbrance/carrying-capacity should be changed from unsigned to
plain int so that no extra handling for just one field will be needed.
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/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 did my best to exempt some of the bigger aligned blocks from the reformatting
using the /* clang-format off */ and /* clang-format on */ tags. Probably some
that shouldn't have been formatted were anyway; if you encounter them, please
fix.
The clang-format tags were left in on the basis that it's much easier to prune
those out later than to put them back in, and it means that, modulo my custom
version of clang-format, I should be able to run clang-format on the source tree
again without changing anything, now that Pat has fixed the VA_DECL issues.
Pat noted that I neglected to drop the SCCS lines on the files I've been
committing, so clean up those and any others I could find where the SCCS
line date is out of date.
This provides the core support needed for status field highlighting.
This patch doesn't actually perform status field highlighting for any port,
but provides the core hooks for doing so.
The syntax is:
OPTIONS=hilite_status:{fieldname}/{threshold}/{below}/{above}
where {fieldname} is the name of a status field.
{threshold} is the value used as the threshold to trigger a display
change. It can also be set to "updown" to trigger
a display change whenever it rises or whenever it falls.
If you end the threshold value with %, then it signifies
that you want to trigger the display change based on the
percentage of maximum.
{below}, {above}
are the color or display attribute that you want to use when
the field value is underneath the threshold. Supported display
fields are: normal, inverse, bold, black, red, green,
brown, blue, magenta, cyan, gray, orange,
bright-green, yellow, bright-blue, bright-magenta,
bright-cyan, or white.
Valid field names are:
alignment, armor-class, carrying-capacity,
charisma, condition, constitution, dexterity,
dungeon-level, experience-level, experience,
gold, HD, hitpoints-max, hitpoints, hunger,
intelligence, power-max, power, score,
strength, time, title, wisdom
Refer to window.doc for details. Guidebook updates to come later.
It was possible for status_finish to get called twice, therefore free() could end up called twice.
Add a macro symbol for the argument to status_initialize().
Adjust some field widths so that there is a little bit of breathing space.
Introduction of a new set of window port status display
routines. The new routines are conditional on
STATUS_VIA_WINDOWPORT
being defined in config.h. See the experimental section,
where the #define resides for the time being.
