Change the way wishing for bear traps in wizard mode is handled so
that spelling of "bear trap" vs "beartrap" doesn't affect the result.
Land mine doesn't have a similar spelling variation, so it already had to
be handled differently (if you wanted an armed trap, you needed to append
something--anything--such that it didn't match the object name). Now
they're consistent with each other. By default, you'll get an object
regardless of whether you include a space inside the name, and you'll
need to specify a prefix ("trapped") or a suffix ("trap"--actually,
anything other than "object") to get an armed trap placed on the ground.
"bear trap", "beartrap", "untrapped bear[ ]trap", "bear[ ]trap object"
will yield the disarmed object,
"trapped bear[ ]trap", "bear[ ]trap trap", "bear[ ]trap<anything else>"
will yield an armed trap.
"land mine" works the same way, treating the embedded space as optional
even though both object and trap include it.
Remove some clutter from the wish handling code, mostly by taking
advantage of the fact that the wizard flag is valid even for the !WIZARD
configuration. No change to game play.
When testing singularizing of fruit names I noticed that "bunches of
grapes" became "bunche of grapes". makesingular() had a comment about
not recognizing "es" and suggesting that recursion could solve it. But
makeplural() already handled things like that without resorting to
recursion, and it also recognized more compounds than just "foo of bar"
and "*man-at-arms" (such as "pie a la mode" and "soup du jour"). This
moves the compound phrase recognition into a separate routine so that
both makesingular() and makeplural() will handle the same stuff, and it
modifies makesingular() to do as well as makeplural() when processing the
front half of compound phrases (the "foo" part in "foo of bar").
Also, a minor plurization tweak: algae was recognized as already
plural but larvae and several similar words weren't.
I almost abandoned this when Michael beat me to it, but besides
handling the fruit rename bug it also moves `current_fruit' into the
context structure to eliminate separate save/restore for that.
The post-3.4.3 ring removal bug also applied to suit when wearing a
cloak and shirt when wearing a suit or cloak or both, although it would
never give "you have nothing else to take off" because the covering item
was always present as a likely candidate. The ring fix also fixed armor.
When testing that fix, I saw "you can't take that off" for trying to take
off a suit while wearing a cloak. That isn't new or a bug, but it seemed
awfully terse so I've changed it to give "you can't take that off without
taking off your cloak first". (Likewise, "cloak", "suit", or "cloak and
suit" as appropriate when trying to take off a shirt.)
This adds new routine `suit_simple_name()', comparable to 3.4.3's
cloak_simple_name() and post-3.4.3 helm_simple_name(). No doubt there
are other places besides "without taking off your X first" that could
make use of it but I haven't attempted to track them down. The "you are
already wearing _some armor_" one doesn't quite fit. It would need to
adjust "some" to "a"/"an" at times ("some mail" or "some dragon scales"
vs "a suit" or "a jacket").
ansimpleoname() and siblings always reported statue and figurine
type to be "of a giant ant" because the corpsenm field was left as 0.
Explicitly set it to -1 in the minimal object and teach xname() to leave
off the monster type in that situation, yielding just "a statue" or "a
figurine". [It's tempting to classify this as an xname() bug since other
object types which use corpsenm do so in doname().] No fixes entry; this
is post-3.4.3 code.
"The death ray hit it." Changes to vtense() during the makeplural
makesingular overhaul four weeks ago contained a typo, or rather a set of
matching thinkos.
Move some common code from makeplural & makeingular into a separate
routine. Also, add ``candelabrum <-> candelabra''. Wizard mode wishing
for "candelabra" now works; "Candelabra of Invocation" does not--not due
to case but because the " of " isn't preceded by 's' in the plural form.
Move some of the singular<->plural transformations from code to data.
Also fixes one more missed singularization: lurkers above. A big chunk
of this is just a bit of minor reorganization: moving otense() & vtense()
next to makeplural(), and moving the wishable subranges array from between
makeplural & makesingular to in front of the wishing code.
I was going to redo makeplural to use the same style as makesingular
(switch from ``len >= N && !strcmpi(buf, spot-(N-1))'', with spot pointing
at final character, over to ``BSTRCMPI(bp, p-N)'' which tests p-N against
bp as the bounds check and has p pointing to the string's terinating '\0')
but have decided not to tackle that.
Extend makeplural/makesingular case-insensitivity to vtense() and to
wizard mode wishing for dungeon features. And the previous set of fixes
missed one: makesingular("zombies") was producing "zomby". Plus a bit of
groundwork for a likely second overhaul of makeplural/makesingular.
I stumbled across a copy of an old newsgroup bug report which
complained that wishing for "Gauntlets of Power" didn't work. I thought
that this was something which had already been fixed, but when I tried it
out, I discovered that you still couldn't wish for that. It was failing
because case-sensitive makesinglar() didn't recognize that "Gauntlets"
needs special handling. After the unwanted transformation, the case-
insensitive object matching would fail to find "gauntlet of power".
Removing case-sensitivity for special cases like "boots" and "gloves"
would have fixed that, but this patch goes further and removes case-
sensitivity entirely for both makesingular and makeplural. Words which
get their endings modified work when the input is upper or mixed case.
Any modified letters retain the case of the original, so the reason for
case-sensitivity--user specified fruits that aren't lower case--is covered.
Some makeplural fixes: the plural for dingo is dingoes (dictionary
says "-es", not "-s") and for roshi is roshi (just guessing here; most of
the Japanese names use same spelling for singular and plural, but we were
producing roshis). Several words which makesingular leaves in plural form
(boots, gloves, &c) are now recognized by makeplural (avoiding gloveses).
It also fixes a bunch of incorrect singularizations of plural monster
names: foxes, *wolves, lynxes, fungi/humunculi/succubi, mumakil, wumpuses,
baluchitheria, Aleaxes, *elves, erinyes, djinn, priestesses, & valkyries.
Some non-monsters that makeplural handles correctly were also not being
singularized right: feet, hooves, lice/mice, algae, children, nemeses.
Noticed while testing a patch for touching cockatrice corpses;
corpse_xname(,, CXN_ARTICLE) would produce "a cockatrice corpses" when the
object stack quantity was greater than 1. (This applies to the post-3.4.3
expansion of corpse_xname() in the trunk code, so no fixes entry.)
killer_xname() was adversely affected by yesterday's change to
obj_is_pname() that required artifacts to be fully identified in order to
use just their name.
Many (most?) non-weapon artifacts show up in inventory and messages
as "the <foo> of <bar>" even when their underlying object type hasn't been
discovered yet. For types which don't use the `known' bit, obj->known is
forced to 1; obj_is_pname() checked that but not the oc_name_known flag
for the type. So you'd see things like "the Heart of Ahriman" instead of
"a luckstone named <the H of A>" or "a gray stone named <the H of A>" even
though it hadn't been identified yet, unintentionally hiding the artifact's
object type from the player.
When wishing for terrain, allow type "moat" as well as "pool". And
when wishing for a trap, verify that trap creation succeeded instead of
always reporting that the requested type was made.
simple_typename and obj_typename operate on item types rather than
particular objects so have to assume that the item involved has been seen.
That means that simple_typename(obj->otyp) is not suitable; if obj->dknown
hasn't been set, it gives away information. This adds mininal_xname(obj)
to be used for that purpose. I'm not aware of any straightforward way to
actually expose the original problem; it's more than hypothetical but not
something anyone's likely to have come across.
Not fixed: test driver program reveals that obj_typename(GOLD_PIECE)
and simple_typename(GOLD_PIECE) yield "coin of gold piece". But I don't
think there's any way to get nethack to show that to the user.
Some code I recently added was misusing count_unpaid() and would
traverse some or all of inventory instead of just container's contents
when looking for unpaid items. Add mew routine `is_unpaid(obj)' to do
what I was intending to do with count_unpaid().
Inventory display adds "(unpaid, N zorkmids)" to carried unpaid
items, but it didn't show anything comparable for indirect unpaid ones
(hero-owned containers holding shop-owned objects). Now it will include
"(contents, N zorkmids)" in such cases.
Change safe_qbuf() so that instead of picking one of three strings
for sprintf() to plug into a prompt string, it actually constructs the
full prompt string itself. Also pass in the unformatted object and a pair
of formatting functions instead of performing dual formatting in advance.
The actual formatting is done via new routine short_oname() which also
takes an object and a pair of formatting routines plus a target length.
It uses the first routine, typically xname() or doname(), and formats the
object, then if the result is too long it makes some transformations, and
tries again. If truncating "called foo" and "named bar" down to 12 chars
and omitting "uncursed, rustproof, thoroughly corroded" attributes still
result in a string that's too long, it uses the other formatting routine.
The latter calls one of several jacket routines around simple_typename()
to produce a short result.
This has been through about four incarnations now and has gotten a
bit less testing each time, but I need to get it in place before I end up
running out of gas and abandoning it. I've got some changes to shk.c
(where safe_qbuf is needed but not currently used) that now need to be
redone and will come eventually.
Fix the bug From a bug report.alt.org server, where killing a monster by closing the
castle drawbridge resulted in a panic after the dead monster's possessions
were dropped into the moat and a potion of acid exploded in the process.
water_damage() deleted the object but had no way to tell flooreffects()
that it was gone, so flooreffects() couldn't tell its own caller not to
place and stack the object. After that, a chunk of freed memory became
part of the floor objects chain and eventually triggered a panic which
tried to make a save file but whose reason didn't get logged properly.
There were routines that were passed the
object name as an argument. Before the oextra
patch, ONAME() always returned a valid pointer
to a location within the obj struct. The oextra
patch worked around those cases by
using a temporary variable that was either set
to ONAME (if the obj passed the has_oname() test),
or to "" (pointer to an empty string) if no name was
present.
Since that might be a common thing to do, provide
the safe_oname() routine that you can use as a
function parameter without having to worry about
about whether ONAME(obj) is valid, and without
the need for the temporary variable.
move oattached and oname and other things that vary
the size of the obj structure into a separate
non-adjacent oextra structure, similar to what has
already been done for mextra. The obj structure
itself becomes a fixed size.
New macros:
#define ONAME(o) ((o)->oextra->oname)
#define OMID(o) ((o)->oextra->omid)
#define OMONST(o) ((o)->oextra->omonst)
#define OLONG(o) ((o)->oextra->olong)
#define OMAILCMD(o) ((o)->oextra->omailcmd)
#define has_oname(o) ((o)->oextra && ONAME(o))
#define has_omid(o) ((o)->oextra && OMID(o))
#define has_omonst(o) ((o)->oextra && OMONST(o))
#define has_olong(o) ((o)->oextra && OLONG(o))
#define has_omailcmd(o) ((o)->oextra && OMAILCMD(o))
changed macros:
has_name(mon) becomes has_mname(mon) to correspond.
The CVS repository was tagged with
NETHACK_PRE_OEXTRA
before commiting these, and
tagged with
NETHACK_POST_OEXTRA
immediately after. The diff
between those two tags is this oextra patch.
The associated mail daemon changes to use an oextra
structure instead of a hidden command located in the
name after the terminating NUL, have not been tried
or tested.
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).
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.
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.
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.
The code let you wish for trapped containers in wizard mode and tried
not to let you do so in normal mode. But it handled the trapped attribute
by overloading the poisoned one, so wishing for a "poisoned chest" would
produce a trapped chest in any mode. This fixes that by removing the
overloading. You can wish for a trapped box/chest (or tin) in wizard mode
and you can now also explicitly wish for an untrapped one in any mode.
Asking for trapped in normal mode--most likely hoping to seed a dangerous
bones file--just negates any preceding "untrapped" handled earlier within
the same wish, and specifying "poisoned" for a container no longer has any
effect.
cknown and lknown flags for containers are now checked when deciding
whether an item is fully identified, and they're set when identification
takes place. (You'll learn how many items are inside even if you haven't
looked to see what they are yet. This means that an inventory listing of
unpaid items will reveal the contents after you've used enouch magic to ID
an unpaid container.) Also, set those flags for any container in initial
inventory; rogues should know that sack starts out empty.
Suggested by Janet, after inhaling paint fumes. Unlike mother-in-law,
which is an entry in the hallucinating monsters list and would be pluralized
if chosen as a tin description, I think the rank title man-at-arms will only
ever go through plural/singular handling if used as a fruit name. But since
the man/men part was already implemented for pluralization, adding the -at-
part is trivial. Also adds men/man singularization for the general case
where -at- isn't involved.
From a bug report, (is that name just
a coincidence, or is it our Matt?), "this tin smells like mother-in-laws"
should be "this tin smells like mothers-in-law". That led to a small can
of worms when I tried experimenting with mother-in-law as the named fruit.
Naming your fruit "pomegranates" would result in "pomegranateses" if you had
more than one. These changes are mostly just band-aids for that; I think
the proper solution is to singularize the user's value when fruit name is
being assigned. Force it into lower case at the same time, then some other
special casing could be eliminated. There's no particular reason to keep
"grapes" and "grape" as separate entries, nor "matzot" and "MATZOT" either.
One of the non foo-in-bar changes prevents "grapefruit" from getting
a false match against named fruit "grape". (Are there any legitimate cases
where trailing text should be ignored? I couldn't think of any.) Another
results in a wish for "kumquats"--when fruit name "kumquat" exists--yielding
two instead of a random amount, the way that specifying plural works with
other sorts of objects. And if you're strange enough to name your fruit
"kumquats" in the first place, asking for "kumquat" will produce exacly one.
This patch applies cleanly to 3.4.4 but I don't think it's been tested
adequately enough to be included there.
When a wish request for "<foo> armor" fails to match anything, check
whether it matches "<foo> mail" before resorting to selecting a random piece
of armor. Most of the suits are named "mail", and while I don't think many
people will ask for "ring armor", I do think that "crystal plate armor" and
"gray dragon scale armor" are sometimes tried.
This also greatly simplifies the handling for spelling variant "armour"
by rewriting it to "armor". Unfortunately "grey" vs "gray" can't be handled
the same way since both spellings are used by the program.
[Attention: This patch increments EDITLEVEL in patchlevel.h, rendering all
previous save and bones files obsolete.]
Here's the first cut at the two recommended flags lknown and cknown.
I've attempted to stay close to Pat's recommendations:
"Containers ought to have two new flags: lknown for lock status known,
and cknown for contents known (ie, `secret'). Formatted box and chest
descriptions should include locked/unlocked/broken when that is known
and empty/nonempty (or something like "holds N items") when contents
are known. The contents indicator would also apply to nonlockable
containers."
I probably overlooked a place where a flag should be adjusted, but this
should give us a good starting point.
I wasn't sure what to do with the case of the auditory feedback for
magical locking "Click" and "Clunk". The question that came to my mind
was: Should those reveal the locked or unlocked status of a box?
I suppose if you knew the type of wand you were zapping or the spell
you were casting, you could argue that they should.
In the end, I opted for setting lknown right off the zap/cast effect
for anyone playing a Wizard role, and not setting it for anyone else,
thus advancing class differentiation a little bit too.
I haven't checked the cknown results under all flags.menu_style options
at this point, only MENU_FULL.
Fix the wizard mode crash From a bug report. Move the WIZKIT
message suppression to a lower level instead of trying to guard against
present and future pline() calls in the wishing code. The way that was
being handling wasn't suitable for dealing with quest feedback.
This also includes a couple of additional wishing synonyms.
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.)
User reported the following incorrect feedback:
You drop Medusa's corpse. corpse falls down the stairs.
and apparently thought that the problem was a glitch in the middle of the
sentence; the actual problem is that the second sentence lacks its start.
This fix isn't perfect. You'll now get
Medusa's corpse falls down the stairs.
for the second sentence, but
The Oracle corpse falls down the stairs.
when dealing with a unique monster who doesn't have a personal name.
Either form seems acceptable to me, but mixing them appears inconsistent.
Probably all the uses of corpse_xname() (and its callers back up the
chain cxname(), aobjnam(), yobjnam()) need to be reviewed for usage. I
don't have the energy for that.
Give more information about your attributes in debug mode
via Control-X.
I'd like to see some way of getting bits of this info to the
player during the game (from the Oracle or something),
but this patch keeps it limited to debug mode.
Report was for scattering gold during a land mine explosion, but the
message was delivered by the widely used hit(). Bug was caused by a typo
in vtense() when handling a subject containing a space.
- store the variety of tin at tin creation time
rather than at tin-opening time (as a negative
value in spe just as homemade was; spinach
is still spe 1)
Allow wishing for a particular variety of tin
from the tin variety list:
"deep fried", "boiled","broiled","candied"
"dried", "french fried", "homemade"
"pickled", "pureed", "rotten", "sauteed"
"smoked", "soup made from", "stir fried",
"szechuan"
Example: "tin of soup made from orc"
non-debug player could randomly fail on the
variety specification 1 in 4 times
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
