A new feature, enabled by default to maximize testing, but one which can
be disabled by commenting it out in config.h
With this, some additional information is added to the glyphmap entries
in a new optional substructure called u with these fields:
ucolor RGB color for use with truecolor terminals/platforms.
A ucolor value of zero means "not set." The actual
rgb value of 0 has the 0x1000000 bit set.
u256coloridx 256 color index value for use with 256 color
terminals, the closest color match to ucolor.
utf8str Custom representation via utf-8 string (can be null).
There is a new symset included in the symbols file, called enhanced1.
Some initial code has been added to parse individual
OPTIONS=glyph:glyphid/R-G-B entries in the config file.
The glyphid can, in theory, either be an individual glyph (G_* glyphid)
for a single glyph, or it can be an existing symbol S_ value
(monster, object, or cmap symbol) to store the custom representation for
all the glyphs that match that symbol.
Examples:
OPTIONS=glyph:G_fountain/U+03A8/0-150-255
(Your platform/terminal font needs to be able to include/display the
character, of course.)
The NetHack core code does parsing and storing the customized
entries, and adding them to the glyphmap data structure.
Any window port can utilize the additional information in the glyphinfo
that is passed to them, once code is added to do so.
Also, consolidate some symbol-related code into symbols.c, and remove it from
files.c and options.c
If messages aren't currently being skipped due to --More--ESC when a
message flagged as urgent is issued and that urgent message itself
triggers --More-- to have the user acknowledge the previous message,
and the user types ESC at this new --More--, message suppression
starts. With the overly simplistic existing code from a few days
ago, it was too late for the current message to override that. Since
the urgent message gets buffered like any other (until another message
needs the top line or until input is needed), it wouldn't be shown
when the next message came along and discovered suppression in effect.
I'm not sure that all the changes here are necessary; there was some
flailing about involved. But it seems to behave as intended now.
Follow up on some old groundwork. For tty, if the core has designated
a message as 'urgent', override any message suppression taking place
because of ESC typed at the --More-- prompt. Right now, "You die"
messages, feedback about having something stolen, feedback for
"amorous demon" interaction (mainly in case of armor removal), and
exploding a bag of holding are treated as urgent.
The "You die" case is already handled by a hack in top-line handling;
I left that in place so the conversion of 3 or 4 pline("You die.*")
to custompline(URGENT_MESSAGE, "You die.*") was redundant. There
are probably various non-You_die messages which precede done() which
should be marked urgent too.
Other interfaces might want to do something similar. And we ought to
implement MSGTYPE=force or MSGTYPE=urgent to allow players to indicate
other messages that they want have to override suppression. But I'm
not intending to work on either of those. I mainly wanted to force
the magic bag explosion message to be shown since a sequence of "You
put <foo> into <bag>." messages is a likely candidate for --More--ESC.
When we save gamestate as part of making an insurance snapshot, we will
save message history which will clear toplines but leaving window state
in tack including the need for more.
When fuzzing, we would increment ttyDisplay->inmore but then prematurely
exit more() leaving ttyDisplay->inmore set.
Under various conditions, we can request to remember the topline when
the topline had not yet been acknowledged leaving toplin state in an
inappropriate state.
Submitted for 3.7.0; all but one also apply to 3.6.3.
I rewrote the curses terminal-too-small message instead of just
fixing the spelling of "minumum".
When we were saving message history as part of a game save for insurance,
we were calling remember_topl() and thus inappropriately changing topline
state. This would cause us to mis-manage the topline in subsequent calls
to update the topline.
The code has been re-worked to fix the issue, reduce complexity and make
the code clearer.
When we save gamestate as part of making an insurance snapshot, we will
save message history which will clear toplines but leaving window state
in tack including the need for more.
When fuzzing, we would increment ttyDisplay->inmore but then prematurely
exit more() leaving ttyDisplay->inmore set.
Under various conditions, we can request to remember the topline when
the topline had not yet been acknowledged leaving toplin state in an
inappropriate state.
Messages on tty which bypass message history weren't handling long
lines properly. If the text wrapped to line 2, that continuation
portion was left on the screen after whatever operation that put it
here was finished. (To reproduce: assign a long name to a monster
with a long type name so that the combined length exceeds the display
width, then move the cursor over it with ';' or '/' while autodescribe
is On.)
This time prompting isn't adversely affected.
This effectively reverts 1ad2415315
because it was interfering with prompts that spanned more than one
line (by inserting '--More-- + erase' between displaying of prompt and
getting input for the answer).
So we're back to the situation where autodescribe feedback when moving
the cursor will leave text on the second line if it generates text too
wide for one line. (^R redraws the screen correctly.)
Messages on tty which bypass message history weren't handling long
lines properly. If the text wrapped to line 2, that continuation
portion was left on the screen after whatever operation that put it
here was finished. (To reproduce: assign a long name to a monster
with a long type name so that the combined length exceeds the display
width, then move the cursor over it with ';' or '/' while autodescribe
is On.)
Noticed while testing the history suppression: if you have DECgraphics
enabled and look at a graphics character on the map, the topline shows
x description of x
where 'x' is displayed as it appears on the map (line drawing char).
^P for msg_window:single knows about that and reproduces the effect if
you recall such a line. But msg_window:full/combination/reverse didn't
know about that and dumped it as-is into text output, ending up with a
strange 8-bit character for 'x' instead of the line drawing one.
I think other rendering schemes will be unaffected by this. It's just
duplicating what is done for msg_window:single.
Extend 'putstr(WIN_MESSAGE, attribute, string)'s attribute so that
'custompline(SUPPRESS_HISTORY, ...)' can work with ^P's message
history like DUMPLOG history, in order to keep autodescribe feedback
and intermediate prompts for multi-digit count ('Count: 12', 'Count:
123') prompts out of recall history. The old autodescribe behavior
could easily push all real messages out of the recall buffer when
moving the cursor around for getpos, and the count behavior looked
silly for a four or five digit gold count if you set the msg_window
option to 'full' or 'combination' and viewed them all at once.
Other interfaces may want to follow suit, but this doesn't force them
to make any changes. I added a hook for "urgent messages" that might
be rendered in bold or red or some such and/or override the use of
ESC at --More-- from suppressing further messages, but there aren't
any custompline(URGENT_MESSAGE, ...) calls (potentially "You die...",
for instance) to exercise it. Other people have implemented similar
feature it different ways and I'm not sure whether this one is really
the way to go since the core needs to categorize each message that it
deems to be urgent. MSG_TYPE:stop may be sufficent, although MSG_TYPE
matching can entail a lot of regexp execution overhead at run-time.
