If a monster picks up an item thrown by the hero, change its 'how_lost'
flag from LOST_THROWN to LOST_STOLEN and pickup_stolen will be used
instead of pickup_thrown to decide whether to override pickup_types
and autopickup exceptions when hero eventually steps on it. If a
monster picks up an item dropped by the hero, change its flag to
LOST_NONE and autopickup will work normally without being overridden
by dropped_nopick. If item is flagged as stolen, leave it that way.
Moving over at item that's resting on ice gives a message about there
being ice present and then about the item, whether mention_decor is On
or Off. With it On, you'll get a message about being back on solid
ground as soon as you leave the ice. With it Off you wouldn't get
that at all if not levitating; that's the basic no-mention_decor
behavior for ice. However, if you were levitating, you would get a
delayed "back on solid ground" message when moving over some other
object, which might occur quite a bit later. Autopickup handling is
calling describe_decor() when the hero is levitating and some of that
wasn't appropriate for no-mention_decor.
This issue has been present since I first implemented mention_decor,
not introduced by recent back_on_ground() changes.
Fuzzer encountered an error because the game couldn't place
a level region; allow placing the stairs to the left or right
edge of the fixed map part, just in case the randomly generated
map didn't extend out of it.
Fix the teleport region preventing falling into the orctown.
selection_getbounds() has a check and early return.
Initialization will ensure a known state if that early return
were ever taken.
This is an alternative approach to pr #1163.
Reverse part of commit 8b5e9eadb1.
Shouldn't use get_obj_location(obj,...) to try to figure out if obj
has been deleted. That routine uses obj->where rather than scanning
the various object lists and doing that when obj has been deleted
would access stale memory.
The following were listed in extern.h as residing in makemon.c,
but they are actually in mon.c:
copy_mextra(struct monst *, struct monst *);
dealloc_mextra(struct monst *);
usmellmon(struct permonst *);
The new "riding blocks stealth" code was reading u.usteed at an
early point in the restore process, before its value was reliable
(dorecover()->restgamestate()->set_uasmon()->steed_vs_stealth());
because restgamestate() happens prior to restlevelstate(), the
value of u.usteed will be a stale pointer from some previous game,
and attempting to determine whether the steed is flying will crash
the game.
steed_vs_stealth() doesn't actually need to be called during the
restore process (because BStealth is saved in the save file), so
this can be easily fixed by omitting the call to it during the
restore.
A zap from a wand of striking shouldn't hit a drawbridge if it is
just passing over the span's spot when the bridge is closed. This
change matches the 3.7 behavior when the zap is performed by the hero.
It does hit if passing over that same spot when the bridge is open or
if it hits the portcullis spot whether open or closed.
Also, simplify the handling for the wand's destruction. It still
ends the zap early if that happens even though logically the rest of
the zap range should still be targetted.
After a music.c change earlier today, an annoying compiler warning resulted.
.\music.c(721): warning C4295: 'notes': array is too small to include
a terminating null character
Report was for an impossible "What an interesting effect (%d)" which
the fuzzer turned into a panic. Monster on the drawbridge zapped
toward the open portcullis, destroying the bridge and killing itself.
Wand was made of wood and burned up in lava under the fallen span.
Freeing the object zeroed it rather than leaving stale data, and the
zap continued while referencing freed memory that looked like it had
type STRANGE_OBJECT, triggering the impossible.
This will make a monster-induced zap stop early if a drawbridge
incident destroys the wand. That isn't the best possible fix
because the zap should continue despite the wand's destruction, but
at least it will now avoid triggering "intestsing effect".
When trying to reproduce the wand of striking "interesting effect (0)"
report, I tried wishing for lava under the castle drawbridge. That
wasn't handling drawbridges properly. This fixes wishing for moat,
lava, ice, or floor at a drawbridge span location whether the bridge
is currently open of closed. It also allows wishing for room or floor
or ground at room spots; that hasn't had much testing.
Wishing for furniture, pool|moat|water, or lava at an ice location
wasn't cancelling any pending melt timer.
ice_descr() was declared as returning const but returns its non-const
output buffer argument. Change to 'char *' so that wizterrainwish()
can capitilize that output without jumping through any hoops.
After the drawbridge was destroyed, playing an instrument on the castle
level while knowing the tune continued to offer a chance to play it.
Then nothing interesting happened even if you were close enough to the
former bridge for it to have been useful prior to the destruction.
I think the hero could also be given the tune as a divine prayer boon
after bridge destruction but I didn't verify that. The player might
not know that the tune is no good anymore, but the hero's patron deity
should.
Hide some of the details about new Stealth.
Streamline mon_break_armor(). Move replicated bypass handling into
m_lose_armor(). Also, eliminate a 'goto'.
Donning elven boots while riding and not already stealthy, you'd get
the message "you walk quietly" when not walking at all. Instead of
just changing the message, make riding a non-flying steed block
stealth. Riding a flying steed (or one you take aloft with an amulet
of flying) does not. It would have been quite a bit simpler to have
made riding anything block stealth, but the hard part is done.
The new formula is: (xlevel + Con)% chance of regenerating 1 hp
each turn.
This formula has been extensively playtested throughout the whole
game (including two ascensions). The intention is to make late-
game combat more interesting: early game the HP regeneration rate
is potentially slightly faster but not significantly changed, but
in the midgame and lategame is substantially slower because there
is no longer a big regeneration boost once the character's xlevel
is in the double digits.
With the new formula, I'm finding that my characters have to heal
with potions (rather than by waiting) in places that they never
had to before (e.g. lower Dungeons, and upper Gehennom), which in
turn means that fighting efficiently is now more important than it
was before. (In fact, in one of the games I wished for potions of
full healing on Astral for safety, although I think I would still
have won without.) It's also generally the case that you can no
longer regenerate "mid-fight": you need to disengage in order to
heal up. This made the game more fun as it meant that escape items
became more relevant, and I was using a greater range of items
throughout the game than I normally would.
The ring of regeneration has also been slightly buffed: it now
heals an extra 1hp per turn unconditionally (rather than becoming
less effective as the character levels). In both my test
ascensions, I found a ring of regeneration, but intentionally
refrained from using it in order to ensure that the new HP
regeneration rate would be tolerable even without one.
Issue reported by mkuoppal: drum of earthquake triggers a sanity
check warning which the fuzzer escalated to panic.
Analysis by entrez. If a pit gets created next to a pool or moat or
lava, liquid might flow there and replace the pit. But the drum of
earthquake code assumed that the pit was still there. If there was a
monster there and it wasn't levitating or flying and it wasn't killed
by the liquid, it got marked as trapped even though the pit was gone.
'sanity_check' noticed.
With difficulty I was able to reproduce the impossible warning before
the fix, but the are a bunch of random factors at play. After the
fix I can't reproduce it again, but that's not a guarantee that it's
actually fixed. The analysis seems correct though and the fix is
based on dealing with that.
Closes#1170
In the rare event that
make fetch-lua
is not working because the primary Lua site is not available,
provide another target
make fetch-lua-mirror
that uses the official lua mirror site documented at:
https://www.lua.org/mirrors.html
Allow 'm p' to pay via menu when menustyle is traditional and to pay
via the old sequence when it's combination, full, or partial. Also
revise the "Itemized billing?" prompt to accept 'm' as well as 'ynq'.
Answering 'm' will switch from the old sequence to the menu (whether
you got to that prompt via m-less 'p' for traditional or 'm p' for
other styles).
... and have more than 1 billed item, and using non-traditional
menustyle.
I opted to add an extra field to the bill struct, because
that made the code cleaner.
Breaks saves and bones.
During very early startup, Windows may not have loaded
the tty window procs yet, and it is running with safeprocs.
It will eventually load the tty stuff. If the currently
operating window port fails in can_set_perm_invent(),
try the check for WC_PERM_INVENT again explicitly on
the tty windowport.
There is a slight change in behavior here when collecting build-time
option information. If MAXOPT is too small, collecting will now save
MAXOPT lines and then skip anything that should come after. It used
to always keep the very last line, each time replacing whatever the
previous last line was, but would leak memory if that ever happened.
And after yesterday's "fix" it would try to keep that very last line
beyond the array bounds.
The recent commit to interpret walking into a shopkeeper as a "pay"
command was triggering in too many circumstances. Check to ensure
that the monster that we're walking into is a known shopkeeper
before activating the special case.
"Grand poohbah" is a common term while "high poohbah" is not, and it
seems appropriate for hallucinogen-distorted high priests. (It seems to
most commonly be spelled "grand poobah" but I left that alone; "poohbah"
seems like a decent compromise between that and the spelling of the
character's name in the Mikado).
Pull request from entrez: add 'nopick_dropped' option of not pick up
items dropped by hero via autopickup and 'pickup_stolen' to picup up
items stolen from hero via autopickup, bypassing pickup_types and
autopickup_exceptions like existing 'pickup_thrown'.
This fixes entry commit also fixes the description of pickup_stolen.
Closes#1140
Add pickup_stolen option to autopick items stolen from you by a nymph or
monkey, even if they don't match your normal autopickup settings.
Replace was_dropped, was_thrown with a 2-bit bitfield that can contain
values LOST_DROPPED, LOST_THROWN, and LOST_STOLEN (or 0), since they
should all be mutually exclusive anyway as they track the most recent
way the item left the hero's inventory.
[Rebase/merge conflict fixed up. PR]
