This finally eliminates all direct increases of `oeroded` and `oeroded2`
and moves them all to go via `erode_obj()`. They are still manipulated
directly in a few places, but not to erode objects.
This now merges the `fire_damage()` function to a common codepath, used
for items on lava and burning oil, but fire needs more work. There is
still a duplication between `destroy_item()` and `fire_damage()`; the
two codepaths should eventually be merged in some manner so that there
is only one codepath to say "an object was affected by fire". This path
might require some parameters, such as whether the fire will just erode
objects or burn them outright, but that can happen another day.
This now ensures that dipping into water works like other sources of
water damage. There is a potentially significant gameplay change here:
dipping a container into uncursed water will wet all its contents. If
this is a problem, then we should add another parameter to water_damage
which will suppress this behaviour for dipping.
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.
This finally eliminates all direct increases of `oeroded` and `oeroded2`
and moves them all to go via `erode_obj()`. They are still manipulated
directly in a few places, but not to erode objects.
This now merges the `fire_damage()` function to a common codepath, used
for items on lava and burning oil, but fire needs more work. There is
still a duplication between `destroy_item()` and `fire_damage()`; the
two codepaths should eventually be merged in some manner so that there
is only one codepath to say "an object was affected by fire". This path
might require some parameters, such as whether the fire will just erode
objects or burn them outright, but that can happen another day.
This now ensures that dipping into water works like other sources of
water damage. There is a potentially significant gameplay change here:
dipping a container into uncursed water will wet all its contents. If
this is a problem, then we should add another parameter to water_damage
which will suppress this behaviour for dipping.
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.
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, you could crawl
out of water to avoid drowning by moving diagonally into an intact doorway
even though regular movement won't allow that. (Second version of Medusa's
level has a door adjacent to water.) You could also escape diagonally when
polymorphed into a grid bug.
When testing armor theft by nymph I got a message "you dream that you
hear <something or other>" even though I was awake. steal() was leaving
nomovemsg null in order to get the default of "you can move again", but
unconscious() was treating null value as 'yes, hero is unconscious'. I'm
pretty sure its intent was just to guard against passing null to strncmpi()
and didn't really mean that null indicates unconsciousness.
> On 01/30/2012 08:20 PM, <Someone> wrote:
> The boulder from a rolling boulder trap can be generated on a
> lava pool. mkroll_launch() in trap.c, line 1584 checks only for pools
> of water.
Removing ring or boots of levitation while stuck in solid rock was
silent as intended, but timeout of potion or spell said "you float gently
to the ground" even though there's no actual movement.
Using '>' command while in solid rock said "you can't go down here"
without attempting to toggle off controlled levitation.
From a bug report. The first report complained about levitation
allowing you to move through water on the Plane of Water, something that's
come up in the newsgroup lots of times (mostly about how levitation is
the best way to get around, only occasionally wondering why it works:
water walking doesn't work there because there's no surface, so where are
you levitating such that you're kept dry?) The second report complained
about being told you were floating up if you put on a ring of levitation
while stuck inside a wall (perhaps after being stranded when polymorph
into xorn form ended).
This implements intrinsic blocking for levitation and also for
flying. Being inside solid rock (or closed door) anywhere and being in
water on the Plane of Water are the things that do it for levitation;
those two and levitating are what do it for flying. Entering such
terrain turns off ability to float/fly, and leaving there turns it back
on; starting levitation blocks flight, ending it unblocks (levitation
has always overridden flying's ability to reach the floor). Being able
to phase through rock doesn't prevent levitation and flight from being
blocked while in rock; you aren't floating or flying in that situation.
Simplify many of the intrinsics macros from
#define xxx_resistance (Hxxx || Exxx || resists_xxx(&youmonst))
down to
#define xxx_resistance (Hxxx || Exxx)
by setting or clearing an extra bit in Hxxx during polymorph so that the
resists_xxx() check becomes implicit.
Unfornately there were lots of places in the code that treat Hxxx
as a timeout number--primarily for Stunned, Confused, and Hallucination;
Stunned happens to be one of the revised macros--rather than as a bit
mask, so this patch needed a lot more changes than originally antipated.
Something I've had in mind for a long time and finally gotten around
to implementing: when you fill in the last pit or hole of a sokoban level,
it's considered to be completed so luck penalties for unsokobanish things
(breaking a boulder, dropping everything and squeezing onto a boulder's
spot, reading a scroll of earth) stop being assessed and most Sokoban-
specific movement restrictions (against pushing boulders diagonally,
squeezing diagonally between boulders, floating over a pit or hole without
falling in, digging of new holes by monsters) are lifted. Teleporting,
level teleporting, and phasing through walls are still prohibited when in
the sokoban branch of the dungeon. (Keeping the non-phasing one in place
prevents taking a shortcut to the final prize in order to bypass the
treasure zoo monsters.)
This adds level.flags.sokoban_rules, defines Sokoban macro to access
it, and replaces most In_sokoban(&u.uz) tests to check it instead. It
gets set when a sokoban level is pre-mapped at the end of level creation,
and if it is set then whenever a trap is deleted, the flag gets cleared
if there are no more pits or holes present on the level.
Noticed while working on the "lava inconsistencies" patch: it was
possible for lava_effects() to be called recursively, despite a patch
five and half years ago which was supposed to prevent that. That patch
handled the case where the hero dies and gets life-saved, but it didn't
deal with a hero who survives due to water walking boots and then has
those burned away. [Not an issue in 3.4.3 because Boots_off() didn't
call spoteffects() for lava then, but it does in post-3.4.3 branch as
well as trunk. fixes34.4 has an entry about fixing an "object lost"
panic for this but I don't think it's accurate. I think that the panic
only became possible after the post-3.4.3 "handle lava when removing or
losing water walking boots" fix was introduced.]
From a bug report, if you move into lava, die,
and are life-saved or leave bones, your potions will remain intact,
whereas if you have fire resistance and survive, they'll be subjected to
destroy_item() and usually be destroyed (not always, because stacks of
more than 1 don't always destroy the whole stack). Also, wooden ring
will be destroyed even if it happens to be ring of fire resistance.
This addresses both of those bugs.
He also thought that all vulnerable armor should be destroyed rather
than just boots in the case where you have fire resistance and survive,
but I didn't change that. It is a little odd, but presumeably only your
feet are in lava at first (although later sinking further into lava
doesn't actually burn up any other stuff).
This is mostly groundwork prior to making the Protection intrinsic
become more meaningful. The Mitre of Holiness (priest quest artifact)
and the Tsurugi of Muramasa (samurai quest artifact) will now confer
Protection when worn/wielded (though at present that effectively does
nothing). While in there, this also changes the Eye of the Aethiopica
(wizard quest artifact), the Eyes of the Overworld (monk quest artifact),
and the Sceptre of Might (caveman quest artifact) so that they need to
be worn/wielded rather than just carried in order for them to confer
magic resistance. That way they're a little less attractive for wishing
by other roles and a little more likely to be actively used by their own
roles (not an issues for the Eyes, I'm sure). This change actually works
to the player's advantage, since it means that monsters who successfully
steal those items won't instantly obtain magic resistance in the process.
This adds protects() as a predicate routine to check an item for
conferring Protection. In order to do that, it renames the existing
protects() routine to defends_when_carried(), because that predicate is
actually a variant of defends() for items which aren't worn or wielded.
From a bug report,
when falling into a spiked pit and being killed and then life-saved, you
could immediately die from fatal poison. It isn't necessarily a bug and
there are other ways to be killed, life-saved, and re-killed (such as
zaps that bounce off walls or reflecting targets), but it does seem to be
somewhat unfair. This patch makes life-saving be more effective: in a
damage-plus-poison situation, if the damage triggers life-saving then the
poison won't deal out any further damage (including its nasty chance for
instant death). The poison still matters, but it will always target an
attribute stat--which is already one possible random outcome--instead of
maybe doing damage. [It is actually possible to get damage if stat loss
tries to take hero's strength below 3, but now there's no chance of that
being fatal immediately after savelife() has restored full hit points.]
