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.
> 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?
Add the caveman, healer, and monk data.base entries supplied by
<Someone>, plus the healer one from <Someone>'s list of outstanding bugs and
requests. Every role now has its own entry. I left "dwarven caveman"
and "gnomish caveman" pointing at the generic dwarf and gnome entries
respectively, because the caveman quote feels to me to be more human-
specific than the earlier role ones have been.
I added blank lines to the monk quote to break it into paragraphs,
and made two minor tweaks to the text. I hope we can find or invent a
separate entry for Master Kaen though. Getting a quote that refers to
Buddhism for him seems wrong to me, but leaving the generic human one
now that there's a monk-specific one didn't feel right either.
I've moved a few quest guardians around this time. Deciding which
of them should yield the corresponding role entries and which shouldn't
involves judgement calls and I don't claim that the current situation
is now perfect.
> This patch adds a bit of help on where a win32 bison/flex port can be
> downloaded, how to set it up, and provides default settings for that
>port. It seems the homepage has been stable for at least four years.
>The bison outputs from this port are y_tab.c and such, so I changed
>the defaults in the makefile to be such. The flex output is yy.lex.c.
>One question that was fwd'd to me after the release dealt with
>using bison and flex.
<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.
The problem with the new autocomplete was tracked down to
be the result of differences between different implementations
of backsp(). The differences go all the way back to the
early MSDOS port by the look of it, and the win32,
and Mac tty ports all seemed to pattern themselves after the
MSDOS port for that routine. Apparently, it didn't cause any
harm until now.
The problem is that backsp() sends a character sequence
of 0x08, 0x20, 0x08 on at least those ports, where the Unix
tty code only sends 0x08. So the characters in the new
autocomplete were all being erased from the screen.
This patch only fixes the win32 tty port, so I've left the
conditional code in getline.c for DOS and Mac. I
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.)
