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.
Take care of a minor 'TODO' and make another stab at getting truncated
encumbrance and/or level-description to reset to full size when enough
space becomes available.
Put the prototypes for routines in botl.c into the same order as the
corresponding functions are in the file. Also a few were missing and
another few used STATIC_OVL when STATIC_DCL was appropriate.
When the 'time' option is on and context.botl isn't already set,
call a simpler status update routine that ignores all other fields.
When that flag is already set, full status update takes care of time
along with the other fields.
Expected to reduce bottom lines processing time but not screen I/O.
Only lightly tested.
I finally figured out why status gets updated periodically even if
none of the fields have changed. Once a temporary highlight times
out, it starts a cycle of timeouts every 'statushilites' turns. When
I worked on this before, it was convoluted but not this convoluted.
In moveloop, if 'context.botl' call bot; in bot
call evaluate_and_notify_windowport;
for each field, call evaluate_and_notify_windowport_field:
call hilite_reset_needed and set 'reset' to the result;
if 'reset' is True then do status_update
and set 'curr->chg' and 'prev->chg' to True.
Then in moveloop call status_eval_next_unhilite:
for each field
if 'curr->chg' set 'curr->time' to moves+hilite_delta;
on the call after hilite_delta ('statushilites') moves,
call hilite_reset_needed which returns True if there is any
rule for temporary highlight and set 'context.botl'.
Go back to start. If multiple fields had temporary timeouts and
they were activated on different turns so expired on different turns
you could conceivably end up with context.botl being set every turn.
My first writeup trying to explain all this was wrong. I won't
testify about the accuracy of this one in court....
This extends the highlighting data structure to track the current
rule that's in use. And for that to make sense, it eliminates the
merging of settings from multiple matching rules. So anybody with
hit-points/up/inverse
hit-points/up/green
hit-points/up/bold
will need to manually merge their rules like
hit-points/up/green&inverse+bold
or else whichever rule matches last will be the only one in effect.
There are a lot of miscellaneous changes made as I flailed about.
The three most significant ones are that there is no guesswork over
what kind of highlight rule is in effect, status_eval_next_unhilite
will only set a timeout value if the current rule is for a temporary
highlight, and hilite_reset_needed will only return True if a timeout
is for a temporary highlight (probably moot after the _next_unhilite
change).
Status formatting used to truncate the Name portion of "Name the Rank"
or "Name the Monster-type" at 10 characters even if the rank or monster
portion left room for more. Change that to keep as much of the name as
will fit. The truncation might vary over time as new experience levels
produce new rank titles of differing lengths, but I don't think that's
a problem. For truncated names, it still keeps at least 10 characters
even if that leaves the field longer than the target length for title
(which used to be 29 but now is 30).
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.
It took me a while to track this down: if you use 'O' to create
hilite_status rule(s) for status condition(s) and you specify multiple
attributes in the rule creation menu, it accepts them but it was
parsing the new rule(s) incorrectly and only supported one attribute.
if (mask & bit)
something;
else if (mask & other_bit)
something_else;
else if (mask & yet_another_bit) ...
effectively stops at the first bit matched. (At the time that that
was written, the menu leading to it only accepted a single attribute.)
Change the generic status line location "End Game" to relevant element
name "Earth", "Air", &c. ("Plane of <element>" might be too long if
hungry and encumbered and afflicted by conditions. "Astral Plane" is
already specific so not affected.)
Symset:Blank sets all the map symbols (except STRANGE_OBJECT) to
<space>. The status lines for !STATUS_HILITES force status to use '$'
instead of ' ' for the prefix before ":1234" for gold, but the status
lines for STATUS_HILITES did not. tty ended up with ":1234" for gold.
win32 and curses both ignore the prefix and construct their own, but
since win32 uses the map symbol for that it must also be ending up
with ":1234" (I assume; I haven't seen it). curses is forcing '$' for
the prefix, even on the rogue level.
This attempts to fix win32 without be able to test the result. I've
left curses alone.
Stop pretending that long and int are the same size when picking status
highlight rule for gold or time or experience-points.
Also, K&R compilation might lack <limits.h>, so let XXXconf.h define the
necessary macro(s) (currently just LONG_MAX) so that it can be skipped.
With options along the line of
OPTIONS=statushilites:4
HILITE_STATUS=gold/always/yellow
gold started out unhighlighted (unhighlit?). I didn't try to figure
out why, just changed things to force a full status update when gold
requires internal changes (different \G encoding or different glyph)
which is something that happens when session first enters moveloop().
Clean up quite a bit of minor things found with simple grep patterns:
operator at end of continued line instead of beginning of continuation
(and a few comments which produced false matches, so that they won't
do so next time), trailing spaces (only one or two of those), tabs (a
dozen or so of those), several casts which didn't have a space between
the type and the expression (I wasn't systematic about finding these).
I think the only code change was in the function for the help command.
a stale gold symbol could be displayed on the status line following a switch
to a new symset, as observed and reported for Windows RogueEpyx symset.
An update is required for gold in the status line for a change to
any of the following:
context.rndencode value
the encoded glyph value for COIN_CLASS
the gold amount
Set X resource NetHack*fancy_status: False to enable the TTY-style
status lines. Default is the fancy status.
This patch is somewhat unfinished - even though the TTY-style status
allow for status hilites, the colors don't work correctly yet.
Also changes the fancy status to use the windowport notification code.
Remove trailing spaces, and remove tabs from the files that had
trailing spaces.
Also, rndorcname() was using a random value to terminate a loop
and was recalculating a new one each iteration.
Like BL_FLUSH, only send BL_RESET if the window port has
indicated it wants them via setting the appropriate WC2
bits in its window_procs structure. Update documentation.
The temporary highlight types 'goes-up' and 'goes-down' aren't useful
for the three string status fields (title, dungeon-level, alignment)
since the string values might go up when the underlying value goes up
or might go down instead (and similarly for down, down, up). The code
involved can compare strings but the values are effectively arbitrary
so the comparison is only really useful for same vs changed. This
treats types 'up' and 'down' for strings as 'changed' when coming from
config file and no longer offers them as choices when using 'O'.
Config file parsing perhaps ought to treat them as errors instead.
