This is intended to resolve GitHub Issue #1650, which I was unable to directly reproduce
on my test system.
This fix assumes that the reported issue was related to cmdstr[BUFSZ] buffer not
getting initialized, thus containing random memory values.
1d3178a quieted the g++ build, but made the warnings even
worse with a clang build.
The addition of the -Wno-sfinae-incomplete caused an unrecognized
option warning using recent clang.
Recent clang build with Qt6.1 also caused several warnings
during the processing of the Qt6.1 header files related to
c++26-extensions.
This adds (under Linux) -Wnoc++-26-extensions to the clang++
command line to quiet those warnings and restricts the
-Wno-sfinae-incomplete command line option to the g++ build.
In the event that there is a collision between a menu group accelerator
and an individual menu item's accelerator, disregard the group
accelerator.
'$' is the only known collision in NetHack 5.0 presently.
Close#805
Reported by @youbo0 in GitHub issue #1616
This issue text stated:
"To enter wizard mode, I have a shortcut with -D -u wizard as suggested by
the wiki for Windows players. However, the name is now overridden by a name
in .nethackrc since 5.0, resulting in me not actually entering wizard mode
due to having the wrong name despite using -u wizard. In the previous
version, -u wizard was applying properly regardless."
Closes#1616
This is an initial attempt at adding support for hilite_pet and
hilite_pile to the msdos tile implementation, using the new
decal.txt tiles.
This initial attempt only supports a 16-bit vesa mode.
Other vesa modes and vga have not been done as of yet.
Hopefully, someone more familiar with vesa might contribute
improvements and support of the other modes at some point.
win/share/decals.txt contains (initially) a decal_delimiter tile,
a decal_pet tile, and a decal_pile tile.
The latter two can be used for hilite_pet and hilite_pile implementations
that don't have something in place already. The implementation would
just need to apply (merge) the non-background decal pixels over a
regular tile.
The special decal_delimiter tile can be used to confirm the presence
of the delimiter tiles in the tileset and mark the end of the regular tiles,
and the start of the decal tiles.
row 1 contains the background color whose pixels should be
ignored when applying a decal to a tile.
row 2 contains a row of pixels colored (0, 0, 0).
row 3 contains a row of pixels colored pure green (0, 255, 0).
row 3 contains a row of pixels colored pure blue (0, 0, 255).
cmd.c: In function ‘dokeylist’:
cmd.c:2961:23: warning: ‘]’ directive writing 1 byte into a region of size between 0 and 255 [-Wformat-overflow=]
2961 | Sprintf(buf2, "[%s]", key2txt(key, buf));
| ^
Use LUA_VERSION_NUM, not LUA_VERSION_RELEASE_NUM, for the check.
Move the definitions of the versions supported by this release of
NetHack to the top of nhlua.c, rather than 2300 lines into the file.
Close#1633
During a synchronous save operation initiated by the player (or
other trigger for dosave0()), the u.usteed_mid and u.ustuck_mid
values get set by savemonch(), and the monst pointers that
u.ustuck and u.usteed point to are no longer valid, but not
cleared.
The checkpoint operation, which also needs to ensure that
u.ustuck_mid and u.usteed_mid are set, must set them during
the checkpoint, which is okay because the u.usteed and
u.ustuck pointers _are_ valid during a checkpoint operation.
So, we need to distinguish between a save game sequence,
and a checkpoint sequence when writing out the u struct.
When corpses haven't stacked, and there is no player-discernable
reason why, provide some additional information in some cases,
but only when it is required.
Gender variance is the supported case in this commit.
Related to GitHub issue #1607.
This commit doesn't change the underlying mechanics to allow
the corpses to stack, but it does help the player understand
why that's the case in this instance.
In file included from ../include/hack.h:34,
from sp_lev.c:14:
In function ‘create_monster’,
inlined from ‘lspo_monster’ at sp_lev.c:3386:5:
../include/rm.h:528:32: warning: array subscript -1 is below array bounds of ‘struct monst *[80][21]’ [-Warray-bounds=]
528 | if (!svl.level.monsters[x][y]) \
| ~~~~~~~~~~~~~~~~~~^~~
sp_lev.c:2045:25: note: in expansion of macro ‘remove_monster’
2045 | remove_monster(x, y);
| ^~~~~~~~~~~~~~
../include/rm.h: In function ‘lspo_monster’:
../include/rm.h:476:19: note: while referencing ‘monsters’
476 | struct monst *monsters[COLNO][ROWNO];
| ^~~~~~~~
In function ‘create_monster’,
inlined from ‘lspo_monster’ at sp_lev.c:3386:5:
../include/rm.h:530:27: warning: array subscript -1 is below array bounds of ‘struct monst *[80][21]’ [-Warray-bounds=]
530 | svl.level.monsters[x][y] = (struct monst *) 0; \
| ~~~~~~~~~~~~~~~~~~^~~
sp_lev.c:2045:25: note: in expansion of macro ‘remove_monster’
2045 | remove_monster(x, y);
| ^~~~~~~~~~~~~~
../include/rm.h: In function ‘lspo_monster’:
../include/rm.h:476:19: note: while referencing ‘monsters’
476 | struct monst *monsters[COLNO][ROWNO];
| ^~~~~~~~
see_monsters() was producing spurious vault guard at 0,0
messages
Reproduce issue by:
1. Entering vault via teleport.
2. Wait for guard to enter.
3. Drop gold (if necessary) and follow guard.
4. Right after the guard disappears, but before
the corridor does, the following can lead to
the messages:
a) control-R to refresh the display.
or
b) save the game and restore.
In both cases, see_monsters() will get called and lead
to the spurious messages for the vault guard that is
parked.
Also, add a macro PARKEDMONSTER(mon) instead of checking the
the isgd bit and the value of mon->mx being zero in multiple
places
Also, adds MON_PARKED bit to mstate.
Currently the PARKEDMONSTER(mon) macro mentioned above,
does not use the new bit.
u.ustuck and u.usteed are handled differently in 5.0.0 than
in previous releases, and an unexpected halt to NetHack could
result in an inability to use recover to get the game back.
If the hero was engulfed, u.uswallow, could get saved to the
checkpoint file with a value of 1 without a corresponding
u.ustuck_mid value representing the m_id of the engulfing monster.
Recover had no information to use to restore the u.ustuck pointer
when loading the monsters on the level.
With u.uswallow set to 1, the game would proceed to enter if-blocks
based on that, and then crash/fault when it attempted to dereference
u.ustuck, during the recover attempt.
This updates the values of u.ustuck_mid immediately before saving
struct you during a checkpoint, so that the resulting file had
u.uswallow and u.ustuck_mid values that were in concert.
It does the same for u.usteed and u.usteed_mid.
This also now adds a save_currentstate() checkpoint call when
the swallowed/unswallowed status changes, that is whenever set_ustuck()
is called.
nhmall