The same occurred for fountains and drinking surrounding water while
underwater.
I also added a !Levitation check for sinks, like already exists for
fountains. I cannot believe sinks are taller than an altar, and if you
can't pick up stuff from an alter while levitation, it stands to reason you
cannot drink from a sink then either.
<Someone> reported that riding a steed into a magic portal can
give "steed is still eating" message, feedback normally used to explain why
you can't go down stairs. Rather than preventing portals from activating
in that situation, just force the meal to be finished in order to suppress
the message. Proper fix is probably to prevent all steed movement while
eating, but that would most likely result in no one ever riding again.
Fix the wizard mode crash From a bug report. Move the WIZKIT
message suppression to a lower level instead of trying to guard against
present and future pline() calls in the wishing code. The way that was
being handling wasn't suitable for dealing with quest feedback.
This also includes a couple of additional wishing synonyms.
Someone in the newsgroup expressed surprise that he didn't get any
special message after surviving the eating of a cockatrice corpse. Combine
the cliche that unconventional meat inevitably tastes like chicken with
the mythology that cockatrices are a bizarre hybrid of chicken and reptile
(or whatever). This will give a message about tasting like chicken for
corpses or smelling like chicken for tins when the hero has petrification
resistance (poly'd into a xorn, for instance) or is hallucinating.
A user reported that when breaking potions inside a box in a shop, he
wasn't charged for them. The code was calling stolen_value() as intended,
but that routine only charged for types of items which the shop normally
carries. That meant that breaking the contents of a box in a general
store would charge for them but doing so in a tool shop would, not even
though the tool shopkeeper would gladly sell such things when you picked
them up instead of causing them to go away.
When fixing this, I noticed that stolen_value() was only charging
for single items. Most of the time that was right, because throwing and
kicking things always split one off, but there are cases (such as zapping
a wand of teleportation at shop goods) where an entire stack gets stolen
as a group. This makes stolen_value() handle all quantities.
Eggs thrown straight up which don't splatter on the ceiling yield
"you've got it all over your face", so wearing a helmet shouldn't protect
against petrification from cockatrice eggs in that situation. This was
part of my delayed helm vs hat stuff; I can't remember whether it was done
before or after this same issue came up in the newsgroup.
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.)
Allow the #adjust command to be used to split an inventory stack
as well as for moving things to specific slot letters. Splitting is
accomplished by specifying a count along with the letter of the stack to
operate on, similar to when dropping a stack with 'd'. The comment above
doorganize() has more details.
This change will make it possible for users to split stacks of cursed
loadstones which they couldn't easily do before, but I don't see anything
wrong with that. It was always possible to have multiple stacks of load-
stones by starting with ones that had different curse/bless status, so this
hasn't introduced a totally new situation. On the other hand, I haven't
tested this with the GOLDOBJ configuration and am not sure whether there is
any need to prevent gold from being split there. The getobj() call doesn't
specify COIN_CLASS so perhaps it's irrelevant (unless it ought to be
changed the other direction by adding that to intentionally allow gold to
be split?).
Despite lack of feedback from the beta testers about it, add the code
which tries to stack an object being added to inventory with the quiver
before trying with other carried objects. Only matters to user if quiver
is non-empty and one or more other slot(s) are compatible with it, but
that's not uncommon for someone who starts a rogue by splitting the initial
daggers into separate wield and throw slots. Firing a dagger from quiver
and then having it merge with wielded weapon instead of back into quiver
when picked back up leads to tedious inventory manipulation. Assigning
different names to the two stacks solves this, but can't help when picking
up an unnamed item which is otherwise compatible. (A rogue with starting
daggers wouldn't encounter that since unnamed ones won't be sufficiently
identified to stack, but any character who just gathers unID'd daggers and
uses them for both melee and throwing has a chance of running into the
"picked up into less desireable slot" trap whenever new ones are found.)
<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.
From the newsgroup: if you were polymorped into a cockatrice and
a trapper attempted to swallow you, the 't' displayed at its location
would be left behind after it turned to stoned. This fixes that and a
much more serious issue as well: if you were punished at the time, the
game would panic on your next attempt to move because the ball&chain were
left in limbo. There would also have been strangeness (monster sharing
your location, stale u.ustuck setting) if the swallower was life-saved,
but I didn't try to make that happen so am not sure how bad things would
have been.
From a bug report, but pulls back" while successfully
praying. Gas spores' only "attack" is to explode when dying, so the code
that checks whether the monster has any attack needs to handle AT_BOOM as
a special case. Unfortunately this change means that you won't interrupt
an occupation when a gas spore approaches, and a subsequent kill by your
pet might end up causing you harm while still occupied. The callers of
`noattacks()' are messy enough that I didn't want to try to address that.
This also moves noattacks() from mhitm.c to somewhere more sensible.
Reported last December by <email deleted>. Using
a wand or spell of undead turning inside a shop used up corpses without
checking whether they were owned by the shop. Although the report didn't
mention it, using stone-to-flesh on statues had the same problem.
I'm not completely satisfied by some aspects of this code, but if I
don't commit what I've got now I probably never would. My original notes
are lost; I thought that there were some additional fixes present, but
looking at these diffs I don't see anything else significant enough to
warrant mention in the fixes file.
Fix the two minor grammar problems for messages given when eating
that were From a bug report: inappropriate or inconsistent
capitalization in mid sentence for
Ulch - That <object> was rustproofed!
and missing punctuation for the appended clause for cannibalism in
Ulch - that meat was tainted cannibal!
Patch was sent in by <Someone> on Sep 8:
This bug causes a number of impossible messages (starting with splitbill:
no resident shopkeeper??)
Repeat by:
Enter a large shop.
Wish for a large stack of projectiles.
Sell your projectiles and then pick them up again.
Trap shopkeeper against the door with a scroll of earth.
Throw the projectiles at the shopkeeper to anger him.
Move away from the boulder trap and wait for the shopkeeper to leave the
shop.
Throw one of the projectiles at the free space.
It appears that the Athena text widget in recent XFree86 distributions
does not properly honor the XawtextScrollWhenNeeded flag, so the text
widget created by X11_display_file() does not have a vertical scroll bar
when the text does not entirely fit in the window. I have seen this bug
in XFree86 versions from 4.0.2 through 4.3.0. Using XawtextScrollAlways
for the vertical scrollbar ensures it will always appear.
Objects which were destroyed by dipping them into lit potions of oil
didn't get unworn or unwielded in cases where that was needed. This left a
stale pointer which could result in various strange things (user saw it be
formatted as "glorkum" but that isn't guaranteed) and there was no update of
any attributes or intrinsics conferred by the item, so persistent levitation
or water walking or dexterity boost could occur.
Eliminate two minor anomalies in the behavior of the rnl() function
which returns a random number that is modified by the hero's Luck attribute.
Integer division by 3 on requests for small ranges and the fact that the
chance of making a modification was lower for good luck than for bad luck
meant that highest luck did not produce best chance to avoid worst result.
The actual effect on game play is sure to have been negligible. More
troubling is that the program has several rnl(3) and rnl(4) calls. These
practically guarantee a result of 0 when the hero has maximum luck. The
rnl() function really shouldn't be used for such tiny ranges (unless the
actual intent is that high level characters are expected to almost always
have the 0 outcome...).
<Someone> Cced from rgrn:
<email deleted> (<Someone>) writes:
[killed by a boulder trap, left bones]
> Then I realized... there's no boulder. Did the boulder disappear
> because I died from the attack, thus bypassing the code that moves the
> boulder to its intended destination? Did the creation of the bones
> file destroy the boulder? Do boulder traps sometimes get
> "deactivated" when bones files are loaded?
The first of these. If you look at launch_obj(), there's an
obj_extract_self() early on, then all the tracking its trajectory,
then a place_object() when it comes to rest; since the thitu() call
kills you during the trajectory part, the boulder never gets re-placed
onto the map. This is, I think, a bug (and one that will apply to any
monster-thrown object that kills you, as well); reported to the
DevTeam.
A user pointed out that you lose pacifism conduct if you kill your
pet by displacing it into a trap but you don't gain any experience in
the process. Make this consistent with killing monsters in other ways:
if you get blamed for it then you should also get credit for it.
Probably minliquid() and mintrap() should take another argument so
they can call killed() instead of mondead() when necessary, but I didn't
go to that much effort....
From a bug report: fracture_rock() was unintentionally propagating
the boulder or statue's dknown flag to the resulting rocks, producing a
trivial but noticeable difference in description of "rock" vs "stone" if
the source object had been seen up close prior to being broken and the
rocks are then examined remotely or while blind.
The curse/bless state is propagating too, but this seems reasonable
so I've left it alone.
User reported the following incorrect feedback:
You drop Medusa's corpse. corpse falls down the stairs.
and apparently thought that the problem was a glitch in the middle of the
sentence; the actual problem is that the second sentence lacks its start.
This fix isn't perfect. You'll now get
Medusa's corpse falls down the stairs.
for the second sentence, but
The Oracle corpse falls down the stairs.
when dealing with a unique monster who doesn't have a personal name.
Either form seems acceptable to me, but mixing them appears inconsistent.
Probably all the uses of corpse_xname() (and its callers back up the
chain cxname(), aobjnam(), yobjnam()) need to be reviewed for usage. I
don't have the energy for that.
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).
Fix the situation <Someone> reported where the "You disturbed me, fool!"
result when releasing a djinni from a cloudy potion sometimes produced a
peaceful djinni for neutrals due to the usual randomness in how monsters
react to characters of the same alignment. Explicitly force it to be
hostile for that outcome.
Also, for the "it's about time" result, suppress the "It vanishes"
message when the character doesn't see the djinni depart.
Fix the situation <Someone> reported where a shopkeeper removing a trap
from the shop doorway yielded "you see the shop door reappear" instead of
reporting about the trap. It made sense if the door had been destroyed
but not when intact.
For trunk only, try to fix up the shop repair message situation when
multiple repairs occur at the same time. Some things were being treated
as mutually exclusive when they aren't. This part needs more testing,
probably using a debugger to force multiple pending repairs to all occur
on the same turn. At any rate, using wizard mode and hoping for some
simultaneous activity was ineffective.
<Someone> wrote:
>It seems silly to have two flags being used for counting djinn and
>ghosts, now that there's mvitals.born...
This does not break save and bones compatibility in the 3.4.x branch,
it changes the code, but leaves the obsolete fields in flags.
"<Someone>" on January 8, 2004, wrote:
> A Valkyrie on the Quest home level, wearing an
> amulet of magical breathing, enters a fire trap
> out on the ice:
>
>> A tower of flame erupts from the ice!
>> The ice crackles and melts.
>> You fall into the water. You sink like a rock.
>> But you aren't drowning. You touch bottom.
>> A cascade of steamy bubbles erupts from the bottom!
>
>Should the trap really be being triggered twice, once on ice and
>once underwater, when I've only moved onto the location once?
As From a bug report, if you couldn't see a rolling boulder
fall into a pit, you only heard the sound if you were blind.
Also fixes the article used in the message.
<Someone> reported:
>> The marilith wields 5 daggers!
>> The marilith thrusts her dagger. The marilith misses.
> Shouldn't she thrust her daggerS?
Change to:
"The marilith thrusts one of her daggers." in that case.
Fix the situation <Someone> reported where requesting information about
the not too unlikely word "offering" would match the "ring" quote. I didn't
add a new quote for it but made "offer[ing]" and "sacrific[e|ing]" match the
existing altar quote. I also added one small quote I've had laying around
for a while.
Disable processing of double-click messages if the first click
causes map to scroll. The problem is that if the first click scrolls
the map the second click is going to scroll it even further
(before it is redrawn) which is very confusing for the user.
>If you hit a cockatrice with a weapon that immediately breaks
>(like a potion, mirror, or cockatrice egg) you get stoned,
Add a parameter to passive() to make it possible to pass
additional information that indicates that the weapon was
there at the start of the turn, but destroyed during the turn.
Fix the bug From a bug report. Subsequently removing
the item caused those attributes to be returned to an incorrect value
which was higher than the character started out with.
<Someone> wrote:
> You have much trouble removing u - a helmet.
> You have much trouble lifting a plate mail. Continue? [ynq] (q)
> You have much trouble removing R - a plate mail.
> You have much trouble removing N - a leather cloak.
> Why am I told that I have trouble "lifting" a plate mail?
1. Add strsubst() routine to hacklib to replace a word or phrase in a string in place.
2. Correct the inconsistency reported.
- as requested by ESR, remove the use of parentheses from the usage
summary, it confused some man page conversion tool he has
- updated documentation for the -p option to mention the word "role"
so anyone search for role in the man page will still find it
- removed use of .UC, it is listed as deprecated in all the current man
documentation I could find, when it was even documented at all
- other minor spelling and formatting (hyphenation) changes
<Someone> reported that dipping acid in a fountain did not always destroy
the acid. It might be best to have get_wet call useup in this case, but
that would require more work.
Reported to the list back in November: scaring a mimicing mimic will
produce a "turns to flee" message, but the mimic does not unmimic nor
does it flee. The latter behavior made sense to me as a defense mechanism,
so I changed monflee to avoid printing the message in this case.
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.
<Someone> reported back in December of an invisible monster using an amulet of
lifesaving and looking much better. While the comment in the code says the
amulet is visible, this does not mean the monster is. Add a secondary check.
Both the reported tombstone message and the initial message could be
grammatically incorrect for eating identified artifacts. This begs the
question whether artifacts should be so easy to destroy.
<Someone> drew attention to the silly message in the newsgroup
Since I'm not sure if the act of polymorphing has a sound,
I opted to use a new usmellmon() routine to put out a
message based on the smell of the resulting monster
under those circumstances.
Not every monster has a recognizable smell, so no
message at all is given in that case.
olfactory(youmonst.data) will determine whether
you are capable of detecting smells.
There is lots of room for enhancement, and some of the
existing smell-related messages in the source should perhaps
be checking olfactory(youmonst.data) too, but this patch
doesn't go that far.
