<email deleted>
> comments: When dieing from an iron ball landing on your head, the death is
> listed as: "Crunched in the head by an iron ball"
> However no other deaths start with a capital letter.
Monks get a big penalty to hit when wearing a suit; otherwise they
get a bonus when not wielding a weapon. But as reported, that lets them
have their martial arts bonus even while wearing a shield which does seem
rather unexpected. This change makes them only get their to-hit bonus
while shieldless as well as weaponless. Impact on play balance is likely
to be quite small; late game characters hardly ever miss due to high luck
bonus and very early game ones won't have found a shield yet.
Shouldn't the "your armor is cumbersome" message be ``if (verbose)''?
From the newsgroup: wishing for a "Scorpius egg" succeeds;
fortunately the resulting egg will never hatch. Turn such eggs into
normal scorpion eggs instead.
Prevent #rub from wielding an item that is already being worn
(which should narrow things down to the various types of eyewear;
other tools and weapons that go through wield_tool() can't be worn).
Fix up the wield_tool message spacing in the process.
This moves wield_tool() from apply.c to wield.c. Some plural
handling for messages is included; it is feasible to try to #rub a
"pair of lenses" or a stack of N candles.
m_initweap() was trying to give him wands of fire and cold; since
he had no weapon attacks, he wasn't is_armed(), so this code never
got called.
This moves the code to m_initinv().
resulted in "That is a silly thing to [put on | wear]".
But those two cases really aren't so "silly", so adjust
the messages to better explain why the game objected
to the action and point new players at the appropriate
command.
Also adds a cmdassist message for the case where
'R' or 'T' have no appropriate items to point
new players to the correct command. (That can be
turned off with !cmdassist, of course.)
Also adds a const to a recent shade patch by request.
<Someone>:
Baby shimmering dragons have been made DRAGON_SILVER. Adults are still
cyan, as are their scales. Not that it matters while they're still
commented out, but why the discrepancy?
Breaking a boomerang while bashing with it didn't work right when
there was a stack of more than one involved. The message given had a
grammar buglet and the remaining boomerangs became unwielded. (This
issue wasn't present in 3.4.0 because the boomerang bashing code never
got called there.)
hold_another_object() will try to quiver the object being held if
it's a weapon (or gem/rock ammo) and the autoquiver option is enabled and
the quiver is empty. It was doing that even if the object had just merged
with primary or secondary weapon, resulting in it being equipped in two
slots at once. (Easiest way to reproduce it is via wish+wield+wish for
similar item, but it could also occur when stealing while in nymph form.)
This also addresses one of the old items on <Someone>'s list: if you
carry a sling equipped in the alternate weapon slot, include gems and
rocks as likely candidates for quivering same as when wielding a sling.
This extends that to autoquivering; ammo appropriate for your alternate
is now given preference over arbitrary weapons (ammo for your wielded
weapon and arbitrary missiles still take precedence over alternate ammo).
Bug? pickup_object() is not autoquiver aware, hence autopickup isn't
either.
Bug too (perhaps moot if the above is changed)? Snagging a monster's
weapon with a bullwhip uses hold_another_object() so possibly autoquivers;
snagging an object off the floor with a grappling hook uses pickup_object()
so doesn't.
This makes all unique monsters resist being given a name. Aside
from the Oracle, the four high priests are the only monsters affected
that weren't already being covered by the old tests. They might as well
decline to receive names too.
This also fixes a longstanding quirk that prevented you from
calling a type of object something if the representative sample of it
had been picked up while blind and you hadn't explicitly examined your
inventory since regaining sight. There's not much point in requiring
an extra 'i' command or use of '?' or '*' at the "what do you want to
call?" prompt, particularly since that makes gameplay be slightly
different depending on whether perm_invent is available and in use.
> Bug with flaming attacks...? These monsters should be unaffected,
> IMO.
>
> The fire elemental hits the stone golem. The stone golem is on
> fire!
fixed in patch
> The pyrolisk gazes at the flaming sphere... The flaming sphere is
> on fire!
This was already corrected in CVS.
For "traditional" menu style, pickup and #loot/apply can't accept an 'm'
response to bring up a menu upon request when all items involved are of
the same class, because the prompt where that response is allowed only
gets issued when multiple classes are present.
Also allow 'm' prefix for pickup.
For "traditional" menu style, pickup and #loot/apply can't accept an 'm'
response to bring up a menu upon request when all items involved are of
the same class, because the prompt where that response is allowed only
gets issued when multiple classes are present.
From the newsgroup recently: cause of death on tombstone and in
log file was "slipped while mounting a saddled Stockholm" (with horse
named after city). This fix will produce "slipped while mounting a
saddled horse called Stockholm" in that case.
Narrow openings are currently not checked for by hurtle_step() or
mhurtle_step. This has the consequence that you can jump or use
Newton's 3rd to get through somewhere you can't get through on the
ground, and monsters can stagger or be jousted through somewhere
they wouldn't attempt under their own steam.
This patch fixes hurtle_step(). It does not address mhurtle_step.
Move the "tame <monster>", "peaceful <monster>", "hostile <monster>"
handling for <ctrl/G> so that it works when <monster> is a class letter as
well as when it names a monster type.
Wizard mode monster creation underwent several changes for 3.4.0
(explicitly create "tame <monster>", create a monster by class letter,
repeat the creation for N monsters) and one of them rendered the check
to prevent creating orphaned shopkeepers, temple priests, vault guards,
and worm tails inoperative. Put that back, and extend the control to
allow you to specify "peaceful <monster>" and "hostile <monster>" too.
For the bribery check that lets you get away with offering a little
bit less than what was demanded, never treat an offer of 0 as acceptible.
Also, add some missing set_malign() calls.
This patch ensures that two-weaping stops if uswapwep gets cursed
while two-weaponing. I think this means the 'A' command will never
encounter the situation now in the complaint now.
See rules at top of wield.c.
Another vintage compiler (not as old as the previous one...) didn't
like the assignment `nlp = shkgeneral;' when nlp had been declared using
array syntax. It didn't used to mind that, until an extra `const' was
inserted by the "move stuff to read-only area" patch submitted by someone
a while back. The prototype is already using pointer syntax here.
The complaint states:
It still won't let you unwield a cursed secondary weapon while
two-weaponing, even though you can drop such a weapon without problem.
You aren't supposed to be able to two-weapon
with a cursed alternate weapon at all. It appears that there are some
checks to prevent twoweaponing if uswapwep is cursed when you try.
This patch ensures that two-weaping stops if uswapwep gets cursed
while two-weaponing. I think this means the 'A' command will never
encounter the situation now in the complaint now.
The rules in wield.c state
The secondary weapon (uswapwep):
1. Is filled by the x command, which swaps this slot
with the main weapon. If the "pushweapon" option is set,
the w command will also store the old weapon in the
secondary slot.
2. Can be field with anything that will fit in the main weapon
slot; that is, any type of item.
3. Is usually NOT considered to be carried in the hands.
That would force too many checks among the main weapon,
second weapon, shield, gloves, and rings; and it would
further be complicated by bimanual weapons. A special
exception is made for two-weapon combat.
4. Is used as the second weapon for two-weapon combat, and as
a convenience to swap with the main weapon.
5. Never conveys intrinsics.
6. Cursed items never weld (see number 3 for reasons), but they also
prevent two-weapon combat.
The heros_fault() macro added to region.h relatively recently causes
a K&R vintage compiler to choke on the heros_fault variable in dothrow.c.
Although the latter has been around longer, changing it was a little bit
simpler.
Hitting with a wielded boomerang was supposed to have a chance to
break it, but the code was located in a spot that would never be reached
when bashing with a missile weapon. Also, its rnl() usage would have
made the bad effect--losing your weapon--be more likely to occur when
you had good luck and less likely when you had bad luck. And it wasn't
setting `unweapon', so you wouldn't have gotten a bashing with barehands
message on the next attack after the weapon had been destroyed.
Building with an old version of gcc with various warnings enabled
generated a lot of noise. Most of it was due to not guarding string
literals with `const', but there were a couple of actual problems too.
Some recent newsgroup discussion claiming that a pet ki-rin was
wearing a helmet (I think poster was hallucinating) caused me to look
at some of the hat handling code. There were a couple of noticeable
problems and one latent one in code added for 3.4.1. Polymorphing
into a minotaur pushes hard helmets off hero's head, but nothing
prevented you from putting one right back on. Helmet wearing monsters
who polymorphed into minotaurs weren't affected at all. And message
handling always assumed multiple horns even though we have some singled
horned monsters, but since all those have no hands they can't wear any
armor and that potential pluralization issue wasn't noticeable.
Fix the problem From a bug report. An earlier fix (3.3.1)
made them be listed during final disclosure, but the points shown for
them actually got left out of the total due to misplaced brackets.
Rather than just fixing the brackets, merge the two inventory scanning
loops so that both passes will always be synchronized with each other.
<email deleted> on Saturday, January 4, 2003 at 12:16:29
comments: I just noticed that, while wearing a -1 ring of adornment, a potion
of enlightenment gave the intrinsic "You are adorned." Shouldn't it be more
accurately, "You are unadorned." or something similar?
Back in 2000 "Pat Rankin" wrote:
> From a user (in a message which had several unrelated things):
>
> > I think the colour of silver dragon scales / scale mail should not be
> > SILVER (which is not a colour), but HI_SILVER. Of course the colour of
> > silver dragons would have to be adjusted to match this.
>
> I don't normally have access to a color display, so I hadn't noticed
> that silver dragons are CLR_BRIGHT_CYAN. It is pure coincidence
> that material SILVER happens to have the same numeric value as that.
> Is bright cyan intentional, to make them distinguishable from gray
> dragons (since color HI_SILVER is defined to be the same as CLR_GRAY)?
> Or was it done for the monsters just because the corresponding objects
> accidentally had the wrong value? It seems to me that they ought to
> be the same shade of silver (ie, gray) as other silver things, even
> if that makes them look identical to gray dragons.
Using the material value SILVER in the "color"
field was wrong, no matter what the reason. I
suspect it was probably a mistake originally.
This patch does not alter the displayed colour for the
bug-fix release, but does correct the misuse of the
material.
Steve VanDevender noticed that fixing the default text window font
caused the rip window to use this font as well, due to intricacies
of X11 resource relationships.
Various damage types which wouldn't work when a cancelled monster
attacks the player were working when it attacked other monsters instead.
Besides attempting to fix that, this also makes cloaks and other magic
blocking armor ("magic cancellation factor") work for monsters similar
to the way it works for the player.
Most types of damage appear to revert to physical damage when the
attacker is cancelled; I'm not sure that's appropriate in many of the
instances. The leg-pricking case was clearly wrong, since it gives
messages about the attack failing yet still hurt the character.
This really needs a lot more testing than I have energy for. I've
tried to clean up various inconsistencies and may have made some typos
in the process.
