This change has two parts.
First, the Book of the Dead now has a special message in lava. This was
originally added by Steve Melenchuk (aka Grunt) as a precaution against the Book
burning up. While I'm pretty sure that the Book can't burn up in the current
codepath, the message is a nice touch and it doesn't help to add a safety check.
Second, always print the inventory destruction messages. The reason for this is
fairly subtle, but relates to the timing. By not printing the messages when
dying, the visible effect to the player is that if they have lifesaving, the
items burn up before they die, but if they do not, they burn up after they
die---the fact that they do burn up is visible in the dump or bonesfile.
This avoids a player being left standing on lava if their boots are burned up and
they survive the damage.
This change is originally due to Steve Melenchuk, fixed up by Derrick Sund.
Simplify retouch_equipment (post-3.4.3.code, called when hero
changes alignment or turns into a silver-hating critter; inventory
traversal must cope with the possibility of losing object->nobj when
processing object) by switching to recently added object->bypass code.
From a bug report, dropping a lit
(burning) potion of oil while levitating can produce an explosion which can
destroy inventory. If in the process of dropping multiple items, the ones
after the oil might be gone, resulting in use of stale pointers and possibly
triggering an "extract_nobj: object lost" panic or even a crash. While
testing my fix, I discovered that being killed by an exploding potion of oil
could produce an "object_is_local" panic if bones are saved (and reproduced
with unmodified 3.4.3).
From a bug report, being teleported onto
a sink while busy putting on levitation boots triggered a crash when
Boots_on() was called (as '(*aftermv)()' on the next turn) because
'uarmf' would be null by then. Not mentioned, but the same problem was
encountered by Boots_off() if the teleport happened while you were busy
taking boots off. It could be fixed by having having dosinkfall() call
cancel_don() if donning(uarmf) yields true, but this patch does a little
more than that: cancel donning/doffing of any multi-turn armor if you
fall onto a sink. It also prevents you from falling if you end up
flying (which will have been blocked while levitating).
The situation when putting on levitation boots has a sequencing
issue: setworn() causes you to be flagged as levitating immediately,
but the float_up() feedback doesn't occur until Boots_on() gets called
a turn later. Teleporting to the sink will tell you that you crash
onto the sink and and that you stop putting on boots, without having
been told that you've floated up into the air. It's suboptimal but it
doesn't seem to actually be incorrect.
After newsgroup discussion of C343-162, I noticed that it had fixed
the verb usage in the message for confused and/or stunned, but not in the
one for resisting. (If a monster name ends in 's', or it has been named
"you", 3.4.3 used the wrong verb because vtense() was fooled about plural
or second person.) No new fixes entry needed....
When hiding as a monster, say so during the #monster command and
also list being hidden in the status section of enlightenment/^X.
Also, prevent hiding on the floor or ceiling on the planes of air
and water. (Didn't apply to monsters, who only hide on ROOM spots.)
Half the change to dohide() is just revised indentation.
In the newsgroup recently, someone mentioned that when polymorphed into
a flying monster, he couldn't retrieve items out of pits, even with the '>'
command. I thought that we had fixed that, but the fix apparently only
covered walk-through-wall creatures (xorns and earth elementals), not flyers
and ceiling clingers. Now those can also deliberately enter pits via '>'.
The fixes entry is in the new features section in order to be next to
the xorn one. '>' at pit locations is new, but it handles something which
was missing so feels more like a bug fix than a new feature to me....
[Keni, the bug page entry C343-12 about '>' (for xorns?) is general enough
to cover this fix, so we don't need to add a new one for flyers.]
I noticed an unrelated fixes35.0 entry mentioning '>' which was duplicated;
this removes one of the copies.
From a bug report, the message displayed to the screen by
impossible() might be different from the one written into paniclog, if it
had argument subsitution/formatting. I couldn't reproduce that myself,
but stdarg.h/varargs.h is tricky stuff and I think that passing the va_list
to a routine which steps through it requires that va_start be called again
if you're going to use the va_list a second time. This changes impossible()
to handle its arguments only once, like panic().
Message tidbit when engraving with a weapon which becomes too dull to
finish the whole text: add missing final period to
You are only able to write "<partial text>".
I think that proper usage puts the period in front of the quote rather than
after, but that could make it look as if the period ended up inside the
partial engraving.
From a bug report, you get the message "this shop
appears to be deserted" when entering a shop whose shopkeeper is not there,
even if you can't see at the time. Change it to be
'this shop is deserted'
when you can see that the shop is empty,
'this shop is untended'
when there's no shopkeeper but you can see some other monster(s) inside,
'this shop seems to be deserted'
when you can see but there is a monster that you can't see (probably a
hidden mimic, but possibly an invisible monster or one standing behind
a boulder that's ended up in the shop), or
'this shop seems to be untended'
when you can't see (and don't have active telepathy or persistent
monster detection).
From the newsgroup: inventory dropped by a monster killed by system
shock when zapped by a wand of polymorph is protected against being poly'd
by that same zap, but worn/wielded equipment that's forced to be dropped
due to being unusable in a transformed monster's new form was not. Not
mentioned in the newsgroup, but also fixed: boulders dropped when a giant
turns into a non-giant were also subject to the zap instead of protected.
Introduce some variation in monster movement by adding and substracting
small random amounts to the fixed increment from the main monster table. The
amount added is potentially bigger (average is +2) than the amount substracted
(average is +1), so monsters will tend to be slightly faster. Probably not
noticeable except for super-slow monsters not being so glacially slow, since
net +1 is a bigger relative increase for such critters' low movement rates.
In practice, the noticeable effect will be that ordinary speed monsters will
occasionally get an extra move even if/when player keeps the hero unburdened.
Possible extension (although I'm not planning to do it): sort the
monster list by pending movement points, so that faster monsters move before
slower ones. The random variation would become noticeable because groups of
same-speed monsters would alter their movement order depending upon who got
a bigger increment or smaller decrement on that turn.
From a bug report, when the hero has
precisely 24 movement points, fast monsters will move twice and then the
hero will move twice, instead of being interleaved. The hero will get 24
additonal movement points approximately one turn out of three when wearing
speed boots (or when using spell of haste self or potion of speed) and can
also get 18 additional points twice in succession, with a net of 24 after
12 of them are used on the first turn. But hero might not be starting at
zero at the time, so I'm not sure how often this is actually noticeable.
He apparently got a report about this for <some variant> and had some
user-contributed instrumentation in place that made it easier to replicate.
This fix is the one he suggested.
From the newsgroup, while rehashing our bug page entries someone
mentioned that buying a minor consultation from the oracle exercizes
wisdom twice. First when getrumor() chooses one, then again when
outrumor(BY_ORACLE) delivers it.
This also simplifies some #if GOLDOBJ conditional code.
From a bug report, stinking cloud
harms hero even when u.uninvulnerable is set during successful prayer.
This makes the cloud harmless during prayer as he suggested.
It also makes being inside a stinking cloud become a major trouble
that prayer can fix. (With magical breathing such a cloud is harmless and
with poison resistance it is just a nuisance; it won't be considered to be
trouble in such cases.) The fix is to clear away the cloud, or to teleport
the hero if he's inside multiple overlapping clouds or in one that is
marked as permanent (which I think isn't currently possible).
From a bug report, this turned out to be caused by a fix
I implemented for #H1749 three and a half years ago. Kicking a hidden
monster's location would bring the monster out of hiding but lacked a
newsym(), so if there was 'I' displayed there it stayed displayed as 'I'
even while subsequent messages referred to the unhidden monster.
No fixes entry.
A post-3.4.3 change made the contents of thrown (or dropped while
levitating) containers subject to breakage, but it had sequence issues.
When something was thrown from outside a shop (or from its doorway or
entry spot) and arrived inside, the shopkeeper was taking possession too
soon, charging the hero for any broken contents, and then going ballistic
(summoning kops and attacking) because the hero was outside the shop while
owing money. We need to break contents before shk claims ownership, which
turned out to be trickier than it sounds since it has to occur after any
item-hits-floor message if such feedback is given.
Also, clear the container's contents-known flag when contents break.
Conceivably it should stay set when there is only one item, since hearing
something break could only be that item, but this resets container->cknown
unconditionally if anything inside breaks.
Reported last December by <email deleted>, attempting to kick
a peaceful monster then declining to attack at the confirmation prompt
uses no time, as expected, but does wake up nearby monsters and scuff an
engraving at the hero's location.
Reported last December by <email deleted>, attempting to move
into a peaceful monster's position and then declining to attack at the
confirmation prompt uses no time, as expected, but does burn nutrition
the same as if you carried out the attack. A player could abuse that to
make room to eat an intrinisic-conferring corpse before it rots away.
This fixes that, and also makes attacking a monster via applying a polearm
and via kicking burn the same extra nutrition as ordinary attack. I didn't
add it for attacking via throwing.
He/she also reported that kicking at a peaceful monster and declining
to attack at the prompt wakes up nearby monsters even though no actual kick
ultimately takes place. I can confirm that, but this does not fix it.
From a bug report, using a magic whistle when
you're mounted and standing on a trap location would cause your steed to
trigger the trap even though it didn't move. Since it is already at the
same place as you, make steed be unaffected by magic whistle so that trap
complications can be avoided.
