PatR [Thu, 28 Nov 2019 23:00:54 +0000 (15:00 -0800)]
3.7: goldX and other stuff
Move option variable goldX (True: treat gold as BUC unknown, False:
treat gold as uncursed during BUCX filtering) from iflags to flags
so that it persists across save/restore.
Get rid of a few obsolete things from struct flags.
Try to make the 'cursesgraphics' option work although I don't think
that it was ever functional enough for anybody to use so probably
could have been removed instead.
Bump EDITLEVEL; any current save files are invalid.
Demote status from Beta to Work-in-Progress.
I modified src/sfdata.c manually (not included here) to get a full
build. The Unix Makefile.src needs to be taught when and how to
regenerate it.
PatR [Thu, 28 Nov 2019 00:27:13 +0000 (16:27 -0800)]
paranoid_confirmation:eating
Add 'eating' (synonym 'continue') to the list of things that can be
set via paranoid_confirmation to require "yes" instead of "y" when
the user is prompted about something, in this case "Continue eating?".
dat/opthelp was missing a few of the paranoid_confirmation choices.
nhmall [Wed, 27 Nov 2019 22:19:55 +0000 (17:19 -0500)]
number pad changes from pull request #247
Below is the accompanying text from the pull request on
GitHub https://github.com/NetHack/NetHack/pull/247:
> This fixes the issue brought up in https://www.reddit.com/r/nethack/comments/dv3pae/curses_and_the_numberpad/?st=k3hgply6&sh=dbc2bf7d .
>
> I don't know why the "regular" (tty) method doesn't seem to work for him,
> but I'm going to chalk it up to a PDCurses oddity. What I do know, however,
> is that the alternate method I added a year ago or maybe longer, that allows
> numpad usage even with number_pad:0 (to retain the default keybindings in case
> an user is used to them, while keeping number pad behaviour making sense,
> similar to NetHack4+friends) was only partially implemented, for some reason.
> This adds the rest of the keys, meaning that this means of key interpretation
> should be more realible. KEY_A2/B1/B3/C2 are not standard keys in the Curses
> documentation, and is thus behind an ifdef -- but PDCurses, amongst other
> implementations, makes use of them.
>
> As a side effect, Home/End/PgUp/PgDn are now interpreted as diagonal movement,
> since some terminals interpret number_pad keys that way. I do not consider this
> a problem since they went unused in normal gameplay anyway (This does not
> interfere with menus or similar).
PatR [Wed, 27 Nov 2019 19:24:23 +0000 (11:24 -0800)]
fix part of #H9467 - clairvoyance vs sensed mons
When a monster is drawn on the map, remove any "remembered, unseen
monster" glyph being shown at the same spot. Clairvoyance shows
all monsters in vicinty, then ones which can't be seen are replaced
with the 'I' glyph (which is on the object layer or the display,
not the monster layer show is subject to different update behavior).
But subsequent monster refresh didn't get rid of it when a sensed
monster was displayed over it. (3.6.1 included a similar fix for
warned-of monsters.)
Also during clairvoyance, don't draw an 'I' at a spot that will
immediately be refreshed with a monster because 'I' clobbers any
remembered object at the same location.
Fix alternate number pad interpretation only working for diagonals
This fixes the issue brought up at https://www.reddit.com/r/nethack/comments/dv3pae/curses_and_the_numberpad/?st=k3hgply6&sh=dbc2bf7d .
I don't know why the "regular" (tty) method doesn't seem to work for him,
but I'm going to chalk it up to a PDCurses oddity. What I do know, however,
is that the alternate method I added a year ago or maybe longer, that allows
numpad usage even with number_pad:0 (to retain the default keybindings in case
an user is used to them, while keeping number pad behaviour making sense,
similar to NetHack4+friends) was only partially implemented, for some reason.
This adds the rest of the keys, meaning that this means of key interpretation
should be more realible. KEY_A2/B1/B3/C2 are not standard keys in the Curses
documentation, and is thus behind an ifdef -- but PDCurses, amongst other
implementations, makes use of them.
As a side effect, Home/End/PgUp/PgDn are now interpreted as diagonal movement,
since some terminals interpret number_pad keys that way. I do not consider this
a problem since they went unused in normal gameplay anyway (This does not
interfere with menus or similar).
PatR [Wed, 27 Nov 2019 03:27:00 +0000 (19:27 -0800)]
3.7 Unix Makefiles
Copy lib/lua-$(VERSION)/src/liblua.h to lib/lua/ rather than lib/.
Instead of copying any of the header files or telling the compiler
where to find the lua ones, generate include/nhlua.h on the fly and
restrict the knowledge of where they are to it (paths are relative
to include/).
|/* nhlua.h - generated by top Makefile */
|#include "../lib/lua-5.3.5/src/lua.h"
|LUA_API int (lua_error) (lua_State *L) NORETURN;
|#include "../lib/lua-5.3.5/src/lualib.h"
|#include "../lib/lua-5.3.5/src/lauxlib.h"
|/*nhlua.h*/
This might need to be redone (or augmented by having CFLAGS add back
'-I path-to-lua') if some compiler can't find '#include "luaconf.h"'
issued by lua.h.
nhmall [Tue, 26 Nov 2019 05:02:38 +0000 (00:02 -0500)]
more msdos cross-compile fixes
undefined reference to g.variables if certain parts of
drawing.c are included in host-side utilities, so
surround the offending code in
-> #if !defined(CROSSCOMPILE) || defined(CROSSCOMPILE_TARGET)
PatR [Mon, 25 Nov 2019 23:01:40 +0000 (15:01 -0800)]
alignment of mimicked or polymorphed altars
A reddit thread about an unaligned altar in an aligned temple was
a tipoff that mimics posing as altars didn't have any particular
alignment. The look-at code was misusing an operloaded field of the
underlying terrain. Pick an alignment at random when taking on the
appearance of an altar, store it in the mimic's mon->mextra->mcorpsenm
field, and have look-at use that.
Also, dropping a ring of polymorph into a sink can transform it, and
one possible outcome is an altar. In this case, the alignment is
part of the location's topology, but code setting that up was using
Align2amask(rn2(foo)). That's a macro which evaluates its argument
more than once. The first evaluation was effectively a no-op. If
the second evaluation picked lawful then the result was lawful as
intended. But if the second picked non-lawful and the third picked
lawful, the result would end up as none-of-the-above (a value of 3
when it needs to be a single-bit mask of 1, 2, or 4).
PatR [Mon, 25 Nov 2019 20:20:42 +0000 (12:20 -0800)]
lua reorganization
Reduce the implied reliance of a specific version of lua.
Instead of copying liblua.a to src/, copy it to lib/. Instead of
telling the compiler to look for headers in lib/lua-5.3.5/src/ as
well as in include/, copy the relevant ones to lib/ and tell the
compiler to look for them there. 'make spotless' in src/ will
remove both the object library and the header files from lib/ but
there really should be a new Makefile.lib to take care of that
directory.
Update Makefile.src to be able to build lua in case someone starts
with 'make all' there instead of in the top Makefile. It doesn't
duplicate the option to fetch the lua source package though.
NHinternal/../genFiles.c has been updated to mention lib/liblua.a
and lib/lua*.h as 'generated at compile time' in Files and to skip
lib/lua-* entirely if it comes across that (so not operating on a
completely clean tree). But it won't be accurate unless/until
other ports stage their lua files there instead of in src/ and
lib/lua-$(VERSION)/src/.
I haven't tried 'make depend' to see what it makes of the numerous
changes....
PatR [Mon, 25 Nov 2019 02:29:14 +0000 (18:29 -0800)]
3.7: fix #9397 - pronouns when hallucinating
Developed for 3.6 but deferred to 3.7. Most of the testing was with
the earlier incarnation.
Report was that pronouns were accurate for the underlying monsters
when hallucination was describing something random, and also that the
gender prefix flag from bogusmon.txt wasn't being used. The latter
is still the case, but pronouns are now chosen at random while under
the influence of hallucination. One of the choices is plural and an
attempt is made to make the monster name and verb fit that usage.
|The homunculus picks up a wand of speed monster.
|The large cats zap themselves with a wand of speed monster!
|The blue dragon is suddenly moving faster.
There is no attempt to match gender for the singular cases; you might
get
|The succubus zaps himself [...]
or
|The incubus zaps herself [...]
PatR [Mon, 25 Nov 2019 01:56:01 +0000 (17:56 -0800)]
3.7 build cleanup
Unix Makefile.utl wasn't aware of the dependency of makedefs.o on
src/mdlib.c so didn't rebuild makedefs when it should have.
Eliminate several warnings:
mdlib.c - #if inside the arguments to macro Sprintf();
nhlua.c - nhl_error() ends with a call to lua_error() which doesn't
return, but neither of them were declared that way;
nhlsel.c - because of the previous, the 'else error' case of
l_selection_ellipse() led to complaints about uninitialized
variables;
sp_lev.c - missing 'const'.
I did minimal testing which went ok, but revisiting a couple of levels
gave me un-freed memory allocated by restore.c line 1337. (I haven't
looked at that at all.)
PatR [Sun, 24 Nov 2019 23:33:16 +0000 (15:33 -0800)]
fix #H9462 - segfault with levitation boots
This is similar to the helm of opposite alignment case fixed some
time ago. Deferring the setting of foo->known until an item is fully
worn (because it used to get set earlier but gave away information if
the wear operation was interrupted) didn't take into account that foo
might end up Null in various circumstances. So Boots_on() needs to
validate uarmf before setting uarmf->known in case putting on boots
of levitation while on a sink caused them to come right back off.
I put similar validation into all foo_on() just in case (as far as
I'm aware, only Boots_on() and Helmet_on() actually need that).
PatR [Sat, 23 Nov 2019 17:28:08 +0000 (09:28 -0800)]
more #H9375 - Rider bargethrough
I think the previous expression would allow moving (via swapping
places) from a pool to solid rock or closed door which was not what
was intended (but moot since there aren't any pools on the Astral
level). This revised expression does what is intended: can only
swap to a pool location if already located in/over (the Riders fly?
they should probably be non-breathing) another pool.
nhmall [Sat, 23 Nov 2019 03:35:48 +0000 (22:35 -0500)]
incremental improvements to cross-compiling support in NetHack 3.7
Some support of new code #defines to faciliate cross-compiling:
OPTIONS_AT_RUNTIME If this is defined, code to support obtaining
the compile time options and features is
included. If you define this, you'll also have
to compile sys/mdlib.c and link the resulting
object file into your game binary/executable.
CROSSCOMPILE Flags that this is a cross-compiled NetHack build,
where there are two stages:
1. makedefs and some other utilities are compiled
on the host platform and executed there to generate
some output files and header files needed by the
game.
2. the NetHack game files are compiled by a
cross-compiler to generate binary/executables for
a different platform than the one the build is
being run on. The executables produced for the
target platform may not be able to execute on the
build platform, except perhaps via a software
emulator.
The 2-stage process (1. host, 2.target) can be done
on the same platform to test the cross-compile
process. In that case, the host and target platforms
would be the same.
CROSSCOMPILE_HOST Separates/identifies code paths that should only be
be included in the compile on the host side, for
utilities that will be run on the host as part of
stage 1 to produce output files needed to build the
game. Examples are the code for makedefs, tile
conversion utilities, uudecode, dlb, etc.
CROSSCOMPILE_TARGET Separates/identifies code paths that should be
included on the build for the target platform
during stage 2, the cross-compiler stage. That
includes most of the pieces of the game itself
but the code is only flagged as such if it must
not execute on the host.
If you don't define any of those, things should build as before.
One follow-on change that is likely required is setting the new dependency
makedefs has on src/mdlib.c in Makefiles etc.
More information about the changes:
makedefs
- splinter off some of makedefs functionality into a separate file
called src/mdlib.c.
- src/mdlib.c, while included during the compile of makedefs.c
for producing the makedefs utility, can also be compiled
as a stand-alone object file for inclusion in the link step
of your NetHack game build. The src/mdlib.c code can then
deliver the same functionality that it provided to makedefs
right to your NetHack game code at run-time.
For example, do_runtime_info() will provide the caller with
the features and options that were built into the game.
Previously, that information was produced at build time on the
host and stored in a dat file. Under a cross-compile situation,
those values are highly suspect and might not even reflect the
correct options and setting for the cross-compiled target
platform's binary/executable. The compile of those values and
the functionality to obtain them needs to move to the target
cross-compiler stage of the build (stage 2).
- date information on the target-side binary is produced from
the cross-compiler preprocessor pre-defined macros __DATE__
and __TIME__, as they reflect the actual compile time of the
cross-compiled target and not host-side execution of a utility
to produce them. The cross-compiler itself, through those
pre-defined preprocessor macros, provides them to the target
platform binary/executable. They reflect the actual build
time of the target binary/executable (not values produced
at the time the makefiles utility was built and the
appropriate option selected to store them in a text file.)
- most Makefiles should not require adding the new file
src/mdlib.c because util/makedefs.c has a preprocessor
include "../src/mdlib.c" to draw in its contents. As previously
stated though, the Makefile dependency may be required:
makedefs.o: ../util/makedefs.c ../src/mdlib.c
^^^^^^^^^^^^^^^
PatR [Sat, 23 Nov 2019 02:16:59 +0000 (18:16 -0800)]
fix #H9375 - unintended Rider corpse suppression
Don't let Riders swap places with something (fog or ooze, perhaps)
located at a closed door spot because if it gets killed there, there
won't be any corpse and it will stop auto-reviving.
Just avoid moving to spots where mondied() won't place a corpse
instead of worrying about whether a bargethrough creature (if there
ever are any besides the Riders) might be able to survive at the
destination (so ignore pass-walls, door-opening, swimming, &c).
projects / nethack / log