Prior to this commit, there was no good way to deal with swarms of
weak, good-AC enemies using magic; trying to play a wizard as a
pure spellcaster would make bees and ants very difficult to deal
with (because they would usually dodge force bolts).
This commit adds a new spell designed to be very good against
swarms of weak enemies: "chain lightning", which does 2d6 lightning
damage to every monster around you. It has an initially short range,
but can chain from monster to monster to cover potentially large
distances (as long as none of the monsters en route are shock
resistant or tame/peaceful; the spell can't chain past shock
resistant monsters and avoids peacefuls). Monsters within one
space of the visible lightning bolts are affected. Unlike other
lightning effects, this one does only 2d6 damage, not enough to
blind affected monsters.
This commit breaks existing save and bones files (thus the
EDITLEVEL increase).
Features like menucolors and so forth, are now done in the
core, and passed to the window interfaces via add_menu().
TTY_PERM_INVENT was disregarding the passed color value.
That can be turned off by the option !menucolors.
If a way to turn off menucolors in TTY_PERM_INVENT (or
perhaps in any perm_invent implementation), while keeping
it on for other menus, then a new option will be required.
Revise the tty permanent inventory window's in-use mode to be able to
switch back and forth between one full width panel and two side-by-side
half width panels on the fly as needs dictate.
A lot of trial and error involved but I think it has reached a state
where it is reliable, and the smaller number of lines required at
present can probably be viable for actual usage. At the moment it
requires at least 10 extra lines below the standard tty mesg+map+stat
display, 34 lines total for statuslines:2 or 35 for statuslines:3.
The top and bottom of the 10 or more extra lines get drawn as boundary
lines using wall characters, leaving 8 lines for full width or 16 half
lines when 8 isn't enough. If more that 16 items are in use (maybe
lots of lit candles forced into separate inventory slots or a
menagerie on leashes), the excess get skipped. However, it will use
more lines if they are available. Prior to a few days ago it was
requiring 17 extra lines and able to show 15 items as full lines only,
unable to take advantage of more lines when available.
Allow perm_invent to be enabled with 1 less line when statuslines==2
by not reserving a line for statuslines==3. If the player changes
that from 2 to 3, the perm_invent window is torn down and repositioned
one line lower if that will fit. If it won't fit, it won't reenable.
Temporarily(?) allow perminv_mode==InUse to be enabled with room for
only 8 lines instead of requiring 15. It will use more than 8 if are
more rows.
8 happens to be the amount (via 1+21+3+(1+8+1)) that will fit within
35 lines which is the biggest I can make fit on may laptop without
switching to a smaller font. Switching is a nuisance, worse than that
for the font tiny enough to fit the full perm_invent.
ToDo: if in-use won't fit in the number of lines allotted, switch to
two columns before resorting to ignoring the excess.
Maybe: allow fewer lines for full perm_invent too and use the '|'
command to scroll them. Might be too clumsy to be worthwhile.
"engraved part of a room" and "engraved part of a corridor" sound
silly. Change to "engraving in a room" and "engraving in a corridor".
Still displayed to player as just "engraving".
An orhpaned wintype.h tweak got dragged in. Renumbers to_core_flags.
With CLIPPING disabled you should need a terminal or window with at
least 25 lines to change the 'statuslines' option from 2 to 3, but
it was being allowed on tty when there were only 24 lines available.
I think the other interfaces always have clipping capability enabled
so aren't affected.
Not many level maps extend to the bottom row (line 22 for a 1-based
count) so it wasn't likely to be noticed during play. That points
that maps which don't use all rows and/or all columns could get by
without clipping by adjusting their position. However, implementing
adaptive clipping is not something that I'm going to try to tackle.
Issue reported by entrez: on tty, ^C while a menu was open followed
by 'yes' to "Really quit?" would lead to a bad window panic.
Brought on by screen erasure changes included with recent SIGWINCH
(window resize signal) changes.
Closes#1145
'm O' is a prime candidate for using ':' to select a menu item since
you can use that to avoid scrolling through many pages, but typing ':'
would immediately overwrite two or three lines of the menu with a
status refresh. curses doesn't suffer from this problem. X11 and Qt
show menus in separate windows do don't either. Not sure about WinGUI.
I think that this may have been reported in the past, but if so I don't
recall by whom, or why it wasn't addressed.
<color>
off: map, menu items, menu headings, menu prompt/title all, everything should have color suppressed.
<curses guicolor>
on: map, menu items, menu headings, menu prompt/title can all feature color, as can
menu borders, menu-selector letters.
off: map, menu headings, menu prompt and menu items (menucolors on) can still feature color,
but all other non-map features such as menu borders, menu-selector
letters will not have color.
<menucolors>
on: menu items can have colors if they match one of the regex in config
file; menu headings, menu prompt can also be in color (based on menu_headings option).
off: menu items won't have colors, but menu headings, menu prompt still
will feature colors (based on menu_headings option); those are not impacted by turning
off menucolors.
This implements the mechanics to use the ctrl_nhwindow() interface
capability to pass down a setting change from the core to the active
window port, without resorting to accessing a core global variable
from within the window port, and without altering the interface..
The passed setting is honored in the tty and curses window ports.
X11 and mswin receive and store the values, but no implementation
to change the menu prompt style is there yet.
Qt does not store the values or have an implementation.
The setting change is done in allmain.c immediately after
creating the WIN_INVEN window.
Remove menu_color support from the window port side of the interface.
The window port just has to honor the color parameter that was added
to the add_menu() interface definition in June 2022 commit
2770223d10, and let the core-side of
the interface handle things.
To that end, this does the following:
Removes the #define of add_menu() from include/winprocs.h and add a
real core-side add_menu() function to windows.c which acts as a
trampoline to the window port win_add_menu() function, while providing
a single location to adjust the parameters passed to the window port
function. get_menu_coloring() is now called in there.
Moves get_menu_coloring() from options.c into windows.c and makes it
static.
Removes all the calls to get_menu_coloring() from the tty, Qt, X11,
curses, and win32 interfaces and adjusts their code to simply honor
the color parameter in add_menu, similar to what the menu_headings
change from earlier today did.
../win/tty/wintty.c: In function ‘set_item_state’:
../win/tty/wintty.c:1174:9: warning: implicit declaration of function
‘term_start_color’; did you mean ‘term_start_attr’?
[-Wimplicit-function-declaration]
1174 | term_start_color(item->color);
| ^~~~~~~~~~~~~~~~
| term_start_attr
../win/tty/wintty.c:1178:9: warning: implicit declaration
of function ‘term_end_color’; did you mean ‘term_end_attr’?
[-Wimplicit-function-declaration]
1178 | term_end_color();
| ^~~~~~~~~~~~~~
| term_end_attr
Instead of just accepting an attribute, it's now possible to
use a color, or both color and attribute, for example:
OPTIONS=menu_headings:inverse
OPTIONS=menu_headings:red
OPTIONS=menu_headings:red&underline
Default is still just inverse.
This lets the player change the menu heading color without
needing to use menu colors for them.
Also makes it so the core uses NO_COLOR instead of 0, for all
the menu lines which don't have any prefedefined color.
Tested for tty, curses, x11, qt, and win32
With 16x16 tiles on X11 or Qt, I couldn't see the (dark blue?)
engraving marks on either the room engraving tile or the corridor one.
Change those marks to yellow so that the contrast with floor more.
The corrdidor engraving tile was based on the lit corridor tile.
Change that to be midway between the lit (centered solid dot) and
unlit corridor (centered hollow dot) tiles. It no longer directly
matches either one but it also can't sometimes match the wrong one.
Add a new option 'perminv_mode' to augment perm_invent. It handles
the same choices as the temporary TTYINV method: show all items other
than gold, show full inventory including gold, or only show in-use
items (similar to the '*' command).
For tty, both the all-except-gold and full-inventory modes can add
the poorly named 'sparse' variation which populates unused slots in
its fixed grid with the inventory letter that would go in each.
For others, the default has been changed from full-inventory to
all-except-gold. Note that gold is treated as part of 'all' or of
'in-use' if it is quivered because having the amount be shown on the
status line doesn't make that redundant.
Changing the default may mess up WinGUI if it assumes that perm_invent
is full inventory with gold.
Initially I was going to change perm_invent into a compound but this
leaves it as an on/off toggle and adds perminv_mode as a separate
option for how to show the inventory when the toggle is on. It may
make sense to combine them since dual controls is a little confusing,
but right now setting perm_invent On when perminv_mode is 'none'
changes that to 'all' and changing perminv_mode away from 'none' when
perm_invent is Off toggles it to On.
Guidebook.mn has been updated but as usual Guidebook.tex is lagging.
If there's room, avoid writing the column indicator (when one or more
entries have been truncated due to insufficient window width) on an
entry. Only applies to first page so only matters if sortpack is off.
Also, for windowborders=3 or 4, where the map, message, and status
windows have borders but the perm_invent one doesn't, insert a blank
line at the top when there is only one line of output (such as "not
carrying anything") so that it lines up with the top line inside the
adjacent window rather than with that window's top border. No effect
when perm_invent itself has a border or when none of the others do.
Pull request from bernhardreiter: NetHack.ad has a comment about
needing to use an external tool such as XV or PBMplus rather than
the NetHack.double_tile_size resource if nethack is built with the
USE_XPM configuration. Add some more detail since using 'hints' when
setting up the Makefiles can define that behind the builder's back.
The extra detail won't be useful to players who obtain prebuilt
binaries that incorporate the X11 interface. The comment in config.h
(see preceding pull request) won't be either, and maybe should be
moved to NetHack.ad where such users will be able to see it.
Fixes#1114.
Menus in the curses interface would honor a digit as a selector
character ("letter" :-) for PICK_ANY menus but forced it to start a
count in PICK_ONE menus. This fixes that, although the menu where I
was using digits as selectors (not included) has been changed to use
letters so this fix isn't being exercised anymore.
Also, add a couple of comments about persistent inventory.
Gold can be quivered but not wielded, so remove the reference to the
latter. Inuse-only mode gets passed lamps and leashes when they're
actively used, so remove the reference to that being different from
Qt's paperdoll. (It is actually different, but not because they
won't be shown as in-use. The paperdoll only shows one of each but
inventory of in-use items might have more than one of either or both.)
Add a what-if comment to tools_in_use().
and reimplement 'sparse' mode (TTYINV=2 or TTYINV=3).
When hero had no inventory except for gold and perminv display mode is
ignoring gold, the header said "empty" when "only gold" was intended.
Sparse mode populates perminv with inventory letters in the unused
slots instead of leaving them blank. (The core doesn't need to be
aware of that since it doesn't affect what display_inventory() sends
to the inventory menu.)
My repository got out of synch and I had a hell of a time restoring
sanity.
The most recent commit included a line in wintty.c that shouldn't have
been there.
Some changes I made while chasing the slots 'A' and 'B' bug. These
weren't necessary to fix that and I don't think they produce any
change in behavior, aside from making the "Bad window id N" panic
be more specific if it occurs.
The problem with tty perminv slots 'A' and 'B' boiled down to
slot_limit = SIZE(slot_tracker); /*54*/
...
/* blank out unused slots */
for (slot = 0; slot < slot_limit; ++slot) {
...
row = (slot % rows_per_side) + 1; /* +1: top border */
side = slot < rows_per_side ? 0 : 1;
ttyinv_populate_slot(row,side,...);
}
Unused slots [52] and [53] (available for show_gold mode to display
"$a..zA..Z#", not filled with inventory for normal tty perm_invent
"a..zA..Z") yielded rows 1 and 2, side 1, so clobbered slots 'A' and
'B' with blanks.
This is a subset of the changes I was working with and didn't get as
much testing as the full set.
It turned out that using '^' as a group accelerator (new behavior for
the 'whatis' command to view traps) already worked for curses and Qt.
Fix that for tty and X11. I don't know the situation for WinGUI.
Offering any of the menu paging keystrokes as group accelerators
should be avoided if there's any chance that the menu will need more
that one page. The menu for '/' is short though so losing "^ to go
back to first page" for it isn't an issue.
Rest of 'not PR #1102'. Resizing the terminal while getpos was in
operation recalculated the map from scratch instead of redrawing what
the core considers to already be shown. And it was always operating
while an asynchronous signal was excuting which could potentially
clobber whatever was running at the time the signal arrived.
This uses same redrawing as the prior '^R during getpos()' fix. It
also only performs the resize while tty_nhgetch() is waiting for
input. If that is the situation at the time that the signal arrives
then it will resize immediately (while in the asynchronous signal
handler); if not, it will set a flag and tty_nhgetch() will do the
resize the next time it gets called.
This builds with TTY_PERM_INVENT enabled and doesn't seem to be any
worse than before, but there are bugs with that. The only way I could
get perminv to appear was to save and restore, then perm_invent was
honored for both RC file and mO command. And once I managed to get it
to display, moving an item from a lower case slot to slot 'A', made
that item vanish; nothing appeared in the invent's right hand panel.
Both of those misbehaviors already happen prior to this commit. I
also saw an abort+panictrace if I resized while at the "Dump core?"
prompt when running the pre-commit code and didn't see that with the
post-commit code (although the prompt wasn't shown so I couldn't tell
that it was waiting for an answer). The abort probably sounds scarier
than it warrants; I suspect that the pre-commit code just treated the
resize as answering 'y' for some reason, possibly a stale value in the
variable it uses.
This fixes the part of pull request #1102 by entrez dealing with the
map refresh side of things. It was pulled out of a much larger patch
that also deals with terminal window resize for tty.
Using ^R when getpos() is in operation, whether actually picking a
position for something or browsing the map during #terrain or post
detection magic, it was reconstructing the known map and positioning
the cursor on the hero instead redrawing the selected terrain subset
or detected objects/monsters/whatever. There's already a routine to
redraw the current view of the map without recalculating it, but it
wasn't being used for ^R during getpos operation.
Clipping mode was not activated when a comfortably-sized game window was
resized horizontally to become too narrow to display the entire map,
causing various display errors and bugs if the window was resized like
that. I think the horizontal resize check was removed by mistake in
d1dade164e.
