Noticed while investigating the broken chest whose lock was already
broken: wishing for locked, unlocked, or broken chest (or large box)
was treated as asking for something unknown. Add support for those
three prefixes, although they only have meaning for chest and box.
If more that one is specified in the same wish, whichever one comes
last overrides the others.
Also, "empty" was already an accepted prefix (for tins); honor it for
containers too.
Lastly, wishing for "box" failed. Give a large box instead. I went
back and forth about whether to do the same for "small box" and ended
up not including it, but turns out that small/medium/large prefix for
globs ends up making "small box" and "medium box" match "box" which
has now become a synonym for "large box". I'm not sure whether that
is a bonus or a bug; small box is clearly not the same thing as large
box, but getting the only available box when asking for any box seems
better than claiming not to understand the request.
> When you try to #force a large box or chest whose lock is already broken from a
> previous #force, the game tells you "There is a broken large box here, but its
> lock is already broken." It's minor, but this implies that the box being broken
> is separate from the lock being broken (as well as that the box itself *can* be
> broken).
change the wording to "lock-damaged box" and suppress
", but its lock is aleady broken" when "lock-damaged box" has
already been displayed.
(Nobody particularly likes the wording "lock-damaged box" either, but at least
it seems less misleading)
Handle more *man and *men cases.
Some plural usage of completely made up fruit names that should
be entered in singular form but have what appears to be a
valid plural name it will end up singularized. Not much
we can do about that for ficticious words.
For instance, if you try to name your fruit bigmen or snakemen
and you intended that to be the singular name, NetHack will likely
singularize it to bigman or snakeman.
Many real dictionary words that end in "men", however, should
be handled a wee bit better now. A real word such as stamen,
for example.
"boxen" may be hacker slang for plural of "box", but "foxen" is
definitely not the plural of "fox". Restrict the "ox"->"oxen"
entry to full word "ox", not "*ox" suffix.
Reported nearly four years ago for 3.4.3, original subject was
\#H3013: NetHack grammar bug when taking unpaid fruit from chest
Player used OPTIONS=fruit:Quorn and the capitalized value confuses
the() into thinking it's a proper name which shouldn't be preceded
by an article, resulting in "Quorn will cost you N zorkmids" when
removing it from a chest in a shop, followed by "X - a Quorn (unpaid)"
as it went into inventory. It is a product name, but when used as a
fruit it shouldn't be treated as a proper name. (Quorn is a meat
substitute rather than anything related to fruit.) Teach the() about
named-fruits, so that we'll get "The Quorn will cost you N zorkmids."
Unfortunately, it means that someone who names their fruit after a
proper name used by the program, for example Mjollnir, can probably
induce other poorly worded messages (about the item rather than the
named-fruit). the() is used all over the place and all it has to work
with is text, not the object whose formatted name produced that text.
I looked through a bunch of old cvs log messages last night, and
spotted one I wrote (in objnam.c) a dozen years ago where I suggested
forcing named-fruit values into lower case as they're being set up.
I don't remember that, but if we'd done it, this bug would have been
avoided.
The object name formatting routines operate using a pool of buffers to
hold intermediate and/or final result. Some routines consume multiple
intermediate buffers, so use releaseobj() to try to reuse just one in
order to avoid churning through too many and maybe clobbering live
data. It worked as intended for routines that use nextobuf() directly
but wouldn't haved worked right for xname(), also doname() and other
xname() callers. This fixes that.
There have never been any reports of garbled messages which could be
traced to clobbering of formatted object names, so this fix is mostly
academic.
Add some new routines for dealing with fruit. I had hoped they would
let the existing fruit handling be simplified quite a bit, but the
improvement wasn't great. However, they're also groundwork for fixing
an old bug.
A couple of days ago when verifying the report about being forced to
pay for a second tin when eating one from a stack on a shop's floor,
wishing for 'tins' (rather than 'tins of foo meat') was repeatedly
producing tin wands instead. The name "tin" and the wand description
"tin" in objects[] were being given 50:50 chance for either one by
the 3.6.1 wishing code. Wishing for "tins of spinach" also gave me
a tin wand on the first attempt. Handle 'tin(s)' more explicitly.
This also does some reformatting.
It's apparently somehow possible to have a leash "attached" to
a monster not present on the current level. Complain instead of
segfaulting. (This is a post-3.6.0 bug)
This segfault happened when a detected monster such as a garter snake was
hiding under an unknown/unseen armor of a type that has no description
field (eg. a leather armor), and you farlooked at the monster.
At the same time, simplifies the code a tiny bit.
farlook was changed (end of December) to use doname instead of xname
to yield more info for items which had already been seen up close,
but it gave away info about ones which hadn't. So doname was changed
(end of April) to use "some" instead of precise quantity (when the
quantity is greater than 1) for the latter, but that doesn't work
well with corpse_xname() when the hero is blind, yielding "a some
<foo> corpses". While testing the first fix attempt, I noticed that
pickup gave "you can only lift some of the some <foo> corpses".
This fix is far from perfect. farlook can still say "some <item>s"
but lookhere and pickup always say "N <item>s". Picking up a stack
while blind will show "N <item>s" in inventory display, but dropping
it while still blind will revert to "some <item>s" for farlook.
"The the Wizard of Yendor corpse tastes terrible."
"The" was supplied when formatting the sentence, "the" when formatting
the corpse object. Same applied to several other monsters, those
flagged as unique and without personal name (Oracle, Cyclops, others).
This also changes the corpse eating message to not always specify the
taste as "terrible" when the eater is omnivorous.
It also makes corpses (and tins) of unique monsters be wishable in
wizard mode. I had killed the Wizard at least half a dozen times
without a corpse being left, so used wishing instead. Later retries
did finally leave one--lack of corpse turned out to just be by chance.
"Your pair of speed boots glow silver for a moment." should be
"Your pair of speed boots glows silver for a moment.". The fix
reverses a post-3.6.0 change to is_plural(). Also, add new
pair_of() to test for object formatted as "pair of Bars". For verb
usage, that's definitely singular, but for pronoun usage, sometimes
plural seems better (although it might actually be incorrect).
I fixed up the formatting of a block comment in obj.h, but it is
still a candidate for tab cleanup.
Make wishing for an artifact and not getting it because it already
exists break never-wished-for-artifact conduct. The wish was made
even if the result wasn't what the player wanted.
rnd_otyp_by_namedesc() had an off by one error when choosing which
matching item to return, making it impossible to successfully wish
for the Amulet of Yendor, always yielding the plastic imitation.
n == 2, maxprob == 2
prob = rn2(maxprob); => 0 or 1
i = 0; while (i < n - 1 && (prob -= ... + 1) > 0) i++;
always exited the loop on the first test of the condition because
subtracting 1 from 0 or 1 never yielded a result greater than 0.
It's still suboptimal: "amulet of yendor" should find an exact match
and should never return "cheap plastic imitation of amulet of yendor"
from the partial match.
I think biasing the choice among multiple candidates based on their
generation probabilities only makes sense when all the candidates are
within the same class. If scroll of light occurred in 5% of scrolls
and spellbook of light occurred in 10% of spellbooks (both percentages
pulled out of thin air), having "light" get a 2 out 3 chance to be a
spellbook doesn't seem right because scrolls are four times more
likely than spellbooks (in most of the dungeon; books aren't randomly
generated at all on the rogue level or in Gehennom).
Globs of pudding maintain an item quantity of 1 but vary in size
based on weight. xname() formats with prefix of "small", <nothing>,
"large", and "very large" depending upon weight but wish processing
didn't recognize the prefix strings and reported "nothing fitting
that description exists". Make wishing handle "small" (which is
actually the default), "medium" (since <nothing> isn't the default),
"large", and "very large". They get ignored if the item isn't a
"glob of {gray ooze, brown pudding, black pudding, or green slime}".
Also, clean up recently added rnd_otyp_by_namedesc().
At the end of December, farlook was changed to use doname() instead
of xname() in order to give more information when looking at stuff
the player had already seen. But it ended up giving away precise
stack size for mergable objects too, even if they hadn't been seen
up close. Changing doname() to be vague when dknown wasn't set
only worked for items in particular classes; dknown is pre-set for
a lot of things. So this changes mksobj()'s dknown handling to not
do that for stackable items.
The change to objclass.h is just comment formatting (for the first
part of the file only), provoked by the second line of the one for
oc_pre_discovered.
There have been two or three reports on getting feedback about
amulets rusting. Object formatting doesn't display erosion for
them, so being told about damage then not seeing that damage
feels like a bug. Even if damage was displayed, it has no effect
on them so would still feel somewhat strange. It does display
erosion for wands and rings, which is strange too.
This limits erosion damage--and its feedback--to items which are
actually impacted by erosion: armor, weapons and weapon-tools;
also heavy iron balls and iron chains since they've traditionally
shown rust even though it has little effect.
A side-effect of this change is that flammable items (other than
armor and weapons) which don't burn up immediately will no longer
become burnt, then very burnt, thorougly burnt, and finally be
destroyed. Since the player couldn't see or possibly repair the
erosion state, it seemed incomplete. It could be reinstated by
making other flammable items be subject to erosion and displayed
as such by xname() & co.
Wishing now avoids applying erosion and erosion-proofing to items
that aren't affected by it, regardless of material. It also now
allows wishing for "rusty rustproof <iron-object>" which used to
suppress "rusty" in that combination and triggered a couple of
old bug reports.
Heavy iron balls and iron chains can have rust repaired and can
be made rustproof by wielding, then reading enchant weapon while
confused, as if they were weapons.
Sometimes you can see a hidden monster without bringing it out of
hiding (wand of probing, blessed potion of monster detection) but
look_at wasn't mentioning the fact that the monster was hidden and
probing described mimics accurately but lumped all hiders together
as "concealed". Describe all hidden monsters more consistently.
'Poisoned by a rotted gray ooze corpse' should have been
'Poisoned by a rotted glob of gray ooze'.
eatcorpse() is called for non-corpse globs and then corpse_xname()
is called for them too to set up death reason for make_sick(), but
it didn't know anything about globs. Now it does. Blob size is
ignored since it's not relevant for cause of death.
Change "unlockable" to "broken" so that it won't be misunderstood to
mean "capable of being unlocked". The accompanying suggestion to omit
"broken" unless/until a lock or unlock attempt is made is no good since
the main reason for describing the broken lock is to avoid unnecessary
attempts to lock or unlock a container that the hero knows to be broken
but the player may have forgotten.
I also changed remote look-at for objects to use distant_name(doname)
instead of distant_name(xname) so that qualifiers like "empty" and
"broken" will show up on chests you've investigated before but aren't
standing on now. Monster type for corpse also gets shown, instead of
just 'food (corpse)'. Other remote items will become more verbose,
but only those that the hero has already seen up close.
Avoid "spellbook of novel" after novel becomes discovered. Now it will
just be "novel". Prior to discovery, it might be on the list as "book
called whatever" if the player assigns a type name.
Also, make novel become discovered after reading one instead of only via
object identification. It already shows up as "novel" in inventory, but
changing its definition to designate it as not-interesting-to-discover
feels disrespectful to the tribute.
Make a fix suggested during beta testing: you can read scrolls while
blind if you know the label, and you can write a scroll with a magic
marker while blind, but the result was flagged as description unknown
so you couldn't read the newly written scroll until regaining sight
or obtaining object identification. So change writing a previously
discovered scroll while blind to set dknown since a successful write
always yields the type of scroll requested. Getting lucky while
attempting to write an undiscovered scroll--which has to be done by
scroll's type name (for instance "food detection") rather than by its
label ("YUM YUM")--still leaves the description flagged as unknown
since hero hasn't seen the what sort of label the new scroll has.
Along the way I got side-tracked by the possibilty of writing a scroll
of mail. It's allowed and yielded the same result as finding such a
scroll in bones, or wishing for one: when read, it was junk mail from
Larn. Make one written via marker give different feedback since it
comes from creation of a stamped scroll without any stamps available.
Also, suppress an "argument not used" warning for readmail().
Entered in bugzilla prior to release: "slice of birthday cake" became
"slouse of birthday cake" when made plural. "slice of pizza" used to
work, but adding an entry for "louse" <-> "lice" to one of the special
handling lists for singular/plural broke "slice" since only a trailing
substring match is performed for entries in that particular list.
distant_name() temporarily blinded the hero before calling xname() or
doname() in order to prevent the object being formatted from having
its dknown flag set. The Eyes of the Overworld override blindness, so
that bit got set for heros wearing them regardless of intention. This
switches to a file-scope global instead of blindness as the way that
distant_name() tells xname() not to set dknown.
This bug has been present ever since the Eyes were added (3.3.0?).
Replace the code that uses strcat with two pointers into the same buffer.
Treated separately, they point at distinct strings (no overlap possible),
but the C standard does disallow that in order to enable optimizations
using block transfer or such, so the tool that complained about it isn't
wrong. The characters getting appended to the output pointer can end
up overlapping the beginning of the other input pointer, conceivably
breaking an implementation that didn't use simple left-to-right byte-at-
a-time copying.
Also, I noticed that wishing for "luck stone" gave me a random gem.
There's code to strip off " stone" and compare against gem types, but it
prevents other code that accepts "foo bar" as a match for "foobar" and
vice versa from finding a match, since "luck" doesn't match anything
once "stone" is gone. So add the four gray stones into the array of
alternate spellings.
Another bit: it now accepts " gem" in addition to " stone" as optional
gem suffix, so "ruby", "ruby stone", and "ruby gem" all yield ruby.
("luck gem" won't work; you'll end up with a random gem-class object.)
And a last other bit: wishing for "lamp (lit) named foo" would yield
an unlit, unnamed lamp because "(lit)" followed by anything didn't match
"(lit)" and threw away everything past the opening paren. Now it will
produce "lamp named foo (lit)"--a lit lamp named "foo". (Wishing for
"lamp named foo (lit)" produces an unlit lamp named "foo (lit)". That's
acceptable to me... I'm not crawling any farther down this hole. Maybe
object formatting should be changed to keep the lit attribute in front
of the name?)
While the topic of strprepend() is current, make good use of it.
Simplify code which inserts "the Nth " in front of "<arrow,&c>".
I'm pretty sure there are one or two other places where I assumed that
the outpuf of xname() was a char array which is BUFSZ in length rather
than BUFSZ-PREFIX, and reused the buffer, but I don't know where they
occur. (BUFSZ-PREFIX is still big enough to hold most things, so it
might not lead to trouble.)
