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.
