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
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.
Support aiming at self (to become blinded) and aiming up/down (to
light the hero's current map spot only, persistently rather than
temporarily). Also, recognize cancel at the "direction?" prompt to
not leave the #invoke cooldown count set when aborted.
Aiming at self was a little trickier than expected to test because
you're blindness-resistant when wielding Sunsword. But it doesn't
have to be wielded to be invoked.
The code doesn't handle zapping blinding ray at yourself;
maybe it should be changed to handle it, but for now just
prevent Sunsword blinding the hero.
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
This doesn't directly affect nethack, but it should prevent HTML
dumplog for variants that include that from showing T-shirt and
apron slogan text in tooltips for the 'gameover' map. And it makes
end-of-game attribute disclosure slightly less susceptible to being
unintentionally reverted.
Code in pull request #300 shows that it uses do_screen_description()
for tooltips and do_screen_description() uses distant_name() for
objects so that's where I added this change that will trigger the
code from commit c6992777f5.
From a reddit thread: after genociding "arch-lich", player's next
target was "master-lich". The character was a monk who immediately
died of genocide.
("Master<almost anything>" other than "master mind[ ]flayer" or
"Master Thief" or "Master Assassin" matches level 30 monk rank "Master".)
Rather than muck about with fairly complicated matching code, just add
"master-lich" and "masterlich" as explicit variations.
Disclosing final inventory while wearing an alchemy smock reported
the apron's slogan accurately but then disclosing attributes gave
different text if it was conferring poison resistance and/or acid
resistance. The extra text was unneeded/unwanted there anyway, so
simply suppress it rather than force it to be accurate.
3.6.x had the same issue but it wasn't detectable there because it
only had extra text for T-shirts and they don't confer attributes.
Reported by NetSysFire: if hero dealt a weapon-shattering melee
blow to an unseen target, the weapon was accurately described in
the accompanying message
|Its <formatted-weapon-description> is shattered from the force...!
If the hero can't see or sense the monster, report
|Its weapon is shattered from the force of your blow!
If the monster isn't seen but is sensed, then
|<Monster>'s weapon is shattered from the force of your blow!
Fixes#1220
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.
