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.
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.
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).
Closes#247
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.
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).
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.
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)
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).
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....
