The g? structs had a mix of variables that were written to
the savefile, and those that were not.
For better clarity and to distinguish those that end up in
the savefile, relocate some g? variables that get written
directly to the savefile into different structs.
This updates EDITLEVEL, although technically it probably
didn't need to, since savefile contents are not changing.
Details:
gb.bases -> svb.bases
gb.bbubbles -> svb.bbubbles
gb.branches -> svb.branches
gc.context -> svc.context
gd.disco -> svd.disco
gd.dndest -> svd.dndest
gd.doors -> svd.doors
gd.doors_alloc -> svd.doors_alloc
gd.dungeon_topology -> svd.dungeon_topology
gd.dungeons -> svd.dungeons
ge.exclusion_zones -> sve.exclusion_zones
gh.hackpid -> svh.hackpid
gi.inv_pos -> svi.inv_pos
gk.killer -> svk.killer
gl.lastseentyp -> svl.lastseentyp
gl.level -> svl.level
gl.level_info -> svl.level_info
gm.mapseenchn -> svm.mapseenchn
gm.moves -> svm.moves
gm.mvitals -> svm.mvitals
gn.n_dgns -> svn.n_dgns
gn.n_regions -> svn.n_regions
gn.nroom -> svn.nroom
go.oracle_cnt -> svo.oracle_cnt
gp.pl_character -> svp.pl_character
gp.pl_fruit -> svp.pl_fruit
gp.plname -> svp.plname
gp.program_state -> svp.program_state
gq.quest_status -> svq.quest_status
gr.rooms -> svr.rooms
gs.sp_levchn -> svs.sp_levchn
gs.spl_book -> svs.spl_book
gt.timer_id -> svt.timer_id
gt.tune -> svt.tune
gu.updest -> svu.updest
gx.xmax -> svx.xmax
gx.xmin -> svx.xmin
gy.ymax -> svy.ymax
gy.ymin -> svy.ymin
Related note:
There are some pointer variables that are heads of chains that were not
moved from 'g?' to 'sv?', because they are not actually written to the
savefile directly, but the objects/monst/trap/lightsource/timer in the
chains they point to are. That can be changed, if desired.
Examples: gi.invent, gm.migrating_objs, gb.billobjs, gm.migrating_mons,
gf.ftrap, gl.light_base, gt.timer_base
Reason: The following concern was raised:
"The trademark indicators were not out of sync. The Guidebook
uses footnotes for that, 'history' uses "(tm)" in the text which
works better when nethack displays the text."
@Umbire wrote:
Very simple change code-wise - if he's gonna use a yumi a hunter of his expertise should presumably have the projectiles match.
Closes#1213.
This may be useful for some build environments to avoid parallel make
issues, and artificially-concocted order dependencies, leaving the ordering
up to that specified in the Makefile.
The related makedefs options are now:
‐s Generate the bogusmon , engrave and epitaph files.
‐1 Generate the epitaph file.
‐2 Generate the engrave file.
‐3 Generate the bogusmon file.
Also resolves an existing issue encountered in doc/makedefs.6 where "and epitaphfiles"
was being produced in the result.
One to link with the stuff that needs to be built and executed on
the build host during the build, such as makedefs.
One to link with the stuff that will run on the target platform.
consoletty.o : error LNK2005: _tty_change_color already defined in wintty.o
consoletty.o : error LNK2005: _tty_get_color_string already defined in wintty.o
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.
Take advantage of the ability of some compilers to warn if
not all values are covered in a switch statement, to draw
attention to the need to update make_corpse() when new
monsters are added to NetHack.
This adds explicit entries for the current "default" handling
in make_corpse().
It might be a good idea to review the explicit entries to see
if any of them represent others that are not being handled,
but should be.
To test this, I temporarily reverted 85c86444, and I did receive the
following warning:
mon.c:545:13: warning: enumeration value 'PM_GOLD_DRAGON' not handled in switch [-Wswitch]
545 | switch (mndx) {
| ^~~~
1 warning generated.
wizcmds.c: In function 'wiz_custom':
wizcmds.c:1845:40: warning: format '%d' expects argument of type 'int', but argument 4 has type 'uint32_t' {aka 'long unsigned int'} [-Wformat=]
1845 | Sprintf(bufa, "%s: colorcount=%d %s", wizcustom, iflags.colorcount,
| ~^ ~~~~~~~~~~~~~~~~~
| | |
| int uint32_t {aka long unsigned int}
| %ld
wizcmds.c: In function 'wizcustom_callback':
wizcmds.c:1895:32: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'uint32' {aka 'long unsigned int'} [-Wformat=]
1895 | Sprintf(bufc, "%011x", cgm->customcolor);
| ~~~~^ ~~~~~~~~~~~~~~~~
| | |
| | uint32 {aka long unsigned int}
| unsigned int
| %011lx
wizcmds.c:1899:37: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'uint32' {aka 'long unsigned int'} [-Wformat=]
1899 | Sprintf(bufu, "U+%04x", cgm->u->utf32ch);
| ~~~^ ~~~~~~~~~~~~~~~
| | |
| | uint32 {aka long unsigned int}
| unsigned int
| %04lx
Program terminated with signal SIGSEGV, Segmentation fault.
77 ../sysdeps/x86_64/multiarch/strlen-evex.S: No such file or directory.
(gdb) bt
at glyphs.c:419
at glyphs.c:173
op=0x5a34af30a574 "DECgraphics") at options.c:3418
early_init() calls decl_globals_init() which zeros out
a number structures:
ZERO(flags);
ZERO(iflags);
ZERO(a11y);
ZERO(disp);
ZERO(u);
ZERO(ubirthday);
ZERO(urealtime);
Setting values in any of those during startup prior to
the early_init() call was futile, and the values would
get overwritten.
Such was the case with the setting of iflags.colorcount
during Windows startup, so do it after early_init() has
been called.
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
nhmall