I'll push a formatting guide at some point. There may still be
outstanding changes, but please feel free to resolve those as you arrive
a them.
To the best of my knowledge, there is no changes to the actual code
content, but the formatter does have the occasional bug. If you run into
an issue, please fix it!
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"
The message "you stop taking off <that armor>" when interrupted by a
nymph's or monkey's theft attack would only be given if you were using 'A'
to take off the armor. If you used 'T', you'd get "you stop putting on
<that armor>" instead. The fix for that also makes it easy to vary the
nymph message "<the nymph persuades> you to start taking off" to be "<the
nymph persuades you to continue taking off" when taking that same piece
of armor off was interrupted by the theft.
From a bug report, having some
armor stolen while in the midst of putting on armor--when both items have
a multiple turn completion delay--could result in side-effects for the
latter item being reversed even though they hadn't been applied yet. So
you'd lose points of Int and Wis when attempting to put on a positively
enchanted helm of brilliance, or gain such with a negatively enchanted one.
steal() was assigning to afternmv before it had been used to finish the
action of putting on or taking off armor. Fix by interrupting the attempt
to put on or take off armor when being victimized by theft (or being hit by
succubus or incubus seduction). The existing stop_occupation() call wasn't
sufficient because afternmv is different from occupation.
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.
While looking at fixing the mfrozen issue for monsters (there's no
way to tell whether it's been caused by sleep or paralysis, necessitating
that some messages be vague or suppressed when actions impact monsters
who can't move), I noticed a drawbridge bug for the hero. It was using
the misleadingly named Sleeping intrinsic incorrectly. When that is
nonzero, the hero is prone to falling asleep at random intervals, not
necessarily asleep right now. I've always intended to rename it to
something that's not misleading, but hadn't ever gotten around to doing
so, until now: change the SLEEPING property to SLEEPY and the Sleeping
intrinsic/attribute to Sleepy.
This may be moot for the drawbridge. I can't remember any hero ever
jumping to safety instead of being crushed by either the bridge or its
portcullis, and I'm sure sleepiness hasn't been a factor. So I haven't
included any fixes entry about misusing Sleeping when it meant u.usleep
(or better yet, unconscious(); or even better, Unaware [a post-3.4.3
pseudo-property that tests both unconscious() and fainted() when checking
whether hero is incapacitated]).
[Short writeup; see 'cvs log' of flag.h or options.c for the long one.]
This is a reworking of user contributed patch known as Paranoid_Quit.
Add a new compound option, paranoid_confirmation, accepting a space
separated list of values "quit die attack pray Remove"; default is "pray".
paranoid:quit - yes vs y for "really quit?" and "enter explore mode?"
paranoid:die - yes vs y for "die?" in explore mode or wizard mode
paranoid:attack - yes vs y for "really attack <peacful monster>?"
paranoid:pray - y to pray; supersedes prayconfirm boolean; on by default
paranoid:Remove - always issue an inventory prompt for 'R' an 'T', even
when only one applicable item is currently worn.
From a bug report, when putting on a
cloak of displacement you discovered what it was even if you were invisible
and unable to see invisible, hence couldn't see yourself. It isn't exactly
clear what the hero sees of himself when displaced, but I think it makes
sense that you shouldn't discover the cloak when you can't see yourself,
which suggests that you shouldn't discover it when blind either.
Discovering it after regaining sight, becoming able to see your
invisible self, or losing invisibility seemed complex and likely to be
bug-prone, so this patch leaves the cloak undiscovered in that situation.
But it does become discovered when taken off (provided that you can see
yourself by then) rather than waiting all the way 'til put back on again.
Elven cloaks had a comparable issue. I assume that stealthiness can
be perceived without being able to see yourself, but it shouldn't become
discovered when you're already stealthy from some other means. (Elven
boots already behaved this way; now elven cloaks work like them.)
Rings of stealth would never be auto-discovered. Now they'll be
like elven cloaks and boots and be discovered if put on when not already
steathy or taken off and losing stealth. In both cases, the ring has to
have its description known; if picked up when blind and still not seen
yet it won't become discovered even when you notice yourself gaining or
losing stealth.
Not tested: feedback given when a worn ring or cloak gets dipped
into a potion of polymorph and changes into or away from a stealth or
displacement conferring item.
From a bug report, wearing
(or removing) an amulet of restful sleep was overriding permanent
sleepiness which had been obtained previously via eating another amulet.
The setting of timeout clobbered the non-timeout bits for that intrinsic.
This also adds the timeout counter for sleepiness to enlightenment
feedback in wizard mode. Unrelated: rephrase enlightenment feedback for
adornment to more accurately describe what that does.
Picking up and putting on a +1 ring of protection while blind
resulted in having a "+1 ring (on {left|right} hand)" in inventory and
having ring of protection show up in the discoveries list. The problem
is the same as the one for wands which has been previously addressed
(but not 100% fixed...): when using an item whose effect is observable,
the item's type became discovered based upon that observation even if the
item itself had never been seen.
The code for removing ring of protection lacked its break statement
and fell into the case for removing ring of protection from shapechangers,
but didn't cause any noticeable problem.
1) the change yesterday to mark inventory as seen when recovering from
blindness neglected to handle blindfold removal;
2) fix grammar when using 'R' or 'a' to try to remove cursed lenses
(now "they are cursed" instead of "it is cursed");
3) attempting to put on a wielded or quivered blindfold, amulet, or ring
and failing because of already wearing one (or two in the case of
rings, where cursed gloves and ESC at "which ring-finger?" prompt got
similar result) unwielded/unquivered item rather than leave it as is.
The post-3.4.3 ring removal bug also applied to suit when wearing a
cloak and shirt when wearing a suit or cloak or both, although it would
never give "you have nothing else to take off" because the covering item
was always present as a likely candidate. The ring fix also fixed armor.
When testing that fix, I saw "you can't take that off" for trying to take
off a suit while wearing a cloak. That isn't new or a bug, but it seemed
awfully terse so I've changed it to give "you can't take that off without
taking off your cloak first". (Likewise, "cloak", "suit", or "cloak and
suit" as appropriate when trying to take off a shirt.)
This adds new routine `suit_simple_name()', comparable to 3.4.3's
cloak_simple_name() and post-3.4.3 helm_simple_name(). No doubt there
are other places besides "without taking off your X first" that could
make use of it but I haven't attempted to track them down. The "you are
already wearing _some armor_" one doesn't quite fit. It would need to
adjust "some" to "a"/"an" at times ("some mail" or "some dragon scales"
vs "a suit" or "a jacket").
A bug in some post-3.4.3 code made attempting to remove a worn ring
when wearing two skip inventory the selection and give "you don't have
anything else to remove" if you were wearing gloves and weren't wearing
an amulet or blindfold. The intent was that rings wouldn't be included
as likely candidates in the list of inventory letters to choose from if
you were wearing cursed gloves, but had a copy+paste mistake in the
argument controlling whether to consider the gloves curse state and was
in the wrong section of getobj()'s "ugly hacks". Also, it makes more
sense to require that the player know that those gloves are cursed, so
inaccessibe_equipment() got changed too. [Not knowing that the gloves
are cursed leaves rings listed as candidates; picking a ring will get
removal failure feedback later and mark the gloves as known cursed then.]
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.
<email deleted> reported back on 8/31/06 that elven weapons were not
affected when he poked a fire elemental with them. This is true, but
moreover, there was no code to have passive fire to affect attackers.
Now erode_obj() supports all the same damage types as rust_dmg(), and added
the connecting code to allow passive fire attacks do something.
There probably should be macros for the damage types used by rust_dmg
and erode_obj, and possibly these functions should be combined, but they
are slightly different and dealing with that requires more thought.
Extend rotouch_equipment() to cover all items in use, worn/carried/
invoked in addition to wielded. Done when you change alignment, change
shape, or catch lycanthropy. No-longer-touchable items inflict modest
damage; worn/wielded ones will be unworn/unwielded. For the shape change
and lycanthropy cases, unwieled weapons are also dropped. Other unworn
stuff stays in inventory, as do weapons for the alignment change case.
It ought to force off gloves if worn silver--or hypothetical
artifact--ring has become untouchable and gets unworn. Instead it just
curses the gloves, if necessary, so that there's some plausibility to
having the ring come off.
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.)
Slippery fingers would cause a wielded, in-use leash to be dropped
without first unleashing. The fixes entry for the polyself case applies
to this one too:
dropped wielded, in use leash should remain in inventory, since it's in-use
From a bug report: you
can dip a worn item such as shirt or suit into a potion of polymorph and
it will become unworn--but as of a couple of days ago, unworn only if the
transformed object's new form can't be worn in the same slot--even if it
is covered by a cursed worn item (suit or cloak). It didn't seem like
trying to fix that special case would be very worthwhile; this fixes the
more general situation of "you could dip worn items even though they were
covered up by other worn items".
In the same report: you could apply grease to rings while wearing
cursed gloves. The code already prevented greasing a suit when it was
covered by a cloak (regardless of whether that cloak was cursed), and a
shirt when it was covered by a suit or cloak or both. This moves that
code into a separate routine which is used for dipping as well as for
applying grease, and now handles rings vs gloves.
Since covered rings, shirt, or suit are no longer eligible to be
dipped or greased, this also makes "?" for the pick-an-item prompt leave
such things out of the list of likely candidates.
From a bug report. That's hard to fix in the general case because armor
and tools might not fit back into the same equipment slot, but most other
types of worn items can be re-worn after being transformed. This makes
any transformed worn item stay worn if it is wearable in the same slot.
The latest Micrsoft compilers complain when a function is
assigned to a function pointer, and the function's argument
list does not match the prototype precisely.
It was evem complaining about the difference between this:
int x()
{
[...]
}
and a prototype of
int x(void);
when assigning that function's address to a function pointer.
This quiets those warnings, without suppressing the mismatch
check altogether for more serious mismatches.
<email deleted> wrote:
> While levitating, I put on an unknown pair of boots. They turned out to be
> elven boots. I received the message, "You finish your dressing maneuver. You
> walk very quietly." Incidentally, I was hallucinating at the time.
>
> It seems to me that levitating individuals shouldn't be able to tell that they
> walk quietly.
Putting on the Eyes while blind causes sight to be regained, which in
turn causes xname() to set the dknown bit and start using the previously
unseen object's name. But obj_is_pname() was being called before xname in
the "you are now wearing ..." message, while dknown was still clear. So
obj_is_pname thought the name was being suppressed and returned false,
resulting in "an Eyes" instead of "the Eyes". Fix is to call xname first.
Extend the capabilities of corpse_xname() so that various callers can
be simplified. It can how handle an article prefix, effectively turning it
into corpse_doname() (not quite; still need doname() to see a count when
quantity is more than one, or to see bless/curse state). It can also handle
inclusion of adjectives like "partly eaten" or "bite-covered". For unique
monsters those come out in the form
the Chromatic Dragon's partly eaten corpse
instead of the old
partly eaten Chromatic Dragon corpse
[so wishing probably needs to be taught about potentially finding a monster
name before assorted adjectives such as blessed; also, name_to_mon() needs
to learn how to cope with the possessive suffix].
A sizeable chunk of this patch deals with consolidating some of the
redundant "petrified by a cockatrice corpse" handling. It may be possible
to consolidate all remaining instances together since they're quite similar,
but I didn't think about that until just now and I want to get this patch
over with.
The in_lava_effects flag should never be saved and restored; putting
it into the context struct was a mistake. Move it to the iflags struct
(where the branch code already has it). I haven't bumped the EDITLEVEL
setting. Save and bones files from more that a few days ago were breifly
invalid but should be viable again. Save and bones files from the past
couple of days are now no good; sorry about that.
While testing some killer_xname() changes, I noticed that it was
feasible to avoid having some gear destroyed by causing a hangup after
getting the destruction message. And while testing the fix for that, I
stumbled across a panic situation (not caused by my changes). If you
survive entering lava while wearing water walking boots (and aren't fire
resistant yourself, and don't have enough hit points to survive 6d6
damage, and your boots aren't fireproofed...), having those boots be
destroyed will dump you back into the same lava recursively (lava_effects
-> Boots_off -> spoteffects -> lava_effects). And if you survive that
(wizard/explore mode or life-saving), there will be a panic when finishing
deletion of the boots (useupall) because the recursive call will have
already done it (since they aren't worn anymore when inner call handles
them, no additional recursion gets triggered and object deletion happens).
Some of the other stuff I was working on is mixed in here because
this is the configuration I ended up using to test the panic fix.
Several Makefiles are missing the dependency for context.h (post-3.4.3
revision). If yours is, then you'll need to force a full rebuild after
applying this or you'll end up with havoc. (Mine was, but I noticed that
the expected full build wasn't happening and interrupted it to fix that.)
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.)
<Someone> reported that she got "your weapon slips from your hands" when
inflicted with slippery fingers while wielding multiple daggers. That
should be "weapons" plural and they're only being dropped from one "hand"
singular. Fix that and also give more specific feedback than "weapon"
for non-swords based on their weapon skill category names. This works
pretty well for most common weapons but might need some more tweaking for
ones where different types have gotten lumped together in the skills.
old feedback:
Your weapon slips from your hands.
Your tool slips from your hands.
Your food slips from your hands.
twoweapon:
Your sword slips from your hands.
Your other sword also slips from your hands.
new feedback:
Your daggers slip from your hand.
Your <one-hander> slips from your hand.
Your <two-hander> slips from your hands.
Your pick-axe slips from your hand.
The corpse slips from your hand.
twoweapon:
Your sword slips from your left hand.
Your other sword also slips from your right hand.
Fix the reported problem of being able to safely stand on lava after
taking off fireproofed water walking boots. The situation was more wide-
spread than that; the same thing happened when non-fireproofed boots were
burned off while walking over the lava in the first place. Now you'll
fall in and end up getting stuck (you have to have fire resistance for any
of this to happen and that resistance makes falling in be survivable).
Just From a bug report: getting interrupted and then
resuming would sometimes produce two instances of the "You finish" message
(and evidently consumed an extra turn in the process). I think this is
an old problem and that it's just coincidence that it showed up right after
the patch dealing with avoidance of stale context for 'A'; the interruption
has to occur when there is just one turn left in removing the final item
so doesn't happen very often.
[ Caveat: compiles ok on branch code but only play tested on trunk code;
the do_wear.c diff is a lot different between the two variants and the
trunk one includes some whitespace cleanup. ]
<email deleted> reported that having a spellcasting monster
destroy some armor while you're in the midst of using 'A' to take that
armor off would result in a crash. The problem was actually more
widespread than that: having a nymph steal worn items (accessories as
well as armor), or a succubus remove them, or being interrupted by monster
activity and then reading a scroll of destroy armor prior to resuming 'A'
could all produce a similar crash. 'A' relied on stale context and could
attempt to manipulate an equipment slot which had become empty, ultimately
leading to an attempt to dereference a null pointer.
The 'R' command didn't have this problem since any accessory gets
removed immediately. The 'T' command already had handling for this:
there's only one item to deal with and multi-turn take off only applies
to some of the slots; the donning() check followed by cancel_don() took
care of those. Only 'A' was vulnerable to the problem and it wouldn't
necessarily need to be interrupted and resumed; loss of the current
multi-turn item or any pending item would be enough--but I'm not sure
whether such item loss could occur without also interrupting the current
activity, so resumption of previous 'A' was probably a requirement for
triggering the crash.
This makes shield and shirt handling be similar to other types of
armor instead of relying on the fact that none of them need to have any
attribute adjustments when put on or taken off. However, there are
still assumptions (the `cancelled_don' stuff) that some slots don't have
any eligible items requiring more than a single turn to use; that should
probably be changed.
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
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
