PatR [Sat, 28 May 2016 07:51:54 +0000 (00:51 -0700)]
black&white lava
Add MG_BW_LAVA to mapglyph() instead of hijacking MG_DETECT. Used
to display lava in inverse video if color is disabled and lava is
using the same display character as water (which is the default).
(The use_inverse option must be enabled for tty to honor it. X11's
text mode doesn't care. Win32 does care but probably shouldn't--it's
not a case like tty where the hardware might not support it.)
This implements both MG_DETECT and MG_BW_LAVA for X11, but only if
the program is built with TEXTCOLOR enabled. Those should work even
when color is not supported, but I suspect that configuration is
unlikely to ever be used so didn't want to spend the time to figure
out how to do it. (The relevant data is overloaded on the color
data, so not available when TEXTCOLOR is disabled.)
PatR [Sat, 28 May 2016 01:39:17 +0000 (18:39 -0700)]
number_pad:-1 qwertz keyboard
Reported almost exactly one year ago by a beta tester proofreading
the Guidebook, the number_pad setting to support the German keyboard
which swaps the Y and Z keys is for a keyboard that is used in other
places too. The report mentioned France and Belgium; Wikipedia's
"keyboard layout" entry mentions "Germany, Austria, Switzerland and
other parts of Central Europe". This changes references to "German
keyboard" (there were only a couple) into "QWERTZ keyboard".
PatR [Fri, 27 May 2016 01:35:27 +0000 (18:35 -0700)]
'^O' command documentation and '^' command help
While looking for things in core which might conceivably trigger the
Windows ctype assertion failure (haven't found any yet), I noticed
that help_dir() was still treating ^O as a wizard mode-only command.
Also, documentation about that command was never brought up to date.
I wish this change to ^O hadn't been done. #overview already has
a meta/alt M-O shortcut and overloading wizard mode commands makes
documentation more complicated since wizard mode stuff traditionally
has been left unmentioned.
PatR [Thu, 26 May 2016 00:25:47 +0000 (17:25 -0700)]
unix mail cleanup bulletproofing
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.
PatR [Wed, 25 May 2016 08:09:45 +0000 (01:09 -0700)]
more #H4347 - corpse revival
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.
PatR [Wed, 25 May 2016 01:00:57 +0000 (18:00 -0700)]
fix #H4347 - revival of carried corpse in shop
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.
PatR [Mon, 23 May 2016 00:29:59 +0000 (17:29 -0700)]
potential ctype.h issues
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.
PatR [Sun, 22 May 2016 01:25:16 +0000 (18:25 -0700)]
mon->mhp manipulation
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.
Pasi Kallinen [Sat, 21 May 2016 08:29:39 +0000 (11:29 +0300)]
Add sample config file
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.
PatR [Sat, 21 May 2016 07:11:19 +0000 (00:11 -0700)]
Guidebook tweaks
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.
PatR [Sat, 21 May 2016 00:24:18 +0000 (17:24 -0700)]
far-look which swallowed
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.
PatR [Fri, 20 May 2016 01:12:45 +0000 (18:12 -0700)]
zap beam symbol descriptions
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.
PatR [Wed, 18 May 2016 23:36:18 +0000 (16:36 -0700)]
fix #H4343 - obscure tty bug while swallowed
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.
PatR [Wed, 18 May 2016 08:49:56 +0000 (01:49 -0700)]
fix bz451 - non-sequitur role prompt
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.
PatR [Wed, 18 May 2016 01:21:02 +0000 (18:21 -0700)]
corpse_chance()
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.
PatR [Wed, 18 May 2016 01:10:31 +0000 (18:10 -0700)]
fix 'crash when reviving shopkeeper'
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.
PatR [Sat, 14 May 2016 23:57:56 +0000 (16:57 -0700)]
implement #H4340 - indirect kills vs pacifism
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.
PatR [Sat, 14 May 2016 11:02:07 +0000 (04:02 -0700)]
farlook when underwater
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.
PatR [Sat, 14 May 2016 09:13:07 +0000 (02:13 -0700)]
different fix for #H4332 - Qt crashes upon quit
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.
PatR [Sat, 14 May 2016 02:16:18 +0000 (19:16 -0700)]
use of #terrain while underwater
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.
PatR [Fri, 13 May 2016 14:22:08 +0000 (07:22 -0700)]
water vs lava
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.
PatR [Fri, 13 May 2016 01:57:10 +0000 (18:57 -0700)]
autodescribe for #terrain
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.
PatR [Fri, 13 May 2016 01:00:29 +0000 (18:00 -0700)]
detection/#terrain fix for u.uinwater
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.
PatR [Thu, 12 May 2016 00:55:33 +0000 (17:55 -0700)]
nutritution consumption/starvation tweaks
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.
PatR [Wed, 11 May 2016 22:10:33 +0000 (15:10 -0700)]
fix #H4332 - Qt crash upon immediate quit
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.
PatR [Tue, 10 May 2016 22:59:22 +0000 (15:59 -0700)]
more angry god vs pacifist conduct
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.
PatR [Tue, 10 May 2016 01:56:31 +0000 (18:56 -0700)]
fix bz424 - cannot wish for different size globs
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().
PatR [Mon, 9 May 2016 23:21:35 +0000 (16:21 -0700)]
fix #H4333 - angry god vs pacifist conduct
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)....
PatR [Mon, 9 May 2016 00:56:52 +0000 (17:56 -0700)]
option parsing buffer overflow vulnerability
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.
PatR [Sun, 8 May 2016 01:39:36 +0000 (18:39 -0700)]
options bit
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.
PatR [Sun, 8 May 2016 00:26:01 +0000 (17:26 -0700)]
cursed potion of levitation
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.
PatR [Sat, 7 May 2016 23:32:25 +0000 (16:32 -0700)]
hack.c formatting
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;
}
PatR [Sat, 7 May 2016 23:24:17 +0000 (16:24 -0700)]
fix #H4336 - extra space in potions boil message
'Your <single-potion> boils and explodes.'
'One of your <stack-of-potions> boils and explodes.'
'Some of your <stack-of-potions> boil and explode.'
'All of your <stack-of-potions> boil and explode.'
The last variation had an extra space in the message prefix....
In addition to removing the excess space, this adds
'Both of your <stack-of-potions> boil and explode.'
to be used for the (All == 2) case.
The bug and fix also apply to stacks of potions 'freezing and
shattering' and to stacks of scrolls 'catching fire and burning'.
PatR [Thu, 5 May 2016 22:21:22 +0000 (15:21 -0700)]
Vlad's Tower bookkeeping
The lower two levels of Vlad's Tower were got showing the wizard-mode
special level indicator '[level_abbrev]' in #overview, nor appearing
for ^O or in the level teleport menu, indicating that Is_special()
wasn't finding them. It took a while to figure out why, but the fix
is trivial.
PatR [Thu, 5 May 2016 00:42:58 +0000 (17:42 -0700)]
disclosing genocided/extinct monsters
Make the handling of unique monsters consistent between vanquished
monsters and genocided/extinct monsters. No visible difference to
players.
This also prevents Nazgul and erinys from being polymorphed into
some other form to reduce the chance that their kill count fails
to match the expected number when they're reported to be extinct.
[My long test game (with 3451 total dead critters as of the last
save file) used for exercising the sorting of vanquished monsters
included
120 soldiers
111 wolves
9 Nazgul
2 erinyes
and the genocided/extinct list had none genocided, those four
extinct. No doubt the missing third erinys was alive somewhere
rather than counted as something else after getting polymorphed,
so this band-aid wouldn't have helped this particular game.]
PatR [Tue, 3 May 2016 08:12:32 +0000 (01:12 -0700)]
complicate #vanquished monsters processing...
...to make it more interesting. Using #vanquished in wizard mode
or answering 'a' to the "disclose vanquished monsters?" prompt will
put up a menu to choose how the list of vanquished monsters should
be ordered. Right now there are 6 choices:
Traditional: by monster level, by internal index within level;
by monster toughness, by internal index within monstr[] rating;
alphabetically, first unique monsters, then others;
by monster class, low to high level within class;
by count, high to low, by internal index within tied count;
by count, low to high, by internal index within tied count.
Two other orderings are implemented but suppressed from the menu
since they seemed uninteresting (alphabetical with uniques
intermixed with other monsters, and by-class high to low within
class). The first two are very similar to each other and one of
them should probably be discarded too. The by-class order(s) have
class-name separator lines between classes.
Options parsing for end of game disclosure has extended current
+v (always show vanquished monsters)
-v (never show vanquished monsters)
yv (prompt about them, with default response 'y')
nv (prompt about them, with default response 'n')
to include
#v (always show vanquished monsters and choose the ordering)
?v (prompt about them, with default response 'a' to choose ordering)
The 'a' response was picked because it's easy to use ynaq()
instead of ynq(), but it can be considered to mean "ask about sort
order". (Neither of the two new option values could be "av"; 'a'
for disclosing attributes would become ambiguous.)
+v or answering 'y' for any of yv, nv, or ?v uses the most recent
sort ordering (if #vanquished has been used in wizard mode) or the
traditional one (normal mode, or #vanquished not used). Players
will probably want to specify a default order and then use +v
rather than choose the final order from a menu. That hasn't been
implemented here. Count high to low might be a better default than
level high to low.
While looking through Guidebook.tex to try to determine whether
the new text needed special handling, I spotted multiple mistakes
in the existing text. Probably all from earlier updates of mine;
this attempts to fix them. As usual of late, Guidebook.mn has been
tested and Guidebook.tex hasn't.
PatR [Sun, 1 May 2016 20:54:08 +0000 (13:54 -0700)]
simplify #vanquished monsters processing...
...prior to making it more complicated. Most of the diff is just
reducing the block nesting level of the kill-count formatting by
a couple of tab stops.
PatR [Sun, 1 May 2016 01:55:52 +0000 (18:55 -0700)]
farlook of detected objects
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.
From a bug report sent directly to devteam 16-Jan-2015 (subject:
"NH343 (NAO version) - display bug"), if the hero was blind and
levitating and searched next to 'I' (text) or '?' (tiles) which
was displayed on top of a known pool and the remembered unseen
monster was no longer there, the 'I'/'?' was removed but the spot
was redrawn as floor rather than water.
This ended up being more elaborate than I anticipated. 'Q' will
now accept the wielded weapon as a choice of item to quiver. If
that item is a stack of more than one, it will offer to split N-1
into the quiver and leave 1 wielded. If the offer is declined, or
if there is already just 1, it will require confirmation to move the
item from the weapon slot to the quiver slot. The alternate weapon
is handled similarly, with different phrasing when in twoweapon
combat mode.
Just to be crystal clear: a single object cannot be in more than
one weapon, alt-weapon, or quiver slot at the same time. 'Q's old
behavior of rejecting the wielded weapon was to avoid accidentally
becoming empty-handed, not anything to do with multiple worn/wield
slots.
'Q' will also accept a count when picking an inventory item, then
put 'count'-many into the quiver, leaving N-count in original stack.
Except when the chosen item is already in the quiver; it that case,
it undoes the stack split and leaves things as they were. (That
restriction may not have been necessary but I'm not planning to
revisit it....)
Tidy the output from disclosure of vanquished monsters at end of game
or from #vanquished wizard-mode command. Instead of
Juiblex
The Wizard of Yendor (twice)
a mastodon
3 purple worms
an erinys
120 gnomes
42 grid bugs
it will line up the monster type names, yielding
Juiblex
the Wizard of Yendor (twice)
a mastodon
3 purple worms
an erinys
120 gnomes
42 grid bugs
For short lists, the original looked ok (maybe even better...), but
for long lists at the end of a long game, aligning the names looks
better and is easier to read than left justifying everything.
Change sort ordering of
diluted potion of bar
diluted potion of foo
potion of bar
potion of foo
potion of fruit juice
to
potion of bar
diluted potion of bar
potion of foo
diluted potion of foo
potion of fruit juice
so that potions of the same type are grouped together. Bless/curse
state (when known) takes precedence over dilution, so "blessed
diluted potion of foo" will come out before "uncursed potion foo".
Start coloring after the space which follows the selection indicator
instead of on that space. The difference isn't noticeable when the
highlighting is just a color, but it is if that highlighting includes
inverse video or underline which visibly apply to spaces. So for
a - entry A
the old code produced
a -########
and this revised code produces
a - #######
where '#" indicates characters subject to menu coloring.
I saw a lich in solid wall at one of the spots which gehennom.des
marks with a pool (so that baalz_fixup() can find the two spots that
need post-wallification fixup). I could understand the special level
loader placing a swimming or flying monster there, but don't know
whether it might do that for a lich (which doesn't need to breathe)
so am not sure whether this actually fixes what I observed.
The lich was there for far too long to have been a shapechanger, but
when I went back to the save file it was no longer there, producing
another puzzle.
Digging a grave witha a pick-axe converted the grave to floor but
did not dig a pit and unearth the grave's contents. [Caused by a
change to maketrap() intended to prevent wizard-mode wishing for
traps on top of furniture.] Digging a second time succeeded in
creating a pit since the location was no longer furniture.
When items were sorted alphabetically, holy water ended up in the H's
and unholy water in the U's. Force them to get placed with water in
the W's, as would happen if water wasn't given an alternate name when
blessed or cursed.
Ft.Ludios entrance (fort's entry, not level entry)
The code to apply an automatic annotation to the knox level was looking
for a drawbridge like on the castle level, but knox doesn't have any
drawbridge. Look for its door instead. (It's initially a secret door,
so won't be revealed via magic mapping. It needs to be found or
destroyed to get mapped as a door or empty doorway in order to trigger
the annotation.)
Also, give a tiny bit of variation to the knox level layout. It used
to have both the throne and the secret door on the lower of two similar
rows and the door into the treasure vault on the upper one. Now each
of the three can be on either of those two rows (independently of each
other), making eight possibilities. This doesn't accomplish much,
other than to make the secret door locations not always be at the same
fixed spot.
Silly shapechange message if <mon> is sensed via telepathy and takes
on a mindless form. In the case I noticed, it was a doppelganger on
the far side of a maze wall who changed from something ordinary into
a mummy while the hero was wearing an amulet of esp.
3.6.0 could deliver this message, but I think changes since then have
increased the chance for newcham() to give shapechange feedback.
getobj() was caching 'invent' in 'firstobj', dating from the days
of the !GOLDOBJ configuration, and sortloot() could change the value
of invent, making firstobj end up pointing somewhere into the midst
of the inventory list. So collecting letters of applicable items
could miss things (typically right after restoring a saved game).
Repeating the command would operate on already sorted invent, making
firstobj remain valid and things mysteriously reappear after having
been missed before.
Just get rid of 'firstobj' since it's no longer useful.
flags.sortloot was changed from boolean to xchar, but proper type
is plain char. (Presumeably it was originally off or on, then got
changed to 'n' for off, 'l' for on, plus 'f' for super-on.)
Also, make the sortloot menu for 'O' mark the current value as
preselected when interactively setting the value. (I've been
meaning to do this for various other options but haven't gotten
around to it. The need to workaround PICK_ONE+MENU_SELECTED menu
behavior is a nuisance.)
... when exploding chest trap destroys uchain without using
unpunish() to un-wear it first. The '!carried(uball)' clause
should be applied to the uball->ox,oy test only, not to both
uchain->ox,oy and uball->ox,oy.
Force the menu for the look-here command when 'here' is the inside
of an engulfer to be PICK_NONE. That way '>' won't exit the menu
by choosing the extra inventory item "> - hero".
For menustyle:Traditional, the object class prompt for 'D' includes
an entry choice of 'm' to request a menu. Supplying real classes
and 'm' resulted in a menu limited to those classes, as intended,
but any of BUCX for curse/bless state and 'm' without any actual
classes resulted in a menu of entire invent. A one-line fix once
the proper place for that fix was located.
For menustyle:Traditional or menustyle:Combination, 'A' includes an
extra choice of 'i' to examine relevant inventory prior to choosing
object classes (and object identification also offers that), but
the inventory display showed everything rather than just the items
applicable to 'A' (or to object ID). Figuring out where to apply
the fix was trivial, but the fix itself was a bit more involved and
it exposed a latent bug in display_pickinv(): "" was supposed to be
the same as NULL when passed in as list of target inventory letters,
but it wasn't being handled correctly.
A patch in late January to suppress suits as likely candidates for
the 'R' command when wearing a cloak also unintentionally suppressed
rings when wearing non-cursed (or not yet known to be cursed) gloves.
Cloak always blocks suit removal; gloves only block ring removal if
cursed.
Extend #stats beyond just monsters and objects. Have it display
memory usage for traps, engravings, light sources, timers, pending
shop wall/floor repair, regions, bones tracking, named object types,
and dungeon overview.
No doubt there are other memory consumers that I've overlooked.
When typedefed to C99's bool type, Clang complains in container_contents about "comparison of constant 108 with expression of type 'boolean' (aka 'bool') is always false".