Issue reported by Shrigis1: the tile for Ixoth depicts a demon that
resembles Nalzok but it ought to be a red dragon.
The issue entry included a binary tile attachment. Rather than try
to deal with that, I've cloned red dragon and included the old tile's
eyes. The issue describes them as green but they look gray to me.
(Ordinary red dragon has white eyes.)
3.4.3 had same issue. I don't remember whether Ixoth was originally
a demon but his tile seems to have always shown one.
Fixes#1239
It was too early to call the windowport change_color() routine
while processing the config file. The windowport was not yet
fully operational.
Now the palette option processing will just place the rgb
value into the appropriate ga.altpalette[CLR_MAX] entry.
init_sound_disp_gamewindows(void) [allmain.c] calls
change_palette() [coloratt.c] and it will call the windowport
change_color() function for each ga.altpalette[] entry that
has been set.
Notes:
The rgb values stored in ga.altpalette[] have the NH_ALTPALETTE bit set
so that the rgb value of 0 can be stored and be distinguishable from
a "not set" entry.
The NH_ALTPALETTE bit is cleared from the rgb value in change_palette()
prior to calling the windowport change_color() function.
The syntax for palette is colorname/r-g-b.
For example: palette:black/12-12-12
colorname must be one of the NH_BASIC_COLOR names or a suitable
alias for one of those 16 entries.
Some of the windowport CHANGE_COLOR functions had the wrong parameters,
perhaps due to bitrot. Those have been corrected to match the prototype.
For tty, make hitpointbar blink if current HP falls to the critical
HP threshold. Doesn't require status highlighting. Not changed:
when status highlighting is active, use the HP color but force the
attribute to be inverse (plus blink if the criterium is met) rather
than whatever the HP highlight specifies.
For curses, do the same thing. It used to honor HP attribute for
hitpointbar, now it behaves the same as tty: always inverse, maybe
combined with blink. The new code assumes that inverse and color
can be turned off without turning off active blink in the process.
I had intended to make hitpointbar be a full-fledged status field
(which happens to be rendered on top of title) so that it could be
highlighted differently from hit points (mainly so that one could
highlight up and down changes while the other showed percentages).
This is less versatile than that but much simpler.
The curses colorpair rework I did changed the pile hilite background
color from blue to red. Change it back to blue, and use a function
to get the color pair instead of hardcoding the value.
Use vi (cursor_invisible) and ve (cursor_normal) to hide and show
cursor, if the terminal supports those. This way on a slower
connection the cursor doesn't jump all over the place when doing
map or menu updates.
Unresolved display issues with rxvt-unicode after the optimizations
dealing with switching between DECgraphics line-drawing character set
and normal character set.
Effectively comment them out rather than revert the commits.
move the custom color data into its own field in the glyphmap
and disassociate it from the unicode/utf8 stuff.
move the glyphcache stuff during options processing and parsing
into new file glyphs.c and out of utf8map.c, and make it
general, and not part of ENHANCED_SYMBOLS.
Do the groundwork for allowing glyph color customizations to
work when any symset is loaded and not restrict it only to
the enhanced1 H_UTF8 symsets.
The customizations in effect are still affiliated with a particular
symset.
Also closes#1224, but the PR itself references a data structure
made obsolete by this commit. The curses comment from the PR was
added into the code.
The PR also made several suggestions, but only the first
one has been included in this commit (and no longer based on
the handler), that being:
"allow defining colors if other symbol handling modes are used
(possibly limited to the standard 16 colors)."
FredrIQ also wrote the following suggestions in PR#1224:
Something I was also contemplating, unrelated to implementation of this
support in curses, would be the ability for the following:
allow defining colors if other symbol handling modes are used (possibly limited to the standard 16 colors)
allow defining attributes (for example: glyph:G_pet_female_kitten:U+0066/red/underline)
allow specifying glyphs as wildcards for defining global color/attribute changes
Something I also want to see are keywords for "don't change the current defined data". If this
were to be added, you could for example do this:
OPTIONS=glyph:G_*_fox:U+0064/blue
OPTIONS=glyph:G_statue_*:basechar/gray/underline
for "make all foxes use a blue color, make all statues gray with underline" without needing
to specify the relevant character for every statue. This ("basechar", "basefg", etc)
should perhaps also be added for MENUCOLORS and statushilites, so that you can, for
example, underline all items being worn without needing to specify a bunch of
near-duplicate rules for combining BUC colors + underline worn items
as per #1064
Make sure the windowcolors option can be specified more than
once without a config file warning.
Make the struct holding the details a little more extendable.
Curses handles menu and text windows specially; their id numbers
keep going up, so we need to check if the id is for a menu or
text window instead of directly accessing the windows array.
When removing a temporary (menu, text, popup) window, the code
was erasing it from memory and then refreshing the screen.
This is unnecessary, as we're refreshing all the windows anyway.
The map frame (background) colors were all over the place; the
code should be much cleaner now, and still work exactly the same
as before.
I tested this with terminals with 8, 16, and 256 COLORS.
The curses message window shows new messages bold, and removes the
bolding from older ones. The code was calling curses mvwchgat with
attribute and color parameters in the wrong order. Also change the
code to actually retain the color of the window, so it just removes
the bold attribute.
new .h files: hacklib.h selvar.h stairs.h
new .c files: calendar.c, getpos.c, report.c, selvar.c, stairs.c,
strutil.c, wizcmds.c
cleanup of hacklib.c and mdlib.c
hacklib contains functions that do not have to link with the core
relocate wiz commands from cmd.c to wizcmds.c
relocate CRASHREPORT stuff to report.c
relocate getpos stuff from do_name.c to getpos.c
remove temporary struct definition from extern.h
cross-compile PRE-section split into cross-pre1.370 and cross-pre2.370
Windows sys/windows/Makefile.nmake and sys/windows/Makefile.mingw32 and
visual studio project file updates
Unix sys/unix/Makefile.src, sys/unix/Makefile.utl
populate selvar.c and selvar.h
build on MS-DOS (not cross-compile) Makefile updates
for sys/msdos/Makefile.GCC (untested)
vms updates for above (untested)
This fixes a lot of problems where a menu or a text window was up
and the main window accepted input - for example you could move around,
making another window of the same type pop up ...
The 0x1000000 bit (NH_BASIC_COLOR bit) was used to mark
CLR_BLACK when storing it in u->ucolor. Now, all of the basic CLR_*
colors are stored that way.
The NH_BASIC_COLOR bit indicates that the value in u->ucolor is
not an rgb value, rather it is one of the 0-15 basic NetHack colors.
The window-ports need to strip the NH_BASIC_COLOR bit off before using
it for color changes.
The wishy-washy warning for case BL_VERS was "may fall through" when
it always fell through, and there was no mention of the fact that the
assignment had no effect because it was immediately overwritten by
similar assignment for the fall through cases.
It may have 'spacing = 2' rather than 1 at some point, but since that
field is right justified it wouldn't make any difference.
Add options 'showvers' (boolean) and 'versinfo' (numeric mask) to
show nethack's version on the status lines during play. It won't be
particularly interesting to ordinary players but should be useful
when making screenshots or video to be streamed, or for someone who
switches between git branches or between nethack and variants.
I worked on this several months back but it was combined with
unfinished changes to 'hitpointbar'. I've separated it out so that
it can be put into use. When enabled, one or more components of
"<name> <branch> <version>" will be shown right justified after
status conditions. At present the default is "<branch>" if that is
available and overall status isn't 'released', or "<version>" if
'released' or if branch isn't available. That might need some
refinement.
It works as intended for tty and curses, although some abbreviation
mechanism would be useful if/when the program resorts to abbreviating
status conditions to make things narrow enough to fit.
For X11, it works ok for fancy_status:True (the default, controlled
via NetHack.ad settings) but is messed up for tty-style status. The
text is positioned correctly but there are gaps in it, making it
appear garbled, similar to what I saw when I tried and failed to
implement statuslines:3 for X11. [It might be due to having empty
condition widgets be 1 pixel wide instead of being totally removed
but I don't think the situation is that simple.]
For Qt, if the text needs to be truncated in order to fit, the center
portion of the string will be shown, discarding parts from the left
and right. That ought to discard from left and retain rightmost
portion instead.
For win32|mswin|Win GUI, no attempt to support it has been included.
Things should be ok when 'showvers' is left as False (the default)
but I don't know what will happen if that gets toggled to True. At a
minimum, the version info won't be right justified. The information,
or at least some of it, is displayed in the game window's title bar
so there isn't any pressing need to add it to status, but toggling
the option will need to behave sensibly if it doesn't already.
The menus in nethackw.exe were being spaced according to the vertical
tile size of custom tiles, but the tiles were being rendered in menus
at the default size anyway, resulting in unnecessary gaps between menu
rows.
Use the default size of 16 for the vertical spacing calculation.
DUMPLOG requests the DUMPLOG feature as it does now
DUMPLOG_CORE requests the internal buffering only (used for CRASHREPORT)
This allows CRASHREPORT to access recent messages without performing
any file I/O.
