Exercise the previous commit a little.
FIQ's suggested wildcard syntax would make this easier
and a lot less verbose, but that isn't available yet.
This updates (adds some colored walls on specific levels) to the following:
IBMgraphics
IBMgraphics_1
IBMgraphics_2
curses
DECgraphics
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
Recently, a config file complaint when windowcolors was used multiple
times was fixed.
This adds a complaint when windowcolors was specified for the
same type of window multiple times thus superseding a previous
setting.
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 }}};
| ^
read.c:148:13: warning: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Wstring-concatenation]
147 | "Ms. Palm's House of Negotiable Affection--A Very Reputable"
|
| ,
148 | " House Of Disrepute",
| ^
read.c:147:9: note: place parentheses around the string literal to silence warning
147 | "Ms. Palm's House of Negotiable Affection--A Very Reputable"
| ^
1 warning generated.
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)
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.
creates new coloratt.c file
Also, this attempts to fulfill a wish-list item by paxed, to
allow naming colors in symbols file by name as an alternative
to using r-g-b values. The basic color names as well as html
color names are supported.
Take advantage of today's EDITLEVEL bump, and add yet another to
remove some field placeholders left behind in when two fields were moved
elsewhere in 22e52ee9.
When makemon was called with all-zero arguments (e.g. for random
monster generation over time), ptr==NULL means "a random monster".
This was being forwarded to mon==NULL in makemon_rnd_goodpos, and
then mtmp==NULL in goodpos, which means "an object, not a monster".
Because objects can be generated under monsters, this meant that an
attempt to create a random monster could end up choosing a location
that already had a monster, which would then cause the monster
generation to fail.
This mostly wasn't noticeable in normal play: it effectively
reduced the monster generation rate depending on how many locations
outside LOS happened to contain a monster. Normally that's a very
small proportion, so the bug had no obvious effects: but when there
are very few locations outside LOS (i.e. the player can see almost
every location on the level), the bug effectively caused monster
generation to stop once those locations became occupied by
non-moving (e.g. hiding) monsters, something that became observable
in games where the player decided to dig out and light almost an
entire level.
This commit fixes the problem by adding a new flag to goodpos that
requests that it not choose a position that already has a monster.
This bug was diagnosed, and this fix committed, by ais523; but
nhmall wrote almost all of the code implementing the fix.
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.
end.c:177:16: warning: unused parameter 'why' [-Wunused-parameter]
177 | NH_abort(char *why)
| ~~~~~~^~~
end.c: At top level:
end.c:1191:1: warning: 'get_saved_pline' defined but not used [-Wunused-function]
1191 | get_saved_pline(int lineno){
| ^~~~~~~~~~~~~~~
options.c:1263:1: warning: 'optfn_crash_urlmax' defined but not used [-Wunused-function]
1263 | optfn_crash_urlmax(int optidx UNUSED, int req, boolean negated UNUSED, char *opts, char *op)
| ^~~~~~~~~~~~~~~~~~
options.c:1240:1: warning: 'optfn_crash_name' defined but not used [-Wunused-function]
1240 | optfn_crash_name(int optidx UNUSED, int req, boolean negated UNUSED, char *opts, char *op)
| ^~~~~~~~~~~~~~~~
options.c:1217:1: warning: 'optfn_crash_email' defined but not used [-Wunused-function]
1217 | optfn_crash_email(int optidx UNUSED, int req, boolean negated UNUSED, char *opts, char *op)
| ^~~~~~~~~~~~~~~~~
Default to INTERNET_AVAILABLE=Y. If the build computer is not
online with the internet available, an explicit
INTERNET_AVAILABLE=N
will be required for the build, if pdcurses and Lua are not already
staged in the lib folder. That can be done by editing the appropriate line
in the Makefile, or by altering the command line:
nmake INTERNET_AVAILABLE=N install
With Makefile.nmake:
Store pdcurses wingui and pdcurses wincon object files in separate
directories.
Rename the two pdcurses static libraries.
Because of the static library changes, the following will be required
prior to the next build:
nmake spotless
nhmall