Realized while fixing #H8271: if persistent inventory got an update
while wearing or taking off was in progress (not within user's control
since hero is busy) the item in question was flagged as "(being worn)"
even though it wouldn't be worn if putting on got interrupted. Update
doname() to show "(being donned)" or "(being doffed)" instead of
"(being worn)" when corresponding operation is in progress. (During
testing, I was able to observe "being doffed" but never managed to see
"being donned".)
Leather jacket doesn't take multiple turns to wear, so wearing it
wasn't calling Armor_on() and recently moved 'uarm->known = 1' didn't
get executed. Not reported yet but had the same issue: fedora and
dented pot wouldn't call Helmet_on().
about the armor. Wearing armor sets obj->known, making its enchantment
be shown when it gets formatted, because the AC value on the status line
lets the player deduce what that is. It was being set at the beginning
of the wear operation. If the armor got stolen before it became fully
worn, the enchantment was still shown. Defer that until the end of the
operation. An attentive player can still deduce the enchantment if the
item is stolen (because its protection starts immediately) but the hero
won't learn that enchantment unless the donning completes.
This might be suboptimal but it isn't qualitatively different from
watching a pet walk/not-walk over items whose bless/curse state isn't
known or dropping unidentified items in a shop to check their price.
The player can deduce something that the hero doesn't know yet.
I don't see the #H8124 bug getting fixed any time soon, so add a
comment about it since the relevant place is unambiguous.
No change in code except removing a couple instances of 'register'.
Replace recent "(light blue aura)" with
"(flickering light blue)" if there are 1..4 orcs,
"(glimmering light blue)" if 5..12, or
"(gleaming light blue)" if there are 13 or more, and move its place
in the formatted name.
_3.6.1_: Sting (weapon in hand) (glowing light blue)
_recent: Sting (weapon in hand) (light blue aura)
_now___: Sting (weapon in hand, flickering light blue)
The thresholds for intensity may need to be tweaked. The start
message has been changed from "glows" to "flickers/glimmers/gleams"
and is given when the intensity changes (up or down) as well as when
first glowing. Stop message will usually be "stops flickering" but
some form of mass kill (genocide for sure, maybe explosion, probably
not wand zap) might result in stopping directly from higher intensity.
It still "quivers" if hero is blind when there are orcs on the level,
but no name augmentation shows in inventory for that situation;
describing it as "(weapon in hand, quivering)" would be too silly.
Also, the quiver or glow intermediate message if blindness is toggled
while Sting is active only worked for make_blinded(), not for putting
on and taking off a blindfold. Now fixed. I think becoming blind due
to polymorphing into an eyeless form is still not handled, but there
are no eyeless creatures capable of wielding weapons so that can wait.
Polymorphing from eyeless to sighted is handled but moot for Sting.
Make being trapped in/on/over floor block Levitation and Flying, the
way that being inside solid rock already does, and the way levitating
blocks flight.
Blocked levitation still provides enhanced carrying capacity since
magic is attempting to make the hero's body be bouyant. I think that
that is appropriate but am not completely convinced.
One thing that almost certainly needs fixing is digging a hole when
trapped in the floor or tethered to a buried iron ball, where the
first part of digactualhole() releases the hero from being trapped.
If being released re-enables blocked levitation, the further stages
of digging might not make sense in some circumstances.
I recently realized that being held by a grabbing monster is similar
to being trapped so should also interfere with levitation and flying.
Nothing here attempts to address that.
Save files change, but in a compatible fashion unless trapped at the
time of saving. If someone saves while trapped prior to this patch,
then applies it and restores, the game will behave as if the patch
wasn't in place--until escape from trap is achieved. (Not verified.)
More fallout from allowing W/T on accessories and P/R on armor without
combining them outright. If poly'd into verysmall or nohands critter,
'W' yields "don't even bother" before even prompting what to wear, but
'P' would prompt for an accessory and then wear armor if that was what
got picked. Now 'P' will still prompt, in case it's for an accessory,
but picking a piece of armor no longer wears that armor.
'W' still doesn't even prompt, so won't allow accessories as well as
no armor. I'm not sure whether that should be changed.
The different menustyle settings have been offering different degrees
of support for BUCX filtering:
Full : multi-drop, container-in, container-out
Trad, Combo: multi-drop
Partial : none (to be expected; it explicitly jumps past class
filtering, where BUCX gets handled, to a menu of all objects)
This adds pickup, container-in, container-out, multi-unwear/unwield,
and object-ID for Trad and Combo, and multi-unwear/unwield for Full.
(Full behaves like Partial for pickup--not sure why--and for object-ID,
bypassing filters to go straight to a menu of all applicable items.)
There are probably several new bugs--this stuff is very convoluted....
I think this finally quashes the "cursed without otmp" issue.
Various ways of destroying wielded weapon used setnotworn() rather
than unwield(), so the previous change to have unwield() clear the
pending W_WEP bit from takeoff.mask wasn't sufficient to prevent
'A' moving on from another item (blindfold--it's the only thing
processed before primary weapon) to weapon which wasn't there any
more. Also, if weapon was already set in takeoff.what to be
processed on the next move, clearing W_WEP from takeoff.mask wasn't
sufficient either.
Move the previous unwield() 'fix' to setworn() and setnotworn() and
extend it to include cancel_don() if the item being replaced or
removed is in progress or scheduled for next. (Most of the time,
remove_worn_item() has already done that before setworn() or
setnotworn() is called.)
The do_wear.c part just eliminates some redundant code but shouldn't
produce any change in behavior.
The steal.c part should fix problems with 'A' when outer items are
taken off during theft in order to steal an inner item, where the
outer item is next to be removed (call to cancel_don() wasn't being
made). The wield.c part matches the X_off() behavior and is needed
to handle a weapon item that's slated for removal but isn't next (so
wouldn't pass the donning()/doffing() test to trigger cancel_don()).
If this seems a lot like trial and error, it is....
Extend the 'A' blindfold fix from three weeks ago to cover weapons
too. This might fix the problem being caught via curse(NULL) when
using 'A' to remove multiple items. The blindfold bug was straight-
forward since it was requiring two turns but not checking for loss
of blindfold when interrupted by theft. Weapon/alt-weapon/quiver
each only need one turn so I'm not sure what's really happening to
trigger problems for them.
Fix an inconsistency with blindfold removal, eliminating possibility
of a panic (3.6.0) or an impossible (since mid-December, 2016). The
'A' command treated blindfold removal as a multi-turn operation, the
rest of the wear/unwear code as single-turn operation so didn't try
to guard against it being disrupted.
Report was for
You finish taking off your boots.
You float gently to the altar. [destination was a red herring]
[take some action to run through moveloop() for next turn]
Your movements are slowed slightly because of your load.
Having float_down() do the next encumbrance check instead of
waiting for moveloop() to do so was straightforward. However,
while testing I noticed the reverse situation (not due to the fix
for the above) when putting on levitation boots
Your movements are now unencumbered.
You finish your dressing maneuver.
You start to float in the air!
Having float_up() do the encumbrance check isn't adequate to fix
this, because it takes multiple turns to put on boots but the
properties they confer are enabled immediately, so moveloop() runs
while hero is already levitating even though the game hasn't told
the player about it yet. Fix is a hack to defer the effect of
levitation on encumbrance until the boots are fully worn, which
might lead to strangeness somewhere. It's also boot-specific so
will need to be updated if some other multi-turn armor that confers
levitation ever gets added.
While fuzz testing, I've seen segfault a handful of times in here,
coming from do_takeoff(). Looks like context.takeoff.what is stale,
having WORN_BLINDF, but we're not wearing the blindfold anymore.
Haven't been able to trace it down yet, so guard it with impossible.
Change the sortloot option to use qsort() instead of naive insertion
sort. After sorting, it reorders the linked list into the sorted
order, so might have some subtle change(s) in behavior since that
wasn't done before.
pickup.c includes some formatting cleanup.
modified:
include/extern.h, hack.h, obj.h
src/do.c, do_wear.c, end.c, invent.c, pickup.c
Reported directly to devteam, the 'R' command would let you take off
a suit from under a cloak or a shirt from under a suit and/or a cloak,
and it didn't require any extra turns. 'T' doesn't allow either of
those. ('A' lets you take off a suit from under a cloak, adding in
extra turns to implicitly take the cloak off and put it back on,
but doesn't allow the same for shirt.)
'R' also let you attempt to take off embedded dragon scales if you
were wearing 2 or more accessories (or just 1 with paranoid_confirm
set for takeoff/remove), which triggered impossible "select_off:
<scales object> (embedded in skin)???".
Adding deafness to the status line spurred me on to something I've
wanted to do for a long time. This adds 'Stone' and 'Strngl' as
new status conditions, and moves the five fatal ones: "Stone Slime
Strngl FoodPois TermIll" to the front of the status list since
information about them is more important than any of the others.
"Ill" has been renamed "TermIll"; "Df" has been renamed "Deaf";
"Lev", "Fly", and "Ride" are three additional new conditions, with
Lev and Fly being mutually exclusive. After the fatal ones, the
order of the rest is now
<hunger> <encumbrance> Blind Deaf Stun Conf Hallu Lev Fly Ride
To handle the longer potential status line, the basic bot2() is now
smarter. If the line is wider than the map, 'T:moves' is moved from
the middle to the end. If the line without time is still wider than
the map, then experience (HD if polyd, Xp:M/nnnnnn is showexp is on,
or Exp:M) is moved in front of time at the end. If the line without
experience and time is still wider than the map, dungeon level plus
gold is moved from the beginning to be in front of experience. The
fields are just reordered, not truncated, so if the interface code
can display lines wider than the map they'll retain the extra info.
The gist is than health and associated fields (Hp, Pw, Ac) get first
priority, status conditions get second priority, then the rest. In
the usual case where there aren't many conditions, status display is
the same as it has been in the past.
STATUS_VIA_WINDOWPORT has been updated too, and it builds for tty
and X11. But the bot2() revision to reorder sections has not been
implemented for that.
win/win32/mswproc.c has been updated but not tested.
STATUS_VIA_WINDOWPORT without STATUS_HILITES had several compile
problems; now fixed for core and tty. STATUS_VIA_WINDOWPORT with
STATUS_HILITES has not been tested.
This one has a couple of code changes included, but they shouldn't
produce any change in game play. If anyone adds a new shirt or shield
they'll have to update the corresponding foo_on() and foo_off() routines
to avoid an 'impossible' when putting on or taking off the new item(s),
the same situation as already happens for other subclasses of armor.
Mostly && and || at end of the first half of a continued line rather
than at the start of the second half. The automated reformat got
confused by comments in the midst of such lines.
foo ||
bar
was converted to
foo
|| bar
but
foo ||
/* comment */
bar
stayed as is.
Some excluded code [#if 0] was also manually reformatted, but this is
mainly stuff that can be found via regexp '[&|?:][ \t]*$' (with a lot
of false hits for labels whose colon ends their line).
Allow 'P' and 'R' commands to accept armor and wear/take-off the chosen
item, and 'W' and 'T' commands to accept accessories and put-on/remove
the item. The which-object prompt only lists the type(s) of items that
traditionally go with each command, as does an inventory menu if the
user picks '?', but items of the alternate type(s) can be chosen, by
unshown letter or by the inventory menu given for '*'.
There shouldn't be much difference if you continue picking items that
go with the original commands, although you will somestimes get
"which object? [*]" when the only choices are for alternate command.
And you won't see the all-four-accessories-are-already-worn message
for 'P' unless you also have something worn in all seven armor slots.
The Guidebook.mn changes have been tested (that's how/why I noticed
the preface glitch) but the corresponding Guidebook.tex ones haven't.
Add macros W_WEAPON and W_ACCESSORY, similar to existing W_ARMOR, bitmask
of all the relevant worn bits. Just for code readability; there should
be no change in behavior.
Also, reformat the "ugly checks" portion of getobj(). Slightly better
readability and fewer continuation lines, but only a modest improvement.
OPTIONS:blind starts the hero off blind, but putting on the Eyes of the
Overworld confers sight. Make that break the blind-from-birth conduct.
Sight persists after removing the Eyes even though they aren't intended
to cure anything. It doesn't make sense to restore the blind-from-birth
flag when taking the Eyes off, but we may want to add another flag, or
make u.uroleplay.blind into a bit mask that can track both can't-see-now
for play and could-never-see for conduct. (Actually, u.uroleplay.blind
should track only the conduct, and starting the game with it enabled
should set one of the extra bits in u.uprops[BLINDED].intrinsic. The
Eyes already override that, and taking them off would restore blindness
since the bit would still be set. As a bonus, the expression in the
macro 'Blind' could be simplified.)
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.
