Having an artifact wish be refused uses zeroobj and code which
followed was attempting to update its weight, triggering a segfault
now that zeroobj is 'const'.
They're never modified. Minor complication: &zeroobj is used as
a special not-Null-but-not-an-object value in multiple places and
needs to have 'const' removed with a cast in that situation.
The recent attempt to have looking inside a container show shop
prices had multiple problems. Worst one was showing shop prices as
if the hero would be buying for items already owned by the hero.
Item handling inside containers on shop floor was inconsistent: if
shop was selling those items, they would include a price, but if not
selling--either already owned by hero or shopkeeper didn't care about
them--they were only marked "no charge" if hero owned the container.
This is definitely better but I won't be surprised if other obscure
issues crop up. Gold inside containers on shop floor is always owned
by the shop (credit is issued if it was owned by the hero) but is not
described as such.
get_cost_of_item() was giving different information from shop #chat
when dealing with containers owned by hero containing objects owned
by the shop. And when it was legitimately reporting a price of 0,
doname_with_price() wasn't reporting 'no charge' for items inside a
shop that were owned by hero or that shopkeeper didn't care about.
Extend the shop price reveal to far-look, but only when hero and item
being examined are inside the same shop.
The fruit name fix a couple of days ago revealed that an() didn't
pick the right article for single letters. If you set named fruit to
"X" and wished for "fruit", you'd have 'k - a X' added to inventory.
This changes an() and also doname() which bypasses an().
Inadvertently reintroduced in f9f1236. It was just the conditional
that was bad: due to resolving the possible buffer underflow when
comparing to "muskox", the pluralizer now only adds -es when the length
of the string is greater than 5. So for "box" and "fox" the pluralizer
will never add the -es ending, since they are greater than 5.
This commit checks for "does not end in muskox" correctly.
Replace recent "(light blue aura)" with
"(flickering light blue)" if there are 1..4 orcs,
"(glimmering light blue)" if 5..12, or
"(gleaming light blue)" if there are 13 or more, and move its place
in the formatted name.
_3.6.1_: Sting (weapon in hand) (glowing light blue)
_recent: Sting (weapon in hand) (light blue aura)
_now___: Sting (weapon in hand, flickering light blue)
The thresholds for intensity may need to be tweaked. The start
message has been changed from "glows" to "flickers/glimmers/gleams"
and is given when the intensity changes (up or down) as well as when
first glowing. Stop message will usually be "stops flickering" but
some form of mass kill (genocide for sure, maybe explosion, probably
not wand zap) might result in stopping directly from higher intensity.
It still "quivers" if hero is blind when there are orcs on the level,
but no name augmentation shows in inventory for that situation;
describing it as "(weapon in hand, quivering)" would be too silly.
Also, the quiver or glow intermediate message if blindness is toggled
while Sting is active only worked for make_blinded(), not for putting
on and taking off a blindfold. Now fixed. I think becoming blind due
to polymorphing into an eyeless form is still not handled, but there
are no eyeless creatures capable of wielding weapons so that can wait.
Polymorphing from eyeless to sighted is handled but moot for Sting.
Clean up quite a bit of minor things found with simple grep patterns:
operator at end of continued line instead of beginning of continuation
(and a few comments which produced false matches, so that they won't
do so next time), trailing spaces (only one or two of those), tabs (a
dozen or so of those), several casts which didn't have a space between
the type and the expression (I wasn't systematic about finding these).
I think the only code change was in the function for the help command.
Description for use when an item hasn't been seen up close yet falls
back to real name if there is no separate description, but was doing
so before real name substitution for samurai.
actualn = foo;
dn = description ? description : actualn;
if (Samurai)
actualn = bar;
So player saw a flail (via 'dn') until dknown bit got set, then
nunchaku (via 'actualn' after it got set to samurai-specific value).
Wait until after substitution of Japanese real names before falling
back to real name when there's no description.
Fixing rnd_otyp_by_namedesc() for use by get_shiny() broke its use
by readobjnam(). Make the chance for 0% generation objects to have
non-zero chance of being selected be a parameter.
The wishing code uses 'oc_prob + 1' so that probability 0 (never
random) objects are eligible to be selected if their name matches
a wish; collecting 'shiny' objects shouldn't do that. (No effect
on play since there aren't any shiny objects with 0% random chance.)
rn2() takes int, and total oc_prob for entire objects[] array is
15000, so don't accumulate the target probability in a long.
Wishing for "orange" might grant an orange, but it might give an
orange gem, orange potion, or orange spellbook instead (but never
orange dragon scales or orange dragon scale mail). Force the food
object to be an exact match so wishing always produces an orange.
Unlike cloak_simple_name() and helm_simple_name(), suit_simple_name()
wasn't guarding against Null. Current usage never trips up against
that, but when I added a new use in doseduce() [pending], it caused
a crash.
Redo how updates of permanent inventory window are suppressed during
restore. Reverses part of e9f1e03271
which included a simpler attempt to deal with this.
It looks like we should have been getting impossible "unpaid_cost:
object wasn't on any bill" but segfault was reported; I haven't tried
to figure out why. The band in xname() ought to be redundant now but
is included for bulletproofing.
Wishing for "<size> glob of black pudding" worked, and wishing for
"black pudding glob" worked, but wishing for "<size> black pudding
glob" didn't work. Fix that.
Also, remove a bit of spaghetti introduced by the previous patch.
And once we know we're wishing for a glob, we can skip a big chunk
of wish parsing and special case handling.
Fixes#108
"small"/"medium"/"large" prefix was being stripped off during wish
parsing so that it could be used to control glob size. But those
are also prefixes for monster and/or object names. Wishing for
"small mimic corpse" or "large mimic" corpse failed with "nothing
matching that description exists" when it tried to satisfy "mimic
corpse". (Asking for "giant mimic corpse" worked as intended.)
Not mentioned in the report: wishing for "large {dog, cat, kobold}
corpse" produced the corpse of corresponding normal sized critter
instead of that of a large one.
Noticed while testing the fix: wishing for "glob" failed rather
than pick a random glob type. Wishing for "glob of grey ooze"
failed even though "grey ooze" is recognized as a variant spelling
for the gray ooze monster. Wishing for "<monster type> glob" also
failed even when the monster type was viable for globs. This fixes
all of those even though no one will ever notice....
Wishing for "small box" (and "medium box") no longer yields a large
box, it fails with "nothing matching..." instead. I was ambivalent
about the earlier change which had the unintended side-effect of
making them synonyms for "large box" so haven't tried to revive it.
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.
