Finish shop changes begun in 2674a9904d.
Fix the longstanding bug where shop paying with itemized buying would
reveal container contents if any unpaid items were inside containers,
regardless of whether the containers' contents were known yet, even
when the container was a locked box/chest or a cursed bag of holding.
Paying by menu made that be more noticeable but it has been present
ever since itemized paying was introduced. I can't find any old bug
reports for it though. I did find an old message of mine that claims
it's in bugzilla with a "#Hnnnn" tag.
This changes how buying containers and their contained items behaves.
It's now an all or nothing operation. Itemized billing will list
the container but not contents, and to buy what is inside you need
to pay for the whole thing as a single unit. If the container itself
is unpaid then its price is part of that item's total cost. If it is
hero-owned than it is listed as an item to buy but doesn't increase
the cost derived from its unpaid contents. (If you decline to pay,
hero will still own the container and still owe for unpaid contents.)
If the 'sanity_check' option triggers a warning, don't show the
"Program in disorder! (Save and restore might fix this.)" and
"Report these messages to <devteam>." messages and also don't run
the crash report submission.
Doesn't affect the fuzzer because it escalates impossible() to
panic() before reaching those extra messages.
If sanity_check starts spewing out warnings, don't run it again if
player types ESC when the program finally asks for the next command
(rather than --More--).
Also, some reformatting of the main command table.
Issue reported by ars3niy: unpaid containers containing one or
more other unpaid items appear on the menu for 'p' along with
separate menu entries for those other items. Buying the container
buys the contents too, then if any of the contents were also picked
in the menu, an attempt will be made to pay for them separately.
Since they are no longer on the bill by that point, that triggers
an impossible warning.
This fixes that by paying for the container but not its contents.
(Temporarily, until more extensive changes get implemented.) Then
those contents will still be on the bill. It they've been chosen
in the 'p' menu, paying for them will work as expected.
This also fixes the pay menu for the case where the bill contains
any instances of a partly used up portion of some stack and also
the unpaid intact portion of the same stack. With itemized billing,
you are allowed to buy the used up portion separately, then maybe
drop the unpaid portion. (If you try to pay for the intact portion,
the shk won't accept the payment and will tell you to pay for the
used up portion first.) With the recently added menu for billing,
they were lumped together as a single item and you had to pay for
their whole stack.
And it fixes a much older bug dealing with the cheapest item on
the shop bill. If you don't have enough to pay for that, the rest
of buying gets skipped. But stacks that had used up and intact
portions were lumping those together instead of separately checking
the two portions for possibly being the cheapest, so it was possible
to have enough gold to pay for one portion but be told that you
couldn't affort to pay for anything. If it was the intact portion,
you wouldn't be able to buy it anyway, but if the cheapest item was
used up portion, being told you didn't have enough gold was wrong.
This commit does not fix the longstanding bug that itemized billing
reveals the contents of containers which haven't been opened. It
was intended to do so but I've run out of steam.
(There is groundwork for that, where buying a container would
include payment for its unpaid contents without revealing what those
are, and they couldn't be purchased separately unless they get taken
out of the container. Uncommenting '#define CONTAINED_BUYING' will
enable it, with updated pay menu handling but without being able to
pay for non-empty containers.)
Fixes#1249
Pull request from mkuoppal: curses menu handling could go out of
bounds accessing array groupaccels[] if strange input gave a false
positive for STDC's isdigit(). Discovered by debug fuzzer.
Failure was triggering an error by the undefined behavior sanitizer.
[randomkey() ought to return int rather than char.]
Closes#1259
curletter is screened to be in valid range in all
other switch/case branches except in the default case,
which is fallthrough.
Add check for valid range in here also, otherwise
array might be addressed with invalid offset.
This should fix the following, found
with UBSAN and #debugfuzzer:
../win/curses/cursdial.c:1558:49: runtime error: index -154 out of bounds for type 'char [256]'
0x5f3857eff140 in menu_get_selections ../win/curses/cursdial.c:1558
0x5f3857ef78c8 in curses_display_nhmenu ../win/curses/cursdial.c:801
0x5f3857edd390 in curses_select_menu ../win/curses/cursmain.c:768
This took me a while to track down. I noticed it while drinking
unpaid potions but didn't expect the issue to be potion-specific.
Affects paying shop bill in addition to examining [former] inventory.
Start with a stack of 3 unpaid potions.
Iu
a - 3 potions of healing (unpaid)
Ix
no used up items
Drink one.
qa
Iu
a - 2 potions of healing (unpaid)
Ix
x - potion of healing
So, far everything's normal. Note that 'x' is an arbitrary letter
used for expended items when shown in inventory style rather than an
inventory letter or menu choice.
Drink another.
qa
Iu
a - a potion of healing (unpaid)
Ix
x - potion of healing
x - potion of healing
Drink the last one.
qa
Iu
no unpaid items
Ix
x - potion of healing
x - potion of healing
x - potion of healing
In 3.4.3, these last two Ix cases would have had single lines of
'x - 2 potions of healing' and 'x - 3 potions of healing', respectively.
After this fix, they will again--unless potion stack 'a' was wielded,
readied as alt-weapon, or quivered.
The list of possible object locations used when formatting obj->where
wasn't updated when the objs_deleted list was introduced. If object
sanity checking ever tried to report it for something, it would have
been described as "unknown[9]" rather than as the intended "deleted".
A fairly recent change to improve the message given when hero isn't
able to force a locked chest due to type of weapon or weapons being
wielded had one of the text substitutions backwards. If wielding 1
dart, it gave
|You can't force anything with those weapon.
and if wielding more than 1,
|You can't force anything with that weapons.
Reported by ars3nly as "#1250: Repeating #sit causes a sitting loop",
with a followup comment describing how to reproduce easily, and by
Umbire as "#1229: Curses and extended command menus". Repeat count
from previous command carried over to current command when ^A was
used to re-run the current one.
Reset 'last_command_count' every time a repeat count is obtained,
even when the new one is 0. This is a much simpler fix than what
was used with several previous attempts, but it seems to be working.
The do-again code is convoluted, but the tricky bit was the fact
that this problem only happened when number_pad was On with repeat
counts entered as 'n<digits>'. I still don't understand that aspect,
but it wasn't happening for count of simple '<digits>', making
reproducing it by someone who doesn't use number_pad be difficult....
Closes#1229Closes#1250
While testing a potential fix for issue #1250, I discovered that
using the altmeta option, to simulate typing Alt+x to get M-x via
typing 'ESC x', didn't work after a count prefixed by 'n' when in
number_pad mode. It did work as intended for !number_pad when a
repeat count prefix is entered via digits without 'n'.
This doesn't solve #1250, which also occurs for number_pad but not
for !number_pad.
Add a theme room with multiple visible teleportation traps
which will always teleport to specific locations in the same level.
Teleport trap change from xNetHack by copperwater <aosdict@gmail.com>.
if Wizard escapes the dungeon
Reported by vultur-cadens: a fix to prevent quest feedback when quest
nemesis is removed from the game during bones creation introduced a
regression for an earlier fix that kept context.no_of_wizards up to
date if the Wizard of Yendor escapes the dungeon without dying.
Change 'wizdead()' to 'wizdeadorgone()' and call it from m_detach()
for mongone() as well as for mondead().
Fixes#1256
When debugging, allow player to choose which outcome for #sit on a
throne (just 1 to 13; no menu; player has to check source to figure
out what the values mean). Also when the chance to use up the throne
afterward comes up, prompt whether to honor it (similar to drying up
a fountain).
Added to ease testing for github issue #1250 but I still haven't been
able to produce anything odd with ^A after #sit whether or not it was
preceded by a counted action that got interrupted before the count
expired.
Pull request from mkuoppal: avoid integer overflow when user types
digits and they're combined into a number by successively multiplying
intermediate value by 10 and adding new digit. Needed to avoid
triggering undefined behavior if the value overflows the largest
signed integer (actually long int).
This is a much more general fix than the code in the pull request,
which imposed an arbitrary limit for one aspect of tty input.
I'm not convinced that integer.h was the right place to add the new
AppendLongDigit() macro. I may not have caught all the places where
it is needed. files.c accumulates a value from digits but uses
unsigned int, so overflow won't trigger undefined behavior (although
it presumably ends up with a different value than what was intended).
options.c and coloratt.c accumulate smaller integers and have a limit
on the number of digits they'll use, so can't overflow.
Fixes#1254
Containers can't become fireproofed so the line of code in
fire_damage() which tested for that led to confusion.
Also, add missing handling for statues as containers.
I was trying to examine gi.invent (via
print ((struct instance_globals_i *)&gi).invent
don't ask...) and gdb gave me very confusing rejections that don't
occur with other g<letter>.variables. It turned out that gdb was
treating 'gi' as a type rather than as a variable reference.
I suspect it was because Qt was included so linking used C++ mode,
and C++ handles struct names differently from C. Anyway, renaming
'struct gi' to 'struct glyphinfo' made the mystery problem go away.
Restoring was hiding unhidden mimics and if that chose an object
other than boulder of gold pieces, it called mkobj() before an
array used by that routine was initialized. The result was warning
"rnd(0) attempted" when NH_DEVEL_STATUS wasn't set to 'released' or
divide by 0 crash if it was set to that.
Restore should not be catching up for lost time when unpacking a
save file into individual level files, and if it hadn't done that
it wouldn't hide mimics who aren't currently hidden.
In addition to avoiding that, this also moves the initialization of
the offending mkobj array sooner.
[3.6 didn't use that array so wasn't susceptible to this. It is
hiding unhidden mimics during what should be a strictly bookkeeping
operation though.]
I happened to restore a save file left over from testing yesterday's
attempt to fix github issue #1253 and had a werejackal change from
human to beast while next to my hero on "Elbereth", then attack me.
This should be sufficient to prevent that. I'm not sure why the
previous fix attempt seemed to be adequate when testing it. The new
fix relies on the previous one.
Issue reported by chadministratorwastaken: were-creature that was
ignoring Elbereth while in human form would make one more attack
after changing into creature form.
Have new_were() make an onscary() check when changing to beast form
while next to the hero. Do likewise for polymorphing creature.
Fixes#1253
Fetching a value of DEBUGFILES from the environment to enable
debugpline() messages was intended to operate in wizard mode only
but that wasn't enforced.
Honor the objection to an earlier change to tty_curs(), despite the
fact that it seems delusional. Four integer comparisons per cursor
positioning call affect the throughput of cmov(), but only if the
program is built without DEBUG defined?
More analyzer induced hackery. If tty_curs() discovers that the x,y
passed to it are no good, don't use them, even if that results in
the next output being in the wrong place.
The old issue of behaving differently when built with DEBUG defined
versus when it is not defined is fixed in a different way.
Check getenv("DEBUGFILES") unconditionally during startup rather
than waiting until it's needed.
Might prevent the static analyzer from getting so aggravated.
Most likely not though, but should make debugpline() less fragile
if it gets called during a panic or a signal.
Since croom and maxroom both point to elements in the rooms[] array,
the complaint that the memcpy() in
| if (croom != maxroom)
| memcpy(croom, maxroom, sizeof (struct room));
might have overlapping source and destination is bogus. The fix is
trivial but not vetted by the analyzer.
