Fix a FIXME added for issue #1233. When engraving, if the writing
implement is a stack of cursed weapons which are welded to the hero's
hand, just write in the dust rather than engrave in the floor, in
order to keep the whole stack welded.
Only applies when the stack is actively welded. Other stacks of
cursed weapons will have one split from the stack to perform the
engraving, otherwise engraving could be used to determine whether a
stack is cursed without the risk of wielding it.
Issue reported by NetSysFire: engraving with a stack of multiple
weapons dulls the whole stack where it ought to only dull one of them.
This was actually trickier than it ought to have been, and will need
a lot more testing. When engraving with a stack, split one off and
use just that one. If inventory is full, it will be dropped (after
writing the first 2 characters and becoming duller). I've avoided
moving it into the overflow slot, otherwise engraving repeatedly with
an arbitrarily large stack could be used to produce an arbitrary
number of overflow items.
Engraving with a weapon of known enchantment us somewhat more verbose
than it used to be.
From the report:
" It would be a great quality of life change if only one item of the
" specified stack was used, as with #forceing open chests.
One person's improved quality of life is another's outrage. Players
who want to dull a stack of +6 daggers down to +5 in order to have
another try of enchanting to +7 are not going to like this....
Closes#1233
Failed #force due to wielding wrong implement didn't phrase things
well if current weapon was a stack.
Plus some reformatting split out from a forthcoming #engrave patch.
Contains some wood nymphs and fountains, and the room walls are trees.
Adds a new lua hook for themeroom generation, "post_level_generate",
which is called last when generating the level.
Give a resistance animation if you #invoke Sunsword while it's
wielded and direct its blinding ray at yourself. Flashing a camera
at a monster who is wielding it will also produce the animation.
about testing whether an unsigned value is >= 0. Since there's no
chance that it might have a value of NON_PM (-1), just comment out
the assertion that was intended to ward off a potential complaint
about that.
Commit fddc966a3e included:
Add S_suit as another alternate for S_armor.
I got fooled by the description "suit or piece of armor" and was
thinking that each of the 7 armor slots had their own symbol that
could be overridden.
There's no need for S_suit when there isn't any S_helm, S_boots, &c.
Even 100 deaths wasn't enough, as the fuzzer was still quitting.
If we're in wizmode, just execute wizmakemap to recreate the level,
getting rid of whatever was blocking hero from teleporting to safety.
Prevent glyph change messages while loading a level file.
Otherwise a monster hiding under an item triggered a vision recalc
before light sources were linked to their sources, leading into
strange errors looking like pointer corruption.
getlev -> hide_monst -> hideunder -> newsym -> show_glyph ->
pline_xy -> vision_recalc -> do_light_sources -> get_obj_location
Add in_getlev program state variable, analogous to in_mklev
When a monster mimicks another monster (traditionally Double Trouble
Wizard, since 3.6.x also pet that eats a mimic corpse), using farlook
or getpos+autodescribe revealed the monster's real identity. Hard to
believe that nobody ever noticed, but it was obvious when a pet dog
quick-mimicked a cat or vice versa.
Add an extra x_monnam() flag to ignore monst->m_ap_type==M_AP_MONSTER
plus monst->mappearance. Only the m_monnam() variation of x_monnam()
includes it (via EXACT_NAME); monnam() and the rest will now describe
an M_AP_MONSTER by its appearance rather than as its true self.
Improve the feedback for an unnamed pet eating a mimic corpse.
|You see a tripe ration where Rover was.
is ok.
|You see a tripe ration where the dog was.
looks somewhat odd. Change that to be
|You see a tripe ration where your dog was.
When a camera flash hit a mimic which was posing as something, the
feedback mentioned the mimic but didn't bring it out of hiding.
Change to make light pass over a mimic impersonating an object but
unhide one impersonating furniture. Ones impersonating some other
monster are woken up but wakeup doesn't force it back to mimic shape.
Trying to get the messages right brought on more code changes than
antipated. I changed one of the arguments to mhidden_description()
so had to change its callers; fortunately there aren't very many.
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.
