In 3.6.x, zombie corpses were always aged an extra 100:
NetHack/src/mon.c
Line 375 in 23d331a
obj->age -= 100; /* this is an *OLD* corpse */
in 5.0.x, zombie corpses are always aged TAINT_AGE, which is only 50:
NetHack/src/mon.c
Line 648 in 97a6c13
obj->age -= (TAINT_AGE + 1); /* this is an *OLD* corpse */
This is the result of commit 408321b.
The accompanying comment states that the purpose of that patch was meant to
just replace hard-coded numbers with symbolic values, but the commit set
two differing numeric values to the same symbol name, thus causing the
regression reported in:
https://github.com/NetHack/NetHack/issues/1664
Revert the values to match those of 3.6, and add the additional symbolic value.
Closes#1664
Fix#576
Reported initially by @copperwater for polymorphed monsters:
"observe how the [polymorphed-monster] hovers placidly above the water for
several turns like Wile E. Coyote before it gets a move, realizes it's
above water, and drowns. Ditto for lava."
A comment in the GitHub issue thread by @Tomsod pointed out that a
revived corpse could do the same.
This should set things up for other terrain fallout if discovered or
implemented in the future.
- consume an additional bit in enum mon_terrain_effects (hack.h)
- include the additional bit in TERRAIN_FALLOUT_MASK (monst.h)
- add detection to maybe_set_terrain_effects (mon.c)
- add action to terrain_effects (mon.c)
Implemented by stealing some upper unused mstate bits to avoid
invalidating existing save and bones.
../sys/unix/unixmain.c: In function ‘process_options’:
../sys/unix/unixmain.c:458:9: warning: use of uninitialized value ‘origarg’ [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
458 | config_error_add("Unknown option: %.60s", origarg);
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/pline.c: In function 'execplinehandler':
../src/pline.c:678:15: error: implicit declaration of function '_spawnv' [-Wimplicit-function-declaration]
678 | ret = _spawnv(_P_NOWAIT, sysopt.msghandler, args);
| ^~~~~~~
../src/pline.c:678:23: error: '_P_NOWAIT' undeclared (first use in this function); did you mean 'MM_NOWAIT'?
678 | ret = _spawnv(_P_NOWAIT, sysopt.msghandler, args);
| ^~~~~~~~~
| MM_NOWAIT
../src/pline.c:678:23: note: each undeclared identifier is reported only once for each function it appears in
make: *** [GNUmakefile:1376: o/nethack/pline.o] Error 1
early_init() was already being called at pcmain.c line 70,
so the recently added call at line 132 was problematic
because it cleared program_state values that had been
intentionally set since the call at line 70.
Reported directly to devteam, the code was using "Your little dog
devours the tripe ration" during the taming process, prior to the
pet becoming yours.
The startup had fallen behind NetHack 5.0 startup for other platforms,
and lacked support for some of the early command line options.
Following this, if PC_EARLY_OPTIONS is defined in pcconf.h, the
port will support those options, such as --version, --showpaths,
--dumpenums, etc.)
Currently, MSDOS #defines's PC_EARLY_OPTIONS, but AMIGA, ATARI,
and MAC68K do not.
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.
nhmall