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