Instead of just "while helpless", the death reason will tell
more explicitly why the player was helpless. For example:
"while frozen by a monster's gaze"
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.
> 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.
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.
