Any monster with rusting or corrosion attack can eat through
the bars. This includes rust monsters, grey oozes, and black puddings.
Original patch by Malcolm Ryan
There is a lot of code affected by this, and Pat Rankin correctly
observes that it would be better to store roguelike as a level flag
rather than just using Is_rogue_level. A note for the future.
Something I've had in mind for a long time and finally gotten around
to implementing: when you fill in the last pit or hole of a sokoban level,
it's considered to be completed so luck penalties for unsokobanish things
(breaking a boulder, dropping everything and squeezing onto a boulder's
spot, reading a scroll of earth) stop being assessed and most Sokoban-
specific movement restrictions (against pushing boulders diagonally,
squeezing diagonally between boulders, floating over a pit or hole without
falling in, digging of new holes by monsters) are lifted. Teleporting,
level teleporting, and phasing through walls are still prohibited when in
the sokoban branch of the dungeon. (Keeping the non-phasing one in place
prevents taking a shortcut to the final prize in order to bypass the
treasure zoo monsters.)
This adds level.flags.sokoban_rules, defines Sokoban macro to access
it, and replaces most In_sokoban(&u.uz) tests to check it instead. It
gets set when a sokoban level is pre-mapped at the end of level creation,
and if it is set then whenever a trap is deleted, the flag gets cleared
if there are no more pits or holes present on the level.
From a bug report, a
monster incapable of moving could yield the message "<Mon> turns to flee!"
when hit by an attack which scared it. I thought that something to fix
this had already been done, but that wasn't the case. Now it will give
"The immobile <mon> seems to flinch" instead. I'd rather use
mon->data->mmove == 0 ? "immobile <mon>" :
mon->paralyzed ? "paralyzed <mon>" : "sleeping <mon>"
but it presently isn't possible to distinguish between sleep, paralysis,
and being busy doning armor because mon->mfrozen is used for all three.
(I'm not going to worry about the busy case, even though "immobile" sounds
inaccurate for it.)
Also, stethoscope and probing were suppressing "scared" after giving
"can't move", in order to reduce the chance of wrapping the top line.
This changes it to display both status conditions so that scared state
isn't hidden when the target is paralyzed or asleep (or busy).
From a bug report, a stunned monster
moved away from the hero, but remained holding him. That behavior was
still present in the dev code, although the hero was free to move and
would become unstuck as soon as he did so. I don't know how many fixes
for this sort of thing have been made, but they evidently haven't been
made in the proper place. [Perhaps it really ought to be done as a
monster is placed somewhere on the map?]
Get rid of most of the vestiges of the old warning code that was
replaced over 7 years ago. I left the list of colors which were used for
warning flashes.
From a bug report, a monster which
died by moving into a trap which was next to the hero standing on Elbereth
resulted in "The <mon> is killed! The <mon> turns to flee!". An earlier
change made monflee() return if it's given a dead monster, so the fleeing
message is no longer given. This fixes the place where monflee() was
inappropriately being called for a dead monster in the reported situation.
From the newsgroup: Conflict caused tame engulfer to swallow hero.
To try to get out, player hit it (with Magicbane, but that's not relevant
other than to provide an alternate "you hit it" message).
The magic-absorbing blade probes the invisible Audrey!
You get regurgitated!
placing defunct monster onto map?
Program in disorder, &c
[some look_here() feedback]
You kill poor invisible Audrey!
The problem was caused by hmon_hitmon(): it subtracted damage from the
target's hit points, did some bookkeeping and message delivery, then
called killed(). One bit of bookkeeping was to call abuse_pet() and
monflee() when the target is tame, regardless of whether the damage was
fatal. monflee() -> release_hero() -> expels() puts the hero and the
engulfer back onto the map, and that warning was triggered because the
former engulfer had no hit points left.
There's some discussion in the newsgroup about an engraving bug, and
while verifying that it's reproducible I've come across an unintentional
change between the current code and 3.4.3. A recent change made engraving
use accessible(), and that routine wasn't yielding an appropriate value
when applied to a raised drawbridge if the terrain in front of it was ice
or floor (ie, moat or lava had been filled in). Several places which used
the ACCESSIBLE() macro instead of the function suffer from same problem.
This doesn't attempt to address the newsgroup bug (which is that an
engraving written on a lowered bridge transfers to the underlying terrain
if the bridge is raised, even when that terrain is water or lava; the
converse case applies too, an engraving on the ground gets transfered to
the bridge when it lowers).
Turn being unconscious (via several reasons, including fainted from
hunger) into a pseudo-property named `Unaware' and use it in several
places where only being asleep was checked. #H202 was about a stunned
character who got the recovery message when it timed out while fainted.
This suppresses messages for several difficulties when they begin or end
while hero is Unaware. Messages about fatal illness, sliming, or
petrification aren't suppressed; they're too important to hide from the
player. "You feel ..." messages come out as "You dream that you feel ..."
when Unaware; fairly lame but hopefully adequate.
<Someone> reported being swallowed by his pet purple worm during
Conflict, then being stuck inside once Conflict ended. I'm not entirely
sure what dog_move() intended by the "swallowed case handled above" comment.
It returns without letting the pet move when the distance between pet and
hero is 0; that wasn't much in the way of "handling" being swallowed.
Grabbing pets did let go, but peaceful monsters didn't until you actually
attempted to move away from them. Now all four combinations (grabbed or
swallowed by tame or peaceful monster) are handled the same: the monster
will let the hero go next time it gets a chance to try to move, using up
its move in the process.
- restore intended behaviour of kill_genocided_monsters().
It has been incorrect since the chameleon overhaul in June 2004.
- eliminate CHAM_ORDINARY and use NON_PM instead.
From a bug report, bribeable demons will demand money when
hero has fainted from lack of food and hero can pay while unconscious. I
decided to just borrow from vault guard behavior and have the hero regain
consciousness. It turns out that reset_faint() has been broken since a
long ago (before my time...) change to nomul() [nomul(0) is a no-op while
fainted since multi is negative then]. Now fixed; both bribe-demanding
demons and vault guards will cause fainted hero to wake up when they arrive.
If hero can't move for some reason other than fainting, demons will skip
the bribe demand and immediately become hostile (vault guard in that case
goes away after saying that he'll return). There is no deafness handling;
perhaps the bribe demand is accompanied by sufficient pantomiming for the
hero to figure it out? ;-)
Also fix an unintended potential alignment hit against the player if
bribeable demon is killed after becoming hostile due to misjudging displaced
hero's location.
Let monsters use lock picks and credit cards in addition to keys for
opening doors. And the earlier code to have pets hang on to a key didn't
work as intended. It worked fine if the key was the only object carried,
but the monsters' item dropping code didn't give any special handling to
keys so they'd be dropped too if the pet carried another droppable item.
This eliminates second set of checks for handling some items specially--
dropping now uses the same routine as is used when pet movement decides
whether there's anything to drop.
Also, a couple more door message tweaks. "You see a door open" seems
strange when you watch your pet do the opening. Previously fixed for the
"unlock and open" case, this does the same for opening already unlocked
doors and for giants smashing down doors--it now gives a more specific
message when you see a monster perform the action.
Possible change in play balance: pets capable of picking up the
rogue's Master Key of Thievery or tourist's Platinum Yendorian Express
Card will keep one of them. So a player might accidentally lose one by
leaving it on the floor in a pet's path, or more significantly, the Card
will yield a means of giving magic resistance to a monster who can't wear
a cloak or dragon scales. It's neutral and the most interesting high-end
pets are lawful (hence won't pick it up), so that probably won't have much
impact.
Spotted when fixing the Rogue level digging/phasing bug: pet movement
was setting up the wrong flag for pets who happened to be carrying a key.
This wasn't particularly noticeable because they tended to drop keys right
after picking them up. And apparently the checks elsewhere in movement
prevented that wrong flag from having any effect; once I changed it so that
pets would hang on to keys, I never saw them break a door down with one.
Now they'll keep keys, similar to unicorn horns and pick-axes, and use them
properly. The door unlocking message needed a tweak because it assumed
that the opener was on the far side trying to reach you and looked quite
odd when you could see the action taking place.
I've put this into the fixes file as a new feature rather than a fix.
Simplify is_lminion(); as a result, several source files no longer
need access to epri.h. (mondata.c already could have lived without it;
eshk.h as well.)
Makefile dependency changes:
mondata.{c,o} -- doesn't need epri.h or eshk.h
monmove.{c,o} -- doesn't need epri.h
wizard.{c,o} -- ditto
pline.{c,o} -- ditto (yesterday's patch)
From a bug report: the invulnerability conferred
during the multi-turn delay for a successful prayer was not protecting
against damage inflicted by hostile mind flayer's "wave of mental energy".
I think being asleep or unconscious ought to override vision the way
that being blinded does, but that's a more ambitious change than I care to
tackle. This replaces You("see ...") with You_see("..."), comparable to
You_hear(). It catches the reported door case and several variations of
light sources burning out while on the floor rather than in inventory, but
it probably misses some other cases. zap_over_floor() in particular is
highly suspect.
- can shift into fog clouds, vampire bats, and vampire lords into wolves
- after being "killed" in shifted form, they transform back rather than get
destroyed, and you must take them on in vampire form to defeat them
- can deliberately shift into fog clouds to pass under closed doors
Reported to the list back in November: scaring a mimicing mimic will
produce a "turns to flee" message, but the mimic does not unmimic nor
does it flee. The latter behavior made sense to me as a defense mechanism,
so I changed monflee to avoid printing the message in this case.
For now, the code is conditional on BARGETHROUGH
being defined, while it gets tested further. While behavior is
different with and without BARGETHROUGH defined, savefiles
are the same either way.
After this patch is applied, only the riders have the M3_DISPLACES
bit set, but the Wizard and Vlad probably should too. Any others?
A trapped monster with one step between you and the monster (@.@) would
repeatedly switch between a ranged and hand-to-hand weapon if carrying both.
Since the monster switches each turn, it will not make ranged attacks.
Modified the test in dochug to prefer a ranged weapon in this case.
Reported a while back, a (stonable) hiding monster will hide at a location
containing only a cockatrice corpse. While it would be interesting to
allow monsters to try, and stone themselves as a result, I chose the
simpler fix which is to not have monsters hide in such situations. I found
the hiding code was duplicated in several places, so I moved it into a new
hideunder() function that works for both the hero and monsters.
+ Separate the two uses of flags.soundok.
+ Player-settable option is now called "acoustics".
+ Deafness is now handled as a full-fledged attribute.
+ Check for deafness in You_hear(), rather than caller.
+ Check for deafness in caller, rather than verbalize(),
because gods can speak to characters in spite of deafness.
+ Since changes are being made to prop.h, reorder it to the
same order as youprop.h and enlightenment.
There are still some extraneous checks and missing checks
for deafness, which will be followed up in a future patch.
Because of the size of this patch and its savefile incompatibilities,
it is only being applied to the trunk code. Portions of this patch
were written by Michael Allison.
Pat Rankin wrote:
> collect them all into some new struct and
> save that separately rather than jamming more non-option stuff
> into struct flags.
This patch:
- collects all context/tracking related fields from flags
into a new structure called "context."
It also adds the following to the new structure:
- stethoscope turn support
- victual support
- tin support
<email deleted> wrote:
> If more monsters fall through a trap door than can fit on the
> level below, when you go down the stairs, you get the following
> message:
> "Program in disorder - perhaps you'd better #quit.
> rloc(): couldn't relocate monster"
> This message seems to appear once for every monster-too-many that
> fell through the hole. I originally found this while
> intentionally completely filling a level with black puddings
> (there was a trap door I didn't know about). I also confirmed it
> in a wiz-mode test using gremlins and water.
[confirmed: moveloop -> deferred_goto -> goto_level ->
losedogs -> mon_arrive -> rloc -> impossible]
This patch:
- causes rloc() to return TRUE if successful,
or FALSE if it wasn't.
- adds code to mon_arrive() in dog.c to deal with
the failed rloc()
- allows the x,y parameters to mkcorpstat() to
be 0,0 in order to trigger random placement of the
corpse on the level
- if you define DEBUG_MIGRATING_MONS when you build cmd.c
then you'll have a debug-mode command #migratemons to
store the number of random monsters that you specify
on the migrating monsters chain.
If you dug in a pit next to a sleeping, angry monster, you'd stop every
turn due to a complex check at the end of dochugw. It turned out this
was due to a long-standing bug in the special case vision code that failed
to set the COULD_SEE bit for the locations where it set the IN_SIGHT bit.
It looks like the underwater code had the same problem (it didn't set the
bit, obviously there are no pits underwater). However, the same could
occur if you see the angry, sleeping monster with Xray vision. In this
case, setting COULD_SEE is not appropriate, so added a mcanmove check to
the complex check in dochugw.
When Angels were introduced, they were always lawful. Somewhere along the
line, non-lawful angels were added, but is_lminion and uses of it was never
updated to address this change. Among other things, this resulted in
non-lawful angels delivering messages via #chat that are only appropriate
for lawful angels. That is addressed simply by changing the definition of
is_lminion, which must take a struct monst, not a permonst, to return valid
results. Also, non-lawful angels should summon appropriate monsters, not
lawful minions.
<Someone> noticed that the change to require axes for trees (and allow them for
doors) did not extend to monsters. Now it does.
- added 2 new weapon check flags to handle the new cases
- added some detailed digging flags to mfndpos, based on ALLOW_DIG, and
moved some common logic regarding that flag into mfndpos
- made the ARMS check consistent for 2-handed weapons
I also noticed that simply carrying a pick was enough to allow a monster to
dig a door; wielding wasn't required. This is fixed as well.
Pat forwarded a message from the newsgroup in March that the town guards
enforce rules even outside the town proper. Fix: On room-based town levels,
check if the location is in a room containing subrooms (roomno will often
have a subroom id instead). On the other levels (e.g. minetn-5), there are
no subrooms, so the whole level is fair game. Currently, this is valid.
If fancier towns are added in the future, more flags or use of regions may
be required to tell where the town border actually is. These checks are done
in a new in_town function.
<Someone> (and later <Someone>) reported along with several other
things of a dwarf that stood in place and switched between his pick-axe and
broadsword on successive turns. Fixed by bringing the logic in the two
cases in line. The code now prefers to leave the hostile dwarf with a weapon.
- when a shopkeeper leaves the shop to chase the player, and the player
enters the shop, bill_p is set to an unusual value. bill_p needs to be set
back to a valid value if the shopkeeper re-enters the shop.
- Also, the u.ushops state needs to be updated when a shop becomes tended
again if the player is in the shop.
- introduce a new after_shk_move function to handle this
