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.
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.
> You're equally unlikely to be wishing for spellbooks by colour,
> but I note that 'grey' for 'gray' only works for dragonscale and
> stones, not the spellbook description.
[forwarded from newsgroup]
When polymorphed into a handless monster, you can't loot a chest
that's on the ground but you can pick it up and then apply it when
it's in your inventory.
> You hit the shade with an egg. Splat!
> The cream pie splashes over the shade's face!
> Your venom burns the shade! [But it doesn't.]
> A mirror breaking I could possibly see, since the silvering is the
> important part there.
<Someone> wrote:
I happened to be playing under X11 for a change this weekend, and I
noticed that, since the direction help of cmdassist uses (sort of)
ASCII art, it looks rather peculiar in a proportional font. Could it
be made to use the menu font instead?
<Someone> wrote: "Also, hobbits can't wear armour,
at least, you can't wear armour when polymorphed into a hobbit, even
though hobbits do tend to be carrying elven mithril-coats.
It's tempting to suggest adding an explicit exception in
sliparm() for elven mithril just to keep the Tolkienness."
- added a general routine for adding race-based /object
combination exceptions.
- hobbits can wear elven mithril-coats
Post 3.4.0 bug: "Your a lance (weapon in hand) shatters on impact!"
Use xname() instead of doname() to get "lance" instead of "a lance" here.
It also wasn't giving "you start bashing with your bare/gloved hands" on
the next attack after losing the weapon.
Invoking the archeologist's Orb of Detection gave "you feel a surge
of power, but nothing seems to happen" if you were able to see invisible,
but various other ways of toggling invisibility give fade/unfade messages
in that situation. Also, you would get false reports of invisibility
changes if you invoked the artifact while temporarily invisible due to
potion or spell or while wearing a mummy wrapping.
hitmu was trying, and failing, to re-implement parts of x_monnam(). Changed
it to use Monnam(), which produces more detailed messages than before in
some cases, but seems better since its messages are now more consistent
with hitmsg() and prints "The" in this specific case.
- The code in xkilled failed to call spoteffects after killing the monster
that was engulfing you. Being expelled already worked correctly.
- While testing this, I discovered that removing a ring of levitation or
similar while engulfed would call spoteffects when it shouldn't. Fixed
that too.
Add the wizard entry submitted by <Someone>. It doesn't fit
perfectly but seems better than getting the generic human (or other
race) entry. It pointed out that "gnomish wizard" is ambiguous between
a type of monster and a player character race/role combination. I had
to add a special case to the code to make that work out right.
This also makes all the roles that have the their entry match any
race; conversely, match the race's monster for roles that don't have an
entry (caveman, healer, monk, priest, and samurai; we really should get
them their own). Previously many of the non-human ones yielded "I don't
have any information on such things" and at least one (elven priest)
yielded the generic human entry.
Prevent a demon who is carrying the Amulet of Yendor from being
removed from the game when player meets his demand for a bribe since
that was effectively destroying the Amulet. There are various ways
to accomplish this; I chose to make the bribe demand be for an amount
that the player cannot possibly satisfy in that case.
Make timeout of temporary invisibility consistent with other
forms of toggling that state: you notice it even when you are able
to see invisible. (Invoking the archeologist's quest artifact is
still inconsistent in this regard.)
> Zapping a wand of digging at trees in ranger's quest gives a message
> "rock glows then fades".
There was code to handle this, but it didn't work due to the
definition of IS_TREE making checks for STONE be sensitive to code
ordering (STONE was checked first in this case).
#define IS_TREE(typ) ((typ) == TREE || \
(level.flags.arboreal && (typ) == STONE))
Why is it defined this way? Shouldn't STONE simply be converted
into TREE when arboreal levels get created?
Most callers of dropx did not check for altars, but should have. Rather
than add such checks, I moved the check from drop to dropx. I also found
several callers of dropx that could generate out-of-order messages for some
cases (not new) and fixed them. FYI - callers of dropy don't seem to want
altar checks or already do them.
Menu styles `partial' and `full' will let you remove any type of
item from the three weapon slots via the 'A' command, but `traditional'
and `combination' would only do that for the primary weapon slot. For
the alternate weapon and quiver slots, the item in question had to be
one which can normally be wielded or worn, otherwise when choosing the
object class letter you'd be told that it was "Not applicable." And
for wearable items, you needed to be really wearing one of that class
(besides the quivered one) or else you'd get "not wearing any amulet"
or similar.
Ahe 'A' command would not let you remove a cursed item from the
quiver or alternate weapon slot. But other commands such as drop or
quiver would let you get rid of such things since they aren't considered
to be welded in place the way a wielded weapon is.
This seemingly minor bug is more significant than first appears
because it opens a loophole to allow you determine whether any held item
is cursed: quiver it, try to remove it with 'A' and possibly be told
that it's cursed, really remove it with 'Q' if so.
- water elementals now get a special message when they land in lava
- rather than track down all places where non-moving monsters can end up in
lava (or water, not that it currently matters), add a check to mcalcdistress
to catch all such cases, once per turn.
Make sure the three instances of special fire effects stay
synchronized in the future by moving the relevant code into its own
routine.
Shouldn't fire vortices and fire elementals also yield "already
on fire"? How about ice vortices "melting"?
A 3.4.0 report, currently only the mdamagem gaze case caused the strange
"on fire" message for flaming spheres, but other attacks seemed like they
might result in a similar message, so I updated the damageum and hitmu
cases as well.
