The 'A' ("alphabetic") and 'N' ("numeric") column classifiers were being
used to little benefit.
Since 'A' was applying to every row of the table, none was more indented
than any other, except via the inclusion of unadjustable, unbreakable
space escape sequences `\ `, which work just as well with column
classifier 'L' ("left").
In fact, even they are unnecessary; regular spaces will do.
tbl(1):
Ordinarily, a table entry is typeset rigidly. It is not filled,
broken, hyphenated, adjusted, or populated with additional inter‐
sentence space.
...so furthermore convert the escaped spaces to regular ones.
Similarly, 'N' applies several rules to manage alignment of decimal
points. This table doesn't need them. Right-alignment of integers is
just as easily achieved with the 'R' ("right") column classifier.
Comment escape sequences inside table entries can wreak havoc. Use
dummy character instead to visually indicate the deliberate trailing
spaces. Move the comment explaining why they're there closer to what
they document. It's okay to have _whole-line_ comments in table data,
because they are on control lines (lines that start with a dot '.').
Also use the dummy character to indicate deliberately empty table cells.
Issue a livelog/#chronicle message if saving-grace saves the hero.
Right now it's classified as conduct for livelog filtering, because
I didn't want to implement a new category (needs update of global.h
and also the template 'sysconf') and conduct felt like the best fit
of the existing classifications.
Report whether saving-grace is available or already used, among
the attributes of magical enlightenment or end-of-game disclosure.
And move the fixes entry for it from the fixes section to the new
features section of fixes3-7-0.txt.
It seems likely that someone will want to turn not using saving-
grace into a tracked conduct. That seems like overkill to me, not
to mention inflating the N for "N conduct games".
Another byproduct of testing boulder pushing. If you kick a closed
door while polymorphed into a giant, always succeed in breaking the
door instead of maybe getting the Wham! or Thwack! failure result.
Noticed when testing boulder pushing into/out of shops yesterday:
a shopkeeper can "mutter incantations" and fracture a boulder in the
shop, transforming it to rocks. If hero owed shk for the boulder
(happens when it has been further inside the shop and then gets pushed
to the shop's free spot), it would disappear from the shop's bill and
hero would then owe for the resulting rocks (which cost more than the
boulder!). That seemed confusing, especially since neither Iu nor Ix
would show the rocks (which are on the floor rather than in invent;
the $ command reported the amount owed, but not what the item was).
When such fracturing happens move the boulder from the unpaid section
of the shop bill to the used-up section before creating the rocks,
which are no longer interesting.
Issue reported by ars3niy: having a pauper wizard #enhance bare-handed
fighting to basic caused the hero to learn all level 1 spellbooks.
Spellbook discovery for wizards when advancing skills is intentional,
to replace the old Luck-based chance of writing unknown books with
magic markers. (The Luck bias for wizards still applies for scrolls.)
Discovering spellbooks when advancing non-spell skills does feel wrong.
Change it to only happen when advancing spell skills.
This isn't pauper-specific, it's just a lot more noticeable in that
state.
There may be better ways to cope with this, but for the time being I'm
marking the issue 'fixed'.
Fixes#1278
I can't post comments to github but can commit something that will
result in an update of the issue. Hopefully you'll see the commit.
Issue reported by RetepV: using the Macbook option key as an alt
key and using that as a shift with a regular key does not generate
a meta key value for the regular key.
This behavior is not new. I see the same thing on OSX 10.11.6.
The curses interface calls meta(,TRUE) and <option>+key produces
M-key as intended with it. The tty interface can't use that, even
when nethack is linked against a curses library which contains it.
But it should be possible to reproduce the functionality, at least
for some of the paths through the confusing conditional mazes in
sys/share/unixtty.c and win/tty/termcap.c.
However, my attempts to do that have been unsuccessful. Fetching
and sending the termcap 'mm' sequence ('smm' for terminfo) wasn't
enough, tinkering with the internal terminal settings wasn't enough,
nor combining the two. I'm not a UNIX guru so the internals part
was guesswork. And after trying to look at the ncurses source code
in bafflement I've thrown up my hands and given up.
But all is not lost. NetHack's 'altmeta' option can be used to
simulate meta keys. It's intended to support terminals that transmit
<esc> X when you type <alt>+X. But it also allows manually typing
<esc> X (as two separate keys rather than as a shift) when nethack
is waiting for a command. They will be combined into M-X. It works
when positioning the cursor too, so that when using number_pad you
can use <esc> <digit> to move the cursor multiple spots at a time.
'altmeta' deliberately doesn't work when assigning names to objects
or making wishes or various other text entry situations, nor in menus
where <esc> works in the usual way. A potential gotcha is that if
you type <esc> when nethack is waiting for a command, the game will
just sit there until you type another key. That can be another <esc>
since <esc> <esc> is converted into plain <esc> rather than M-<esc>.
Reported by ars3niy, the curses interface could behave strangely on
the first turn if the 'pauper' option/conduct was specified.
There isn't any definitive flag indicating whether or not the game
has started. Since 'moves' has traditionally been initialized to 1
rather than to 0, there were several instances of
| if (moves <= 1 && invent != NULL)
being used to determine the starting state on the assumption that
once hero has inventory, the game has begun. Introduction of the
'pauper' option made the test for non-Null invent become unreliable.
For paupers, the program would behave as if the game hadn't started
yet until the player finally made a time-consuming move.
This changes compile-time initialization of 'moves' from 1 to 0,
then sets it to 1 when initial inventory would be bestowed (even
when 'pauper' inhibits that). That's probably not the best place
for it, but testing for 'moves==0' now should produce an identical
effect as 'moves<=1 && invent!=NULL' used to accomplish.
It would have been much simpler just to give paupers 1 gold piece,
or perhaps one rock, in place of usual starting gear so that their
initial inventory wouldn't be empty, but the moves+invent way of
checking for start-of-play has always bothered me.
Should 'pauper' be preventing 'nethack -X' from giving its starting
wand of wishing? Conducts and explore mode don't really overlap so
maybe it doesn't matter.
Fixes#1275
The old secret door detection just redisplayed locations with
discoveries (secret doors and traps, mostly). Somewhere along the
line it was augmented to find hidden monsters and to deliver one or
two messages reporting how many things had been discovered. Now it
has been augmented again, to find trapped doors and chests, and to
supply a message when the detection attempt fails to find anything.
More substantially, it highlights the relevant locations as they're
found, before the feedback message(s).
Initially I was using tmp_at() to mark all significant locations,
but that required --More-- and for player to acknowledge it when
detection was done. That would probably be ok for wand of secret
door detection and spell of detect unseen, but it would be a hassle
for ^E. It's been revised to use flash_glyph_at() [previously only
used when ^G creates unseen monsters, I think].
The new behavior seems to be working reasonably well. For curses,
the 'timed_delay' option must be set. flash_glyph_at() calls
flush_screen() between its output and nap in each cycle of multiple
flashes, but that evidently isn't sufficient for curses. Maybe
curses init should just force on 'timed_delay'.
I've left the tmp_at() stuff in. We might want to modify things to
use it instead of flash_glyph_at() when the accessibility flag is
set. Its current compile-time selection won't be adequate though.
magic_map_background() would overwrite remembered objects and traps.
That meant discovery of secret corridors by secret door detection
or ^E would forget embedded objects at their locations.
Explicitly sort and label Riders before major demons when displaying
vanquished monsters with sort-by-class. They're lumped in with '&'
but they aren't really demons.
Instead of
" a-z and
" A-Z and
" @&':;
for the lists of characters used to show monsters, followed by
" I
for special "remembered, unseen monster", change the capital letter
line
" a-z and
" A-HJ-Z and
" @&':;
to emphasize that 'I' is used differently from other letters.
Also, add the trailing "and"s to the LaTeX version. I haven't seen
what the result looks like.
Issue reported by ars3niy: a hasted shopkeeper always gets 2 moves
per turn and had a tendency to move away from the door and then move
right back, keeping it blocked.
I didn't view the ttyrec and didn't reproduce the situation, but I
have noticed something of the sort in the past. This reduces shk
speed so that there will usually be 2 moves per turn but not always,
increasing the likelihood of leaving the door unblocked when nearby
hero does not owe anything.
This change results in a slowed shopkeeper having speed dropped to 11
rather than 12. I suspect that the original 18 speed might have been
picked to guarantee slowed speed of at least 12, but if so, that was
in the days when speed 11 would have provided 11 consecutive moves
and then a turn guaranteed to not allow a move rather than the current
11 out of 12 chance to move each turn.
Fixes#1267
From a change made about two and half months ago: eating a pyrolisk
egg tried to use it up from inventory even when it was on the floor.
That would trigger an object lost panic.
When hero was swallowed and a temporary region at swallower's spot
expired, hero was told "the gas cloud around you dissipates". This
just suppresses the message rather than changing it into "the gas
cloud around <engulfer> dissipates".
This fixes the bug where a monster displayed instead of a gas cloud
because the hero was next to it didn't revert to gas cloud when hero
moved and was no longer next to the monster.
Extend paranoid_confirm:trap to also ask for confirmation when
attempting to enter a gas cloud region (scroll of stinking cloud,
breath from green dragons or iron golems, steam clouds from boiling
water, vapor left by fog cloud movement, no doubt several others).
Like with traps, can be overridden for a given move by using the
'm' prefix. Unlike traps, doesn't try to guess whether moving into
a region will be harmless.
Doesn't affect movement into cloud terrain (Plane of Air).
Update the Guidebook to describe the revised behavior of
paranoid_confirm:trap and to mention how #terrain deals with regions.
'any_visible_region()' got mixed in with this but isn't used yet.
Affects extern.h and region.c.
While trying to track down a display problem with regions
[when a monster is shown over a region because the hero is
adjacent, it doesn't revert to the region's cloud glyph when
hero moves farther away; that's not resolved yet],
I discovered a different display problem for the same thing. If
you pick a #terrain choice that keeps traps it is supposed to show
region spots too, but that didn't work when there was a monster at
the same spot. It removed the monster but showed background there.
Issue reported by elunna: none of the display choices for #terrain
offered a way to show the terrain beneath temporary gas/cloud
regions (except "full map" in wizard mode or explore mode). That
prevented the command from being used to find stairs and portals
which had been mapped before becoming covered up.
Adding extra menu choices to deal with visible regions would result
in #terrain becoming a mess. Instead, treat regions as if they were
traps. Picking a choice that includes traps will show region spots
which are in view as cloud or poison cloud, picking one that excludes
traps will show the underlying terrain. Region spots which aren't
within view are handled the same as before: whatever the hero
remembers at their location gets displayed.
The default menu choice excludes traps so will display stairs that are
covered by gas cloud regions, but not portals, same as when no regions
are present. When showing traps and one is covered by a gas cloud,
the trap will be shown rather than the gas cloud, making it possible
to see known portals.
At the moment the new "#terrain handles regions like traps" feature
hasn't been documented anywhere. That might get rectified someday.
I'm not sure whether trap detection ought to also detect regions now.
This doesn't attempt to tackle that and I think that I'll pretend
that the idea never occurred to me.
'parnoid_confirm:traps' definitely ought to prompt for confirmation
when entering a visible harmful region. This doesn't add that.
Bonus fix: it's possible for a visible region to cover up a not yet
explored location. Searching next to such a spot wasn't changing the
spot to be marked as explored (unless hero was blind). Now it will.
Fixes#1262
A recent change accidentally put a dash where a hyphen (default
value for S_golem) is intended. I'm not sure whether verbatim is
necessary here, but it ought to work.
"\(ah" transposed the letters; should have been "\(ha", matching
the actual usage on the same line. Also, the reference to
"circumflex accent" wasn't appropriate since that's the small
caret you get with "^" or "\^".
The description of the default map display was out of date:
Sinks aren't conditional anymore, and were changed from '#' to '{'.
Statues were still listed as '`' but aren't displayed as that.
Room and corridor engravings weren't mentioned.
Wall of water and wall of lava weren't mentioned.
Drawbridge portcullis ('#' when closed) and span ('.' when open)
weren't mentioned.
This splits introductory "- and |" into two entries.
I've forced CR font (similar to TeX's tt font) for the initial
character of all the entries.
The formatting of letters for monsters left something to be desired
so I've tried to redo it. The 'roff edition seems ok (as least when
there's no page break in the middle of it) but I'm not sure how the
LaTeX version will fare. I didn't try to include the trailing "and"
on the first two lines the way the 'roff version does since I wasn't
sure how to accomplish that.
player's input as a comma-separated list of option:value settings
Several compound values that aren't amenable to menus prompt for a
line of input and pass it to parseoptions() as if it came from the
run-time configuration file. That shouldn't be treating commas as
option separators.
The fix is trival, at least for handling the text properly without
introducing new warnings to complain about rejections. Some options
notice an unwanted comma and complain, others don't notice and the
extra text gets ignored.
Issue reported by Meklon2007: some theft feedback during nymph
attacks refers to the attacker as "she" and others as "it" if hero
is blind.
The "she" references are intentional. However, mixing them with
"it" references when a series of messages occurs is jarring. This
changes "it" to "someone", which is still different from "she" but
hopefully enough less so to be tolerable.
That resulted in monkeys also being referred to as "someone" because
they're classified as humanoid. Change x_monnam()'s AUGMENT_IT
handling, which chooses between "someone" and "something" when the
monster is not seen, to override humanoid for animals (affects 'Y'
class) and for mindless (affects zombies, mummies, and golems).
So an unseen monkey will be "it" again.
The final message for current item was relying on a cached monster
name value. If an unseen nymph or monkey stole a worn blindfold
so that hero's vision was restored: "It <stole> item" before the
changes and "Someone|Something <stole> item" after. So update the
cached name if sight gets regained, to give "<Mon> stole <item>."
(If the item is worn armor and the thief is a nymph, it was and
still is "She stole <item>".)
The message for having any worn item be stolen, which got split
into two parts within the past year, was giving "<Mon> takes off
<alt weapon>". When not dual-wielded, the alternate weapon isn't
really worn. Rather than suppress it outright, change the message
for uwep/uswapwep/uquiver to say "disarms" instead of "takes off".
For accessories, change "takes off" to "removes". Those are more
or less interchangeable these days but "removes" matches R instead
of T.
While testing, my pet evidently killed a nymph (I was blinded and
couldn't see it happen) while she stole my gloves and the next
message I got was "You finish taking off your suit." The gloves
weren't worn anymore so equipname() defaulted to suit. Get rid of
equipname() altogether and switch to armor_simple_name() which
doesn't rely on the worn-armor pointers.
Fixes#1257
Implement a couple of missing bits for wall of lava terrain. It was
immune to being distorted by hallucination, unlike molten lava and
wall of water. And the presence of wall of lava made molten lava,
after being shortened to "lava", no longer be listed as something
represented by the "}" character.
I started to renumber S_water, which would eliminate some hackery
from farlook's do_screen_description(), but that will require an
EDITLEVEL increment and make it necessary to reorder/renumber the
corresponding tiles so I stopped short.
This adds NHDT tags to the first line of defsym.h.
If the quest leader observes the hero attacking a peaceful monster,
only become angry if that peaceful monster is a quest guardian. And
when becoming angry, stop waiting for the hero to approach.
If a quest guardian observes the hero attacking any peaceful monster,
don't run away.
When using #loot to put items into a shop-owned container on a shop's
floor, you are asked "Sell it? [ynaq] (n)" for each item, but the 'a'
and 'q' choices only worked as y or n for the current item. By the
next one, the preferred answer had been reset to default and ynaq was
asked again.
Set a flag in use_container() to have in_container() set the sell vs
don't sell state for the first item but not for any others. Reset
the state at the end of use_container() instead of after each item in
in_container().
This bug was present in 3.6.x, also in 3.4.3, and probably earlier.
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.)
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.
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
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.]
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.
