This is also from SliceHack, but with the odds of enlightenment toned
down a bit, to 4/9 for a blessed potion and 1/6 for an uncursed potion
(SliceHack had it at 50% blessed, 20% cursed, and strangely, 0%
uncursed). It gives a much-needed use to one of the potions that's
commonly blanked or discarded.
Several conditions result in stale data on the status line when
starting or stopping because things which didn't used to affect it
haven't been setting context.botl to force an update. This wasn't
systematic; there are bound to be lots more.
Make wearing a wet towel confer new attribute Half_gas_damage in
addition to the usual blindness. It reduces damage from being inside
a gas cloud region and from being hit by poison gas breath attack.
It also fully blocks breathing of potion vapors.
Might make the Plane of Fire easier although overcoming its blindness
with telepathy won't reveal elementals. Definitely has the potential
to make blind-from-birth conduct easier which wasn't the intent and
probably isn't significant.
From SliceHack. Note that this refers to the description of the physical
bottle; it's a substitute for "phial", "carafe", "flask", etc. such as
are seen when a potion crashes on someone's head. They don't obscure the
randomized appearance or actual potion identity.
The SliceHack version evidently went through several revisions; just
take the current one.
Submitted for 3.7.0; all but one also apply to 3.6.3.
I rewrote the curses terminal-too-small message instead of just
fixing the spelling of "minumum".
Move makeplural(body_part(FINGER)) into its own routine, with option
to substitute gloves when wearing such.
Wearing slippery gloves (ie, wearing gloves while having slippery
fingers) wouldn't let you put on a ring because you can't take the
gloves off, but removing a worn ring lacked the same restriction.
After changing that, teach prayer that slippery gloves is another
reason why a ring of levitation can't be removed.
Slippery fingers would transfer from bare hands to gloved hands if
you put gloves on. The reverse, transfering from gloves to bare
hands when taking gloves off, was already being prevented for
directly taking them off, but still allowed the slipperiness to
transfer when gloves were lost. This prevents putting on gloves
when fingers are slippery and attempts to handle cases where gloves
get unworn by ways other than 'T' (or 'R') or 'A'.
There's no slippery attribute for objects (way too much work for too
little value); slippery gloves is just the combination of wearing
gloves and having slippery fingers (which now has to have happened
while already wearing those gloves). This changes inventory to use
"(being worn; slippery)" when applicable and much of the patch deals
with funnelling Glib changes through new make_glib() to try to make
sure that persistent inventory adds or removes "; slippery" right
away when changes happen.
If gloves are taken off involuntarily (shapechange to a form that
can't wear them, destruction via scroll of destroy armor or monster
spell of same or via overenchantment, theft), slippery fingers ends
right away instead of the usual few turns later.
Something I realized while following up a newsgroup post. If you
knew an item's bless/curse state and dipped it into water while
blind, the bknown flag stayed set and you learned the item's new
bless/curse state without seeing any "glows blue/black/&c" feedback.
Clear the flag unless you know that the potion being dipped into is
water (or is clear if not water has not been discovered) and also
know the water potion's own bless/curse state.
Another part of github issue 229, mixtype() didn't have either 'break'
or '/*FALLTHRU*/' separating healing from extra healing, extra healing
from full healing, and full healing from unicorn horn. So dipping
"bad" potions (sickness, confusion, blindness, hallucination) into
healing/extra healing/full healing or vice versa operated the same as
dipping a unicorn horn into the bad potion (producing fruit juice for
sickness and water for the others). It wasn't clear from the code
whether or not that was intentional. It actually seems reasonable
(albeit suboptimal use of {plain, extra, full} healing), so continue
to allow it and make the code clear that it's intentional.
A recent change to make_slimed() overlooked a different recent change
in how mon->m_ap_type and youmonst.m_ap_type are referenced. In this
case it had no impact; fix on general principles.
Fixes#196
If you didn't die from turning into green slime but then died because
green slimes had been genocided, the message given assumed that you
had just seen "OK, you don't die" from answering No to "Really die?".
Its wording didn't make sense if the reason you didn't die was an
amulet of life-saving. Give a different message for that case.
Also, if you survive turning into slime (via either method) and either
green slimes are still around or you answer No to "Really die?" when
they've been genocided, give a message after "You survived that attempt
on your life" pointing out that you have done so in green slime form.
Useful since prior to 3.6.2 you would have reverted to original form--
despite the Slimed countdown saying you had turned into green slime.
Make healing magic which cures blindness also cure deafness. So,
drinking non-cursed potion of healing or any extra healing or full
healing; breathing fumes from blessed potion of healing or non-cursed
potion of extra healing or any potion of full healing; prayer reward
to cure blindness as a minor trouble. (Doesn't affect unicorn horns
which already treat deafness and blindness as two distinct troubles
that are eligible to be cured.)
More of a missing feature than a bug fix, so I listed it in the new
features section of the fixes file.
Noticed when looking at whether alchemy ought to remove user-assigned
name. Get rid of the potion being dipped into sooner so that it won't
still be present if a perm_invent update takes place.
Dropping an existing fragile item while levitating will usually
break it. Getting a new wished-for fragile item and dropping it
because of fumbling or overfull inventory never would.
Some callers of hold_another_object() held on to its return value,
others discarded that. That return value was unsafe if the item
was dropped and fell down a hole (or broke [after this change]).
Return Null if we can't be sure of the value, and make sure all
callers are prepared to deal with Null.
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.
Clean up quite a bit of minor things found with simple grep patterns:
operator at end of continued line instead of beginning of continuation
(and a few comments which produced false matches, so that they won't
do so next time), trailing spaces (only one or two of those), tabs (a
dozen or so of those), several casts which didn't have a space between
the type and the expression (I wasn't systematic about finding these).
I think the only code change was in the function for the help command.
Use the make_foo() intrinsic set/reset routines instead of trying
to manipulate the intrinsics directly. Previous patch left Dex
down by 1 if stoning caused wounded legs to be fixed, and left
delayed killer allocated if stoning cured sliming or vice versa.
I tried 'pick all' in the #wizintrinsics' menu and after 30 turns,
died with "poisoned by a poisoned, while vomiting". Food poisioning
and/or terminal illness beat the other fatal conditions to the coup
de gras. However, the final stage of vomiting sets Sick to 0 cure
food poisoning and ends up clobbering the killer reason if Sick is
due to terminal illness. It's feasible for that to happen without
using #wizintrinsic, so this fixes that, and also a few other
combinations that seemed contradictory:
1) limbs turn to stone during Stoned countdown now cures wounded legs;
2) turn to stone (a couple of turns later) cures vomiting and sliming;
3) turning to slime during Slimed countdown cures stoning.
Fixes#106
If dipping a worn amulet into a potion of polymorph turns it into an
amulet of change, the game panics while trying to use up that amulet
when the new one hasn't replaced the old one in inventory yet. Simply
reordering the relevant code isn't sufficient to fix things: once it
is in inventory and can be successfully used up, later code would end
up deferencing a stale pointer because it was unaware of the deletion.
Report classified this as 'segfault' but it's actually a controlled
panic(). When hero has lycanthropy and is wielding a potion of unholy
water while in human form, if that potion is boiled then it triggers
a transformation to beast form which in turn causes wielded weapon to
be dropped. When the code unwinds back up through potionbreathe() to
destroy_item(), the boiled potion won't be found in inventory any more
and useup() -> useupall() -> freeinv() -> extract_nobj() panics.
Right now, the punishment for being hit more than twice by a level
drainer pre-Quest is disproportionate; grinding back up to level
14 from level 13 takes a long time, and yet isn't particularly
difficult, just slow, and a potion of full healing will only
regain one of the lost levels (as only half the lost levels can
be regained this way).
Meanwhile, potions of restore ability are currently automatically
blanked by almost all spoiled players; they don't do anything that
doesn't have more convenient sources (unicorn horn or the spell),
so they're only useful in the very early game for getting poison
resistance.
This commit aims to fix both problems, by allowing potions of
restore ability to restore lost experience levels, in addition to
lost attribute points; an uncursed potion restores one lost level
(with multiple potions making it possible to hit the cap), a
blessed potion restores all of them. That gives players an
incentive to keep them around rather than blanking them. (Notably,
the spell and tool were not changed the same way; for restoring
levels, you need to use the potion.)
