Levitation side-effects get skipped if Levitation toggles while it
is blocked, so BFlying (the reason Flying is blocked) could become stale
in some situations. Enlightment feedback about latent flight capability
was the only thing affected.
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.
Noticed when testing the [trunk] ^X fix: polymorphing into human
form (not reverting to original form) reported "you feel like a new man"
when I resumed being a cavewomen. Like with ^X, it used poly'd hero's
current monster gender instead of the about-to-be-restored role gender.
It's amazing that nobody seems to have ever noticed in all this time.
Apparently I lied yesterday when I said that patch was the last
polyself one. This has been on my agenda for a long time: when dragon
scale mail merges with your skin during polymorph into the corresponding
dragon, have it revert from mail to scales. Its enchantment stays the
same when reverting. So after returning to your original form, using
enchant armor to convert it into scale mail again will eventually risk
its destruction due to over-enchanting. (Cursed scroll of enchant armor,
spell of drain life, or being hit by a disenchanter can be used to reduce
its enchantment back to a safe-to-enchnat value. Or cancellation if
you're desperate. I think those all work on all colors of dragon scales
despite the assorted magical properties that scales confer.)
Teleport_control is disabled while the hero is Stunned; do the same
with Polymorph_control. Also now disabled while unconscious, but that
is academic since random polymorphs and were-critter transformations are
postponed until multi is non-negative. I included it for completeness.
(Reverting to original form can occur while unconscious, but control is
not a factor in that situation. Teleporting handles being unconscious
differently but does negate control then.)
The fixes entry could just as easily have gone into the new features
section as into the bug fixes one. The teleport control part actually
belongs in fixes34.4 because it is present in the branch, but I didn't
feel like spreading this across two different files (and the current diff
references ``Unaware'' which doesn't exist in the branch so it isn't
trivial to include this patch there).
While making the change to prevent random mail daemons, I noticed
that controlled self-polymorph into a critter specified by class (a post-
3.4.3 feature) rather than by name wasn't excluding NOPOLY monsters so I
checked to see if they were being handled correctly. Accepting NOPOLY
monsters as candidates was intentional but it had a problem (although
many NOPOLY monsters are NOGEN and vice versa, so the problem wouldn't
show up often). If I specified A and Archon was randonly chosen, I'd
be told "you can't polymorph into that" but if I retried A and it chose
couatl, the polymorph succeeded. This changes the way the first case
gets handled: it skips the message and makes another pick from the
specified class, although that consumes the same retry counter as
reprompting so you might still end up with "you can't" if random picks
come out unfavorably too many times (or if you've typed in some bad
choices first and the counter has already been reduced).
When doing that, I changed the "you can't" message to say what it
is you can't polymorph into, instead of just "that".
And I've changed controlled polymorph to accept ESC when prompted
for monster type. When used, either don't polymorph (for wizard mode
#polyself command) or revert to uncontrolled poly (for all other causes
of polyself) instead of just asking again. Specifying "*" or "random"
will also produce uncontrolled polymorph.
From a bug report, if you were a mimic
who was hiding (via #monster, becoming a strange object) and polymorphed
into some other monster type, you retained the hidden/object form. That
didn't happen when reverting to normal form, or when polymorphing into a
monster while involuntarily mimicking gold, but handling for the latter
inadvertently blocked dealing with the hiding-voluntarily case.
Suggested by <Someone> in March, 2005 based on newsgroup discussion
at the time: hallucination protects against touch of death attack by
disrupting how the hero's brain reacts, so why not against gaze attacks
too? This gives hallucinating hero 75% chance of being unaffected by
gazes. If unaffected or if the gazer has been cancelled, the gaze will
fail with some feedback. Previously, all cancelled gazes failed but only
Medusa's gave feedback.
This will give players another way to defeat Medusa, but since it
isn't foolproof and there are several sure fire ways already, I don't
think it'll hurt play balance there. It may be useful to avoid getting
repeatedly stunned by Archons though.
Something else from a copy of an old news message:
You return to human form!
Do you want your possessions identified?
I don't think that this can actually happen any more because the pieces
of code which subtract hit points should all be polyself aware now, so I
didn't bother with a fixes entry for it.
From a bug report: amulet of strangulation
continues to kill hero if he polymorphs into a creature which doesn't
need to breathe or doesn't have a head or even a circulatory system.
Currently, the messages are different when the hero doesn't need to
breathe, but that doesn't seem good enough. This makes strangulation
stop when you polymorph into something which shouldn't be vulnerable and
restart if you poly into something vulnerable while still wearing the
bad amulet.
can_be_strangled() is doing more checks that necessary, in case the
strangulation property ever gets conferred by something other than an
amulet. Its criteria for protection from strangling might need tweaking.
When testing the monster-breath-at-self patch I noticed that trying
to cure green slime by having hero breathe at self didn't work. The code
was calling buzz() with arguments that produced an attack directed against
the hero's location, but there was a chance for it to miss outright and
when it didn't, reflection would block it. This makes breathing at
yourself with `#monster' comparable to zapping a wand or casting a spell
at yourself: it always hits.
Another item from the Dec'04 report sent in by <email deleted>. When prompted for a type of monster to polymorph
into, giving a monster class description like "dog or other canine" (or
single letter like 'd'), triggered "I've never heard of such monsters".
Instead of adjusting the message, this chooses a member from the class.
I put this into the fixes file as a new feature.
<email deleted> reported a long list
of inconsistencies and suggestions. This attempts to address the ones
about werecritters and vampires.
> Polymorphed player does not get werecreature changes. (intentional?)
> Player in were form does not turn into werehuman form, ever. (Previous
> bugged behavior was that player turned into a plain human)
> Player afflicted with a were cannot polymorph into werecreature or
> werehuman form.
The first guess is right; being polymorphed blocks lycanthropy state
changes. The second is not a bug either; hero is either a <werecritter>
when in beast form or a <role> when in human form, never human werecritter
monster. The last one feels more like a bug though; it happened because
all lycanthrope monster entries are marked NOPOLY. This patch extends
an earlier post-3.4.3 change to allow player with polymorph control to
explicitly specify werecritter when in role form or human werecritter when
in beast form to toggle shape. It also allows closely related monsters
to toggle from role to beast (ie, "giant rat" yields wererat).
> Vampire or Werecreature changing form may change sex.
Now the three semi-controlled changes--becoming a dragon due to armor,
toggling were form, and vampire into various critters--are prevented from
having the 10% chance of sex change kick in. For monsters, lycanthropy
didn't apply (sex never toggles) and vampire shifting is now covered but
turning into a dragon due to scales/mail remains susceptible to sex change.
Also, post-3.4.3 code made polymorphing into a vampire enable the
#monster command but neglected to tell the player.
Make polymorphing or changing alignment perform a touch check (as is
done when catching lycanthropy) on wielded weapon(s) to see whether the
hero can still use them in his new form. Part [2 of 2] will update
retouch_equipment() to check all items in use rather than just weapon(s).
(A comment or two in part 1 already refers to expected behavior of part 2.)
Don't say "you must drop your weapon" when it doesn't actually get
dropped. And make "weapon" be more specific, comparable to the handing
for slippery fingers.
Simplify <Someone>'s patch (the part for the secondary weapon wasn't and
still isn't needed since dual-wielding can only occur when both primary
and alternate weapon slots contain weapons or weapon-tools, but we might
as well keep it). There was at least one other case where wielded in-use
leash could be removed from inventory without becoming unleashed first:
a bullwhip-wielding monster could snatch it away.
That lead to some other whip issues: monsters who select disarming
via bullwhip as miscellaneous strategy had 80% chance of not using it on
any given turn, but had no chance to select another misc strategy on such
turns--they always resorted to ordinary nonMUSE behavior and usually just
attacked. The adjacency check missed diagonal locations, also would aim
the disarm attempt accurately even when displacement or invisibility made
the hero's precise location unknown. [I took the easy way out here and
only let them try to disarm when they know the hero's location. It's
tempting to aim at the guessed location and sometimes accidentally disarm
a nearby monster, but disarming is an action which targets a particular
weapon rather than just a location.] Lastly, disarming always targetted
hero's primary weapon, never a dual-wielder's secondary one.
From a bug report, if you polymorph into
something, like a killer bee, that causes you to drop your weapon, but the
weapon is a wielded, in-use leash, the leash would be dropped but retain
it's in-use state. However, the leash was tied to you, so it seems it
should remain attached, just unwielded, just as it would if it hadn't been
wielded. I've changed the behavior to do this. I wonder whether one
should be able to wield an in-use leash.
A couple of months ago Michael forwarded a thread from the newsgroup
about how wielding a cockatrice corpse without gloves while polymorphed
into something capable of that would leave you wielding that corpse
bare-handed if you changed form, turned to stone, then got life-saved.
That got fixed; the corpse becomes unwielded. However, one of the
messages in that described a different bug: if you were wielding such a
corpse as a stone golem and cast stone-to-flesh at yourself, you would
continue to wield it bare-handed as a flesh golem. This makes you revert
back to stone golem once the first transformation has finished.
This also fixes an attribute exercising bug in polymon(). It was
being done after the polymorph was completed, so the attempt to exercise
Con didn't do anything because exercise() of anything other than Wis has
no effect when the hero is polymorphed.
[the problem in the earlier rev was tracked to cleanup_burn(),
where arg was holding a (genericptr_t) timer id, and
passed directly to del_light_source() as is.]
P64 (Win64) has a 64 bit pointer size, but a 32 bit long size.
Remove some code that forced pointers into a long int, and
vice versa where information could be lost.
This part deals with light source functions and their
arguments mostly, and switches some arguments
from type genericptr_t to 'anything'.
P64 (Win64) has a 64 bit pointer size, but a 32 bit long size.
Remove some code that forced pointers into a long int, and
vice versa where information could be lost.
This part deals with light source functions and their
arguments mostly, and switches some arguments
from type genericptr_t to 'anything'.
Some recent code shuffling introduced an unintended change in behavior
(not observable to the player; just unnecessary deletion and re-creation of
light source with identical radius when polymorphing from one light emitting
form to another). The fixup for light range 1 would need to be repeated for
`old_light' when outside the `if (old_light != new_light)' block; move it
back inside where that isn't required. Also, youmonst.data is valid all the
time so a couple of `Upolyd' tests in the surrounding code can be dropped.
Several polymorph tweaks, most dealing with specifying form under
polymorph control or for wizard #polyself:
1) allow "were<critter>" and "human were<critter>" for your type of
<critter> when you're inflicted with lycanthropy; now you'll toggle
shape rather than be told "you cannot polymorph into that".
2) allow your own role; now you'll become a new man (or whatever race)
rather than get "you can't".
3) allow "human" to force a new man (or whatever) regardless of race.
No change for human characters, but elves, dwarves, and such can now
use either their own race or "human". (They never become humans.)
4) for wizard #polyself only, override the 20% chance of becoming a new
man instead of taking on the selected form. (This implicitly prevents
the annoying "your new form isn't healthy enough to survive" death
since your experience level won't drop below 1.)
5) remove a redundant drowning check in polyself(); it's already handled
in polymon() and polyman(for newman()) via spoteffects().
This also gets rid of an old use of 0 as not-a-valid-monster (not
responisble for any bugs though since giant ants aren't lycanthropes).
From a bug report, the game gave feedback
about a monster becoming stuck in a web but there seemed to be no monster
around because it immediately began hiding under an object at the web's
location. Prevent monsters--or poly'd hero--from hiding when trapped in
anything other than a pit or spiked pit. Also, prevent them from hiding if
they're holding you or you're poly'd and holding them. I'm not sure whether
either of those cases ever actually happened but big mimics are capable of
both hiding and grabbing on.
Subject: Some problems to report!
Date: Tue, 17 May 2005 07:01:40 -0700 (<email deleted>
<email deleted>
Hi. I'm a sourcediver but not a source compiler.
I use the Mac carbon port under Mac OS X. But enough
about me; I noticed these things:
Polyself/Anatomy Bugs:
- Mimics are amorphous, so they should have jelly
parts rather than animal parts.
- Piercers, trappers and lurkers above have animal
parts, including "head," but they are M1_NOHEAD.
- All elementals have vortex body parts. This should
only be the case for air elementals.
(Remember: stalkers, unlike the other elementals, have
heads.)
- Krakens ought to have tentacles, like jellyfish. ("A
gush of water hits the kraken's left fin!")
- Worms have snake body parts, but they shouldn't have
scales.
[...]
This patch:
- adds worm_parts
- gives krakens tentacles
- ensures that stalkers have a head
Submitted by <Someone> 12/3/05. player poly'd as guardian naga produced a
different attack than a real guardian naga. The fix causes an algorithm
similar to that used in spitmnu to be used in dospit.
Fix the problem pointed out by <email deleted>
where polymorphing into a new man at level 1 could be used to approximately
double or triple your hit points and spell power. With means to drain
level back down to 1 and with amulets of life saving to survive those times
you lose levels instead of gain, you could do this repeatedly and end up
with HP and Pw values in the millions.
This uses the earlier patch that records the HP and Pw increments from
level gains. Now when polymorphing into a new man, level based HP and Pw
are removed from the current values, remainder get multiplied by 80%, 90%,
100%, or 110% (average 95%, so tend to drop slightly), then a brand new set
of level gain increments (reflecting new man's Con and Wis) are added in.
Code for calculating spell energy is moved from pluslvl() and u_init()
into new routine newpw(). It and newhp() take over responsibility for
remembering the level based increments from pluslvl() which didn't deal
with the initial amount (stored in slot [0]; earlier patch didn't need it).
Make petrification initiation or termination go through a new routine,
make_stoned(), instead of manipulating its countdown timer and delayed
killer directly. No change in behavior.
There's no reason in terms of bug risk or game play or saved data why
this shouldn't be done in the branch too, but so much of the surrounding
context has already diverged between trunk and branch that it's trunk only.
<Someone> reported that when levitating and blind, he was getting
"You float over the hole" without it showing up on the map. Easiest way
to reproduce: zap a wand of digging downwards while levitating blind,
move off the spot and back over it.
Make sure that all traps created by the player are mapped. For other
traps, it was about 50:50 whether the trap triggering message yields enough
information to warrant forcibly mapping the trap when blind.
Finally apply the patch sent by <Someone> in 11/2003 for slashem-Bugs-799278,
updated to match the current code and handle additional cases. The fix
is brute force: always ensure nomovemsg is set when nomul is called with
a negative value. I also scanned the code for places manually setting
multi negative, they all set nomovemsg. It would be nice to have a function
that did the right thing, but there are several special cases and I was
not feeling creative.
Something from <Someone>'s list: some messages have hardcoded references
to "helmet" which sound strange when the character is wearing a hat or cap.
helm_simple_name() is comparable to the existing cloak_simple_name(). It
returns "helm" or "hat" depending upon whether the helmet provides the
same protection that yields the assorted repetitions of "fortunately,
you are wearing a hard helmet". This choice ends up categorizing elven
leather helm as a hat (which I think is ok given that its undiscovered
description is "leather hat"), contrary to <Someone>'s suggestion that the
distinction be made based on whether the helmet was made of cloth.
I started on this a year and a half ago but didn't commit it.
Unfortunately I don't remember why and haven't done any significant
additional work now--just recovered from some intervening bit rot and
confirmed that the patch as is seems to be working ok (in the trunk; the
branch side has not been tested). I suspect that I meant to look for
additional helmet messages which could benefit from conditional headgear
description. (Those "hard helmet" ones don't need it, although they
should perhaps be moved into a common routine instead of being replicated.)
- can shift into fog clouds, vampire bats, and vampire lords into wolves
- after being "killed" in shifted form, they transform back rather than get
destroyed, and you must take them on in vampire form to defeat them
- can deliberately shift into fog clouds to pass under closed doors
This is a foundation patch for patches to follow.
- use a full short index for mon->cham field.
- The current system of providing CHAM_XXX values
was limited to the 3 bits allocated in the bitfield and invalidated
save/bones if the field was expanded.
- The current system didn't provide an easy backwards change
if multiple monster types wanted to use the bit, there was a one
to one mapping: For instance, if you wanted a CHAM_VAMPIRE,
and you wanted vampires, vampire lords, and Vlad to use it, you
would have to have CHAM_VAMPIRE, CHAM_VAMPIRE_LORD,
and CHAM_VLAD defined to achieve that with the one-to-one backward
mapping.
- This new way just uses the mon[] index in the mon->cham field and
eliminates the need for CHAM_XXX (CHAM_ORDINARY is still used).
- no longer requires the cham_to_pm mappings
This patch increments editlevel making existing save and bones files useless.
Add polywarn() code to grant the ability to detect certain monster
types while polymorphed into other specific monster types.
If you polymorph into a vampire or vampire lord, you are able to
sense humans.
And just for fun, if you polymorph into a purple worm, you are able to
sense shriekers :-)
Change pit behavior to always mark a non-flying poly'd player as trapped in
a pit, even when Passes_walls is set. This allows players polymorphed into
xorns to descend into pits and pick things up. In this case, any attempt
to move out of the pit now takes a turn but always succeeds. Also fixed
a related bug (w/o ID) that a player could become trapped as if in a pit
when leaving xorn form because u.utrap wasn't checked, and simplified the
code since the extra Passes_walls checks are no longer needed. Also
updated code in sit.c that duplicated uteetering_at_seen_pit.
It was possible for status_finish to get called twice, therefore free() could end up called twice.
Add a macro symbol for the argument to status_initialize().
Adjust some field widths so that there is a little bit of breathing space.
>Hemmed in by one invisible wererat?
><Someone>: Should I feel hemmed in if I can see that a wererat summons
>zero rats? Can the invisible wererat hem me in all by itself? And
>even if it had summoned anything, wouldn't a different message had
>been clearer (for isntance, "Rats appear around you!"); after all,
>I could see *what* was hemming me in.
>I agree that the current messages (and even the ones aspired to by the
>comment) are non-ideal.
<Someone>'s suggested set-up:
Seen summoner, seen help : "The wererat summons help!"
Seen summoner, unseen help: "The wererat summons help! You feel hemmed in."
Seen summoner, no help: "The wererat summons help! But none comes."
Unseen summoner, seen help: "(A rat appears|Rats appear) from
nowhere!"
Unseen summoner, unseen help: "You feel hemmed in."
Unseen summoner, no help: No message.
Reported a while back, a (stonable) hiding monster will hide at a location
containing only a cockatrice corpse. While it would be interesting to
allow monsters to try, and stone themselves as a result, I chose the
simpler fix which is to not have monsters hide in such situations. I found
the hiding code was duplicated in several places, so I moved it into a new
hideunder() function that works for both the hero and monsters.
> Not all objects say "Splash!" when they fall in the
> water. When levitating/flying and dropping things they
> don't, but when polymorphing and forced to drop items
> they do. [<email deleted>]
when floating over the water, things dropped always
make some sort of sound. Also fix up some messages
when Underwater that previously said things like
"feel what is lying on the water" by adjusting
surface() in that situation to return "bottom."
While looking into this, I noticed that if you
are polymorphed into a Flyer and you then polymorph
back into your normal form, you don't end up in
the water until you move, so this attempts to
correct that too.
Introduce a new set of functions to manage delayed killers in the trunk, used
in addressing the various reports of delayed killer confusion. Since existing
delayed killers are related to player properties, the delayed killers are
keyed by uprop indexes. I did this to avoid adding yet another set of
similar identifiers.
- the new delayed_killer() is used for stoning, sliming, sickness, and
delayed self-genocide while polymorphed. Some other timed events don't
use it (and didn't use the old delayed_killer variable) because they
use a fixed message when the timeout occurs.
- A new data structure, struct kinfo, is used to track both delayed and
immediate killers. This encapsulates all the info involved with
identifying a killer. The structure contains a buffer, which subsumes the
old killer_buf and several other buffers that didn't/couldn't use killer_buf.
- the killer list is saved and restored as part of the game state.
- the special case of usick_cause was removed and a delayed killer list
entry is now used in its place
- common code dealing with (un)sliming is moved to a new make_slimed function
- attempted to update all make dependencies for new end.c -> lev.h
dependency, sorry if I messed any up
This change adds a new flaming() macro and uses it in several places
where the list of flaming monsters was tested. on_fire() didn't list
salamanders as already being on fire, but should have. A couple other
cases were not updated to include flaming sphere.
Pat Rankin wrote:
> collect them all into some new struct and
> save that separately rather than jamming more non-option stuff
> into struct flags.
This patch:
- collects all context/tracking related fields from flags
into a new structure called "context."
It also adds the following to the new structure:
- stethoscope turn support
- victual support
- tin support
