while wielding a cockatrice corpse without gloves
Reported by vultur-cadens: if safely wielding a cockatrice corpse
without gloves due to temporary stoning resistance or wearing yellow
dragon scales/mail, having the resistance be lost to timeout or to
taking off the dragon armor should have turned the hero to stone but
didn't.
Extend the handling for taking off gloves to cover these other two
cases too. The feedback for these deaths is usually too verbose to
fit on the tombstone but does show up in logfile.
Fixes#715
Implement the suggestion by NetSysFire that a levitating of flying
hero won't treat pits and holes as off limits when testing potential
destinations during teleport.
Closes#716
Using #name and picking an item on the floor to be assigned a type
name allowed any of the four types of globs to be named. After
that, wishing for those by the assigned name bypassed the code that
forced the quantity to stay at 1. Asking for "3 foo" could then
produce "3 small globs of gray ooze" which fails obj_sanity() and
issues an impossible warning (which the fuzzer escalates to panic).
The "getobj refactor" patch changed the return value of call_ok().
When it gets used to check whether an object on the floor could have
a type name assigned (rather than as a getobj() callback), the test
that should have rejected the naming attempt accepted it instead.
Update the wishing code to handle globs differently: you can still
specify the relative size via small, medium, large, or very large,
but now you can specify a count either instead or in addition. A
count of more than 1 is used to multiply the created glob's weight,
although it's less likely to be honored as-is when the size is bigger
than small. Quantity is always forced to 1, at a different place in
readobjnam() than previously.
The change in the long-standing default for 'autopickup' warrants
mention in the Guidebook. Also, the X11 interface can switch to
alternate tiles but doesn't use the 'tile_file' option to do so.
In Guidebook.mn, the list of options pads ones shorter than 8
characters with trailing spaces, necessitating quotes. A few longer
ones had such quotes and even trailing spaces. Take those away.
When creating stairs in a random location in a special level lua file,
there was a chance it overwrote eg. other stairs. Make randomly placed
stairs pick locations with room, corridor, or ice terrain.
Fixes github issue #702
For timed acid resistance and timed stoning resistance, report
"You {are,were} temporarily {acid,petrification} resistant."
For items being protected by worn equipment, add "by your {armor,&c}"
similar to the existing feeback about you being protected "because
<some-reason>". Wizard mode only.
When eating a meal that is affected by acid resistance or stoning
resistance and protected by temporary resistance, increase the timeout
so that the resistance doesn't expire until after the meal finishes.
That avoids getting the "you no longer feel safe from {acid,stoning}"
during the meal and not being affected by the dangerous food despite
that message. Useful because the protection is checked at the start
of the meal and not rechecked during; extending the duration hides
the latter.
From a report by a beta tester 8 years ago: kicking a chest gave
"THUD! The chest explodes!" but the chest remained intact. The
explosion was destroying all floor items at the hero's spot rather
than at the chest's spot. Fixing that results in the chest being
destroyed because it's one of the items at its own spot.
While fixing that I noticed that delobj() was only protecting the
Amulet and the invocation items from destruction, not Rider corpses.
You could destroy one or more of those by getting a trapped chest's
explosion while using a key at its spot rather than by kicking it
from adjacent. (Getting the exploding chest result is not easy,
particuarly with positive luck. I eventually resorted to forcing
it with a debugger.)
There were at least two cases of travel oscillation that occurred,
even after my previous fix. To fix those, the guessing routine
would also have to consider distance to original target location.
I opted not to make that part more complex - as there was
no guarantee those changes would catch all of the oscillation cases.
Instead, when we're guessing where to move, and we would actually move
back to where we came from, stop travel, and give a message.
This should fix (and fuzzing seems to confirm) all of the travel
oscillation bugs for good, and it shouldn't affect actual good travel.
(Other than the player getting a YAFM in the occasional case of trying
to travel to a location with no travel path)
There's been occasional reports (perhaps once or twice a year)
of travel getting stuck moving repeatedly between two locations
next to each other, but it has never been reproduced before.
This special level lua code fragment is a minimal test case
which triggers it:
--- special level lua fragment, indented
des.map([[
--##---
###----
#-+----
####--L
]]);
des.door("open", 2,2)
--- end of special level lua fragment
The open door is required.
Magic map the level. Start from somewhere NW of the door, and try
to travel to the lava pool. Hero will get stuck oscillating between NW
of the door and two steps west of the door.
Here are the maps of the travel[][] array values from findtravelpath()
in those two steps in the above map:
------------- -------------
| . . 2 3 | | . . 1 2 |
| 1 1 2 . | | 1 @ 1 . |
| @ . . . | | 1 . 2 . |
| 1 1 2 . | | 2 . 3 4 |
------------- -------------
There are two possible closest locations to the lava pool,
the one marked with "3" on the left map, and "4" on the right map.
Based on that alone, both would be valid places to path to.
But, in the left case, hero could not see the bottom location, so
the code won't even consider pathing to it, so it will start moving
towards the "3".
When hero moves to the second position, in the right map, now the "4"
could be seen. Now there are two possible closest locations we could
choose from. The code that scans the possible locations goes from top-left
to bottom-right, first going down (y-axis). So, the code sees the
"2" on the right. distmin() to there is 2. Good, we pick that location
to path to. Next, going down, the code considers the "4" ... which is
also equally close to the lava pool. and distmin does not consider terrain,
so ignores the door, so it has the same distmin value of "2", so the
code picks this location.
But: this was just a guess, because there's no known valid path to the
lava pool. The code loops back up to rebuild the travel[][] array
with a new starting location as the "4" from the right map, pathing
back to hero.
This is that travel array map:
-------------
| . . . . |
| 4 @ 3 . |
| 3 . 2 . |
| 3 2 1 x |
-------------
The way travelstepx and travelstepy arrays are built means that the first
location that considers the hero's location is the "3" SW of hero, so
hero will move there next. Repeat from beginning. If there was no door,
the travelsteps would reach hero's location first from SE.
(I left the travel[][] array rebuild and travelstepx/travelstrepy build
off from the other movement position, as it's not relevant)
The fix: When considering which of the two possible closest places to the
lava pool to path to, use the one with the lowest value in the travel array.
That value is the real number of moves it takes for the hero to walk there,
so the code will consistently path to the upper location, as it is "2",
instead of considering the "4" below it.
Also some minor code reorg, so it considers couldsee first instead of
later in two separate places.
It turns out that there were a bunch more monsters with the corpse-
conveys-stoning-resistance flag than just green mold. Instead of
stripping it off, give them (including green mold) a chance to confer
timed resistance against stoning and also against acid.
All of these can convey either of those two resistances. Like other
intrinsics obtained via eating, at most one can be obtained from any
given corpse.
green mold, acid blob, spotted jelly, ochre jelly, black naga,
yellow dragon, Chromatic Dragon
These can confer temporary stoning resistance but not acid resistance:
lizard, chickatrice, cockatrice, gargoyle, winged gargoyle,
xorn, Medusa
There aren't any that confer just acid resistance without a chance for
stoning resistance.
The effect lasts for 3d6 turns, or is extended by 3d6 more if randomly
chosen and applied when already in effect.
Having temporary acid resistance time out during another meal when
eating a corpse that ends up conferring acid resistance seems strange.
The protection against acid is granted at the start of the meal and
continues to the end (in regards to eating, not external attacks) even
when the intrinisic is lost in between. I'm not sure whether that
needs some form of fixing, and if so, what that fixing should be.
Fix a minor 'fixme': if hero breaks vegetarian conduct by eating
something made of bone, leather, or dragon-hide while polymorphed
into a shape which can eat such things, change the message from
"ate meat for first time" to "ate meat by-products for first time".
It took me a while to arrive at a sequence of actions which would
successfully test this. You need to break foodless and vegan
conducts first, then break vegetarian with leather/bone separately
or it won't trigger a livelog event for that. Wish for and eat a
candy bar to break vegan conduct, polymorph into a gelatinous cube,
wish for and eat leather armor, then use the #chronicle command.
If poly_when_stoned() is true, an uninitialized buffer kbuf[] is passed to instapetrify().
Although instapetrify() doesn't access it in that situation for now,
it should be initialized anyway for readability.
A reddit posting points out that the green mold monster definition
has the flag for conveying stoning resistance but it doesn't work.
There seem to be 3 choices:
1) implement being able to gain that resistance;
2) take the flag away;
3) mark green molds no-corpse so that the issue becomes moot.
The poster was hoping for (1) but I've gone with (2). Green molds
are too common and not at all dangerous; being able to gain stoning
resistance--even with a tiny chance--could potentially be a major
change in play balance.
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.
Pull request from entrez: the log message "hit with a wielded weapon
for first time" for breaking the "never hit with a wielded weapon"
conduct wss being given when hitting with wielded non-weapons. Since
the conduct remained unbroken in that situation, the 'first hit'
message would be re-logged for subsequent non-weapon hits. This bug
was not present in initial livelog implementation; it was introduced
by the change to log first-hit before first-kill when those occurred
on the same attack. Verify that the wielded object is actually a
weapon or weapon-tool when deciding whether to log first-hit event.
Closes#708
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.
Catch up with tty, curses, X11, and Qt: menuitem_invert_test()
applies to select as well as invert and if menuinvertmode is 2 then
it also applies to unselect.
Not tested.
Catch up with tty, curses, and X11. Items flagged as skip-invert
will not be toggled On by select-all. If menuinvertmode is 2, they
also won't be toggled Off by unselect-all.
Catch up with tty and curses. Menu items flagged as skip-invert will
not be toggled On by select-all and select-page. If menuinvertmode
is 2 they also won't be toggled Off by deselect-all and deselect-page.
Change curses' use of menuitem_invert_test() to match the recently
changed tty behavior: when menuinvertmode is 1 the test excludes
special menu items that are flagged 'skip-invert' while handling
select-all and select-page as well as invert-all and invert-page,
and when that option is 2 then it also operates on deselect-all and
deselect-page.
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"
