mondead() -> m_detach() -> m_unleash() suppresses
the m_unleash() slack message, so deliver it in
the caller explmm() in those circumstances.
(The issue of whether it should be possible to leash light
is side-stepped.)
bug H7406, 1548
The original report stated:
"I located a bear trap as a human and just ignored it
for the time. I polymporphed into a Vampire Lord, then
went to #untrap the bear trap. On the first attempt,
I stood beside the trap and attempted to #untrap. I
received the 'Whoops!' message and automatically moved
onto the trap square as a result. The bear trap vanished!
I obviously wasn't trapped since I'm polymorphed into a
flying monster, but the trap glyph was no longer present.
The glyph looked like regular floor - as if I had
untrapped the bear trap and taken the trap with me."
The trap was actually still there but became hidden intentionally
for other valid scenarios, but was an unintended side-effect for
this scenario.
Fix it by failing the #untrap operation for a Flyer earlier on,
and in a more benign manner, since the Flyer ultimately doesn't
end up in the trap anyway. You'll still get the "Whoops!",
followed by a message, but that's as far as the "failed" #untrap
attempt will go under the circumstances.
Address a drum of earthquake inconsistency reported 2017-03-23:
"Drum of earthquake does not make you deaf. Leather drum or depleted
drum of earthquake does."
bug 1099
Like BL_FLUSH, only send BL_RESET if the window port has
indicated it wants them via setting the appropriate WC2
bits in its window_procs structure. Update documentation.
Fixes#134
An invisible hero (who can't see invisible and doesn't have autopickup
enabled) going down stairs to an object which fell down those stairs
will see the stairs instead of the object on them. Missing newsym()
in obj_delivery() when objects aren't being passed through scatter().
The original report complained that gremlins seemed impervious to
Sunsword's light yet a flash from a camera caused them to cry out in pain
despite "The long sword named Sunsword begins to shine brilliantly!"
This commit does two things:
1. A dmg bonus is applied against gremlins using a lit Sunsword.
2. Gremlins will generally avoid the light emitted by Sunsword.
There's a few minor flavor bits thrown in also.
It is understood that this effectively makes Sunsword provide
"gremlin-proofing", but the gremlin myth and Sunsword's characteristic
feature pretty much demand it.
bug 42
This outstanding bug was complicated slightly because the same
code was used for a sleeping mon as for a paralyzed mon so
message phrasing was called into question.
Just flip the phrasing to be about what you are able to discern
under those circumstances, which is very little, and don't have
the sleeping or paralyzed monster react to the mirror.
new file: doc/fixes23.e
new file: doc/fixes30.pl01
new file: doc/fixes30.pl02
new file: doc/fixes30.pl03
new file: doc/fixes30.pl04
new file: doc/fixes30.pl05
new file: doc/fixes30.pl06
new file: doc/fixes30.pl07
new file: doc/fixes30.pl08
new file: doc/fixes30.pl09
new file: doc/fixes30.pl10
Wishing for "orange" might grant an orange, but it might give an
orange gem, orange potion, or orange spellbook instead (but never
orange dragon scales or orange dragon scale mail). Force the food
object to be an exact match so wishing always produces an orange.
A polymoprh zap which creates a long worm can hit and transform the
same monster again depending upon tail segment placement. Similar
behavior occurs if monpolycontrol is set in wizard mode and player
chooses 'long worm' for what to transform an existing one into (in
which case polymorph fails and zap might hit that same worm again
in another segment, prompting player to choose its new shape again).
Simplest fix would be to make tail segments be immune to polymorph,
but that would prevent players from deliberately attacking the tail
(for polymorph attacks only). Next simplest would be to make long
worms M2_NOPOLY so that polymorph can't create them, then just live
with multiple promptings when monpolycontrol is set. This fix
tracks whether a long worm has just been created via polymorph (or
explicitly retained its shape via monpolycontrol) and makes further
hits on same creature on same zap have no effect. It does so by
setting mon->mextra->mcorpsenm to PM_LONG_WORM when a long worm is
result of polymorph, and setting context.bypasses to get end-of-zap
cleanup. (It doesn't bother discarding mon->mextra if reset of
mcorpsenm leaves mextra empty.)
The report was "doesn't kill even if unchanging", but it does cause
rehumanize() when not Unchanging, the same thing that happens when
you die due to loss of hit points. But losing the activating word(s)
and then having Unchanging retain the clay golem shape does seem
wrong, so make losing the word(s) while being unable to revert to
normal form be fatal.
Poly'd hero (without Unchanging) reverts to normal when cancelled,
so make monsters behave that way. Previously, only werecritters in
beast form were forced to human form. This changes cancellation to
make shapechangers and hiding mimics take on normal form too.
Cancelled shapechangers now behave as if the hero has the
Protection_from_shape_changes attribute and will be unable to change
their shape (after having been forced into normal form). Getting
polymorphed in any fashion uncancels them prior to giving new shape.
[There may be some newcham() situations that should be disallowed
when cancelled rather proceeding and consequently uncancelling.]
Bug report #H7156 listed three items, all relating to perm_invent:
1) it shouldn't persist across save/restore since restore might be
on a system which doesn't have enough room to display it (report
actually complained that config file setting was ignored when
restoring old games, which is an expected side-effect for options
that persist across save/restore);
2) permanent inventory wasn't updated when using scroll of charging;
3) attempts to update permanent inventory during restore could lead
to crash if it tries to access shop cost for unpaid items.
Items (2) and (3) have already been fixed. This fixes (1).
Replace 'flags.perm_invent' with a dummy flag, preserving save files
while removing it from flags. Add 'iflags.perm_invent' to hold the
value of the perm_invent option.
The win32 files that are updated here haven't been tested. Whichever
branch contains the curses interface needs to be updated; ditto for
any other pending/potential interfaces which support perm_invent.
Fixes#133
Monsters who lost an amulet of life saving while having their life
saved wouldn't attempt to put on another amulet unless/until they
picked up some object. Likewise if they had a worn item stolen.
(There are probably other events which should re-check worn gear.)
The suggested commit had a life-saved monster re-check equipment
during life-saving which might have led to reports about them
effectively getting extra moves, especially if two-weapon fighting
or zap rebound with sequence of kill/life-save/kill-again allowed
the target to put on a replacement amulet of life-saving prior to
the second kill. It also wasn't amenable to dealing with stolen
equipment. This alternate fix sets a flag to have monster check
its equipment on its next move.
Jumping performs the placement of the last step after using hurtle()
to move to the destination, so if hurtle() triggered a trap then it
would happen twice. Report was for a Sokoban pit but it would happen
for fire traps too. Other traps would yield "you pass over <trap>"
while hurtling and then trigger the trap when landing. Have
hurtle_step() ignore a trap for the last step of a jump, leaving it
to the jump's landing to handle.
Also, give feedback when hurtling over water or lava, similar to what
happens when passing over a previously seen trap which doesn't
activate.
Change the placement of the code that makes a replica of the
current status fields for later comparison.
A loop shortcut was causing it to be skipped under some
circumstances and that was negatively impacting the placement
of status field values that were further to the right.
The temporary highlight types 'goes-up' and 'goes-down' aren't useful
for the three string status fields (title, dungeon-level, alignment)
since the string values might go up when the underlying value goes up
or might go down instead (and similarly for down, down, up). The code
involved can compare strings but the values are effectively arbitrary
so the comparison is only really useful for same vs changed. This
treats types 'up' and 'down' for strings as 'changed' when coming from
config file and no longer offers them as choices when using 'O'.
Config file parsing perhaps ought to treat them as errors instead.
This adds BL_RESET to status_update to send a flag to a window
port that every field should be updated because something has
happened in the core to make current values shown to be
untrustworthy or potentially obliterated.
That is now distinguished from BL_FLUSH, which now has no
bearing on whether every field needs to be redone, and instead
can be used by a window port indicator that it is time to render
any buffered status field changes to the display.
tty port now sets WC2_FLUSH_STATUS indicator for BL_FLUSH support
and now does one rendering per bot() call, instead of up to 22.
Side note: The tty hitpoint bar code was relying on the old
behavior of redrawing everything upon BL_FLUSH apparently, so it
initially had some color change lag issues, corrected by marking
BL_STATUS as dirty (in need of updating) in tty_status_update()
whenever BL_HP was marked as dirty.
ensure BL_FLUSH always gets sent down to the window port whenever bot() is
called with context.botlx set so that status updates work as
expected after full screen clear after a level change
Fixes#107
make the transformation message of a deliberate apply of a figurine seem
a bit less definite when blind. Put 'I' unseen monster marker at the spot
you expect it to be.
make transformation message of a deliberate apply of a figurine seem a bit
less definite when blind. Put 'I' unseen monster marker at the spot you
expect it to be.
tty: turn off an optimization that is the suspected cause of Windows reported
partial status lines following level changes. It was turned on for
non-unix platforms only
Don't display the selection to identify all items if there are none.
Complete an item marked ToDo in cmd.c: allow selection of one or more
particular items to permanently identify rather than just all or nothing.
I noticed that the description of ^O still referred to the 3.6.0
behavior (either #wizwhere or #overview depending upon play mode)
rather than the 3.6.1 behavior (unconditional #overview).
While updating that I changed a bunch of "Wizard-mode" references
to "Debug mode" which is the proper end-user name.
I slightly expanded the descriptions of #wizdetect, #wizgenesis,
\#wizintrinsic, WIZKIT, and Debug mode, and removed at least one
out of date reference to debug mode being a conditional feature.
And for most of the stuff I was looking at, I changed the nroff
source to honor the roff guideline of having each sentence start
on its own line (and also the latex source to use those same line
breaks even though they don't need it).
Not done: a lot of quoted single characters use 'c' instead of `c'
(pair of ticks rather than back-tick and normal tick). One form
or the other should be changed so that they're all consistent.
I'm pretty this was mentioned the last time it was formatted for
the web site.
Guidebook.mn has been tested, Guidebook.tex has not.
Fixes#124
Fix github pull request #124 which was also reported directly (but not
through the contact form so #Hxxx number). Using ^I or #wizidentify
displays inventory with everything ID'd for that command only and adds
a menu entry "_ - use '^I' to identify" that can be chosen to make
those ID's persistent. Picking underscore would work but picking the
alternate '^I' wouldn't work if the platform had unsigned characters
for plain 'char'. Switch the return value from magic number -1 to
magic number ^I which isn't a valid inventory letter and isn't subject
to sign conversion. Casting -1 to '(char) -1' would have worked too
despite some confusion expressed in discussion of the pull request.
If ^I has been bound to some other command and #wizidentify hasn't
been bound to any keystroke, temporary ID didn't disclose any extra
information (ie, acted like ordinary inventory display) and the extra
menu entry to make temporary ID become persistent wasn't available.
This fixes that too.
