cliparound() was called before rhack(), triggering a map redraw with
stale vision data followed by a second correct redraw. Move it after
vision_recalc() so the map is redrawn once with correct data.
In wizard mode, I used ^W to wish for the Amulet of Yendor and was
immediately prompted for another wish. It was baffling and took a
while to figure out. Give a message before initiating the wish.
Counting wizkits as starting inventory causes side effects (giving
you skills from them, making the wizkit items formally identified,
etc.). Some of these side effects are undesirable (because, e.g.,
it can give you skill in a weapon you're restricted in), and the
others are mostly neutral (because wizard-mode players can identify
anything they want to). As such, it's better to treat the wizkit as
something you obtain immediately after entering the dungeon, rather
than something you had all along.
This adds a "reroll" option that lets players reroll their
character's attributes and starting inventory. Although I generally
think doing this makes the game worse, a) some players are going to
do it regardless and b) if a player is going for a challenge game,
rather than to win, it may be required. So in the absence of an
option like this, players repeatedly start and quit games instead,
creating a large number of junk logfile entries and generally
causing problems for other players on the same shared machine
(because repeatedly reloading the game is very CPU-intensive).
This should in theory be windowport-agnostic (although in practice
it may not be). Tested on tty, X11 and curses; on tty and X11 it
works fine (although X11 treats the change in attributes as
something that needs a status highlight), on curses it is slightly
jankier in terms of what other windows are drawn in the background
(but still plays correctly and I suspect this is a pre-existing
bug).
To form a complete implementation, we will need to consider the
following:
- Should there be a delay on a) starting the game and/or b)
rerolling? If so, what should it be (maybe configurable via
sysconf?)
- Should we take more steps to discourage players from rerolling?
It would be bad if players see the option exists and turn it on
just because it exists, or (worse) treat it as condoning the
particular style of play.
- Should we take steps to detect that players are rerolling
manually and a) tell them to use the option instead, b) tell them
that this is not an intended way to play (and may make the game
less enjoyable and/or prevent them getting the practice they need
to eventually win)?
Breaks save and bones files.
This doesn't implement inventory rerolling, just adds the
infrastructure: it's now possible to call u_init_inventory_attrs
multiple times and the starting inventory/attributes replace those
from the previous call rather than compounding.
For example, being hit by the bounce of a wand of fire means that
the main character could take damage twice in a turn, which would
kill even through saving grace; and scrolls and potions could burn
up after that and finish off the last HP, even if the wand only hit
once. This commit changes it to track all damage done during the
turn, and prevent HP dropping below 1 from damage until the next
player action or the next turn boundary, whichever comes first.
There was only one point in the code at which this caching was
being done, and it was incorrect: it's possible for the result of
near_capacity to change during a monster turn because monster
actions can change either inventory weight or carry capacity.
The bug was particularly relevant in cases where a character
polymorphed into a slow weak monster gets attacked by a monster
that moves at normal speed: due to the polyform being slow, the
normal-speed monster gets in a lot of attacks and causes a
rehumanization, but due to the polyform being weak, it was
burdened at the start of the monster turn, and so when that
penalty is (due to the bug) applied to the next turn it can
mean that the character misses the next turn too, and may end up
dying as a result.
Part 4 of implementing wish spreading. (This is now a complete
implementation, although the details are likely to change - but it
makes sense to commit something with the right balance properties,
and then tweak it based on feedback from playtesting.)
This helps to make the Amulet of Yendor feel special, and restores
approximately the same average number of wishes per game as existed
prior to the nerf to wands of wishing.
Placing the wish in allmain helps to avoid the wish happening at an
awkward place in the game's control flow, and is simpler than
testing every possible mechanism for gaining items for bugs (message
order is a common issue when trying to place it in addinv-related
functions, and this also avoids issues with the wished-for item
immediately invalidating an assumption that was made by the calling
code).
It is possible that this would be better as an invoke effect,
although I like the impact of picking up the Amulet and immediately
being given a wish.
Provide a way to bypass a debugger when initiating fuzzing.
nethack -D --debug:fuzzer # run fuzzer in wizard mode
nethack --debug:fuzzer # run it in normal mode
nethack [-D] -@ --debug:fuzzer # skip role/race/&c selection
Experience-level and experience-points, if enabled, could be
highlighted via 'up' or 'changed' rules in initial display after
restore. I tried 'down' rule too but didn't produce with that.
I don't understand what was going on but was able to reproduce it
and then fix it via the trial and error method....
Options processing can be early, even before ttyDisplay is allocated.
If we find that TTY_PERM_INVENT initialization is happening too early,
just set a marker (iflags.perm_invent_pending) to try again a bit later.
The changes in win/share are just to be able to sucessfully
reproduce the original issue on Windows. It was easily reproduced
on Unix, just by building with TTY_PERM_INVENT in include/config.h
and setting OPTIONS=perm_invent in config file.
There was a transcription error in the comments in cstd.h for
the standard list of header files, where only the description
remained for <stdlib.h>, not the name of the file itself.
Remove several extraneous inclusions of the standard C99 headers.
Tested on the following afterwards:
Linux (using hints/linux.370) including tty, curses, qt6, and X11
macOS (using hints/macOS.370) including tty, curses, qt5, and X11
Windows MSYS2 using sys/windows/GNUmakefile
Windows Visual Studio using sys/windows/Makefile.nmake
msdos cross-compile on Ubuntu using djgpp cross-compiler
I don't think this solves the recent light source reports,
but it changes a couple of things in an attempt to get more
information.
1. Having gy.youmonst.m_id field always be zero makes it tough
to distinguish it from uninitialized memory, or a random memory
value. This changes the m_id for the hero's gy.youmonst.m_id
to always hold the identifier 1, instead of 0.
2. write_ls was taking the stashed pointer in the light source,
and using it to immediately extract the m_id field and search
for that m_id. This changes the approach slightly, to actually
try and locate the stashed pointer itself in one of the monster
chains. Only if the monster pointer is located, do we dereference
it to obtain the m_id field.
3. For the interim, mark the saved ls with another set bit when
there has been a failure to locate the monst. At this time,
no code is acting on that bit, but it can be seen in a debug
session.
Hopefully, the next report will provide enough information to
understand the scenario a little better.
Experience equivalent to killing a monster is gained when starting a turn
adjacent to and being able to see the monster.
Breaks saves.
Idea and parts of code via dNetHack
gcc has recognized various "magic comments" for white-listing
occurrences of implicit fallthrough in switch statements for
a long time:
The range and shape of "falls through" comments accepted are
contingent upon the level of the warning. (The default level is =3.)
-Wimplicit-fallthrough=0 disables the warning altogether.
-Wimplicit-fallthrough=1 treats any kind of comment as a "falls through" comment.
-Wimplicit-fallthrough=2 essentially accepts any comment that contains something
that matches (case insensitively) "falls?[ \t-]*thr(ough|u)" regular expression.
-Wimplicit-fallthrough=3 case sensitively matches a wide range of regular
expressions, listed in the GCC manual. E.g., all of these are accepted:
/* Falls through. */
/* fall-thru */
/* Else falls through. */
/* FALLTHRU */
/* ... falls through ... */
etc.
-Wimplicit-fallthrough=4 also, case sensitively matches a range of regular
expressions but is much more strict than level =3.
-Wimplicit-fallthrough=5 doesn't recognize any comments.
Plenty of other compilers did not recognize the gcc comment convention,
and up until now the compiler warning for detecting unintended
fallthrough had to be suppressed on other compilers. That's because the code
in NetHack has been relying on the gcc approach, and only the gcc approach.
The C23 standard introduces an attribute [[fallthrough]] for the
functionality, when implicit fallthrough warnings have been enabled.
Several popular compilers already support that, or a very similar attribute
style approach, today, even ahead of their C23 support:
C compiler whitelist approach
--------------------------- -------------------------------------
C23 conforming compilers [[fallthrough]]
clang versions supporting
standards prior to
C23 __attribute__((__fallthrough__))
Microsoft Visual Studio
since VS 2022 17.4.
The warning C5262 controls
whether the implict
fallthrough is detected and
warned about with
/std:clatest. [[fallthrough]]
This adds support to NetHack for the attribute approach by inserting a
macro FALLTHROUGH to the existing cases that require white-listing, so
other compilers can analyze things too.
The definition of the FALLTHROUGH macro is controlled in include/tradstdc.h.
The gcc comment approach has also been left in place at this time.
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.
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.
The g? structs had a mix of variables that were written to
the savefile, and those that were not.
For better clarity and to distinguish those that end up in
the savefile, relocate some g? variables that get written
directly to the savefile into different structs.
This updates EDITLEVEL, although technically it probably
didn't need to, since savefile contents are not changing.
Details:
gb.bases -> svb.bases
gb.bbubbles -> svb.bbubbles
gb.branches -> svb.branches
gc.context -> svc.context
gd.disco -> svd.disco
gd.dndest -> svd.dndest
gd.doors -> svd.doors
gd.doors_alloc -> svd.doors_alloc
gd.dungeon_topology -> svd.dungeon_topology
gd.dungeons -> svd.dungeons
ge.exclusion_zones -> sve.exclusion_zones
gh.hackpid -> svh.hackpid
gi.inv_pos -> svi.inv_pos
gk.killer -> svk.killer
gl.lastseentyp -> svl.lastseentyp
gl.level -> svl.level
gl.level_info -> svl.level_info
gm.mapseenchn -> svm.mapseenchn
gm.moves -> svm.moves
gm.mvitals -> svm.mvitals
gn.n_dgns -> svn.n_dgns
gn.n_regions -> svn.n_regions
gn.nroom -> svn.nroom
go.oracle_cnt -> svo.oracle_cnt
gp.pl_character -> svp.pl_character
gp.pl_fruit -> svp.pl_fruit
gp.plname -> svp.plname
gp.program_state -> svp.program_state
gq.quest_status -> svq.quest_status
gr.rooms -> svr.rooms
gs.sp_levchn -> svs.sp_levchn
gs.spl_book -> svs.spl_book
gt.timer_id -> svt.timer_id
gt.tune -> svt.tune
gu.updest -> svu.updest
gx.xmax -> svx.xmax
gx.xmin -> svx.xmin
gy.ymax -> svy.ymax
gy.ymin -> svy.ymin
Related note:
There are some pointer variables that are heads of chains that were not
moved from 'g?' to 'sv?', because they are not actually written to the
savefile directly, but the objects/monst/trap/lightsource/timer in the
chains they point to are. That can be changed, if desired.
Examples: gi.invent, gm.migrating_objs, gb.billobjs, gm.migrating_mons,
gf.ftrap, gl.light_base, gt.timer_base
Make object deletion work similarly to monster deletion:
it's marked for deletion (by setting the where-field to OBJ_DELETED
and moved to specific deleted-objects chain), but they're actually
freed at the beginning of turn.
This may need some more tweaking, especially in places that iterate
over object chains, but fuzzing did not find any obvious problems.
Fix a case of accessing freed memory: a monster breathed at hero,
destroying some items. The code stored the next item in the chain
(a cloak), but a ring of levitation was destroyed, causing hero to
plop down into lava, destroying the cloak. The item destruction
code then tried to access the destroyed cloak object.
Make the code check the object where-field - which will be different
if the object was marked for deletion. Also removed an extra loop
going through the whole object chain looking for the items to
destroy.
It was too early to call the windowport change_color() routine
while processing the config file. The windowport was not yet
fully operational.
Now the palette option processing will just place the rgb
value into the appropriate ga.altpalette[CLR_MAX] entry.
init_sound_disp_gamewindows(void) [allmain.c] calls
change_palette() [coloratt.c] and it will call the windowport
change_color() function for each ga.altpalette[] entry that
has been set.
Notes:
The rgb values stored in ga.altpalette[] have the NH_ALTPALETTE bit set
so that the rgb value of 0 can be stored and be distinguishable from
a "not set" entry.
The NH_ALTPALETTE bit is cleared from the rgb value in change_palette()
prior to calling the windowport change_color() function.
The syntax for palette is colorname/r-g-b.
For example: palette:black/12-12-12
colorname must be one of the NH_BASIC_COLOR names or a suitable
alias for one of those 16 entries.
Some of the windowport CHANGE_COLOR functions had the wrong parameters,
perhaps due to bitrot. Those have been corrected to match the prototype.
move the custom color data into its own field in the glyphmap
and disassociate it from the unicode/utf8 stuff.
move the glyphcache stuff during options processing and parsing
into new file glyphs.c and out of utf8map.c, and make it
general, and not part of ENHANCED_SYMBOLS.
Do the groundwork for allowing glyph color customizations to
work when any symset is loaded and not restrict it only to
the enhanced1 H_UTF8 symsets.
The customizations in effect are still affiliated with a particular
symset.
Also closes#1224, but the PR itself references a data structure
made obsolete by this commit. The curses comment from the PR was
added into the code.
The PR also made several suggestions, but only the first
one has been included in this commit (and no longer based on
the handler), that being:
"allow defining colors if other symbol handling modes are used
(possibly limited to the standard 16 colors)."
FredrIQ also wrote the following suggestions in PR#1224:
Something I was also contemplating, unrelated to implementation of this
support in curses, would be the ability for the following:
allow defining colors if other symbol handling modes are used (possibly limited to the standard 16 colors)
allow defining attributes (for example: glyph:G_pet_female_kitten:U+0066/red/underline)
allow specifying glyphs as wildcards for defining global color/attribute changes
Something I also want to see are keywords for "don't change the current defined data". If this
were to be added, you could for example do this:
OPTIONS=glyph:G_*_fox:U+0064/blue
OPTIONS=glyph:G_statue_*:basechar/gray/underline
for "make all foxes use a blue color, make all statues gray with underline" without needing
to specify the relevant character for every statue. This ("basechar", "basefg", etc)
should perhaps also be added for MENUCOLORS and statushilites, so that you can, for
example, underline all items being worn without needing to specify a bunch of
near-duplicate rules for combining BUC colors + underline worn items
as per #1064
Adds a new extended command #lookaround, which will describe
the map around the hero they can see or remember.
Adds a new boolean option mention_map, which will give a message
when an interesting map location in sight changes.
Add the 'dump' argument to the existing '--version' command-line
option to display the magic numbers used when validating save and
bones files for compatibility.
Nothing exciting, just a line of 5 hex values. I was going to also
list the values for however many save and bones files are specified
on the command line but it seems to need more effort than I care to
expend. And I hadn't made up my mind whether that should be done by
nethack, recover, or some new standalone program. [Single line of
relatively raw output is so that they could be compared more easily.]
nethack --version:bad-argument was writing a message to stdout and
then starting play--which immediately overwrites stdout. Have it
quit instead. Player wasn't trying to start a game and quitting is
what it does with --version:good-argument.
add CRASHREPORT for Windows
add ^P info to report (via DUMPLOG)
new options: crash_email, crash_name, crash_urlmax
new game command: #bugreport
new config option: CRASHREPORT_EXEC_NOSTDERR
new command line option: --bidshow
deleted helper scripts:
NetHackCrashReport.Javascript
nhcrashreport.lua
misc:
update CRASHREPORTURL (will need to be updated before release)
update bitrot in winchain
winchain for Windows
add missing synch_wait for NetHackW --showpaths
add PANICTRACE (and CRASHREPORT) in mdlib.c:build_opts
missing:
packaging (Windows needs the pdb file)
no testing with MSVC command line build
port status:
linux: working, but glibc's backtrace doesn't show static functions
Windows VS: working. pdb file is large - looking into options
MacOS: working
msdos: not supported
VMS: not supported
MSVC: planned, but not attempted
MSYS2: working, but libbacktrace not showing symbols (yet?)
AFAICT, we only used the first char of the "command_line" string.
Just turn it into int to hold the key the main input loop parse() got.
Shouldn't have any functional difference.
