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.
I enabled 'extmenu' and went through all the extended commands under
curses and try to find out what github issue #1229 refers to and
didn't spot anything out of the ordinary, except for #wizmondiff
which reported that the calculated diffculty ratings for ice devil
and barbed devil didn't match the values in their definitions. They
were each given an extra ability about 6 months ago and it was enough
to have a higher rating.
Issue #1239 remains open.
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.
A couple of predicates in sym.h didn't cover all the relevant map
symbols.
is_cmap_stairs() only affects the MS-DOS position-bar. It appears
that it would have been overlooking the extra stairs to the mines
and to sokoban but I have no way to verify that.
is_cmap_lava() affects getpos() and #lookaround. lava-wall wasn't
being treated as lava.
In 3.6.2 parts of the wakeup code were merged together, and this
caused pets consider any noise made by the hero - such as hitting
iron bars or digging - as whistling for them to come to the hero.
Change it to only consider actual whistling and ringing a bell.
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.
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
Inspired by self-recover, sort of. Enabled for unix by default; can
be disabled by commenting out '#define CHECK_PANIC_SAVE' in unixconf.h.
When starting the game, if there is no save file to restore and no
lock/level files to recover, check whether a panic save file exists.
If there is one, tell the player that it's there and that it might be
viable, then ask whether to start a new game.
It doesn't convert the panic save into a reconverable one (rename by
nethack, then continue trying to restore) or tell the player how to
make it viable (rename to remove ".e" by game admin), just whether it
is present. If player opts to start a new game, the panic save is
left alone and will trigger the "there's a panic save file" situation
again once the new game finishes and player starts another.
The new change to reset discoveries and monster-stats when exiting
the tutorial used dynamic data which wouldn't be freed if player
used #quit and declined to resume the regular game.
It turns out that such a leak was already present for start-of-game
inventory that gets stashed away during the tutorial.
In both cases, it could happen at most once per game so wasn't a big
deal as far as memory leaks go.
When bulk reformatting took place prior to 3.6.0, the
\#if 0 "Palandir of Westernesse" #endif
block was left as-is, making it different from all the ones that
changed. Reformat it manually, a shorten a couple of wide lines.
When processing
|OPTIONS=windowcolors:window-type foreground-color/background-color
parse the color values and use their names rather than the player's
raw options text. Affects the feedback from 'm O' and is essential
for the next feature.
Accept either "gray" or "grey" where colortable[] always uses "gray"
(half a dozen or so instances), and accept dash or underscore where
colortable[] always uses dash (many instances).
Also, complain about 'window-type' if it isn't recognized as one of
menu, message, status, or text. [For curses, the complaint gets
written to stdout and is then immediately erased as it goes into full
screen mode. That's a general problem, not specific to this option.]
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.
symbols.c:429:7: warning: integer constant not in range of enumerated type 'enum symparse_range' [-Wassign-enum]
429 | { 0, 0, (const char *) 0 } /* fence post */
| ^
windows.c:1765:32: warning: integer constant not in range of enumerated type 'enum from_core_requests' [-Wassign-enum]
1765 | { 0, 0, { NO_COLOR, ATR_NONE }}};
| ^
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)
