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.
Since "weapons and spell skills" is grammatically suspect and
"weapons and spells skills" sounds odd, change to "weapon and spell skills"
in both the Guidebook and the game's online descriptions. The #enhance
command itself uses "current skills" and doesn't need any alteration.
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.
Per <Someone>'s request, make the game's description of the ``#enhance''
command be the same as in the Guidebook by mentioning spell skills.
Combining weapons plural with spell singular isn't right, but I'm not
sure which way to change that so am leaving it alone. On the other hand,
the poor grammar used to describe the ``#conduct'' command is easy to fix.
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.
- 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
Play a character without see invisible. Wear speed boots. Generate a troll.
Zap it with a wand of make invisible. Kill it. Stand on the same square and
wait for it to rise from the dead. It will appear as a 'T'. Hitting it then
produces the normal "Wait, there's something here you can't see!"
[ incorporate slashem-Bugs-951439 fix ]
<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.
on Sunday, April 4, 2004 at 20:27:06:
> On occassion when restoring a game where the
> character is wielding Sting, floor glyphs
> will show up before the --more-- prompt.
> These floor glyphs usually correspond to the
> location of monsters (sometimes they are just
> cavern features such as walls). Some of these
> floor glyphs are not in the character's line
> of sight upon restoring.
Also in this patch is a restore of Sting's ability
to glow blue.
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 :-)
Give more information about your attributes in debug mode
via Control-X.
I'd like to see some way of getting bits of this info to the
player during the game (from the Oracle or something),
but this patch keeps it limited to debug mode.
On mazelike levels, mimics will mimic either boulders or statues (of giant
ants, as it turns out). However, it does not make sense to mimic a boulder
on a hole or even a pit, since boulders would typically fall in. Also,
statues are not typical objects in Sokoban. So, skip statue special case
in Sokoban and always avoid the forced emulation of a boulder when on a
trap location outside a room. This is a bit drastic, but I couldn't think of
an argument for adding the code to do this only for pits, holes, et al,
which are the most likely traps outside rooms anyway.
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.
Try to fix the report of a doppelganger (created from using stone-
to-flesh on a fake statue of Demogorgon) having 1700 hit points after
reverting to its native form. The problem was due to the special monster
level of Demogorgon rather than anything to do with shape changers; the
actual bug was use of `mdat->mlevel' where it should have been using
`mtmp->data->mlevel'. But the whole section of code was rather suspect
since it didn't attempt to handle other types of monsters (dragons, golems,
elementals) which have non-standard hit points, so I knocked some out.
Monsters who have gained or lost levels prior to changing form will no
longer carry that adjustment along; the new form will always be a brand
new one of its type. However, if the old form is injured at the time of
change, the new form will be too (same as before).
Since the rogue level does not have closed doors, mimicking one there makes
no sense. Similar to what wand of locking does there, make mimics that end
up there mimic a wall instead of a door.
There was already code to ensure that if a hidden monster moved, it would
no longer be hidden. However, if the monster is asleep or whatever under
a rotting corpse, when the corpse rotted away, the monster would not
immediately become detected. Add a check to the rot code before the newsym.
Attempting to go > while blind and floating over unknown stairs/ladder
would refer to the stairs in the "high above" message (however, the
stairs/ladder remained unidentified on the map). Change this case so
it only refers to stairs/ladder if that's what the hero remembers on the map.
>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 kill the invisible storm giant. The boulder fills a pit."
> [...] why did I find the corpse *lying on* and not *buried in* the
> former pit?
Ensure that the corpse ends up buried in that case.
