The CE ports use makedefs hosted on another platform,
so the version string generated at build time isn't really
appropriate.
Add a way to add information to the version string
at runtime for such ports.
Make wielding Werebane confer defense against catching lychanthropy
from monster bites. It doesn't protect against catching that from eating
lycanthrope corpses and might blast the character if wielded at such time.
Also fix artifact handling to recognize the character as lycanthrope
while in normal human/elf/whatever form--rather than only when in beast
form--just like it does for monsters.
To fix Magicbane's message sequencing, its code needs to be redone
substantially. These changes make that easier.
cancel_monst() let caller know whether cancellation succeeds
resist() give artifact weapons a resistance attack rating
vtense() handle monster names and "you" as subjects; checking against
object names and descriptions pointed out a couple of other
words that would have ended up being miscategorized.
>More worrying is the fact that applying a figurine over water lets
>the monster wait until its next move before it drowns (giving
>you time to teleport it to safety, or whatever) [...]
>Should there be a minliquid() check as part of make_familiar()?
Applying at the water location next to you was easy. But
applying it at your own location (triggering BY_YOU) could
end up placing the figurine at the far side of the level if
there was lots of water.
Correcting that required the ability to pass a flag from
make_familiar to makemon() telling it to not rule out
water locations as good positions. The flag had to
be passed on down to goodpos() and enexto().
The bulk of this patch is just adding an additional
argument to goodpos() in all of the callers.
Provide a way to have a port-specific debug-mode commands
if PORT_DEBUG is defined at build time.
Add a win32 keystroke checking routine to assist debugging
of international keyboards.
Fix a problem with the way NetHack was handling
international keyboards by letting ToAscii() come
up with an input character based on the virtual key,
and the shift and caps lock state.
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.
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.
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.
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.
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.
<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
Added support for
Palm-size PC (Windows CE 2.11) and Smartphone 2002.
It works fine under emulation, but it still needs to be tested
on real device. There are also some minor tweaks here and there.
Removed files:
sys/wince/recover.vcp
sys/wince/wince.vcp
New files:
sys/wince/winhcksp.rc
sys/wince/defaults.nh
sys/wince/hpc.vcp
sys/wince/palmpc.vcp
sys/wince/pocketpc.vcp
sys/wince/smartphn.vcp
<Someone>
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.
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"?
Fix the reported problem of getting impossible warnings for unpaid
inventory items during final disclosure if you level teleport out of
the dungeon while holding shop goods. The fix makes you trigger a shop
robbery first; that required a minor end of game change to prevent the
shopkeeper from seeming to tag along (shk would take your possessions
as if you'd died on the shop level).
use get_adjacent_loc() rather than getdir() directly for some things where
you want to ensure valid adjacent coordinates are returned
<email deleted> wrote:
>>> [...]
>>> I've noticed that the loot adjacent spot code doesn't have any
>>> isok(x,y) test, so will risk crashing if used at the edge of
>>> the screen (whether deliberately, or accidentally due to being
>>> confused or stunned when picking the direction).
>> Would this not be a problem elsewhere, such as use_leash() too?
> Yes, that looks like the same risk. getdir() doesn't validate
> that the <u.ux+u.dx, u.uy,u.dy> is safe and neither does m_at(),
> so their callers need to.
>
> I did manage to provoke a crash with #loot on the plane of earth,
> although an accidental case would be a lot less likely to happen.
Forwarded from the newsgroup: when a monster gets hit by wand or
spell of polymorph, any armor that fell off was protected from being
hit by that same zap, but a dropped weapon wasn't. Nor was the whole
dropped inventory in the case where the monster is killed by system
shock rather than transformed. Protect its entire inventory.
When Angels were introduced, they were always lawful. Somewhere along the
line, non-lawful angels were added, but is_lminion and uses of it was never
updated to address this change. Among other things, this resulted in
non-lawful angels delivering messages via #chat that are only appropriate
for lawful angels. That is addressed simply by changing the definition of
is_lminion, which must take a struct monst, not a permonst, to return valid
results. Also, non-lawful angels should summon appropriate monsters, not
lawful minions.
More region fixes. The region restore code wasn't updating monster
ID numbers for bones data, so monsters already inside stinking clouds
might or might not be affected by them depending on arbitrary mon->mid
assignments across the old and new games.
This also flags stinking clouds in a way that lets the game keep
track of whether they were created by the player, and clears that state
for bones data so that the current player doesn't get credit or blame
for clouds left by the former one. File compatibility with 3.4.0 is
retained; if/when that eventually changes, this code can be simplified.
Testing with current development code has been limited but seems
to be working correctly; testing with actual 3.4.0 files has not been
attempted.
Incorporate a fix from <Someone> that resets the timestamp on
stinking clouds left in bones files. This does allow the cloud's ttl to
restart. Extended it to reset the player_inside flag.
Then noticed that the only placed that called in_out_region was domove().
Added calls when changing levels (which causes player_inside to be set
correctly if the cloud covers the location where the player starts on the
bones level), teleporting, and inside hurtle_step. There are still other
places that fail to call in_out_region, which others may choose to tackle.
I split out the remaining stinking cloud bug reported in the same e-mail
into a separate betabug. That one probably cannot be addressed without
changing the level file format to track the creator.
Fix the reported bug of an unskilled rider who is unable to pick
items off the floor while mounted still being able to dip into water.
There might be other actions which need similar checking; this one only
handles the dip into pool/moat case.
Instead of adding a new artifact.h to pray.c, remove the existing
ones from attrib.c, invent.c, and mkobj.c. This also updates the Unix
and VMS editions of Makefile.src; having stale dependencies in those
for other ports could cause unnecessary recompilation but can't break
anything in this case.
If the character was invisible without being able to see invisible,
his location on the map showed any object there or underlying topology
instead of the hero even when monsters could be seen with infravision,
ESP, or sustained monster detection. The ESP case required an amulet
or helm or quest artifact to be noticeable because being blind overrides
being unable to see invisible, so the more common form of telepathy
didn't exhibit this behavior.
Polymorphing into creature with horns such as a minotaur,
will cause your helmet to fall off if it is made of a hard material.
Only minotaurs pass the has_horns() test in include/mondata.h
because the complaint specifically referred to them, but that
should perhaps be reviewed at some point by someone who is
certain which creatures have horns growing from their
head (some demons?)
Noticed while testing something recently: if you're wearing
a non-cursed ring of levitation but can't remove it because of
some other cursed item, you'll never get the high priority result
of TROUBLE_LEVITATION when praying. This remedies that.
Provide more control over message handling for monsters' use
of equipment. This fixes the statue revival problem (inappropriate
feedback when monster puts on speed boots) mentioned in the earlier
"intrinsics of dead monsters" patch.
> I'm working on a Nethack port, and one of the header files a
> library uses has a structure with a member named "red". Since
> includes/decl.h #defines red to something, this totally loses.
>
> Attached is a patch which fixes the color defines.
This uses pmatch() as a default pattern matcher,
and #defines USER_SOUNDS_REGEX for Qt
to enable the code for regular expressions.
This is enabled for win32tty and win32gui.
Your quest leader would tell you to return later, even after you
were converted, which would be futile, and could mislead new
players.
This patch:
1. Causes the quest leader to banish you the first time you
encounter him/her following a conversion, since you cannot ever
complete the quest anyway in the current game.
2. Adds a new general QT_BANISHED message to be delivered, in
which you are told that you won't be able to get the Amulet without
the Bell now.
This helps resolve the complaint about not knowing that your game
cannot be won.
