Noticed recently when a user reported that an unseen monster zapping
an unseen wand caused wand of striking to become discovered. [That was
because the zap also hit a door and the code for the latter didn't check
whether the wand had been seen, and it got fixed a couple of weeks ago.]
When the player zaps wands while the hero is blinded, it was discovering
(for the cases where the effect can be observed without sight) the wand
even though the wand's description was unknown (showed in inventory as
"a wand"). This replaces the calls to makeknown() in zap.c with calls to
new learnwand(), which checks whether the wand description is known; you
no longer discover something you've never seen. Reverse effect has also
been added: if the type of wand has been discovered earlier, zapping an
unseen wand (another of the same type, picked up when blind and zapped
while still blind) will now mark it as seen (to show up in inventory as
"a wand of <whatever>" instead of just a "a wand"). The latter aspect
really ought to be independent of prior discovery, but we currently have
no way to record "we know what this particular item does even though we
don't know what type of item it is yet". [If we add that, it would be
applicable to potions (when operating on stacks) and rings too.]
Minor change: zapping yourself with wand of opening or spell of
knock will remove attached ball&chain rather than give a "chain quivers"
message. Explicitly zapping the chain already did that; if the unlocking
magic works on the chain connected to your leg then it really should also
work on your leg connected to the chain. Zapping unlocking at yourself
probably should also scan inventory to check for carrying locked chests,
but I didn't add that. (If added, then locking magic will need to be
augmented likewise.)
This also fixes <Someone>'s recent complaint: zapping an unknown
wand of teleportation at yourself didn't make it become discovered.
Now it will be, under the same circumstances as when you're riding: if
teleport control causes you to be prompted for destination, or if random
destination moves you more than jumping distance away from your original
position. (The Stunned exception to teleport control, which was missing
in zap_steed, perhaps ought to be moved into the macro definition of
Teleport_control itself so that all code always handles it consistently.)
From a bug report, the placement
of random doors by the code that loads special levels would attempt to
evaluate rn2(0) and either get a divide by zero crash (normal build) or an
impossible warning (DEBUG enabled when compiing rnd.c, done automatically
when BETA is defined). The problem was only noticable for random door in
a 1x1 room; none of our distributed levels specify such a thing so regular
users won't have encountered this bug. It's a one line fix.
Altar placement in temples also had a quirk of a similar nature. It
wouldn't trigger rn2(0) problems but would always place the altar to left
of mid-point in rooms with even width and above the center point in ones
with even height. Now the placement is randomized so that sometimes it'll
be to the right and/or below mid-point in such cases.
This also simplifies a couple other instances of similar expressions
that I spotted.
Cut down on the excessive verbosity generated when entering a temple.
The first time you enter a particular temple (or more accurately, the
temple attended by a particular priest), you still get the three message
sequence
The <priest of foo> intones:
Pilgrim, you enter a sacred place!
You have a strange forbidding feeling...
or
You experience a strange sense of peace.
except that the last one doesn't say "strange" any more. On subsequent
visits to the same temple, you usually won't get the first introductory
message any more, often won't get the second entry one, and sometimes
won't even get the final one, depending upon how much time has elapsed
since the previous entry. The old verbosity could really be infuriating
when attempting to lug corpses to the altar before they spoil. Even
though the messages don't affect the passage of time, it always felt as
if they were slowing you down. And even when you weren't in any hurry,
it required at least one and often 2 or even 3 responses to --More--
depending upon the length of the deity's name and whether some other
message was also delivered on the same turn (fairly common in minetown).
Saving and restoring, or leaving the level and returning, resets
the priest's memory of when the messages were last given, so the next
entry after that behaves similar to the very first. This was initially
intended for cleanup prior to saving bones data, but it seemed reasonable
to have it apply to the current game too. Unattended temples now also
have a 25% chance of not giving any message when entering. That one is
random rather than based on the passage of time since last entry; there's
no priest available to track the latter data.
I noticed this a while back while inspecting an unrelated report.
It seems to me the breath of a dragon is more like broiling than baking
and thought the message wasn't consistent with this.
This patch alters wiz_identify so that it displays an
inventory menu with all items shown identified
without actually identifying them.
You can just press ^I (or whatever the wiz_identify command
is) a second time, while the menu is displayed to actually identify
them (tested with TTY menus only).
Pat Rankin wrote:
> Won't the players who notice this immediately ask why they
> can't see the same information for fully ID'd tins during play?
It wasn't clear to me whether Pat wanted the info shown on
fully ID'd tins during play, or whether he didn't want the info
displayed at all.
This withdraws the end-of-game tin details until clarified.
Cleanup up a couple of priest and minion allocation/conversion bits.
Also, restrict minion naming so that "guardian <foo>" is only applied when
<foo> is an Angel. (That restores old behavior from before a change I made
last October; it prevents the guardian Angel from being recognized while
hallucinating. It probably affects slash'em too, where they have tame
minions besides the astral level's guardian Angel.)
Add an introductory comment for each type of extension. Also move
ANGRY/NOTANGRY shopkeeper macros from old eshk.h out of the common header
and into shk.c so that their use doesn't end up spreading into other code.
Not fixed: entry #9 in the block comment at the top is truncated
mid-sentence.
Reveal more tin details at end of game disclosure.
b - an uncursed carrot
c - an uncursed tin of broiled kobold meat
d - an uncursed tin of stir fried fox meat
e - 4 uncursed tripe rations
f - 4 uncursed food rations
g - an uncursed cream pie
n - 4 uncursed tins of spinach
o - 3 uncursed tins of pureed newt meat
p - an uncursed homemade tin of fox meat
Note that in the case of homemade and rotten
it sounded better to have the term before the
word tin, rather than after:
homemade tins of newt meat
rather than:
tins of homemade newt meat
The wishing code should probably be
changed to reflect this so people can wish for
a "homemade tin of newt". As it stands, they must
wish for a "tin of homemade newt" which differs
from the final display. That is not included.
Replace the fixes entry with one which mentions the magic word "panic".
That'll make it easier to find in the future when looking back for the
nasiest bugs (which I seem to end up doing periodically).
Add new_mname/free_mname functions to make monster name handling be
more like the other extended data and to hide mextra details a bit more.
Add some casts where int and unsigned are being intermixed. Simplify
christen_monst(); it ought to be changed to have type `void' but I wanted
to avoid modifying another ten or so files.
<Someone> noticed the leftover zeromextra, this removes it.
Using memset() on a possibly failed mextra allocation was inapprorpriate,
so replace the newmextra() macro with a function.
Prevent a crash in christen_monst() if mextra was not initialized.
Note: The CVS repository was tagged with NETHACK_PRE_MEXTRA
prior to application of this patch to allow easy withdrawal if necessary.
Adds a new mextra structure type that has a set
of pointers to various types of monster structures
including:
mname, egd, epri, eshk, emin, edog
Replaces the mextra bits in the monst structure
with a single pointer called mtmp->mextra of type
(struct mextra *).
The pointer can be null if there are no additional
structures attached. The mextra structure is not
adjacent to the monst structure.
Reduces the in-memory footprint of the monst that
has no other structures attached, at the cost
of adding 6 extra long ints per monster to
the save file
The new mextra structure has the mextra fields
independent of each other, not overlapping as was
the case with previous NetHack versions.
This patch doesn't do anything to capitalize on
that difference however.
Consolidates vault.h, epri.h, eshk.h, emin.h and edog.h
into mextra.h
Adds a macro for checking for whether a monster has
a name:
has_name(monst)
This fixes the magic trap panic
expels() -> spoteffects() -> dotrap() ->
domagictrap() -> tamedog()
because the monst no longer varies in size so no
replacement is required.
From a bug report: while hero
was blinded, monster zapped him with a not-yet-discovered wand of striking
and the wand type became discovered. The report was slightly off; the
described case is already handled correctly. However, if the zap happened
to hit a door, the wand would incorrectly be made known even when not seen.
From a bug report: dwarvish mattock was
subject to breaking when attempting to force a lock, because it is treated
as a bladed weapon. So is pick-axe; they're both defined as blunt (WHACK
attack mode), but the definition of is_blade() erroneously includes them
since P_PICK_AXE falls between P_DAGGER and P_SABER. That skill should be
renumbered, but I haven't investigated what else might happen when that's
done so this fix uses a special case instead.
I noticed that there was an unnecessary old check for rubber hose;
it's excluded along with whip by the skill > P_LANCE test. When fixing
that up, I realized that the obscure feature of forcing via statue was
broken; it always failed the skill < P_DAGGER test. Also, I took away the
exception for aklys; even though designed as a throwing weapon, it is used
as a club. I wasn't sure about the exception for flail; it is perfectly
capable of bashing things but the code apparently excludes it for use as
a prying implement. Switching its check to P_FLAIL catches grappling hook
along with it.
When looking at name_to_mon() to teach it how to cope with possessive
suffices, I discovered that it already knows how. But while looking at
it, I remembered a newsgroup complaint from a while back by someone who
accidentally committed suicide by attempting to genocide "master mindflayers"
(when he meant "master mind flayers"). name_to_mon() didn't recognize that
misspelling but it did match "master" as a role title. Unfortunately for
the player, his character was a monk; the game allowed him to genocide his
own role and he died. That's kind of harsh for such a likely misspelling.
(I don't think a monk is very likely to ever use "master thief" as a mistake
for "master of thieves", but catch that one too just in case. Conversely,
recognize "master of assassins" as an alternate for "master assassin".)
Also, wishing for "the <something>" strips off "the" and finds (or not)
<something>, but genociding didn't. You could specify "a wolf" to wipe out
all wolves, but "the wolf" yielded "such creatures don't exist", and ^G had
similar unfriendly behavior. This extends name_to_mon() to handle it.
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, "You have summoned it!" (when human
sacrifice brings a demon which you can't see) is poorly worded, to put it
mildly. I'm sure there are plenty of other places where "it" seems odd,
but this one is now fixed....
From a bug report, amorphous creatures can fit underneath
closed doors but could still be considered too big to fit through diagonal
gaps. Let them and several other shapeless or flexibly shaped critters
squeeze through provided that they pass the not-carrying-too-much check.
From a bug report: the Call command's
prompt is careful not to include "of <deity>" when asking what name to give
a high priest on the Astral level, but the resulting rejection message of
"the <unique monster> doesn't like to be called names" did not, resulting
in feedback of "the high priest of <deity>" and giving away which temple it
is from afar.
These should have been included with a "#dipping from steed" patch
three years ago. I don't know whether I missed them outright, neglected
to cut diffs at the time, or just forgot to apply the diffs to my cvs
directory prior to committing the rest of that patch.
From a bug report, "The leprechuan quickly snatches some
gold from between your feet!" doesn't make much sense when you're riding.
Fix started out simple, but "between" isn't right if you're above the floor,
and "rear hooves" for horse or "rear claws" for dragon didn't sound right
for steed (or poly'd hero), so it got a little more complex. Complicated
even more due to requiring two copies; ick.
A minor side-effect of this change is that somewhat naughty sounding
"The leprechaun quickly snatches some gold from between your rear regions!"
won't occur anymore. :-}
A bug report complained that Izchak is identifiable when the hero is
hallucinating. That's true but it wasn't particular to him; all shop
transactions were giving accurate shk name regardless of hallucination.
This is a quick fix that avoids changing shk message handling: pick some
shk name at random each time one is used. I didn't intend for it to also
force Izchak to use the general chat response instead of his set of special
messages, but that ends up happening due to randomized name not matching
his, so you really can't recognize him when hallucinating anymore.
The almost never seen names now have a chance to come into play....
Forwarded from the newsgroup by Michael: giving a count before '.' to
rest many turns wouldn't be interrupted by having levitation end (despite
autopickup taking place at the time, which is what the thread is about but
not all that relevant to this particular issue). Stopping counted activity
is easy, so that's all I've done. Stopping a timed occupation would be a
lot harder due to message sequencing; I'm not going to attempt it.
Remove several duplicate includes I discovered while reconciling the
vms Makefile. All of these are already being brought in via hack.h so don't
need to be explicitly included after it.
I couldn't find the original depend.awk (which started out on vms) and
didn't feel like attempting to recreate it, so did this the old fashioned
way (grep,&c of src/*.c). I think that all of the various Makefiles need
one or more of these changes. Adding context.h to the hack.h dependencies
and emin.h to monst.{o|obj} are the most significant ones.
The in_lava_effects flag should never be saved and restored; putting
it into the context struct was a mistake. Move it to the iflags struct
(where the branch code already has it). I haven't bumped the EDITLEVEL
setting. Save and bones files from more that a few days ago were breifly
invalid but should be viable again. Save and bones files from the past
couple of days are now no good; sorry about that.
Have killer_xname() handle corpses properly and also avoid having it
use user-supplied fruit names as per <Someone>'s suggestion. Also make
a start at eliminating the umpteen inconsitent checks for whether a monster
type (like "Oracle") ought to be prefixed by "the ".
I used a stub which looped over all object types, all artifacts, and
corpses of all monster types to print the output of killer_xname() for each
one; its prefix choice among {[no article], a, an, the} looked right.
While testing some killer_xname() changes, I noticed that it was
feasible to avoid having some gear destroyed by causing a hangup after
getting the destruction message. And while testing the fix for that, I
stumbled across a panic situation (not caused by my changes). If you
survive entering lava while wearing water walking boots (and aren't fire
resistant yourself, and don't have enough hit points to survive 6d6
damage, and your boots aren't fireproofed...), having those boots be
destroyed will dump you back into the same lava recursively (lava_effects
-> Boots_off -> spoteffects -> lava_effects). And if you survive that
(wizard/explore mode or life-saving), there will be a panic when finishing
deletion of the boots (useupall) because the recursive call will have
already done it (since they aren't worn anymore when inner call handles
them, no additional recursion gets triggered and object deletion happens).
Some of the other stuff I was working on is mixed in here because
this is the configuration I ended up using to test the panic fix.
Several Makefiles are missing the dependency for context.h (post-3.4.3
revision). If yours is, then you'll need to force a full rebuild after
applying this or you'll end up with havoc. (Mine was, but I noticed that
the expected full build wasn't happening and interrupted it to fix that.)
