finish_meating was checking whether the monster in question was a
chameleon/shapechanger, rather than whether it was a mimic, in deciding
which monsters should be allowed to maintain their current appearance
once they finish eating. This meant that true mimics had their
appearance reset, while a chameleon, vampire, etc, who ate a mimic
would maintain their appearance as a tripe ration even after they had
finished eating and resumed their normal behavior. The result? An
amazing living tripe ration which followed the hero around throughout
the level.
The way statues of stoned unique monsters were marked as "historic" was
not changed when mkcorpstat flags were updated in 04a8ddc, resulting in
unique statues which were no longer marked as historic and were instead
marked as female.
While fixing that, also use the gender-related mkcorpstat flags to
assign the gender of a stoned monster to the resulting statue.
Some messages about owing a shopkeeper money would use 'it' when blind,
with weird results such as "You owe It 267 zorkmids for goods lost." It
seems maybe like these were missed in 6591f8b since they were outside of
shk.c/shknam.c. Bring those messages into alignment with most other
shopkeeper-related messages, which use the shopkeeper's name even if the
hero is blind or can't see them at the moment.
Some of the 'it gets angry' ones don't seem so bad, but similar 'gets
angry' messages in shk.c use Shknam so I changed those as well for
consistency's sake.
If a random G_[SL]GROUP monster was generated in a zoo, the resulting
group of monsters could spill out into nearby hallways and other
surrounding areas. Disregard G_GROUP flags when filling a zoo with
monsters to avoid this problem.
The hero in an aquatic polyform loses HP for time spent out of the
water; allow magical breathing to prevent this, just as it allows the
hero in her non-aquatic natural form to breathe underwater.
Also add a similar rule for monster fish-out-of-water HP loss, even
though currently monsters can't use amulets of magical breathing and
there's no non-breathing fish/eel -- just in case this changes at some
point.
Giving new_light_source '(genericptr_t) mtmp' leads to the light
source's id.a_monst being set to 'mtmp->nmon' rather than 'mtmp',
since that's what is stored in the initial byte of the monst struct.
When mtmp->nmon == 0x0 this can cause a segfault in do_light_sources.
Because some spots in the fly's 'legs' on the Baalzebub lair level are
specified as pools in the level file, then later converted to walls in a
post-generation fixup routine, monsters can be generated on those spots
and then left walled up and inaccessible, Cask of Amontillado style.
For the love of God, makemon-tresor!
Some code already existed to relocate these monsters after generating
the level, but it depends on misorientated 'leg segments' being fixed up
in a particular way. That wasn't being triggered because it didn't
account for the possible rotation of the level; as a result, the
monsters in the leg segments wouldn't be relocated, and the leg segments
themselves would continue to have the wrong orientation.
Account for possible level rotation so that the monsters are relocated
properly (and the leg segments are 'fixed').
Another (latent) case of an artifact possibly being generated and
immediately deleted: part of the process of a mimic disguising itself as
an item involves generating a random object, then deleting it. If this
item is a box or sack, it will generate with random contents, which will
be deleted along with the container. If artifacts are allowed as random
box contents, this can silently remove an artifact from being available
in the game.
This is effectively blocked already, since none of the artifacts
eligible for random generation are items from classes marked as valid
box contents (see boxiprobs[] in mkobj.c). Nonetheless, formally
preventing artifacts from generating as box contents will guarantee this
issue won't crop up if a randomly generated artifact tool, ring, etc, is
added in the future.
Death drops will generate a random item, which may be an artifact.
After the object is created, some rules are applied to check whether its
size matches the monster that dropped it; if it fails these checks,
the item is deleted. aosdict recently pointed out that if the death
drop was an artifact, this would permanently remove it from the game.
Use artifact_exist(..., FALSE) in various cases where potential
artifact objects are created, then immediately removed. This will
prevent artifacts from being removed from play by marking the artifact
as available to create again.
https://github.com/NetHack/NetHack/pull/573 by entrez
Pull request comment states:
"Moving into a position containing a warning symbol with m-<direction> to
'safely' move would still attack as though the 'm' prefix was not
specified. Ensure warning symbols are counted as 'detected' monsters
for this purpose, to avoid falling through to do_attack()."
Closes#573
Updates to m_dowear_type(worn.c) in 5a09a01a13 inadvertently reversed
the effect of an xor near the end of the function, causing it to go from
testing whether a monster's status as 'seen' or 'unseen' changed over
the course of the function to testing whether it remained the same.
As a result, whenever an unseen, invisible monster donned a piece of
armor anywhere on the map, the message 'suddenly you cannot see it'
would be printed. Fix the xor so that it goes back to testing whether
visibility changed since the start of the function.
Drinking booze on an empty stomach will amplify its effects
(i.e. increase the duration of the resulting confusion); stuffing
yourself before drinking will have the opposite effect.
Popeye, used to check whether eating a particular tin is a potential
lifesaving action, considered tins of chameleon meat a cure for sliming
(since you can polymorph into a fiery monster), but didn't credit the
same possible curative power to other tins which can polymorph the hero.
Use the polyfodder macro (used elsewhere to check whether eating
something will polymorph a monster/pet) to determine whether a tin will
polymorph the hero.
(including resuming travel after being interrupted)
Attempting to travel from an 'interesting' spot that would normally
stop travel mid-attempt (next to a door, next to a monster, etc) would
fail to get off the ground, because the 'interesting thing' would halt
travel before taking the first step.
Prior to 433f0cc, initiating travel would immediately trigger a call to
domove in rhack; as part of refactoring travel, the order of events in
rhack was changed so that this didn't happen immediately as before. Add
domove to the end of dotravel_target to produce a similar effect to the
previous arrangement.
domove also zeroes out g.domove_attempting, which I think is the reason
c0c617c seemed to mitigate some of the issues associated with this
problem (e.g. travel target selection seemingly not registering right
away).
Fixes#559
Messages for dropping an object on a trapdoor or hole seemed to
imply they still operate by the rules of a pit (that any object on the
same square as the trap is automatically inaccessible). Since this is
no longer true for trapdoors and holes as of 1b7c372f, it seems
misleading to say an item "tumbles into the hole" even when it doesn't
fall through and stays on the current level.
Even for an item which really did fall through to the level below, these
messages were redundant since they were immediately followed by
near-identical messages from down_gate(dokick.c).
Limit the "tumbles into the pit" messages to pits only, and rely on the
standard down_gate message for items which fall through a trap door
or hole.
Items on a trap door or on the edge of a hole are accessible (they can
be picked up, kicked, etc), but these locations were considered
inaccessible for purposes of feeling the ground for objects while blind.
If an engraving was appended to repeatedly, it could eventually exceed
BUFSZ and cause a crash. Add some checks to prevent this from happening
and inform the player when she runs out of space to engrave on a
particular square.
Engraving with a marker can use up remaining charges to write
semi-permanently in ink, or--if the marker has no remaining charges--can
draw in the dust as with a normal blunt item. Handling in engrave after
a recent refactor (9c6a5fc423) didn't fully cover this second case, and
as a result using an empty marker to engrave would deduct a charge per
attempt and cause an impossible. This could be exploited by repeatedly
engraving with the same empty marker to underflow the marker charges.
The for loop which iterates through the list of movement keys in
movecmd(cmd.c) was updated in 5abf948116 to count down to 0 instead of
up to the end of the list. This commit inadvertently introduced an
off-by-one error which started the loop one past the actual end of the
array. On my system this made 'H' stop working as the 'run West' key.
Functionally similar to reading a T-shirt or apron, but rather than
actual text printed on the shirt being displayed, the design of the
Hawaiian shirt is described: for example, "hula dancers on an orange
background" or "tropical fish on an abstract background". Much like
T-shirts have their text included in the game-end inventory list ('a
blessed +2 T-shirt with text "foo"'), Hawaiian shirts now have a brief
description of their design appended to their item name under the same
circumstances.
Because 'reading' a Hawaiian shirt doesn't actually involve reading
text, using the 'r' command in this way doesn't break illiterate
conduct.
If a monster with a theft attack (nymph or leprechaun) stole something
from an invisible monster (e.g. while under the influence of conflict),
and the attacking monster was not itself invisible, the monster name
buffer used when printing the "<foo> suddenly disappears!" message would
be used while still uninitialized. The attacking monster's name was
only copied into the buffer if the defending monster was visible, but
would be used regardless to print the pline if the attacking monster was
visible and teleported away successfully after the attack.
Nymphs' item theft attack against other monsters was broken in 1696019,
when a break used to select a particular item in the target monster's
inventory was changed to an early return.
Let users of #wizintrinsic set a specific amount by which they want to
increment each particular timeout, by entering a count/typing in
numerals before selecting the item in the list. I think doing it this
way should be pretty intuitive to players who are familiar with the
'enter count -> make selection' flow of normal inventory menus in
NetHack, and is simpler than using a separate prompt, as was mentioned
as a possibility in a comment.
When an intrinsic is selected without entering a count, the increment
will continue to default to the previous value of 30; this value is set
via the DEFAULT_TIMEOUT_INCR macro.
I also deleted a redundant declaration of wiz_intrinsic; the duplicate
seems to have been added by mistake in ff6139c6c5.
Because landing_spot will select a square containing a boulder as a
last-resort option, provided no other squares are accessible, it is
possible for the player to maneuver into a place where this could be
exploited when completing Sokoban (e.g. to get into a corner that would
normally be inaccessible, from which position an otherwise-blocked
boulder can be pushed away). This behavior should incur the same penalty
as exploitation of other Sokoban 'loopholes'.
Dismounting a steed checked whether the target spot was accessible and
whether there was a monster on it, but not whether it could actually be
accessed by the hero through normal movement. As a result, dismounting
allowed the hero to pass between diagonal gaps that would normally cause
a "you are carrying too much to get through" pline; this could leave
them in a position where they are effectively stuck, unable to remount
their steed or move away without dropping their inventory.
This also could be abused by dismounting in Sokoban to squeeze between
boulders in a way that would normally be impossible.
Using a successful result test_move as one of the requirements for a
spot to be valid prevents this and limits valid dismount targets to
squares that would normally be accessible through standard movement.
Land mine explosions did not call liquid_flow(dig.c), and as a result
the pit created by an exploding land mine would never fill with adjacent
water or lava, as pits created by other sources -- digging, breaking a
wand, and earthquake -- can do.
This commit adds the appropriate calls to liquid_flow and fillholetyp to
blow_up_landmine so that land mine explosions may fill with water like
other pits do.
The call to losehp in dotrap had to be moved from after to before
blow_up_landmine, since waiting to call losehp when the pit can fill
with water could lead to silly messages (``That was a close one. You
die...''). After this change, a land mine that killed a character would
be retained unexploded in a bones file, because death would occur before
the call to blow_up_landmine. To avoid this issue, the land mine is
converted to a pit before calling losehp; blow_up_landmine does not
check whether the target trap is in fact a landmine so works as usual
even if the trap is converted to a pit, and will delete the pit in cases
where it should not exist.
Using a for loop instead of an if and a do/while makes the code much
more clear and concise, so that it's easier to understand what the
function does at a glance. The actual approach to iterating through the
current level's bones files and searching for a match is more or less
unchanged.
Multiple functions are involved in the process of targeting and
attacking an enemy with a polearm or lance, and these functions
previously used inconsistent tests to determine which targets were
legal. For instance, find_poleable_mon would give up immediately if the
hero was blind, while neither get_valid_polearm_position nor use_pole
cared as long as the hero could detect a target on the square (e.g. by
ESP). find_poleable_mon considered warning symbols as potential
targets, but use_pole discarded them. get_valid_polearm_position
considered moats and pools to be illegal targets, but use_pole would
let the hero successfully hit a monster on those squares; on the
other hand, get_valid_polearm_position would mark squares that were not
visible and did not contain a known monster as legal targets, while
find_poleable_mon and use_pole would exclude them.
Obviously this was inconsistent and could introduce confusion for
polearm users, who would potentially need to explicitly target squares
marked "(illegal)" at some point over the course of their game, among
other problems. This commit makes polearm targeting tests more
consistent; the following rules are applied to positions within the
appropriate range:
* Monsters which are detected by any means that reveals an actual
monster glyph are legal to target, even if the hero is blind
* Monsters the hero cannot detect, but is aware of -- i.e. those
represented by an 'I' -- are similarly legal to target
* Monsters detected via warning are not legal targets, since the hero
does not have as strong a sense of where exactly they are, their shape
and size, etc
* Statues are legal targets, but will not be suggested by
find_poleable_mon unless the hero is impaired (confused, stunned, or
hallucinating); the same is true of tame/peaceful monsters
* Apparently empty squares, including those containing an undetected
monster, are legal to target unless they cannot be seen (whether due
to blindness or a very dark room/level)
* Positions which are otherwise legal but are blocked by an obstruction like a
tree or pillar are not legal targets
After modifications to amnesia, `deja vu' messages are now displayed
upon entering a level containing bones of a previous character of the
current player. This test is done simply by checking for a ghost on the
level that shares a name with the current character.
However, since ghosts generated in other circumstances (such as in the
Valley of the Dead and other special levels) can have names pulled
randomly from the high score list, etc, this message can be displayed on
non-bones levels where a ghost has been generated with the character's
name. Additionally, when a bones pile doesn't include a ghost (such as
when the character in question was slimed, killed by a wraith, etc), the
`deja vu' message will not be displayed when it should be. This is all
described in in NetHack/NetHack#322.
This commit changes the method of testing for `familiarity' by adding a
function to iterate through any bones data for the current level,
searching for a match to the hero's name.
Should fixNetHack/NetHack#322.
Michael Meyer