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.
Reported directly to devteam: using '#adjust a a' to collect
invent stacks compatible with the one in slot 'a' all into 'a' gave
feedback of "Merging: a - ..." even though "Collecting: a - ..."
was intended. Also, if there weren't any such compatible stacks,
so that the whole operation didn't accomplish anything, it reported
"Collecting a - ..." without the intended colon between the action
and the inventory letter.
Test case was trivial: start with a stack of 2 of something in 'a'
and use '#adjust 1a b' to split into two stacks, then '#adjust a a'
to collect them back again.
While fixing this, I noticed that '#adjust a b' and '#adjust b a'
(from same starting situation) just swapped a and b instead of the
intended behavior of merging them back together.
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.
Reported by AndrioCelos, a handful of objects in the tutorial can
be discovered via use, and such discoveries were carrying over to
normal play when the tutorial ended.
This causes the hero to forget such discoveries. The player will
still be able to remember them. The proper fix would be to discard
the initialized but not-yet-started game when entering the tutorial
and then start a whole new one when exiting so that saving and
restoring game state would become unnecessary. This doesn't do that.
This also causes monster birth and death statistics to be reset when
exiting the tutorial. Affects the #vanquished command and potentially
extinctionist play.
Closes#1134
The constructed value for 'windowcolors' didn't specify the option
value correctly. If windowcolors was not at its default value, the
new RC file created by #saveoptions would contain a value for it
that didn't work when read back the next time nethack was run.
This works, but a non-default windowcolors value shown by the 'm O'
menu won't fit on an 80 column display. curses wraps it ok, but in
a manner that doesn't look good for that menu.
There's a bunch of reformatting here. The actual changes are at the
end of the diff.
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.]
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.
Previously when wishing for "ring of protection from shape shifters",
you got a random ring instead of the protection from shape changers,
because the string matching alias was "protection from shape shifters"
without the object class. Now, we'll check if the wish matched any
object class, but not existing object or alias, and try matching
the aliases again, but only those of the already matching obj class.
Add an alias for the ring of increase accuracy: "ring of accuracy",
and tests for it.
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.
Pull request by elunna with assistance by entrez tried to fix up
wand of striking discovery when the wand is zapped by a monster.
The fix didn't match the intended behavior (which may or may not be
the desired behavior...), so this skips the code in the pull request.
[I can't post comments on github anymore since I declined to switch
to their 2-factor authentication. But I can still read submissions
without logging in.]
This also tries to fix a couple of inconsistencies between zapping
by the hero versus by a monster. If the zap "boinged" :-) due to
target's magic resistance, zap by hero didn't discover the wand but
zap by monster did. Conversely, a zap by the hero that reached a
target and missed did discover it but one by a monster did not.
Now a zap of not-yet-discovered wand of striking by the hero which
hits, whether or not the hit gets resisted, will become discovered
provided that the spot where target is hit can be seen (the target
itself need not be), and one which misses or which can't be seen
hitting something will no longer be.
Supersedes #1223Closes#1223
Reported directly to devteam: if a magic trap gave its uncurse
effect, scroll of remove curse could become discovered.
Turns out that it would happen if hero was wielding a stack of
unholy water potions. It didn't matter whether they were known
as water or known to be cursed or whether hero was carrying any
scrolls of remove curse.
