If the recently added release routine ever gets called twice for
some reason, don't free already freed memory, or worse, was freed
here and then allocated for something else which is still in use.
When a stack of N corpses is hit by wand or spell of undead turning,
1 revives and N-1 remain corpses. If owned by a shop, a fee for
using up all N corpses was charged and if carried at the time, the
extra N-1 became owned by the player but if on the floor, they
remained owned by the shop. Feedback was schitzophrenic as to
whether the whole stack was involved:
One of the <foo> corpses glows irridescently.
You owe <shk> X zormids for them.
Split the stack so that revival explicitly operates on only 1 corpse.
It's done after the revival side of things has already succeeded or
given up, so the split will never need to be undone.
Zapping wand of undead turning at self while inside a shop and
carrying a corpse caused the shopkeeper to claim a use-up fee for
the corpse regardless of whether it was owned by the shop.
Not mentioned in the report: casting stone-to-flesh as self while
carrying a figurine or statue behaved similarly.
A few things which might conceivably pass negative values to ctype
routines. Some are post-3.6.0. None of them explain the sporadic
Windows assertion failure.
Using tolower() without verifying the argument isupper() should be
completely safe when tolower() is a function but might not be when
it's a macro. (Likewise for toupper() without islower().) NetHack's
lowc() function is always safe, at least for ASCII.
I've hunted for other instances where monster hit points were set
to zero or less without calling the routine that kills off the
monster (see recent mon_unslime() vs zhitm()) and didn't find any
for mhp subtraction. I haven't checked for direct assignment yet.
For a while I thought I'd found several cases where a monster was
intended to be killed but got left with positive hit points, but
it turned out that lifesaved_monster(), of all places, was setting
them to zero. I've moved that to its callers so that it isn't so
well hidden. And changed several ''if ((mon->mhp -= dmg) <= 0)''
into separate subtraction and 'if' just so the mhp manipulation is
a bit more visible.
I think the only actual change here is the message for monster
being killed by lava, where glass golems now melt instead of burn.
Several people seem to be confused about config file and what to
put in it. Perhaps this'll help a bit. The options are mostly
in alphabetical order, except where it makes sense to group
them together.
Also add fixes36.1 to the Files
Fix a typo in the text for encumbrance in the Status section.
Fix a typo in Guidebook.mn for non-fatal status condtions that
resulted in bold font for the entire Stun/Conf/Hallu line.
For Guidebook.ps, force
Status
Hunger:
onto two lines instead of being bunched up together on one line.
(For Guidebook.txt, it's already two lines.)
For both Guidebook.txt and Guidebook.ps, force some extra vertical
separation between the set of one-letter commands and the set of
extended commands, between the set of extended commands and the
set of Meta-key commands, and between the set of Meta-key commands
and the extra one-letter commands available when number_pad is on.
I don't know whether Guidebook.tex's output would look better with
something similar.
Change description of area outside of the swallow animation from
"interior of a monster" to "unreconnoitered". For the animation
characters themselves, don't suppress the list of other screen
features which use the same character ('/' for wand and so on).
Add a data.base entry for "unreconnoitered" in case someone tries
to use it to look up an unfamiliar term.
They aren't walls.
Noticed while working on a potential change for far-look while
swallowed, zap beams have a bogus description of "wall" that
showed up when looking at '/' and '\\'. I'm guessing that vbeam
and hbeam were cloned from actual wall symbols and then lslant
and rslant got cloned from them. There doesn't seem to be any
other reason for the description, which is both wrong and applies
to symbols which aren't on the screen at a time when the player
can use far-look to examine them. It's been this way since the
creation of the second cvs repository used to start the current
git one; I didn't attempt to go back any farther than that.
When --More-- was written to leftmost column of line 2 while the
hero was swallowed, after player acknowledged it and the top line
was cleared, the cursor ended up in the wrong place. I still
don't understand what in the world is going on here, but adding
'flush_screen(0)' after 'swallowed(1)' in docorner() makes the
problem go away. Why is the behavior different when --More-- is
in the first column than when it's anywhere else?
After that fix, I commented the whole thing out. The swallowed
optimization is just not significant enough to justify peeking at
core internals.
Core bit: prior to those two changes, I tried inserting 'bot()'
into swallowed(). It moved the mis-positioned cursor from the
end of the second status line to on the map just right of the
bottom right corner of the swallowed display. That didn't fix
anything, but I've left it in place. bot() to update status is
needed following cls(); now it happens before redrawing the map
instead of at some point after.
For OPTIONS=role:Valk,race:!human,align:!lawful (where first+second
contradicts third or vice versa), you'd get
Shall I pick your Dwarven Valkyrie's for you?
where the what-to-pick field names are empty. Now, align:!lawful
gets overridden, producing
Shall I pick your Dwarven Valkyrie's alignment for you?
and then you'll end up lawful regardless of whether you answer yes
or no. That may be suboptimal but does emphasize that the original
alignment constraint couldn't be honored. (Things just fell out
that way and I haven't tried to make it behave any other way.)
While testing the fix, I noticed that OPTIONS=role:Valk,race:random
prompted
Shall I pick your Valkyrie's race and alignment for you?
instead of honoring 'race:random' without asking, so I've tried to
fix that too.
Role selection has become insanely complex, so one or the other of
these fixes has probably broken some other permuation of partial
specification. Both of the changes here have been done in the core
without touching any interface-specific role selection code.
It was hard to test the attempting-to-revive-shopkeeper-corpse
fix when dying shopkeepers kept declining to leave corpses. Make
shopkeepers always leave corpses (modulo various circumstances
which prevent all corpses). I don't know whether or not temple
priests ought to receive the same treatment.
Reported directly to devteam, zapping wand of undead turning at a
shopkeeper's corpse would cause a crash. 'Traits' to fully recreate
the shk were attached to the corpse, but the temporary monster
created on the map intended to be relaced by the shk didn't have any
eshk struct, and the sequence replmon() -> replshk() -> inhishop()
attempted to access mtmp->mextra->eshk when trying to reattach the
shk to his/her shop. No other mextra structs involve pointer fixups,
so pets, priests, vault guards don't need extra handling.
I tested four cases. #1 and #3 had no shop bill at the time; I'm not
sure about #2. These all worked.
1) shk killed inside shop, resurrected there;
2) killed outside shop on the shop level, resurrected there;
3) killed inside his shop, corpse carried to different level before
being resurrected;
4) killed and resurrected on different level from shop after hero
stole something (teleported out of shop with unpaid item)--shk
left shop to chase hero and followed him/her up some stairs.
Implement the suggestion that a monster killing itself with acid
to avoid turning to stone or with fire to avoid turning into green
slime not break pacifist conduct even if the player caused the
"turning into" situation that triggered the accidental suicide.
Along the way I discovered a serious bug: zhitm() applies damage
to target monster but leaves it to caller to finish killing off
that monster when damage is fatal, but muse_unslime() called it
without checking whether the monster should die. For fire breath
that shouldn't matter since all fire breathers are immune to fire
damage, but when support for wands of fire and fire horns was
added later it just cloned the fire breath code and neglected to
check for fatal damage. The result was that a monster with 0 HP
would be left on the map, then impossible "dmonsfree: 1 removed
doesn't match 0 pending" would be given when taking it off fmon
list, but a stale monster symbol (presumably level.monsters[][]
pointer too) was left on the map which eventually led to monsndx
panic or arbitrary crash.
Replace "dark part of a room" with something more sensible when
examining the map while underwater where water/lava/ice within the
3x3 grid centered on the hero is all that can be seen. Adjacent
non-water, non-lava, non-ice spots are now described as "land".
(Note: this stuff doesn't apply on the Plane of Water where being
underwater gets handled differently.) Spots outside that 3x3 grid
are now described as "unreconnoitered", which sounds a bit odd but
I couldn't come up with anything better. "Not visible" is accurate
when the hero can see but needs adjusting when he can't, bringing
us right back to the current conundrum. I suppose "not accessible"
might be viable but nitpickers would consider it to be inaccurate
if hero has teleport capability. (There are a couple of references
to "unknown" from earlier versions of this revision. I think
"a ghost or unexplored or unknown or land or air (land)" is the only
place left where the player might see it, and it seems reasonable
there, although perhaps it ought to be changed to "unreconnoitered".)
Also fix farlook while swallowed and blind, where blindness was
overriding swallower Id even though it doesn't do so for mon_nam()
and things which use that like combat feedback.
Quiting without ever examining inventory caused the Qt interface
to issue an impossible(), then crash due to deferencing a Null
pointer. The prior fix was to suppress the validation code that
was crashing. This changes things so that the inventory window
always gets at least one use, allowing the Qt validation code to
succeed. tty and X11 are ok with it; win32 needs to be verified.
View the regular map, as originally intended, when using #terrain
while underwater. Doing so means you can't see an underwater object
underneath an adjacent critter by viewing map+traps+objs (without
monsters), but being able to see the level map instead of just the
8 adjacent squares is more valuable.
When underwater, map adjacent lava as lava rather than as "not water".
The Valkyrie quest has lava adjacent to water and the hero ought to
be able recognize it while immersed so she doesn't try to climb out
of water directly into lava.
When the color option is disabled and lava uses the same symbol as
pool or as water (which is the case for default ascii, DECgraphics,
and IBMgraphics), apply the detected-monster display effect to lava.
For tty, this will draw it in inverse video if the use_inverse
option is enabled. (Assumes non-tty will nearly always be using
color so not care.) Creating a separate mapglyph special attribute
for B&W lava instead of overloading MG_DETECT ought to be done but
I didn't want to modify any interface code.
Requested during beta-testing however long ago: want a way to
look at specific map locations while #terrain is showing them
without monsters and/or objects and/or traps being displayed in
the way. The post-3.6.0 autodescribe feature for getpos() made
this pretty easy to achieve, although the lookat() aspect felt
more like trail-and-error than careful design.
Instead of putting up a --More-- prompt, ask the player to pick
a location with the cursor. Moving the cursor gives the terse
description for every location traversed. Actually picking a
spot just ends #terrain and goes back to normal play.
Discovered while working on an enhancement to #terrain....
Various detect magic (objects, food, &c) performed while underwater
temporarily removes the hero from the water in order to have access
to the regular map. In 3.4.3, a hangup save during the detection
would leave the hero standing on top of the water. 3.6.0 added a
flag to track should-be-underwater so that during a hangup save the
hero could be put back in when going into the save file. It also
added #terrain, another situation that uses the remove-from-water
hack while manipulating the map.
The flag wasn't being cleared after use, only during save, so normal
play without a hangup left it pending until next regular save. The
result being that after restore, the hero would be considered to be
underwater again regardless of current location, and the map display
would be limited to a view of the adjacent spots as if underwater.
Then, any move--even using '.' to rest--would notice that the
'underwater' hero was not at a water location and put things back to
normal, with feedback of "you are on solid land again." So to the
player, this would seem like a pair of map display and nonsequitor
message issues, not the internal logic one it actually is.
Being polymorphed into a creature capable of eating metal objects
was treated as if the hero didn't/couldn't eat. Treat it the same
as being able to eat ordinary food instead.
Being fainted or unconscious from other than sleep both ran
metabolism at full rate, unlike being asleep which skips per-turn
consumption 9 times out of 10 (but retains periodic ring/amulet
and hunger/regeneration/conflict consumption). Switch to 'Unaware'
to handle sleep, unconsciousness other than sleep, and fainted
from lack of food as one metabolic condition. Being paralyzed
isn't included but maybe should be.
Changing how metabolism operates when fainted changes the amount
of time until starvation occurs, so I adjusted that by an arbitrary
amount. It will probably need tuning. As things stand, you'll
still faint umpteen times before starving, bringing about lots of
frustration since the player can't do much during that time.
Put in Ron Vaniwaarden's fix for crash occuring if player quits
right after choosing a character and declines to disclose anything.
Just a guess, but deleting the never-viewed inventory window might
be the cause. (3.4.3 didn't delete it.)
There's a small amount of reformatting, but cleaning that up
manually is a monumental task.
Do it properly, using the arguments to xkilled() instead of reversing
the conduct counter after the fact.
The xkilled() flag value of '1' has been reversed. It used to mean
'display message' but now means 'suppress message' since both of the
other flag bits are for suppression. All callers have been updated
to specify either XKILL_GIVEMSG or XKILL_NOMSG so the underlying
number remains transparent.
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().
When you're swallowed, an angry god trying to zap you will kill
the engulfer and hero gets credit (experience) and blame (possible
loss of luck and/or alignment if engulfer is peaceful or tame) for
the act. But hero didn't actually kill the critter, so don't
increment the kill counter that monitors pacifism.
I think there are other circumstances where hero gets credit and/or
blame for something he or she didn't directly do, but offhand I
can't think of them. They might warrant similar treatment.
Tidying of xkilled() triggered by malformed block comment which is
actually a hybrid of an end of line comment (the boulder one, not
the 'dest' parameter one)....
The report that parse_config_line() could overflow its buffer
when passed a long value from parse_config_file() was already
fixed for 3.6.1, but longer config lines mean that later stages
of option parsing need to be aware of the possibility of lines
longer than BUFSZ. This fixes the three special options which
deal with regular expressions. Autopickup exceptions, message
types, and menu coloring all could exceed BUFSZ when formatting
a value to put in the menu for 'list' or 'remove' of existing
entries. Menu colors could overflow by an arbitrary amount,
message types by up to 13 bytes, and autopickup exceptions by
just 1 byte.
Both tty and X11 seem to cope with long menu entries (wider
than can be displayed but not exceeding BUFSZ) by truncating.
For menu colorings, that hides the color and highlight attribute
since those are placed after the regexp.
Menu line truncation for tty was straightforward, just chopped
a big chunk off the end of the long string. For X11, it did
that too, taking off a lot less but ending up with much of the
menu hidden off the left edge of the screen. Dragging it into
view showed that the width fit the whole screen (or possibly
fit the width of the map, which was also as wide as the screen).
So the initial position is being miscalculated.
I glanced over the options parsing looking for issues, and it
seems that paranoid_confirm:long-string-of-junk might have been
vulnerable. So this fixes that.
Reported directly to devteam 7-Jan-2016, two issues with cursed
potion of levitation:
1) the go-up-stairs effect for cursed potion still let you choose
not to escape the dungeon if it occurred on level 1 stairs. I've
left that as-is; perhaps there's a gate across the entrance.
2) both the go-up-stairs and bonk-head-on-ceiling effects were
skipped if the hero was already levitating. I don't know whether
that was intentional but there was no comment explaining why, so
I've changed it to happen regardless of whether already levitating.
In the process, I changed the head-bonk case to do more damage when
a helmet is worn:
old: no helmet 1..10 hp, any helmet 1 hp damage;
new: no helmet 1..10 hp, soft hat 1..6 hp, hard helmet 1..3 hp.
Also, not in the report: when you aren't already levitating you
get the "you float up" message, but for cursed potion there was
never any corresponding "you float down" message because you ended
up not levitating. Now you'll levitate for 1 turn and float down
on the next, landing in a trap if one is present.
Triggered by a couple of mis-formatted block comments in spoteffects.
Much of the diff is adding braces to the 'if' portion of things like
if (test)
statement;
else {
block-of-statements;
}
