Add 'tethered' and 'holding' as displable status conditions for X11.
For tty-style status, they're ordinary. For 'fancy status', tethered
is displayed in the 'trapped' slot (since they'll never both be shown
at the same time) and holding is displayed in the 'held' slot (same
situation).
It's more proof of concept for overloading of status conditions than
adding useful specific conditions. This was the third iteration; the
first two were either too fragile or used even more code. It could
probably be simplified by making some mutally exclusive conditions be
more like hunger and encumbrance instead of being distinct flags
X11's "fancy status" does its own highlighting that predates
STATUS_HILITES, showing things which have changed in inverse video
for a turn. However, it excluded conditions plus hunger and
encumbrance. Make it highlight those similarly when they come On
(and when they change from one non-blank state to another in the
case of hunger or encumbrance). There's no corresponding
unhighlight when going Off because they're blanked out instead.
I started out adding a few new status conditions to X11's "fancy status"
(the default) to gauge how difficult it was going to be. In the process
I found several latent bugs. After fixing those, I decided that the same
status conditions should be added to the alternate "tty-style status".
Lots more latent bugs, some of the same nature, others different. Things
spiraled until the code change is very substantial.
Code for the old two-line status is still present but I don't know how
to activate it. Unlike tty-style status, it composes and displays two
lines of text and isn't capable of highlighting portions of that text,
so it would be considered deprecated anyway.
All testing was done with the default NetHack.ad (except when turning
'fancy_status' off) so I don't know whether the new code might override
previously customizable status settings. I'm not sure whether this list
covers all the fixes....
both tty-style and fancy
add new status conditions 'grabbed' (by eel), 'held', 'trapped', and
'sinking-into-lava' (others will eventually follow); grab and lava
are on by default, the others have to be enabled via options
both tty-style (not handled) and fancy (faulty boolean logic)
polymorphing didn't change Xp to HD (silver lining: rehumanizing
didn't need to reverse it)
tty-style only; fancy was ok
force white text (on black background) instead of settling for gray
turning on optional showexp, showscore, and/or time worked but turning
them back off again didn't remove the relevant fields
polymorphing when showexp was on didn't suppress Exp-points
tty-style only; fancy uses different layout
condense conditions into simple left-to-right space separated list
instead of giving them specific locations and having gaps of blank
space for conditions that aren't in effect
tty-style only; not applicable for fancy (status_hilites not implemented)
all highlights stuck if 'statushilites' was reset to 0 to disable them
displaying anything with bold attribute stuck; it wouldn't revert to
normal text if a different highlight rule without bold was used for
subsequent updates
avoid inverting leading space that separates from preceding field when
highlighting with inverse video attribute
add support for 'dim' attribute using gray foreground (only viable
after the fix for white foreground)
fancy only
reorganize the field layout so that things line up nicely instead of
having columns with six, seven, or eight lines be spread over same
amount of vertical space
line up the values of the six characteristics, similar to how vertical
status works in curses: all two digits; when exceptional strength is
present, the '18' lines up and rest goes past implicit right margin
use status conditions as provided by core instead of duplicating them
(other fields still duplicate stuff done in botl.c); doing this
required forcing 'VIA_WINDOWPORT()' if built without STATUS_HILITES
Separate out the reformatting from other changes I'm working on
for X11 "fancy status". Splits a few wide lines but mostly just
switches to the X11 idiom of combining
XSetArg(arglist[argcount], ...);
argcount++;
onto one line:
XSetArg(arglist[argcount], ...); argcount++;
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.
Update X11's status display to include the expanded set of status
conditions. This time the order is
Petrifying <hunger> Blind
Slimed <encumbrance> Deaf
Strangled Levitating Stunned
Food Pois Flying Confused
Term Ill Riding Hallucinating
with the application defaults file specifying red text for the first
column and black for the other two. Previously it was all one column
with seven entries. [Slimed was missing along with the six new ones
(deaf, stone, strngl, lev, fly, ride) and both types of sickness were
shown as 'FoodPois' or 'Ill' or 'FoodPois Ill' on one line.]
So now basic bot2, #if STATUS_VIA_WINDOWPORT genl_status_update, and
#if !STATUS_VIA_WINDOWPORT X11 fancy status have three different
orderings. genl_status_update has hunger and encumbrance first
because all the other status conditions are grouped together as one
bitmask item. bot2 has 'lev', 'fly', 'ride' last so that they're
the first things to be sacrificed if the string of status conditions
ends up being truncated. (genl_status_update also has those last.)
In addition to updating status conditions, I reordered the Hp, Pw, &c
section too so that it's closer to tty in organization.
Hit points Maximum HP
Power Maximum Power
Armor Class Alignment
Exp.Level Exp.Points (if 'showexp')
Gold Moves (if 'time')
Score (if 'showscore')
I didn't have SCORE_OR_BOTL set so haven't seen the last one, but
it's in the same position as it was before.
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!
Suppress close to 400 warnings generated by gcc on the win/X11/*.c code,
most due to -Wwrite-strings which makes string literals implicitly have
the 'const' attribute. (Since modifying a string literal results in
undefined behavior, that is an appropriate check to have enabled, but
it can be troublesome since string literals have type 'char *' and code
that uses them that way is correct provided it avoids modifying them.)
113 warning: initialization discards qualifiers from pointer target type
127 warning: assignment discards qualifiers from pointer target type
29 warning: passing argument discards qualifiers from pointer target type
109 warning: unused parameter
12 warning: comparison between signed and unsigned
The nhStr() hack casts to 'char *', explicitly removing 'const', for
situations where it isn't feasible to make code directly honor const.
The vast marjority of uses are for the second parameter to XtSetArg(),
which is a macro that actually performs an assignment with the second
argument rather than passing it in a function. It takes values like
'XtNtop', which doesn't need to be altered (although in many places I
changed that to nhStr(XtNtop) for uniformity with the surrounding code,
and 'XtNbottom', which does need to have the extra const stripping to
avoid a warning. Go figure.
The nhUse() hack actually uses its argument in a meaningless way if the
code is compiled with FORCE_ARG_USAGE defined. When GCC_WARN is defined,
FORCE_ARG_USAGE will be enabled if it hasn't been already. Example:
/*ARGUSED*/
int foo(arg)
int arg; /* not used */
{
+ nhUse(arg);
return 0;
}
The extra line will expand to ';' when FORCE_ARG_USAGE is not defined
or too
nhUse_dummy += (unsigned)arg;
when it is. I figured direct assignment might lead to a different
warning by some compilers in a situation like
nhUse(arg);
nhUse(otherarg);
where the first assignment would be clobbered by the second, and using
bitwise operations or safer '+= (arg != 0)' would most likely generate
more non-useful code. Some tweaking might turn out to be necessary.
