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
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.
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.
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.
Another tweak to PR #1240. Vampires start out vampshifted to
bat/fog/wolf form. Marking them as 'waiting' forces them back to
vampire form. Testing that revealed one of the brides as a vampire
lord rather than a vampire lady. That could probably be construed
as being politically correct but doesn't match the source material.
The reversion from vampshifted to vampire entailed a 10% chance of
toggling gender, comparable to hero self-polymorph. Don't do that
for vampires. From the player's perspective they change randomly but
from their own perspective, the change is controlled.
This makes it easier to understand what is happening in each of those
places, and also much easier to find the places that conversion between
hero and monster resistances happens (since you can now just grep for
"res_to_mr"). I think I got all the instances where the macro should be
used but I'm not 100% sure since there wasn't a single unique term to
search for to find them all.
I replaced the modifications to give_u_to_m_resistances made in the
previous commit, so that it now uses the same macro as other
conversions, since otherwise it would be much harder to find the
complete list of places where conversions between hero and monster
properties happen.
I think that using two arrays in tandem like give_u_to_m_resistances
originally did is frequently considered a bad idea, because one can
easily be added to or subtracted from without modifying the other --
that could obviously cause problems. Combining the arrays like this
avoids that potential problem.
Landmine blew up, scatter exploded a potion of oil, which melted
the ice on which the landmine was, resulting in the landmine trap
being deleted. The code then tried to access it to make a pit.
Issue reported by Umbire: if hero dies by drowning on the Plane
of Water, cause of death was reported as "drowning in a limitless
water".
Reported for livelogging but applied to tombstone and logfile too.
Omit the article "a" in this situation.
For 3.6.7, it would have started as "drowning in a water" and been
updated on the fly to be "drowning in deep water". 3.7 changed
terrain type WATER to be "wall of water", where "a" is expected,
and also added "limitless water" for Plane of Water, but it was
neglecting to include a similar fixup for the latter. The "deep
water" fixup is still present but doesn't get triggered anymore.
Fixes#1248
A monster swallowed hero, hero teleported the monster away, but the level
was full of monsters, so the swallower ended up not moving anywhere,
so it was in the same location as hero, but hero wasn't swallowed by it.
Move the monster into limbo instead.
A pet titan dropped a boulder over a pool, and the code killed
the titan, because the code was considering the titan to be in
the water.
If a flyer or a floater is over the pool, don't kill them off
if a boulder is dropped in there. Also make the pet movement
code handle the case where the pet might've died while dropping
items.
The revised code returned an uninitialized variable if the new test
failed.
The cloneu() case was ok but this changes it to keep parallel to the
clone_mon() case.
Noticed while doing rudimentary testing of the mnearto() fix for
mimics. #migratemons wouldn't add monsters to migrating_mons if
getlin() was compiled with EDIT_GETLIN defined unless you manually
deleted the invisible default value that wiz_migrate_mons() was
passing. It took a while to puzzle that one out.
The command list has conditional description of what #migratemons
does and it was using the wrong spelling of the macro used to
control that. So '# ?' described the behavior of #migratemons as
it operates without DEBUG_MIGRATING_MONS enabled even when that is
enabled, adding to the getlin() confusion.
