The big typos fix commit changed the misspelling "wharever" to
"wherever" but it should have been "whatever".
Plus a punctuation bit I had sitting around.
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.
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.
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.
Noticed when trying all the extended commands. #wizbury didn't have
any feedback (other than clearing the adjacent floor if any objects
were present).
Also, prevent #wizbury from burying boulders.
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.
If a tame or peaceful monster was trapped and blind hero hadn't seen
the trap yet, attempting to swap places would report that the monster
couldn't "move out of that trap". And if the 'tips' option was True,
the game would suggest attempting #untrap. But #untrap would report
that the hero wasn't aware of any trap at the spot, and fail.
Change the original message to "move out of that <type-of-trap>" and
if hero hasn't seen it yet, map it and vary the wording slightly
"... a|an <type-of-trap>". If #untrap is attempted, it will now be
dealing with a known trap.
Issue reported by Ryton: a sleeping orc caught a thrown gold piece.
Throwing one at some other sleeping monster woke it up.
That is actually intentional. Sleeping monsters with the 'greedy'
attribute will wake up without becoming angry and catch thrown or
kicked gold that is aimed at hit them. The fix here is to augment
the catch message to say so. Non-greedy monsters wake up and treat
it as an attack, but the gold always misses.
Both cases only happen for monsters who are asleep for an indefinite
period of time. Any monster that is asleep (or paralyzed, or busy
putting on armor) for N turns effectively doesn't notice. If it can
be seen, the gold "harmlessly hits" (if it can't be seen, the gold
misses), and the target continues doing--or not doing--whatever it
is doing. That's suboptimal; another case where lumping multiple
can't-move situations into a single monst->mfrozen countdown timer
causes timed sleep to be indistinguishable from timed paralysis.
Closes#1230
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.
Normally the 'O' menu covers the status display, but not always.
Toggling 'time' or 'showexp' via the "simple 'O'" menu should update
the status lines.
Toggling 'hitpointbar' already does so so. I didn't try to figure out
why. Presumeably it triggers a different bot() call somewhere and the
code here sees 'disp.bot' as reset to False.
I didn't check the behavior when adding or removing a status highlight
but those can change the current status display.
