From a bug report,
when falling into a spiked pit and being killed and then life-saved, you
could immediately die from fatal poison. It isn't necessarily a bug and
there are other ways to be killed, life-saved, and re-killed (such as
zaps that bounce off walls or reflecting targets), but it does seem to be
somewhat unfair. This patch makes life-saving be more effective: in a
damage-plus-poison situation, if the damage triggers life-saving then the
poison won't deal out any further damage (including its nasty chance for
instant death). The poison still matters, but it will always target an
attribute stat--which is already one possible random outcome--instead of
maybe doing damage. [It is actually possible to get damage if stat loss
tries to take hero's strength below 3, but now there's no chance of that
being fatal immediately after savelife() has restored full hit points.]
Suggested by <email deleted> a month ago when he
reported that attempting to unlock a door which was actually a mimic
simply told the player that the door was not locked or that there was
no door. He thought that mimic should take the key/pick/card away from
the hero. This gives a 50% chance for the unlocking tool to be stolen
and become part of the mimic's inventory; it will be dropped when mimic
is killed.
The theft routine has groundwork to be able to be used to take the
hero's wielded or thrown weapon when hitting, but the attack code doesn't
call it so that won't happen (and the theft code hasn't been tested under
that circumstance). I'm not sure whether mimics should be able to grab
weapons, but g.cubes perhaps should, and if puddings could then "pudding
farming" [using a low damage iron weapon to split puddings, yielding tons
of experience, death drops, and #offer fodder when they're killed and
repeatable for as long as at least one pudding is kept healthy enough to
be split again] would become tougher to accomplish. [The item drop and
corpse aspects have been toned down quite a bit since 3.4.3, but with
sufficient patience it is still possible to abuse.]
Noticed while testing a forthcoming mimic patch: when blind, some
actions (open, close, #untrap, applying a key [as of a month ago],
possibly others) taken against a mimic posing as a door would yield
"Wait! That's a monster!" but leave the map showing the door instead
of replacing it with the unseen monster glyph. Similarly, using #untrap
towards a known trap location covered by a concealed mimic could yield
"It is in the way." or "It isn't trapped.", depending upon the type of
trap present, and not reveal the mimic. Same thing happened when not
blind, except the message would refer to "the <size> mimic" rather than
"it". Now it will expose the mimic, regardless of the type of trap.
Noticed while looking through steal.c: theft that takes multiple
turns uses stealarm() callback which removes stolen armor from hero's
shopping bill, but theft that happened without delay did not. So theft
of an unpaid non-armor or non-worn item while in a shop left it on the
bill where it wouldn't show up for either ``I u'' or ``I x'', hiding the
charge from the player ('$' did disclose the total amount that the shk
was owed though), and the shopkeeper would persist in blocking the door.
This makes immediate theft behave the same as delayed theft; the stolen
item is removed from shop's bill when the thieving monster takes it away
from the hero.
Dropped items that a shopkeeper doesn't want have their no_charge
bit set; that's only supposed to be used for floor items inside shops.
But no_charge would stick when an object was picked up by a monster, so
the object would stay free for player if that monster was subsequently
killed in another shop which stocked that kind of item. Probably never
noticed because most monsters won't pick up items off of shop floors,
also most levels don't have other shops dealing with alternate types of
stuff. This clears no_charge, except when the monster picking up the
item is tame (so that a pet picking up and then dropping a no_change
object in the same shop won't cause the shk to silently take possession,
which would certainly lead to reports of a bug...).
From a bug report, a purple worm
could swallow a ghost or xorn and end up inside solid rock. It took a
bunch of tries to reproduce this, but I eventually did. (I'm not sure
why it didn't happen every time a worm swallowed a target which was in
rock; the code for positioning an engulfer after it digests a target
always puts the engulfer in the target's former spot.) After this
patch, worms can still swallow ghosts and xorns, but only when they're
in locations the worm could walk onto.
I started to add handling for doorways containing mimic-as-boulder
to doopen() and doclose() as was done for pick_lock(), but decided that
it was better just to prevent mimics from appearing as boulders at closed
door locations in the first place. So the most recent pick_lock() change
and its fixes entry go away.
This also fixes a post-3.4.3 bug. On the top level of Sokoban I
discovered a boulder over a hole; probing reported it as a mimic with
0 hp. The special level loading code moves mimic-as-boulder away from
trap spots by using place_monster() to put it on another spot, but it
was missing the corresponding remove_monster() to take it away from the
original location so left a stale pointer on the map.
Reported five months ago by <email deleted>,
the top level of Sokoban has mimics who pose as boulders and if one was
in a doorway (treasure zoo at final destination) you could still unlock
the door there without waking the mimic. Yesterday's fix for unlocking
a door which was actually a mimic posing as one didn't handle this case.
From a bug report, attempting to use a key,
lock pick, or credit card on an open doorway that contained a mimic posing
as a closed door reported "that doorway has no door" or "you cannot lock
an open door" as if no monster was present, and failed to find the mimic.
<Someone> reported that being killed by a monster with a long name
can result in nethack going into an infinte loop printing spaces. Handle
this by detecting attempts to wrap the topten output on a word that is too
long and just inserting breaks in the middle of the word in this case.
Suggested by <email deleted>, chatting to a gecko will
give a reference to GEICO's car insurance ads. I limited it to when
the hero is hallucinating. Chatting to a gecko monster, or to anything
capable of speaking--except for a couple of previously handled special
cases, like quest leader--which happens to look like a gecko at the time,
or (50:50 chance) to a shopkeeper regardless of appearance, you'll get
"15 minutes can save you 15 zorkmids", parodying "15 minutes can save you
15% or more on car insurance". (One of my comments says there's a chance
to interfere with shopping, but that's not accurate since using #chat to
get shop price quotes doesn't use the monster-response routine. I left
that comment in anyway; the "15 minutes" response might interfere afterall
if someone mistakenly thinks they can save gold by waiting that long
before paying their shopping bill.)
I don't think we ever found a good place to add some reference to
GEICO's other--and more relevant to nethack--slogan, "so easy a caveman
can do it".
From the newsgroup: a player accidentally cast the stone-to-flesh
spell at himself (I don't recall whether he chose wrong spell or wrong
direction, or tried to cancel and game used last remembered direction)
and the barbarian quest artifact he was carring turned into a meatball.
Artifacts already have a high chance (95%) to resist being polymorphed
but that doesn't apply for the stone-to-flesh transformation. This
gives stone artifacts a high chance (98%) to resist being turned into
flesh. Non-artifacts also get a small chance (2%) to resist as well.
From a bug report, you could write scrolls
by type name ("magic mapping") if you had that type of scroll in your
discoveries list via assigning a name to an unknown scroll ("scroll
labeled FOOBIE BLETCH called foo"). Being on that list was enough to
treat the type as known when writing scrolls and books. And he fealt
that it was abusive to be able to collect and name a lot of unknown
scrolls and then write favorite ones which had good odds of being in the
collected set.
This changes it to the original intent: if your discoveries list
has FOOBIE BLETCH on it, you can write a scroll by that label (since we
decided way back when that a scroll's label was its magic, to explain how
a blind hero can read any scroll whose description is known even though
they aren't constructed in braille). If you have identified the type
("scroll of magic mapping labeled FOOBIE BLETCH") then you can write by
type or by description, but you can no longer write one by type when only
the description is known. There is a potential can-of-worms bug here:
if you walked across a "scroll labeled YUM YUM" but have not assigned it
any name, you've still learned its magic words and ought to be able to
write a scroll of YUM YUM. We don't have any mechanism to track items
which have been observed but not been put on the discoveries list. This
patch plugs one obvious hole, by scanning inventory to treat any seen
scroll labels there as an extension of the discoveries list. But the
more general case of something once seen but not named or currently held
is ignored.
This also adds writing scrolls by the user-assigned name, so if
your discoveries list has "scroll labeled FOOBIE BLETCH called foo" you
can write either foo or FOOBIE BLETCH to get the scroll. I'm not sure
the bug report advocated that--parts of it were a bit confusing, at
least to me--and I'm not completely sure that we want to have it, but it
does work. Without it, you got "no such thing as \"foo\"", which seems
counter-intuitive when "foo" is there in plain sight on your discoveries
list. The new code chooses randomly if multiple scrolls have been called
"foo". And if you've called something by an actual object name, it uses
your knowledge of that object rather than anything you've given its name
to. In other words, if you have "scroll labeled YUM YUM called magic
mapping" and try to write magic mapping, it will use your knowledge--or
lack of same--about scroll of magic mapping rather than scroll labeled
YUM YUM to decide whether you'll succeed.
There is also a minor tweak in the chance to write a completely
unknown scroll or book. Wizards almost never failed once their Luck was
5 or more; using rnl(5) instead of rnl(3) requires Luck 11 rather than
just 5 to get that ~39/40 chance of success. Non-wizards didn't change.
Lastly, this fixes an unrelated bug when writing spellbooks. The
message "the spellbook warps strangely, then turns <new description>"
works okay when <new description> is "red" or even "ragged", but not so
well when it's "vellum". A handful of book descriptions refer to the
item composition rather than the appearance of the cover, and turning
into a new composition needs different phrasing. I just tweaked it to
be "turns into vellum", which is probably suboptimal (particularly for
the book description "cloth" :-).
From the newsgroup, losing spells to amnesia always took away the
last 'N' spells after choosing a random N. That kept casting letters
sane, since letters for lost spells became invalid and those for non-lost
ones stayed the same as they were before amnesia. But 3.4.x gave the
player the ability to swap pairs of spells, so he could make his favorites
to be the first spells, and only lose them if the random number of spells
being affected was as large as the whole list. (Also, divine spellbook
gifts give preference to books for unknown spells; in theory, you could
use spell letter manipulation plus deliberate amnesia to make a particular
spell revert to unknown in order to improve the chance of getting a new
spellbook for it. A bit of cleverness by a determined player but it
makes the game and/or its patron deities seem a bit dumb in the process.)
I first implemented losing spells throughout the list, with later
spells moved forward to fill any gaps. But that results in new casting
letters for every spell past the first lost one, potentially wreaking
havoc if a player chooses a casting letter from his own memory of the
pre-amnesia list. So, instead of losing some spells entirely, either
from the end of the list or spread throughout, I've changed amnesia to
set the retention amount (of N spells from throughout the list) to zero,
the same as happens when it's been 20000 turns since the spell was last
learned. Letters for all known spells stay unchanged, and forgetting
due to amnesia becomes the same as the other way of forgetting spells.
(So now a different potential clever use of amnesia occurs; a player who's
trying to a make speed ascension could get access to expired spells--to
cast in order to become confused--without waiting for 20000 turns after
reading the first book.)
From a bug report, when putting on a
cloak of displacement you discovered what it was even if you were invisible
and unable to see invisible, hence couldn't see yourself. It isn't exactly
clear what the hero sees of himself when displaced, but I think it makes
sense that you shouldn't discover the cloak when you can't see yourself,
which suggests that you shouldn't discover it when blind either.
Discovering it after regaining sight, becoming able to see your
invisible self, or losing invisibility seemed complex and likely to be
bug-prone, so this patch leaves the cloak undiscovered in that situation.
But it does become discovered when taken off (provided that you can see
yourself by then) rather than waiting all the way 'til put back on again.
Elven cloaks had a comparable issue. I assume that stealthiness can
be perceived without being able to see yourself, but it shouldn't become
discovered when you're already stealthy from some other means. (Elven
boots already behaved this way; now elven cloaks work like them.)
Rings of stealth would never be auto-discovered. Now they'll be
like elven cloaks and boots and be discovered if put on when not already
steathy or taken off and losing stealth. In both cases, the ring has to
have its description known; if picked up when blind and still not seen
yet it won't become discovered even when you notice yourself gaining or
losing stealth.
Not tested: feedback given when a worn ring or cloak gets dipped
into a potion of polymorph and changes into or away from a stealth or
displacement conferring item.
add SYSCF docs to the Guidebook because it's info needed in a binary distro
Guidebook.tex - also add some missing italics to some "NetHack" occurances
call nethack.org "official"
Guidebook.txt - didn't regenerate cleanly so no diff
add SEDUCE to SYSCF (only partly inspired by the recent email)
Add a man page for makedefs so mdgrep is documented better.
Add missing INSURANCE to mdgrep.h. (yes, LIFE leaks in as well)
Add makefile bits to build makedefs.txt.
Pass dungeon.def through mdgrep internally to makedefs - this will make
it possible to commit the LIFE patch and have config.h actually turn it
all the way off (by skipping bigrm-6).
Have being crowned Hand of Elbereth/Envoy of Balance/Glory of Arioch
give a minor extra benefit beyond resistances and an artifact and maybe
unlocking the artifact's skill: one extra skill credit, making it
feasible to earn 30 rather than 29. (Previously the only way to get any
was to receive one for each new experience level, so you could gain one
29 times when going from level 1 to level 30.) Added as a new feature.
From a bug report, assigning
a vault guard a name such as Marcel could result in messages like
|The Marcel, confused, disappears.
Many of the guard messages had article "the" hardcoded. This gets rid
of g_monnam() and uses noit_mon_nam() instead.
I haven't been able to test all the modified messages; it's a pain
trying to get some of them to occur.
Fix a bug From a bug report: while stunned he tried to close
an adjacent open door and when his choice of direction got changed to
some non-door spot, no time elapsed so he could just keep repeating the
attempt until eventually getting the correct direction. Trying to open
an adjacent closed door and trying to remove the saddle from an adjacent
monster via #loot behaved similarly. Applying keys and lock-picks also
did so in 3.4.3, but had already been changed to use up time in the dev
code. There may be other actions which need fixing.
PORTS: Please make sure I've done the right thing for/to your code.
This patch adds a new winproc that lets the window port approve or cancel
the suspend request - this should take care of the Mac Qt lockup issue.
In addition, Unix suspend is restricted to accounts that can use the shell
if SYSCF is defined.
From a bug report, attempting to respond with ESC when playing an instrument
just continued with the playing sequence. This adds a q choice to the
"Improvise? [yn]" and "Play passtune? [yn]" prompts, and also checks
for ESC as the 5-note tune when not improvising, yielding "Never mind"
and not using up a turn if the player opts not to play any music.
I put the fixes entry in the new features section since the old
behavior wasn't much of a bug.
From a bug report, if you entered water
while blind and any spellbooks got blanked, you would know they became
"plain spellbooks" iff their original description was known. The same
situation applied to scrolls and potions; if they had been previously
seen you'd learn they'd become blank or clear. This fix resets the
obj->dknown flag during transformation so that altered objects are only
known by their class when blind, never their description, the same as
when they hadn't been seen before being blanked. (When sighted, the
dknown flag gets set again the next time the object's name is formatted,
so the player shouldn't be able to notice that any reset took place.)
Unpaid objects which get blanked should be treated as used up for
shop billing purposes (force the hero to buy), but there aren't any pools
in shops so aside from the added comment I'm going to pretend I didn't
notice that that isn't being done....
Potions seen before becoming blind which become diluted while blind
will be known to be diluted since there's no way to know the description
without also knowing the dilution. I don't think that's important enough
to track known-dilution separately, although I suppose we could overload
the cknown (contents-known) flag for that if necessary.
This also removes an inaccurate comment about the effects of Luck.
Its maximum is always 13 regardless of whether the moon is full, so 5%
for the lowest chance of blanking via submersion was impossible.
From a bug report, you could write a
spellbook with a magic marker while blind and were told the description
(often a color) of the resulting book. This prevents books from being
written while blind, just as they can't be read in that situation, and
it adds an extra test when attempting to write scrolls while blind.
(When you succeed in writing a scroll while blind, you're just told that
the result is ``x - a scroll'' as it's moved to its new inventory slot.)
This also removes a couple of overly hyper exclamations when writing
fails. Someday somebody ought to go through the whole program and decide
which messages actually warrant exclamation points, but I doubt that
that'll ever happen.
Someone in the newsgroup has a keyboard where typing '#' is difficult
or impossible to do, and mentioned that he could use Alt+r to get #rub but
was playing a knight and had no way to get #ride. Turns out that there
are several normal-mode extended commands that lacked a meta shortcut.
Since meta chars are case sensitive, I've added Alt+R for #ride, plus
M-A for #annotate, M-O for #overview, M-C for #conduct, and M-T for #tip.
Unfortunately, I've been unable to test them. It turns out that
nethack mode in PuTTY doesn't change the Alt key into a meta shift, it
causes the digits on the number pad to send vi-style movement letters
(with support for shift+digit and ctrl+digit to send modified letters).
That seems relatively useless to me, and I haven't figured out how to
force on high bit for arbitrary characters so can't activate nethack's
meta-key shortcuts.
The Guidebook has been updated via copy+paste and is untested too.
From the newsgroup: the 'O' command's menu for setting pickup_burden
shows "Unencumbered" for the 'u' choice but the Guidebook and the in-game
options help show "Unburdened". (For config file processing, the program
only examines the first letter so accepts either value.) This changes the
documentation to match the game.
From a bug report, drinking a potion of
polymorph which is wielded would trigger an "object lost" panic if hero
took on a form that was forced to drop its weapon. Once weapon/potion
got dropped, subsequent useup() of the potion was no longer operating on
an inventory object.
Unwield the potion at start of drinking, so that dropping doesn't
come into play. (If we ever introduce a monster form incapable of
holding inventory so drops everything, this will have to be revisited.)
From a bug report, it was possible to get
|You hit the with all your might. You stop digging.
if a boulder went away--in his case, it was picked up by a giant--while
you were occupied trying to break it with a pick-axe. The code explicitly
used "" to fill in the message when dig_target had an unexpected value.
This just avoids giving the message in a case like this. Possibly
extra stop_occupation() calls should be done instead, but I didn't want
to try to figure out how many would be needed (monster picks up object,
monster zaps wand of striking, others?).
From a bug report, message sequence
when throwing a poisoned weapon which loses its poison was confusing.
|The dart is no longer poisoned.
|The dart hits the acid blob.
|The poison doesn't seem to affect the acid blob.
This patch makes the first sentence come out last.
[It appears that poisoned weapons thrown/shot by monsters or traps
never lose their poison. That can't be right....]
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?]
From a bug report, if you were a mimic
who was hiding (via #monster, becoming a strange object) and polymorphed
into some other monster type, you retained the hidden/object form. That
didn't happen when reverting to normal form, or when polymorphing into a
monster while involuntarily mimicking gold, but handling for the latter
inadvertently blocked dealing with the hiding-voluntarily case.
From a bug report, black dragon breath
destroys closed doors didn't acknowledge hitting secret doors. bhit()
reveals secret doors, but zap_over_floor() (called by buzz() for ray-type
wands and spells, and for breath attacks) didn't check for hitting those.
When testing the fix, I noticed that feedback for an explosion caused
by breaking a wand was worded oddly for zaps like magic missile which don't
damage doors. "The door absorbs your bolt" didn't make much sense; what
bolt? That was first changed to "absords your blast", which still sounded
weird, then to "absorbs the blast", which seemed better but was inaccurate.
Next was "absorbs some of the blast" since the explosion continues to hit
adjacent spots, but since it still has full strength that wasn't accurate
either. It's finally become "The door remains intact." Unlike with zaps,
there is no additional range being lost, so no reference to absorption.
From the newsgroup: player saw "The spell hits the <monster>?"
where the question mark punctuation reflected negative damage occurring.
Another player diagnosed it as a 2 point force bolt (from 2d12 dice role)
modified by -3 penalty for hero who has Int less than 10. This changes
spell_damage_bonus() to avoid reducing damage below 1 point.
From the newsgroup: someone using <Someone>'s level-flip patch
(to transpose special levels left-to-right or top-to-bottom or both in
order to get more variety from them) ended up in solid rock. When
climbing the stairs up from the Valley to the Castle, goto_level() was
hardcoded to find a spot in the extreme lower right corner. If the level
is turned upside down, solid rock from an unused row at the top edge of
the map ends up at the bottom, and the placement code could put the hero
there. That code only checked for walls and monsters being in the way,
not rock. Also, if the level is flipped side-to-side than hero ends up
in same area as the upstairs rather than on opposite side of the Castle.
This switches to the same teleport-region code used for other level
changes which don't arrive on stairs; such regions get flipped along with
map by that patch (I hope). Even though no such fix is currently needed
for unmodified nethack, this change gets rid of the special case Castle
placement code entirely, simplifying both goto_level() and u_on_sstairs()
in the process.
The Castle's existing from-below region covers the rightmost half-
dozen or so columns across all rows, so offers a bigger landing zone than
just the bottom corner. That could be tweaked within castle.des but I
don't think it needs to be.
Recent newsgroup discussion complained about a pearl ring becoming
rusty. That has no effect on game play but does feel weird. Rings which
are described by their gems specify a material based on the gem rather
than on the band, so making pearl rings be made out of iron didn't fit.
The substance pearls are made of is the same as in the shells of the
oysters or whatever critters excrete them. The closest matches available
seem to be mineral and bone; I've gone with bone here.
From a bug report, the 'D'
command would list 'u' as an item category choice if you were carrying
unpaid items inside a container, but if those were the only unpaid items
then nothing would happen once the dropping stage was reached. Applied
to all menustyles (except partial, which bypasses categories and goes
straight to a menu listing all items). There were two alternatives for
the fix: suppress 'u' as an applicable category when it only applies
to container contents, or include the container among the drop candidates
even though it isn't an unpaid item itself. I went with the latter; it's
simpler to implement and also feels a little more intuitive than behaving
like there aren't any unpaid items present.
[See cvs log for src/role.c for a much longer description.]
When picking role, race, and so forth, new menu entries allow you to
pick any of the other items before the one currently being handled. After
picking all four of race, role, gender, and alignment (or if you answered
'y' to "shall I pick for you?"), there is a followup prompt to confirm the
choices. It's a menu which also provides a chance to rename the character.
This has only been implemented in win/tty's player_selection(), with
some support code in the core that might be useful to other interfaces.
And so far, the chance to rename is only presented as a menu choice if
you've given an answer to "who are you?" prompt earlier during startup.
Also, ports that use pcmain.c aren't able to perform hero renaming yet.
From a bug report, a long worm with 0 HP
was observed via stethoscope after cutting one or more worms in half many
times, followed by an unspecified crash. Cutting a worm doesn't reduce
its level below 3, but if a worm is drained to level 0 by some other means
and then gets cut in half (and still has at least 2 HP left), cutworm()
would give the new level 0 worm 0d8 (hence 0) for current and max HP.
That could confuse end-of-move monster cleanup, which thinks 0 HP is a
dead monster who has been removed from the map but not yet purged from the
fmon list. Purging it would then leave a stale monster pointer on the map.
cutworm() should have special cased level 0 to use 1d4 for HP, but
instead I've changed it to not produce a cloned worm if the source one is
lower than level 3.
In #H1820, <email deleted> reported that helms
of opposite alignment didn't work for monsters. There's never been
any attempt to implement that, and it wasn't omitted by accident, so
I wouldn't classify it as a bug. But it does seem buggy that temple
priests and minions of <deity> would be willing to put such helms on
and risk changing allegiance to another deity. This lets other types
of monsters still wear helms of opposite alignment as ordinary head
protection, but the explicity aligned creatures won't do so anymore.
use_whip() prompts with getdir(), which doesn't prevent the player
from deliberately pointing off the edge of the map, so the bullwhip bug
was more general than yesterday's fixes entry. Being confused or stunned
could trigger a problem but one could happen without them.
From a bug report, applying a polearm to make a
short-range ranged attack didn't scuff any engraving you were standing on,
unlike ordinary melee and throwing/shooting attacks. Grappling hooks had
the same omission. Fixing it led to several other minor bugs. Attempting
to target an unseen monster's spot with polearm or grapnel would yield some
permutation of "wait, there's something there" but draw the 'I' glyph at
the wrong spot. It used <u.ux+u.dx,u.uy+u.dy> instead of the actual target,
so put the 'I' one step in front of your most recent move (or throw or zap
or whatever last set u.dx and u.dy). Giving ESC when prompted for target
spot failed to use up a turn even when the polearm or grappling hook had
just been auto-wielded for use. Neither use_pole() nor use_grapple() set
`notonhead' for hmon() (called via thitmonst() in their cases; this was
academic since plain physical damage attacks don't actually care about it).
[The bad 'I' placement was a post-3.4.3 bug.]
Applying a bullwhip to attack an adjacent monster didn't have any of
those issues but did have the possibility of targetting off the edge of
the map when standing at that edge while confused or stunned.
Applying a polearm to target an 'I' would yield "nothing happens" if
the unseen monster wasn't there anymore, and it didn't bother to remove
that 'I' from the map. After changing it to do so, the phrasing no longer
made any sense. This led to a slightly bigger change than I intended:
since statues are now shown as gray monsters (does that work for tiles?)
instead of as chunks of stone, they are likely to be intentional targets
sometimes, so polearm attacks now handle them differently from other
non-monster locations. [I hope that other attack forms don't need
similar handling. Melee certainly doesn't, since walking onto the spot
is enough to distinguish statues from monsters. Having the missile pass
right through a statue's location probably suffices for ranged attacks.]
From a bug report.5 years ago? and again today:
mimics appear on the rogue level even though they're lowercase letter
monsters. <Someone> notes that during level generation, mimics pretending to
be closed doors are sometimes substituted for trapped actual doors. That
should be avoided on the rogue level both because its doorways are always
empty (enforced after the fact in extralev.c code rather than in the door
making code) and because mimics aren't uppercase letter monsters (so
should only ever appear there if they've travelled from another level).
Noticed while testing the patch for monster ranged attacks when hero
is hidden. Using #monster while in small mimic form would hide you, as
intended, but the first monster (or last monster?) who hit you hand-to-hand
would be grabbed ("It gets stuck on you."). Unlike large and giant mimics,
small ones lack such a grab attack so when you eventually returned to
normal form, u.ustuck would remain set and you would end up being stuck
to an arbitrary monster instead of releasing it from your grasp.
