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.
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.
ensure BL_FLUSH always gets sent down to the window port whenever bot() is
called with context.botlx set so that status updates work as
expected after full screen clear after a level change
Fixes#107
Handle suppression of 'score' from the 'O' menu for viewing and
setting hilite_status rules differently so that the count of the
number of rules will always match the number of rules shown by the
'a - View all hilites in config format' choice. If there are score
rules in the config file for a game running under !SCORE_ON_BOTL
configuration, list 'score' normally but if player picks that menu
entry, the followup menu will have the existing rule(s) and 'X -
remove selected hilites' but not 'Z - Add a new hilite'. If there
aren't any score rules--or there were some but they've now all been
'X'd--then 'score' won't be listed as one of the status fields.
When built without support for SCORE_ON_BOTL (the default), suppress
'score' field from 'O' menus for adding/removing hilite_status rules.
Also, add "encumbrance" as field name synonym for "carrying-capacity"
and "experience-points" for "experience". Relevant for rules set in
config file or via NETHACKOPTIONS.
The formatted value for attributes of condition highlights was
reporting 'normal' (aka no attributes) even when the highlight
rule specified some other value. It initialized a bitmap variable
to ATR_NONE, which is not 0, and then or'd other bits to that.
Then during formatting it checked whether the ATR_NONE bit was set
and returned 'normal' without examining the other bits. Actual
highlighting wasn't affected, just the strings in the rule set
shown by the 'O' command.
This is a separate issue from the earlier 'bonus fix' where the
attributes of previous condition rules got clobbered if a
hilite_status:condition/any-color&normal rule was added.
Take a step towards eliminating merging hilite_status rules during
highlighting by creating a single rule instead of multiple ones
when specifying multiple attributes for the same highlight via the
'O' command's menus.
Old:
(pick_one menu to pick a color) + (pick_one menu to pick an attribute)
| hilite_status:title/always/red&bold
(pick_one menu to pick a color) + (pick_one menu to pick an attribute)
| hilite_status:title/always/red&blink
New:
(pick_one menu to pick a color) + (pick_any menu to pick attributes)
| hilite_status:title/always/red&bold+blink
At present, rule selection during highlighting still merges multiple
applicable rules instead of finding the best one first, with the
problems that entails.
Bonus fix: a hilite_status rule for status conditions which specified
"no attributes" would clear attributes for all previous condition
rules rather than just the one(s) in that "no attributes" rule.
While deciding which highlights to apply, give 'percentage' and/or
'absolute' rules that match precedence over 'always' rules regardless
of order within the config settings.
When using 'O' to add 'up/down/changed' rule, don't include 'down'
as a choice for field 'time'.
When using 'O' to add rules, don't squeeze out spaces if adding a
'textmatch' rule for title (to support "field worker", "high priest",
"student of stones", and so forth).
While deciding which highlights to apply, ignore double quotes when
testing whether a 'textmatch' rule matches the current text of a
field. This allows rules to specify string values as '"value"'
instead of just 'value'. It not does validate them to ensure quotes
are paired at beginning and end, it just ignores them. New rules
created via 'O' for rank title include them when displaying what the
new rule would look like as a config file option. Other text fields
haven't been changed to show quotes but ignoring such applies to all
'textmatch' comparisons.
Expand the menu for adding 'textmatch' rules for title. When a rank
has separate male and female titles, list three entries instead of
just one
"male rank"
"female rank"
"male rank" or "female rank"
(the order of the first two entries and of the two titles in the
third entry is reversed if the current character is female). If the
user picks the third entry, two rules are added instead of just one,
identical to each other except for the text to match.
Further expand that menu with
"none of the above (polymorphed)"
at the end. When deciding which highlights to apply, "none of the
above" and "(polymorphed)" and the full string are treated as
equivalent (with spaces, quotes, and parentheses ignored). Rather
than comparing anything against the title text, it matches if the
hero is polymorphed (where title will be "<hero> the <monster-type>"
instead of "<hero> the <rank>"). Note that the user can have config
file 'textmatch' rules for title to match specific "<monster-type>"
values but the 'O' menu doesn't offer any opportunity for that.
(I've just realized that rules for specific monster types should be
given precedence over "none of the above" but at present that isn't
done; the order of the rules will determine which wins out.)
Simplify the string comparison done when checking 'textmatch' rules
to decide whether to highlight something.
Fix the menu titles when setting up a textmatch via 'O': the title
for color referred to attribute and the one for attribute used the
default. The two tiles are set up in advance; the one for color was
set correctly but then the one for attribute was written into the
wrong buffer.
When using 'O' to manipulate hilite_status rules, if there are any
when you're done and the 'statushilites' option (iflags.hilite_delta)
is 0, give a message reminding that it needs to be non-zero for
highlighting to be activated.
The fact that the index to the array of hunger strings is an unsigned
field in 'struct you' is unimportant as far as its usage for status
highlighting. Since it is the only ANY_UINT field, change BL_HUNGER
to plain 'int' so that there'll be no need for ANY_UINT handling.
And some more validation when setting up highlight rules. For 'O',
in the menu to choose a relationship after supplying a number N,
don't include "less than N" and "N or less" for percentage or
absolute--other than AC--unless N is greater than 0, and don't
include "N or more" and "more than N" for percentage unless N < 100.
Also, when 'O' prompted for a number, if you entered <X or =X (for X
not a sequence of digits), it remembered the '<' or '=' (or '>=', &c)
when reprompting for a valid number. If the 'X' portion is invalid,
discard the relationship operator before asking for another number.
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.
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.
