From a bug report: if swallowed and blind
and in quantum mechanic form, hitting the engulfer would yield "the <mon>
disappears" even though you were still swallowed by <mon>. The pre-teleport
criteria for whether you knew the target was there were different from the
post-teleport ones. Make them match; swallower will remain sensed by touch
and won't be described as disappearing.
Eliminate the somewhat redundant "You die..." following "You turned
to stone..." when becoming petrified by touching a cockatrice (reported
by <email deleted> for kicking, but occurs for weaponless hitting too).
Also, if a cockatrice killed you with normal damage, your tombstone would
erroneously report petrification and presumeably there'd be a statue
instead of a ghost in the resulting bones file. This fixes both things.
More explicit control over the behavior of spoteffects() is probably
the way to go in the long run, but this much simpler fix handles the case
at hand. I'm not sure what `thrownobj' was intended to be used for in the
first place, but it came in handy here. (It was being left as a dangling
pointer when thitmonst() reports that the missile has been used up; that's
fixed now.)
Fix the reported problem of lookhere/autopickup not seeing the missile
which just killed the engulfing monster whose death caused the hero to be
put back onto the map and so look/pickup upon arrival. Normally the missile
gets placed after damage has been dealt and the throw has finished. This
overrides that so that the missile is put into the engulfer's inventory as
it is being killed (which will then put that inventory onto the floor prior
to expelling the hero on top of same). If the monster happens to get
life-saved it just ends up collecting the thrown-from-inside object a little
sooner than usual.
This wouldn't correctly handle the same case for a kicked object, if
that were possible. But it isn't possible to kick objects while engulfed,
so that's moot. Other calls to thitmonst() and hmon() don't appear to have
any objects in transit so shouldn't need any comparable fix (I hope...).
From a bug report, attempting to attack
a hidden monster who is revealed by ongoing monster detection (blessed
potion or skilled spell) gave "wait! there's a <monster> hiding there"
response and prevented the attack. Make it behave the same as when the
hidden monster is revealed by telepathy; the monster comes out of hiding
and the hero's attack proceeds.
Something I encountered while playing slash'em a while back, but
relevant to nethack: "Its orcish spears shatter from the force of your
blow!". I was using a two-handed weapon (at skilled or expert level) to
fight an invisible monster which was wielding a stack of multiple spears
(slash'em gives them out in groups of 3 for monsters' starting inventory).
After killing it, I found 2 orcish spears along with an invisible corpse
of somebody-or-other the Kobold King. The message suggested that the
whole spear stack had been destroyed (and the weapon shattering code in
hmon_hitmon() clearly expects that to be the case), but only one of them
had actually gotten used up.
I can't recall whether "shatter" was actually given as singular or
plural at the time; nethack handles that aspect correctly. Only object
destruction needed tweaking.
Extend the capabilities of corpse_xname() so that various callers can
be simplified. It can how handle an article prefix, effectively turning it
into corpse_doname() (not quite; still need doname() to see a count when
quantity is more than one, or to see bless/curse state). It can also handle
inclusion of adjectives like "partly eaten" or "bite-covered". For unique
monsters those come out in the form
the Chromatic Dragon's partly eaten corpse
instead of the old
partly eaten Chromatic Dragon corpse
[so wishing probably needs to be taught about potentially finding a monster
name before assorted adjectives such as blessed; also, name_to_mon() needs
to learn how to cope with the possessive suffix].
A sizeable chunk of this patch deals with consolidating some of the
redundant "petrified by a cockatrice corpse" handling. It may be possible
to consolidate all remaining instances together since they're quite similar,
but I didn't think about that until just now and I want to get this patch
over with.
From a bug report: sleeping pet could
be shown as "eating" by stethoscope. Fixing that is a one-liner since all
(or should be all; sleeping gas trap wasn't utilizing it) cases of monster
being forced into sleep go through one routine. That wasn't the situation
for paralysis, but now it is. Paralyzed pets won't continue eating either.
From a bug report, eating Medusa's corpse is fatal
but devouring her whole (purple worm or poly'd hero) was not. Now it will
be. Also, being killed by swallowing a cockatrice or a Rider could have
disclosed "you went without food" if you hadn't eaten anything else prior.
This fixes that too, although it might be a little silly if it happens to
a monk since he'll feel guilty (for non-vegetarian diet) right as he dies.
From a bug report, stealing a cockatrice corpse
from a monster while polymorphed into a nymph and not wearing any gloves,
the cause of death ended up being "petrified by cockatrice corpse". It would
also have said the same thing if a stack of multiple corpses was involved.
This fixes both cases, and also hypothetical unique monsters with petrifying
touch. (Last bit tested by temporarily adding Medusa to touch_petrifies().)
Fix a couple of problems From a bug report. Eating a Rider corpse is fatal, but eating a live Rider's
brain was not--now it will be, both for monster mind flayers and for player
poly'd into one. Also, there was no check for cannibalism when poly'd hero
eats brains--now there is. Not mentioned in the report: eating Medusa's
brains will now be fatal just like eating her corpse. And pet mind flayers
who eat the hero's brains will gain some nutrition like they do when eating
monster brains.
Creating a common eat_brains() routine turned out to be something of
a mistake; there is only a tiny amount of overlap among the u-vs-m, m-vs-u,
and m-vs-m cases.
Makefiles need a dependency update to add edog.h for eat.c.
Make petrification initiation or termination go through a new routine,
make_stoned(), instead of manipulating its countdown timer and delayed
killer directly. No change in behavior.
There's no reason in terms of bug risk or game play or saved data why
this shouldn't be done in the branch too, but so much of the surrounding
context has already diverged between trunk and branch that it's trunk only.
While auditing nomul() I noticed unconscious() treats (multi < 0 && !nomovemsg)
as unconscious. This explains the behavior in M29 (unconscious message
while performing #turn). I checked all the places with this combination,
and found a few that did not appear to fall under the "unconscious" category.
Most I changed to use You_can_move_again to ensure the same display w/o the
unconscious behavior. Also:
- found another string that unconscious() should have considered
- vomit() now sets nomovemsg, one caller was also doing this redundantly
- vomiting_dialogue() was calling stop_occupation() after vomit(), which can
reset multi. I reversed the order and removed a doubly-redundant nomul call.
tele() still has a problem: some cases where multi < 0 should probably take
a branch like the unconscious() branch but with a different message.
doturn()'s behavior - turn then wait - is also less than perfect, but I
think this is a known problem.
Finally apply the patch sent by <Someone> in 11/2003 for slashem-Bugs-799278,
updated to match the current code and handle additional cases. The fix
is brute force: always ensure nomovemsg is set when nomul is called with
a negative value. I also scanned the code for places manually setting
multi negative, they all set nomovemsg. It would be nice to have a function
that did the right thing, but there are several special cases and I was
not feeling creative.
Something from <Someone>'s list: some messages have hardcoded references
to "helmet" which sound strange when the character is wearing a hat or cap.
helm_simple_name() is comparable to the existing cloak_simple_name(). It
returns "helm" or "hat" depending upon whether the helmet provides the
same protection that yields the assorted repetitions of "fortunately,
you are wearing a hard helmet". This choice ends up categorizing elven
leather helm as a hat (which I think is ok given that its undiscovered
description is "leather hat"), contrary to <Someone>'s suggestion that the
distinction be made based on whether the helmet was made of cloth.
I started on this a year and a half ago but didn't commit it.
Unfortunately I don't remember why and haven't done any significant
additional work now--just recovered from some intervening bit rot and
confirmed that the patch as is seems to be working ok (in the trunk; the
branch side has not been tested). I suspect that I meant to look for
additional helmet messages which could benefit from conditional headgear
description. (Those "hard helmet" ones don't need it, although they
should perhaps be moved into a common routine instead of being replicated.)
- 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
>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.
There was code higher up that could destroy the obj,
so this eliminates any risk of trying to dereference a
bad pointer in the deferred silver message by saving
a copy of the name earlier on.
From the newsgroup:
> <email deleted> (<Someone>)
> Newsgroups: rec.games.roguelike.nethack
> Subject: Question: Why don't silver wands give silver damage?
> Date: 9 Nov 2003 09:18:50 -0800
> Organization: http://groups.google.com
> Lines: 7
> <email deleted>
>
> I had a character cornered by a werejackal the other day. I'm not too
> bothered by the death but why didn't the silver wand he desperately
> wielded in his final moments do extra damage? I mean, silver rings do
> so why not wands? I realise this is a pretty minor problem since not
> that many people will be going around wielding wands, but still.
>
> ~<Someone>
There was a code path for objects such as wands that avoided
all the silver checks. Now fixed.
<Someone> wrote:
> You start bashing monsters with your 2 cockatrice corpses.
> You hit the foo with the cockatrice corpse (note singular).
> The foo is slowing down. The foo turns to stone.
> Also: Your cockatrice corpses rots away.
It appears that vtense() has a problem recognizing "corpses"
as plural. This doesn't fix that, it just switches to using
otense() in this particular case.
<email deleted> wrote:
- When polymorphed into a quantum mechanic, it is possible to jump in
the water on a no teleport level and instinctively teleport.
- When an engulfing monster is teleported away on a no teleport level
when the hero is polymorphed into a quantum mechanic, there is no
message displayed like "You are no longer engulfed!" because
u_teleport_mon is passed FALSE for give feedback. But maybe this is
for a good reason...
Cutting a shopkeeper poly'd as a long worm would generate strange messages
and could result in a crash. cutworm didn't deal with all the intricacies
of duplicating a monster. Fixed by changing cutworm() to use clone_mon()
to do most of its dirty work. It seems to me that without this change,
cutting a tame long worm could also have similar bad effects.
Other side effects of this change:
- clone_mon now takes x,y coordinates, 0,0 results in previous behavior
- clone_mon no longer always makes cloned monsters tame/peaceful if player
caused the clone, using the same formula previously in cutworm. Someone
else may wish to tweak this for gremlins.
- clone_mon will christen the new mon with the old shopkeeper's name, even
though clones are never shopkeepers (game can't handle 2 for a shop)
- cutworm can now be called during conflict or pet combat, although I
added no such calls (yet)
It is not physical damage if:
1. it already qualifies for some other special type of damage
for which a special resistance already exists in the game
including: cold, fire, shock, and acid. Note that fire is
extended to include all forms of burning, even boiling water
since that is already dealt with by fire resistance, and in
most or all cases is caused by fire.
2. it doesn't leave a mark. Marks include destruction of, or
damage to, an internal organ (including the brain),
lacerations, bruises, crushed body parts, bleeding.
Current exceptions to the rule (already existing):
- holy water burning chaotic ("it burns like acid") is physical damage.
- unholy water burning lawful is physical damage.
- [fixed in trunk] Jumping/Newton's-Thirding into something solid
- [fixed in trunk] Being hit by Mjollnir on the return
- [fixed in trunk] Contaminated or boiling water from a sink
- [fixed in trunk] Falling on a sink while levitating
- [fixed in trunk, fire only] Any passive attack
- [fixed in trunk] Zapping yourself with a wand, horn or spell
- [fixed in trunk] Burning (un)holy water
- [fixed in trunk] Thrown potion (bottle)
- [fixed in trunk] Bumping head on ceiling by cursed levitation
- [fixed in trunk] Exploding rings and wands (under all circumstances)
- [fixed in trunk] Stinking cloud damage
- [fixed in trunk] Sitting in a spiked pit, in lava
- [fixed in trunk] Exploding spellbooks
- [fixed in trunk] Falling off or failing to mount a steed
- [fixed in trunk] Falling into a (spiked) pit
- [fixed in trunk] Land mine explosion
- [fixed in trunk] Fire traps
Introduce a new set of functions to manage delayed killers in the trunk, used
in addressing the various reports of delayed killer confusion. Since existing
delayed killers are related to player properties, the delayed killers are
keyed by uprop indexes. I did this to avoid adding yet another set of
similar identifiers.
- the new delayed_killer() is used for stoning, sliming, sickness, and
delayed self-genocide while polymorphed. Some other timed events don't
use it (and didn't use the old delayed_killer variable) because they
use a fixed message when the timeout occurs.
- A new data structure, struct kinfo, is used to track both delayed and
immediate killers. This encapsulates all the info involved with
identifying a killer. The structure contains a buffer, which subsumes the
old killer_buf and several other buffers that didn't/couldn't use killer_buf.
- the killer list is saved and restored as part of the game state.
- the special case of usick_cause was removed and a delayed killer list
entry is now used in its place
- common code dealing with (un)sliming is moved to a new make_slimed function
- attempted to update all make dependencies for new end.c -> lev.h
dependency, sorry if I messed any up
+ Separate the two uses of flags.soundok.
+ Player-settable option is now called "acoustics".
+ Deafness is now handled as a full-fledged attribute.
+ Check for deafness in You_hear(), rather than caller.
+ Check for deafness in caller, rather than verbalize(),
because gods can speak to characters in spite of deafness.
+ Since changes are being made to prop.h, reorder it to the
same order as youprop.h and enlightenment.
There are still some extraneous checks and missing checks
for deafness, which will be followed up in a future patch.
Because of the size of this patch and its savefile incompatibilities,
it is only being applied to the trunk code. Portions of this patch
were written by Michael Allison.
<Someone> pointed out the inappropriate appearance of the 3.4.2 message when
fog clouds have you engulfed if you happen to be polymorphed into an aquatic
creature. It does seem that a fog cloud should not cause added damage to
amphibious creatures, which includes breathless (but non-flaming) monsters.
I also thought another message was more appropriate for flaming creatures
(see on_fire()), and added a special case for that.
gulpum was missing symmetric code and I added it there too.
This change adds a new flaming() macro and uses it in several places
where the list of flaming monsters was tested. on_fire() didn't list
salamanders as already being on fire, but should have. A couple other
cases were not updated to include flaming sphere.
Pat Rankin wrote:
> collect them all into some new struct and
> save that separately rather than jamming more non-option stuff
> into struct flags.
This patch:
- collects all context/tracking related fields from flags
into a new structure called "context."
It also adds the following to the new structure:
- stethoscope turn support
- victual support
- tin support
This patch introduces a change to yname() and Yname2() that avoids the
possessive "your" for the hero's normal, fully identified artifacts.
Quest artifacts still get the possessive, as do all other objects and all
objects not in the hero's possession. shk_your()/Shk_Your() are used in
many places with a specific, generalized name for the object, so I didn't
introduce the artifact behavior there, although I did change them to append
a space, which simplified some other code. Through added use of yname(),
there may be some places that used to just say "corpse" that will now be more
descriptive via yname()'s use of cxname(). I'm sure <Someone> will point
out any such places that are too onerous, although nothing obviously is.
I took the opportunity to inspect many uses of "your" and even Your(). Two
new functions are also introduced, yobjnam() and Yobjnam2(), which work
like aobjnam() and yname() combined, because I found that many uses of
aobjnam() were preceeded by "your" and I couldn't generally provide the
desired behavior for artifacts (or future artifacts) without a combined
function. In some cases, this change allowed better sharing of code.
rust_dmg() still takes a string as input which is sometimes initialized
from xname() and often prepends "your" to it. Currently, this isn't a
problem since there currently are no normal, armor artifacts. If/when any
are introduced, rust_dmg() will need to be addressed.
The patch is for the trunk only. A lot of research was required and I
didn't feel the upside was there for repeating it in the 3.4.3 branch.
Because hmon_hitmon caches the monster data type, it needs to update this
whenever the monster might polymorph. It already did this for potions, but
not for jousting. There are other more complex ways this could be addressed.
When polymorphed, only attacks involving hands/feet/weapons should result
in damage to object. Theoretically, hug and butt attacks should affect
objects too, but no forms with such attacks currently allow wearing armor.
1) make two-weapon combat perform two attacks instead of always either
hitting twice or missing twice;
2) address <Someone>'s report of weapon skill to-hit adjustment being ignored
for bare-handed and martial arts attacks;
3) address newsgroup complaints about the intrusive "your armor is rather
cumbersome" message given every time a monk wearing a suit attacks;
this implements the suggestion that it only occur for those times where
you miss because of the penalty involved, suppressing it when you miss
due to other reasons and when you successfully hit;
4) bonus fix: a side-effect of #3 is that the order of the messages "your
armor is cumbersome" and Stormbringer's "bloodthirsty blade attacks" is
inverted, making a sensible sequence instead of implying precognition.
'+' is not a valid argument to resist(), although it still works
since the default case catches it. Make the spell class explicit,
although I don't think having the effectiveness of scrolls of confuse
monster depend on the character's level makes much sense.
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)''?
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.
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.)
