If hero survives a killing blow via saving-grace, report that to
livelog but hide it from player's own #chronicle.
Only reveal whether saving-grace was used up during end-of-game
disclosure. Omit that during enlightenment unless running in
explore mode (or wizard mode).
Sanity check failure generated by running the fuzzer, reported
by mkuoppal. The check discovered that the hero's current hit
points were greater than the maximum.
Comments by elunna pointed out where the problem most likely was,
and this attempts to fix the situation, but without a test case
I can't be sure that the fix works.
Both cases being fixed are for formerly fatal incidents (random
chance that poison is fatal, monster touch of death spell) being
'softened' to heavy HP damage (including reduction of maxHP).
The earlier commit I made (045d608) was done without having seen
the relevant comments. It didn't fix anything but did attempt
to make finding the problem(s) easier. It wasn't much help.
Fixes#1252
I don't always want to abort() on an impossible() when debug_fuzzing,
especially if the first impossible() encountered isn't related to the
bug I'm in the midst of trying to hunt down.
I often have breakpoints on impossible() anyway, and I'd like a simple
way to avoid the panic() call during a lengthy debug session.
Make iflags.debug_fuzzer an xint8 instead of a boolean.
Call abort() only if iflags.debug_fuzzer is set to 1.
That allows setting iflags.debug_fuzzer to 2 in order to bypass the
abort call, and make use of other breakpoints that have been set
to narrow down a particular issue.
First noticed this when watching someone livestream, and managed
to figure it out from there: The window that pops up when looking
at a pile of objects under you by pressing ':' is marked as a menu,
but has no selectable options. Curses still allowed you to use the
menu-search command (':') on it.
Prevent the menu search command in windows with no selectable entries.
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".
I've been investigating issue #1252 (while the fuzzer was running,
sanity_check complained that hero's current health was greater
than maximum health) off and on for three months and haven't found
the cause.
I've checked all the places that lower maximum HP that I've managed
to find, but not spent much time looking for places that raise
current HP.
These changes might provide some more information. They don't rely
on sanity_check being enabled.
Issue #1252 is still open.
Take care of most of include/*.h. I punted on extern.h.
For both src/*.c and include/*.h, I used mismatched checks of
width > 79 to decide which files to look at and then width > 78
to decide which lines to maybe revise, so I didn't look at a bunch
of the files.
I don't plan to go back and do it right. Shortening lines that are
80 or wider to less than 80 is the significant part. Otherwise
emacs puts a backslash in column 80 and the rest of the line of text
on the next line of the screen, making things harder to read.
I recently realized that I've been editing sources in a terminal
window that was widened in order to fit curses borders for testing
something or other. That has resulted in some new wide lines in the
source. There were lots of old ones too.
This updates some source files to try to achieve the goal of 78
characters or less. As in the past, I've been inconsistent about
lines with 79 characters. Lines with 80 or more have been wrapped
or shortened (usually by trimming an end of line comment or removing
redundant parantheses, sometimes just by reducing the indentation
of the continuation portion of an already wrapped line).
I eliminated one instance of warning manipulation for non-constant
format string, and simplified stone_luck() where Ken had a silly
comment about the function argument's name.
Since wand of secret door detection now gives feedback even when it
fails to find anything, always discover it.
Some of the other zapnodir() wands had suspect discoveries.
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.
The report is for 3.6.7: pushing a boulder into a general store adds
it to shop's inventory, but pushing it back out lets player remove it
for free. 3.7 has already fixed this; update its comments though.
Pull request from argrath: change a couple of places in moverock()
to use moverock_done() and return early rather than use break to fall
to the end.
Closes#1272
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
This makes custom S_sw_tc etc. from Enhanced1 symset actually work,
yielding nice smooth outlines for swallowers and explosions. Or so I
think, I have only tested the former because when playing locally,
explosions disappear so fast I cannot see them.
While looking at where else glyph_to_swallow was used, I noticed that
parse_id subtracted S_sw_tl from glyph_to_swallow, even though it
returns 0 to 7. This looks like it would cause out-of-bounds access and
perhaps a segfault when trying to customise glyphs for individual
monster swallow glyphs (or whatever it is parse_id is used for), but
I haven't tried to confirm nor change this because who would ever do
such thing?
Even if nethack is meant to support compilers that do not know about
inline functions, this one was frankly too long to be a macro already,
and I'm about to make it longer still.
For 'pauper', most roles start without any skills. However, strong
fighter types were starting with basic bare-handed combat/marital arts,
giving them a big advantage. Knights were starting with basic riding,
which is probably useless now that they have to acquire a saddle to
use it (see below). Take those initial skills away, producing an even
playing field.
Non-paupers get their initial skills without needing to spend any skill
credits (aka slots) on those. Give paupers 2 starting credits that
they'll be able to use once they acquire suitable weapons or spells
and train them up, so that once they're reasonably developed they won't
lag in skills compared to non-paupers.
Pauper knights were still starting with a saddled pony. Suppress the
saddle when the knight is a pauper.
Wizards start knowing a lot of spellbooks. Pauper wizards shouldn't.
Give most roles advance knowledge of one low level spell or other item.
It won't benefit them unless/until they find the corresponding item.
The most-current macOS version is greater than 12 (15 at time of
this change).
Expand Windows suggestions to include variations specific to MSYS2 and WSL2.
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
I normally force DECgraphics for tty and for curses so hadn't noticed
this before. I recently let curses default to 'cursesgraphics' and the
engraving-in-room character was crossed horizontal and vertical bars,
the crosswall character. It certainly stood out in the middle of a
room, but the emphasis seems out of proportion for "engraving here".
There is no 'epsilon' among the DEC line drawing characters. Curses
might be able to render one, but not with DEC-style rendering of 0xEE.
Comment out S_engroom so that curses inherits the default backtick.
