PatR [Mon, 15 Mar 2021 08:05:19 +0000 (01:05 -0700)]
curses perm_invent comment
Stripping article ("a ", "an ", "the ") off inventory items to
squeeze a little more info into truncated persistent inventory
was initially case insensitve. That was removed because it isn't
needed but the comment still reflected it.
PatR [Sun, 14 Mar 2021 22:18:24 +0000 (15:18 -0700)]
genocide failure for already genocided creature
Reported seven years ago: when class genoicde (blessed scroll)
attempts to genocide something that has already been wiped out
|All foos are already nonexistent.
should be simplified to
|Foos are already nonexistent.
I think the redundant "All" was just there to avoid capitalization
handling for the monster species but that's trivial to deal with.
PatR [Sun, 14 Mar 2021 02:18:53 +0000 (18:18 -0800)]
\#perminv, 2 of 2: implementation
Add new '|' command, aka #perminv, which allows the player to
send menu scrolling keystrokes to the persistent inventory window.
Implemented for X11, where its usefulness is limited, and for
curses, where it is more needed and also more fully functional.
The interface can either prompt for one keystroke, act upon it,
and return to normal play, or it can loop for multiple keystrokes
until player types <return> or <escape>. X11 does the former if
the 'slow' application resource is False so that prompting uses
popups, and the latter when 'slow' is True where prompting is in
a fixed spot and doesn't end up causing the persistent inventory
window to be stacked behind the map window. curses always does
the loop-until-done approach. It also accepts up and down arrow
keys to scroll one line at a time.
Also adds two new menu scrolling commands, menu_shift_right (key
'}' by default) and menu_shift_left ('{') if wincap2 flags contain
WC2_MENU_SHIFT. Shifting allows different substrings of too-long
lines to be seen.
For X11, neither works because their handling requires a horizontal
scrollbar and for some reason that escapes me our menus don't have
one of those. If they did, shifts could work for all menus but a
shifted window would hide the selection letters. So shifting would
be most usefully done as: pan right, read more of any long lines,
immediately pan back to the left.
For curses, they only apply to the persistent inventory window.
Shift right redraws it with class headers and inventory letters
shown normally but the item descriptions omit their leftmost
portion, showing more text towards the end. Shift left reverses
that and does nothing if the beginning is already in view. Forward
and backward scrolling while shifted leave the shift in place.
PatR [Sun, 14 Mar 2021 02:17:00 +0000 (18:17 -0800)]
\#perminv, 1 of 2: groundwork
Give the window-port side of *_update_inventory() an argument.
Calls in the core still omit that; invent.c's update_inventory()
is the only place that cares.
PatR [Sat, 13 Mar 2021 02:06:43 +0000 (18:06 -0800)]
scrollbar handling by X11
Looking up scrollbars did not work as intended. The code wanted an
ancestor widget that had both horizontal and vertical scrollbars,
but menus either have none or just vertical. The lookup code found
some top level widget and returned bad data.
PatR [Wed, 10 Mar 2021 20:28:09 +0000 (12:28 -0800)]
options key parsing
OPTIONS=menu_previous_page:\mv
BINDINGS=M-v:menu_previous_page
both worked, but
OPTIONS=menu_previous_page:M-v
BINDINGS=\mv:menu_previous_page
both failed. Make all four variations work. Tiny change made large
by the need to move some things around.
The option definition for menu_first_page had a couple of its flag
bits swapped. I didn't try to figure out whether that had any impact.
PatR [Wed, 10 Mar 2021 19:22:22 +0000 (11:22 -0800)]
fix a couple of options affecting perm_invent
When the 'O' command is used to change either 'menu_headings' or
'sortloot', inventory display can change so persistent inventory
needs to be updated.
Oddly, the flag to indicate initial options processing remained
True after options had been processed, but that ultimately didn't
matter here. It's fixed now anyway.
Also, sort the WC2_xxx options in a couple of places.
PatR [Tue, 9 Mar 2021 15:45:58 +0000 (07:45 -0800)]
signal induced panictrace under curses
When panictrace feedback occurs due to catching a signal rather
than controlled panic, the backtrace is useless when running the
curses interface unless the terminal gets reset first. Let's
just hope that the signal triggering a panictrace doesn't occur
while resetting the terminal.
PatR [Sun, 7 Mar 2021 23:08:08 +0000 (15:08 -0800)]
fix #K3274 - applied polearm locates hidden mon
without using any time. Targetting an apparently empty spot at
valid polearm range where a monster happens to be hiding reports
"Wait! There's something there you can't see!" and displays the
remembered, unseen monster glyph, then aborts the attack attempt.
It would use a turn if the polearm became wielded in the attempt
but not if it was already wielded. Make latter case take time.
PatR [Fri, 5 Mar 2021 02:07:23 +0000 (18:07 -0800)]
blinded Archon gaze bit
From yesterday (old #H3841), the alternate message given when a
monster is being hit by a blind Archon's gaze was checking the
wrong monster for blindness.
PatR [Wed, 3 Mar 2021 23:03:31 +0000 (15:03 -0800)]
discoveries/#known sorting fix
If the sort order for sortdiscoveries was s ('sortloot' order)
and any artifacts or unique items were discovered, using '\'
to see all discoveries included "Discovered Items" as a spurious
class header between the real header for the last object class with
discoveries and the discoveries for that class:
|Discoveries, sortloot order (by class with some sub-class groupings)
|
|Artifacts
| Sunsword [lawful long sword]
|Potions
| water (clear)
|Gems/Stones
|Discovered items
| diamond (white)
| flint stone (gray)
"Discovered items" is supposed to only be shown when sorting
alphabetically across all classes and there are artifacts and/or
unique items before the regular discovered objects.
PatR [Wed, 3 Mar 2021 22:40:19 +0000 (14:40 -0800)]
fix #H3841 - inconsistent Archon gaze behavior
From six years ago: hero is "blinded by the Archon's radiance"
even if the attacking Archon has been blinded, but monsters hit
by same thing were protected from it by that blindness. Make
monsters attacked by Archons be affected similarly to the hero.
Hypothetical case of hero-as-Archon versus monster is ignored
because hero can't polymorph into that shape.
PatR [Sun, 28 Feb 2021 01:13:17 +0000 (17:13 -0800)]
hypothetical buffer overruns
doprtool() and doprinuse() collect the inventory letters of all
applicable items into a buffer capable of holding 52 letters plus
terminator. It is possible to have more than 52 items (ignoring
gold) so theoretically possible to have more than 52 separate lit
candles. Guard against that.
The easiest way to get an item in the overflow slot is to carry
52 non-boulders, polymorph into a giant, and pick up a boulder.
Assigning the latter to one of the three weapon slots would not
impact doprtool() but it will impact doprinuse(). However, that
wasn't enough to cause a crash for me; evidently the overflow
clobbered something innocuous. (52+boulder is not the only way
to get something into slot '#', just the only guaranteed one I
can think of offhand.)
This also removes a bunch of 'register' type qualifiers.
PatR [Sat, 27 Feb 2021 01:06:40 +0000 (17:06 -0800)]
X11 menu handling
In a couple of places, call menu_popdown instead of duplicating
its contents. I'm fairly sure that executing the is_active bit
that the duplications omitted is safe.
nhmall [Fri, 26 Feb 2021 14:05:52 +0000 (09:05 -0500)]
read_simplemail() when SERVER_ADMIN_MSG is defined
Some warnings were mentioned
Add a prototype ahead of the function
Use a non-const copy of SERVER_ADMIN_MSG
quick-tested by:
- uncommenting the following in include/unixconf.h
/* #define SERVER_ADMIN_MSG "adminmsg" */
- building NetHack
- creating a test message:
echo "server_admin: system is going down at 2 pm" >~/nh/install/games/lib/nethackdir/adminmsg
- playtested and received the desired message
PatR [Fri, 26 Feb 2021 08:13:22 +0000 (00:13 -0800)]
fixes37.0 entry about engraving
Revert part of commit f6a30e7b05c9e45b58a8410afb9daf6b7c599180
that moved a fixes entry from the 'fixes to 3.6.x' section
into the 'post-3.6.x, exposed by git' section. It wasn't due
to the conversion of engraving from multi-turn action into an
occupation, it was fixing a bug that had been around for 5 or 6
years. Moot now; the conversion to occupation removed it.
PatR [Wed, 24 Feb 2021 22:41:51 +0000 (14:41 -0800)]
tribute bit: Sourcery passage 4
Fix a mistake that led to a bad fix for a perceived mistake that
wasn't really there.
I think having a comma after "moment" would make things clearer,
but style-wise that's optional and leaving it out restores the
book's original wording.
PatR [Mon, 22 Feb 2021 01:30:09 +0000 (17:30 -0800)]
X11 popup yn_function resizing
When X11_yn_function() re-uses a popup widget to issue a prompt
and get the player's response, make it resize properly. I'm not
sure why the old hack for that apparently worked for some folks
and not for me, or why this does work for me. At least it does.
Also, make the minimum popup width be 25 characters so that
really short prompts don't result in tiny popups. Since the
popup appears at whatever spot the pointer happens to be sitting,
it isn't always immediately noticeable when the player is using
the keyboard rather than the pointer.
PatR [Sun, 21 Feb 2021 01:24:25 +0000 (17:24 -0800)]
"If you see me running, try to keep up."
Noticed while poking about in read.c for the ^G feedback change:
a relatively recently added apron slogan turns out to be a near
duplicate of an existing T-shirt slogan. Change the apron one a
little, although they're still nearly identical.
PatR [Sun, 21 Feb 2021 01:15:58 +0000 (17:15 -0800)]
^G feedback
For ^G, if someone replies with empty input to the "Create which
monster?" prompt, give alternate feedback than "I've never heard
of such monsters." before reprompting.
PatR [Sun, 21 Feb 2021 00:25:12 +0000 (16:25 -0800)]
X11 getline refinement
X11_getlin() echoing its prompt and response to message window
truncates combined value to maximum allowed pline (rather than
having pline truncate it). But it was truncating the response
as if the prompt was maximum allowed length instead of its actual
length, so possibly hiding some of the user's text unnecessarily.
PatR [Fri, 19 Feb 2021 23:38:31 +0000 (15:38 -0800)]
X11 getline: log prompt and response
After player has responded to a getline prompt, echo the prompt
and the line of text response to the message window. Uses pline()
so also gets put into core's message history for dumplog.
PatR [Fri, 19 Feb 2021 22:11:32 +0000 (14:11 -0800)]
X11 update
More issues. The incorrectly rendered map after panning is one
I haven't seen before. Normally I only have a clipped map if I
force double size tiles rather and hadn't noticed this behavior
for that case, so manually resizing--and/or the scrollbars which
get added when that occurs--may be what triggers it.
copperwater [Thu, 18 Feb 2021 23:55:10 +0000 (18:55 -0500)]
Convert room 'joined' and 'needjoining' into booleans
des.region() accepted booleans for the joined field, whereas des.room
accepted xchars. These were only being used as truth values, so this
converts the room ones into booleans for consistency. I don't think
accidentally using an int or a boolean wrongly would actually crash the
level generator, but consistency is good.
This converts an schar field in struct mkroom into a boolean; on most
systems these are probably 1-byte types and save files won't be broken,
but it might be best to treat this as a save breaker anyway.
PatR [Fri, 19 Feb 2021 07:54:30 +0000 (23:54 -0800)]
'wizmgender' flag
"Demote" wizmgender from an obscure wizard mode extended command
to an obscure wizard mode boolean option. Behaves the same except
that no message is given when the value gets toggled.
copperwater [Fri, 19 Feb 2021 05:25:45 +0000 (00:25 -0500)]
Fix: engraving with non-blade dulled the weapon anyway
Due to a logic bug introduced when engraving became an occupation - the
code that tests to see whether the player is writing with a weapon that
will get dulled wasn't correctly checking that they were actually
carving an engraving.
PatR [Wed, 17 Feb 2021 22:27:00 +0000 (14:27 -0800)]
fix github issue #462 - line not displayed
Fix a latent bug in unreachable code. As the comment preceding
the cited code states, hero polymorphed into an eel isn't offered
a chance to use #monster to hide, so program execution won't ever
get to the bad code. Using formatting routine The() where message
delivery routine pline_The() is intended is certainly a bug though.
PatR [Tue, 16 Feb 2021 03:09:00 +0000 (19:09 -0800)]
X11's yn_function() echoing its response
X11_yn_function() issues a pline() to put the prompt and player's
response into the message window. Change it to use visctrl() to
make sure that the response character is ledgible when something
like the '&' command allows an arbitrary answer.
This patch adds a leading space and two extra trailing spaces
to the prompt when it's being issued via popup, but that hasn't
affected the issue mentioned next....
The popup prompting when the 'slow' resource is False doesn't
always resize properly. I saw both too wide and too narrow
[What do you want to throw? [abc] ]b
[ In what direction? ]
and
[Really quit? [yn] (n) ]y
[Dump core? [ynq] (q) ]n (size seemed right, but hard to tell)
[Do you want your posses] (might have shown one more letter;
resize doodad in window's bottom right
corner on OSX oscures the rightmost
column--which is ordinarily a space)
The truncated one did accept responses. If I answered 'n' then
the next question was truncated too, but for 'y' (plus ensuing
feedback) it would be sized correctly for the question after that.
To be clear: the popup width issue was present before this change
and is still present after it. The code already has a hack that's
intended to deal with this but it doesn't do the job for me.
PatR [Sun, 14 Feb 2021 08:57:34 +0000 (00:57 -0800)]
X11 persistent inventory again: initial display
If 'perm_invent' is preset in player's options, have X11 show the
persistent inventory window from the start instead of waiting for
an 'i' command. moveloop() prolog needed a tweak do deal with it
cleanly.
Require WC_PERM_INVENT in order to honor the perm_invent option.
X11 and curses already set that, tty and curses don't support it,
so only Windows GUI needed to be updated for it.
PatR [Sun, 14 Feb 2021 03:17:20 +0000 (19:17 -0800)]
X11 perm_invent: handle 'O' toggling off perm_invent
When persistent inventory window is up, remove it if 'perm_invent'
option gets set to False. This has a side-effect of fixing the
end-of-game prompting problem it caused.
PatR [Sat, 13 Feb 2021 23:15:21 +0000 (15:15 -0800)]
scatter() vs sinks
Objects shot, thrown, or kicked by the hero or by monsters stop
short if they try to pass over a sink; make objects launched by
an explosion behave similarly.
PatR [Fri, 12 Feb 2021 23:07:51 +0000 (15:07 -0800)]
X11: persistent inventory issues and hack for OSX
This hack prevents the perm_invent window for X11 on OSX from
creeping every time it gets updated. It is far from perfect and
at the very least ought be handled via user settable X resources
rather than hardcoded values, but it's as much effort as I'm likely
to spend.
Add a new file containing a list of issues that ought to be fixed.
The initial entries are things I noticed while experimenting with
perm_invent; there is lots of older stuff that could/should be
there too. I'm not sure whether the first one is OSX-specific; the
others aren't.
PatR [Thu, 11 Feb 2021 23:18:12 +0000 (15:18 -0800)]
mklev.c's mkroom qsort
Get rid of some obsolete qsort hackery. Use of prototypes makes
it unnecessary. Even before that it was the only one of a dozen
instances of qsort() usage that cared about pre-ANSI implementation.
Pasi Kallinen [Thu, 11 Feb 2021 16:22:14 +0000 (18:22 +0200)]
Don't complain about unknown option if param is wrong
When a compound option was given an erroneous parameter,
for example "OPTIONS=runmode:foo",
you first got "Unknown runmode parameter 'foo", and
then "Unknown option 'runmode:foo'".
Prevent the Unknown option complaint, if we actually did
find a match.
PatR [Thu, 11 Feb 2021 02:48:21 +0000 (18:48 -0800)]
nroff Guidebook fix
Options which show lists of possible values using '.CC' were
unintentionally being rendered with bold font. I tracked it
down to "figure 3" which has been in place for quite a while.
The font setting and resetting wasn't working as I expected.
This change yields the intended results.
PatR [Tue, 9 Feb 2021 23:07:16 +0000 (15:07 -0800)]
wiz_identify vs perm_invent
Using ^I to identify inventory and picking '_' (or '^I' or full
menu) would update persistent inventory window after identifying
everything, but picking specific items (even everything as long
as '_' was excluded) to identify wasn't doing that.
I moved some fixes37.0 entries around to group the persistent
inventory ones together. One involved hold_another_object so I
group those too. I didn't look very hard to try to find others
that could fit with these.
PatR [Tue, 9 Feb 2021 00:34:29 +0000 (16:34 -0800)]
curses persistent inventory window tweak
Under curses interface, provide a way to get a little more space
for perm_invent without turning off windowborders entirely.
Possible 'windowborders' values:
0 = no borders, max screen space available for useful info
1 = full borders, two lines and two columns wasted for each window
2 = contingent borders, show if screen is big enough, else hide
New:
3 = as 1 except no borders for perm_invent window
4 = as 2 except never borders for perm_invent window
3 and 4 let the map, message, and status windows have borders while
providing two extra lines and two extra columns on each line for
persistent inventory. It's not much but better than nothing when
borders are enabled.
PatR [Mon, 8 Feb 2021 21:16:54 +0000 (13:16 -0800)]
plug config file parsing memory leak
The new options processing had a memory leak: 'parser.inbuf'.
Also, reorder some routines to fit in the corresponding comment
sections (with new sections for wizkit and symset) and reorder
some prototypes to match their order in the file.
nhmall [Mon, 8 Feb 2021 13:41:23 +0000 (08:41 -0500)]
make engraving an occupation pr#460
copperwater commented 8 hours ago:
Instead of inexplicably paralyzing the player for the duration of their
engraving. Many a character has died by trying to engrave something and
then sitting there diligently writing it while monsters surround and
attack them. (This was especially prominent back in the 3.4.3 era when
repeated Elbereths were viable, but it still occurs today with e.g.
using a hard stone to engrave Elbereth). There were also some other
oddities - for instance, if something teleported the player away while
they were engraving, they would continue to "engrave" (be paralyzed) on
their new location, but would not produce any text there; the full
engraving would be placed on their initial position.
In this commit, I have converted engraving to use the occupation
framework, which treats it as an interruptible activity. This
necessitated some logical restructuring, mostly involving the engraving
being written out in chunks as the player spends more uninterrupted time
on it.
I've tried to keep this free of regressions except for those inherent to
the occupation system.
What has NOT changed:
o The rate of engraving is still 10 characters per turn, or 1 character
using slow methods.
o The formulas for determining how much a bladed weapon or marker can
engrave before getting exhausted are kept. Though this is a bit
convoluted, and if it's not considered important to preserve the
existing behavior, I would recommend simplifying it by decreasing the
maximum engraving length for weapons by 1 so that each point of
enchantment simply gets you 2 characters' worth of engraving (e.g. a
-2 weapon will only engrave 1 or 2 characters before dulling to -3,
rather than giving it a third "grace character".
o The input buffer is still modified based on confusion/blindness/etc
only at the time when the player inputs it (if they gain a
debilitating status while engraving, it will not affect the text). My
personal preference is to make the text affected in scenarios like
that, but it's not strictly necessary to do here, so I didn't.
o Wand messages such as "The floor is riddled by bullet holes", and
blinding from engraving lightning, still appear before the hero starts
to take any time engraving. As noted above, getting blinded by the
wand still has no effect on accurately engraving the text, unless the
hero was already blind or impaired.
What has changed:
o Moving off the engraving or losing the object being engraved with
causes the player to stop engraving.
o Wands can still engrave an arbitrary amount of text using a single
charge, but if the hero is interrupted and decides to start engraving
again, they will consume a second charge.
As it adds a new field to g.context, this is a save-breaking change.
copperwater [Mon, 8 Feb 2021 04:21:31 +0000 (23:21 -0500)]
Make engraving an occupation
Instead of inexplicably paralyzing the player for the duration of their
engraving. Many a character has died by trying to engrave something and
then sitting there diligently writing it while monsters surround and
attack them. (This was especially prominent back in the 3.4.3 era when
repeated Elbereths were viable, but it still occurs today with e.g.
using a hard stone to engrave Elbereth). There were also some other
oddities - for instance, if something teleported the player away while
they were engraving, they would continue to "engrave" (be paralyzed) on
their new location, but would not produce any text there; the full
engraving would be placed on their initial position.
In this commit, I have converted engraving to use the occupation
framework, which treats it as an interruptible activity. This
necessitated some logical restructuring, mostly involving the engraving
being written out in chunks as the player spends more uninterrupted time
on it.
I've tried to keep this free of regressions except for those inherent to
the occupation system.
What has NOT changed:
- The rate of engraving is still 10 characters per turn, or 1 character
using slow methods.
- The formulas for determining how much a bladed weapon or marker can
engrave before getting exhausted are kept. Though this is a bit
convoluted, and if it's not considered important to preserve the
existing behavior, I would recommend simplifying it by decreasing the
maximum engraving length for weapons by 1 so that each point of
enchantment simply gets you 2 characters' worth of engraving (e.g. a
-2 weapon will only engrave 1 or 2 characters before dulling to -3,
rather than giving it a third "grace character".
- The input buffer is still modified based on confusion/blindness/etc
only at the time when the player inputs it (if they gain a
debilitating status while engraving, it will not affect the text). My
personal preference is to make the text affected in scenarios like
that, but it's not strictly necessary to do here, so I didn't.
- Wand messages such as "The floor is riddled by bullet holes", and
blinding from engraving lightning, still appear before the hero starts
to take any time engraving. As noted above, getting blinded by the
wand still has no effect on accurately engraving the text, unless the
hero was already blind or impaired.
What has changed:
- Moving off the engraving or losing the object being engraved with
causes the player to stop engraving.
- Wands can still engrave an arbitrary amount of text using a single
charge, but if the hero is interrupted and decides to start engraving
again, they will consume a second charge.
As it adds a new field to g.context, this is a save-breaking change.
Dean Luick [Mon, 8 Feb 2021 04:25:25 +0000 (22:25 -0600)]
Re-fix altar compiler warning
Implement a better fix for commit 2f4f7d22d ("Fix align type
mixup wth align mask") which was reverted in commit 4e35e8b5a
("Revert "Fix align type mixup wth align mask"").
In the present code, the field align in both struct altar and
struct monster is not an aligntyp, but an align mask with extra flags.
Change the type to match its actual use and improve the naming.
Consolidate duplicated code into a single routine.
Change the return type of induced_align() to be unsigned to match
amask usage.
Change the special level align mask values to be separate from
the normal align mask values.
PatR [Sun, 7 Feb 2021 22:58:08 +0000 (14:58 -0800)]
display_pickinv
A formatting bit that grew a little. An end of line comment that
spans on two or more lines
foo(); /* call
foo() */
will confuse clang-format if the continuation lines don't begin
with an asterisk
foo(); /* call
* foo() */
Instead of just doing that, I changed display_pickinv() to add a
comment for each of its arguments.
PatR [Sun, 7 Feb 2021 00:34:41 +0000 (16:34 -0800)]
potion dipping tweak
Update some code from four weeks ago. One of two hold_potion()
calls was followed by update_inventory() but the other wasn't.
Have hold_potion() do that itself. I'm not sure that this is
needed and haven't convinced myself that it's not.
PatR [Sun, 7 Feb 2021 00:04:44 +0000 (16:04 -0800)]
partial fix for #K3262 - X11 perm_invent panic
Prevent the "X Error (bad Atom)" situation that causes an
"X Error" panic.
The issue isn't fixed. This fails to implement the intended
functionality of having the X server remember the persistent
inventory window's location across games (until the next time
that the X server restarts). Worse, on OSX the window creeps
each time it is updated (visually it seems to be moving down by
the height of the window's title bar).
That's not as bad as having it move to the pointer's location as
it did in 3.6.1, but prior to the commit which introduced this
code that had been fixed and it stayed put during the current
game, so more work is definitely needed.
/* Chop engraving down to size if necessary */
if (len > maxelen) {
for (sp = ebuf; (maxelen && *sp); sp++)
-> if (!isspace(*sp)) maxelen--;
if (!maxelen && *sp) {
*sp = (char)0;
if (multi) nomovemsg = "You cannot write any more.";
was changed to:
/* Chop engraving down to size if necessary */
if (len > maxelen) {
for (sp = ebuf; (maxelen && *sp); sp++)
-> if (*sp == ' ') maxelen--;
if (!maxelen && *sp) {
*sp = (char)0;
if (multi) nomovemsg = "You cannot write any more.";
PatR [Fri, 5 Feb 2021 09:04:48 +0000 (01:04 -0800)]
curses: honor menu_next_page/&c option settings
tty and X11 honor the menu_xxx options. Qt currently doesn't
support menu manipulation by keyboard. curses does support that
but was only handling the default menu keys.