Some maze code treats row y_maze_max and column x_maze_max as being
in play, other parts treat them as out. mazexy() was doing both; the
first loop to choose a random spot allowed them, the second loop to
try every possible spot disallowed them. Make those be consistent.
I think the extreme row and column are both expected to be solid wall
so failing to consider them might not be causing any problems.
While in there, change mazexy() to not set cc->{x,y} until it has
found a viable spot instead of potentionally making that assignment
dozens or hundreds of times. The only difference there is that 'cc'
won't have been assigned any value if panic() gets called.
Complain during level creation if stairs are placed on top of anything
other than the expected room/corridor/ice terrain. This won't prevent
the bug of upstairs and downstairs existing on the same spot (github
issue #702, also a newsgroup posting by a hardfought player) but might
at least warn players if/when that happens.
Spiders and cockatrices were using the default animal_parts, which was
noticeably inaccurate in describing certain parts of their bodies. Add
specific handling for both types of monsters: for spiders, add a
spider-specific body part list (the best I could figure out from online
sources, not being a spider anatomy expert), and for cockatrices, use
bird_parts with "scales" from snake_parts thrown in to emphasize their
unusual nature.
For menustyles traditional and combination, allow 'IP' to request
inventory listing of just picked up items even if not carrying any
items flagged as just picked up. The not carrying any such items
feedback was already present but couldn't be triggered.
For menustyles partial and full, the special menu entry for 'P'
when only one item applies shows the item instead of the category
"Items you just picked up". [That sort of thing probably ought to
be done for every menu entry rather than just for 'P'.] Rephrase
it from
| P - <item>
to
| P - Just picked up: <item>
in case it is player's first time seeing that category be listed.
Clear the just picked up flag for any item that is dipped or read.
Lots of other actions besides drop or put-into-container probably
ought to do that too. [Maybe even just picking an item with getobj()
could be sufficient so that it wouldn't have to be replicated all
over the place.]
I polymorphed into something wimpy and became overloaded or even
overtaxed so I dropped everything. The status line still showed
overloaded or overtaxed until my next move. That didn't happen in
3.6.x or 3.4.3 but I didn't pursue trying to figure out what caused
this misbehavior.
I wanted to add an encumber_msg() call to freeinv() but that would
cause message sequencing issues. Instead, add a call to it in a
few places where items are leaving hero's inventory, particularly
for the chain of calls for dropping stuff. I've left it off in a
bunch of other potential places.
Also add a few missing (void) casts where the return value of
existing encumber_msg() calls is being ignored.
Make selection rndcoord return a table with x and y keys.
Allow (most) coordinate parameters accept such a table.
Fix selection and des lua tests broken by the above changes and
an earlier change, because selections tried to set terrain
at column 0, and it now causes a complaint.
Offer the chance to explicitly hide via #monster when poly'd into a
hides-under creature. hides_under() doesn't pass the is_hider() test
so wasn't being allowed before.
If poly'd hero's monster form is both a webmaker and can hide-under,
have #monster prompt the player for which is intended. When poly'd
hero successfully spins a web, say so.
If poly'd hero deliberately tries to hide under a cockatrice corpse,
turn to stone.
Fix the bug reported by entrez where you could end up hiding under
nothing if while poly'd into a hides-under creature and hiding under
something edible you ate whatever you were hiding under. Same thing
could happen if it was a corpse on an altar and you offered it rather
than consumed it.
While in there, fix monsters hiding under cockatrice corpses. They
won't do that unless there are multiple objects in the pile, but
there was no check for the possible case of all additional objects
also being other cockatrice corpses.
Life-saving has been setting u.uhpmax to max(2 * u.ulevel, 10)
and if it took place during level drain that could make u.uhpmax
increase instead of decrease, confusing healing which gets applied
to a monster who has drained the hero with Stormbringer or the
Staff of Aesculapius. Change the setting to be max(u.ulevel, 10)
(removing the times two part) and also have level drain force it
to be set back to previous value if/when it gets increased.
Max HP loss due to strength trying to drop below 3 or to fire trap
or to being hit by Death now uses a mininum max HP of u.ulevel
rather than 1. They don't have the alternate minimum of 10; I'm
uneasy that there are still two different minimum values.
I changed adjattrib() to set the flag to request a status update
before it gave its optional message rather than after so that the
new characteristic value would be visible during the message. That
resulted in not updating status when eating royal jelly changed HP
or max HP after boosting strength. But the same missing update
would have occurred--or rather, failed to occur--without the change
in sequencing if the strength boost causes a change in encumbrance.
The "hit with a wielded weapon for the first time" livelog line could be
produced repeatedly: it was triggered by hitting a monster with a
wielded object of any sort, but the u.uconduct.weaphit counter was only
incremented if hitting with an actual 'weapon' (a WEAPON_CLASS or
is_weptool item). As a result, if a non-weapon-using hero whipped out a
non-weapon item -- a cockatrice corpse, for example -- and started going
to town on some monsters, the livelog message would be repeated with
every hit.
When a monster hit hero with an artifact with drain-life attack
(Stormbringer or The Staff of Aesculapius), and hero lost a level
and hero had more max hp in the lower xp level, the math made the
attacker lose hp. This could put the monster hp in the negative,
causing "dmonsfree: 1 removed doesn't match 0 pending"
Hurtling into a monster is described as "bumping into" it, so it makes
sense that hurtling willy-nilly into a cockatrice (or vice-versa) could
result in petrification. Since hurtling for the hero usually involves
"floating in the opposite direction" (presumably backwards) after
throwing an item, check whether the hero is wearing any body armor which
would cover their torso rather than looking for gloves. Do the same for
monsters on the general basis that it's a bodily collision, and for the
sake of consistency.
When using 'O' to set the menustyle option, include a description of
each of the styles. Makes the menu entries two lines of two columns
each: first line contains the setting value and the first half of
its description; second line has blank left column and second half
of description in the right one. Value on first line and single-line
description on second would have been simpler but this seems easier
to read--the four possible values don't have any clutter between them.
Also, mark the current value as pre-selected.
Change the 'menuinvertmode' default from 0 to 1 so that it gets more
exercise. It can be changed back to 0 via option settings but it's
doubtful that anyone will care enough to bother.
Some pickup/take-off actions have been using it to avoid setting
their 'all' choice when bulk toggling for current-page or whole-menu
takes place; 'O' specifies it for its '?' help choice. This adds
the skipinvert flag to the 'all' choice of #wizidentify.
The comments describing it now state that menuinvertmode applies to
bulk set-on operations as well as to toggle-on/off operations but
that will only be true if/when interfaces call menuitem_invert_test()
for set as well as for invert. tty is about to start doing that.
Add a type to force g.{command_count,last_command_count,multi} to have the
same type (because cmd.c: g.multi = g.command_count;) and some resulting
cleanup.
If special level lua code creates a melting ice timeout, but
later in the code places stairs, or a trap which might change
the ice to room floor, the timer sanity checking doesn't
like that.
Commit c1a6dd4 was meant to prevent flying, levitating, and clinging
monsters from considering walls of water as acceptable movement
destinations, even outside of the Plane of Water. However, it was
evaluating the monster's starting position instead of possible places to
move to, and the evaluation was 'backwards' (the equivalent of
IS_WATERWALL, instead of !IS_WATERWALL).
The result was that non-swimming monsters could only move onto any kind
of water or lava square if the position they were moving from was a
WATER square. Change this so that instead of the starting position,
each potential destination spot's status as a wall of water is evaluated
in turn, and reverse the effect of the test so that it blocks walls of
water instead of allowing them.
