Game is playable, and should compile on linux and Windows.
Assumes you have a lua 5.3 library available.
Removes level compiler and associated files.
Replaces special level des-files with lua scripts.
Exposes some NetHack internals to lua:
- des-table with commands to create special levels
- nh-table with NetHack core commands
- nhc-table with some constants
- u-table with some player-specific data (u-struct)
- selection userdata
Adds some rudimentary tests.
Adds new extended command #wizloadlua to run a specific script,
and #wizloaddes to run a specific level-creation script.
nhlib.lua is loaded for every lua script.
Download and untar lua:
mkdir lib
cd lib
curl -R -O http://www.lua.org/ftp/lua-5.3.5.tar.gz
tar zxf lua-5.3.5.tar.gz
Then make nethack normally.
Wizard mode shows the number of points needed to reach the next level
(unless already maxxed out at 30) for ^X and end of game disclosure.
Do it in normal play for the latter too. (I think it would ok to do
that for ^X too but haven't gone that far.)
Even when it was wizard mode only, the phrasing for past tense had a
minor grammar bug, and it could make the line a little too long for
tty and curses (not sure about others) when level was high, resulting
in wrapped text. That looked bad for tty, which first tries removing
indentation (just 1 space in this case), making that line outdented
as well as wrapped. So change the phrasing slightly when experience
level is 'too high'. I had a version which formatted, measured, and
re-formatted if necessary but that was overkill; simple hardcoded
rephrasing suffices particularly when measuring was against assumed
display width (80) rather than actual width.
TRAVIS CI added Windows to their platform list in late 2018.
Update the .travis.yml file to include a pair of Windows in
machines in the testing suite, one built with visual studio
command line tools and the other with mingw gcc tools.
The visual studio build is currently using nmake with the
sys/winnt/Makefile.msc Makefile from our distribution,
That's the same process we've been using for building
our binaries, pretty much.
BRH may be able to modernize it over the next couple of
weeks to use the msbuild process instead.
I went with the HINTS environment variable on windows
for consistent self-documenting purposes, even though
the environment variable isn't used on windows.
included:
os: linux
Compiler: gcc C
HINTS=linux
os: linux
Compiler: clang C
HINTS=linux
os: linux
Compiler: gcc C
HINTS=linux-x11
os: linux
Compiler: gcc C
HINTS=linux-qt5
os: linux
Compiler: gcc C
HINTS=linux-minimal
os: windows
language: shell
HINTS=Windows-visual-studio
os: windows
HINTS=Windows-mingw
excluded:
os: osx
Compiler: clang
Xcode: xcode10.2 C
HINTS=macosx10.14
Turns the "fix" in commit 319dcf4746
handled removing the default answer for single-line-prompt plus
multi-line-answer but not for multi-line-prompt plus long-enough-
answer-to-reach-another-line. The logic wasn't quite right and I
misunderstood what is stored in linestarts[] so even correct logic
wouldn't have solved things.
A recent fix for #wizidentify showing "Not carrying anything" after
listing inventory items still showed "Not carrying anything" after
"(all items are already identified)". Fix is easy.
Trickier bug was that ^I performs object ID on selected items while
the inventory routine is still in progress (but after it has processed
every item) and the ID routine will call update_inventory() which
will call the inventory routine to reformat invent. So the inventory
display routine was called recursively without having returned to
wizidentify where iflags.override_ID gets cleared to revert to normal
inventory. The nested call was unintentionally narrowing the contents
of persistent inventory window to whatever items were still unIDed.
(Any inventory update, including ^R, restored it to full inventory.)
With 'popup_dialog' On, a one line popup with question and likely
responses and default answer was shown, but without having the
cursor displayed at the end of emphasize that it was waiting for an
answer. Make the popup be one character wider so that there is room
to show the cursor. No effect when 'popup_dialog' is Off and prompts
are shown at the bottom of the message window; those already have the
cursor sitting at the end.
Make final inventory disclosure use a full width menu instead of
the default 38-column width with lots of wrapping. Also, increase
that default from 38 to 40 for the rest of the time. Commit
9f6588af49 made the 38 vs 40 portion
matter much less but I decided to keep it in anyway.
When a menu or 'things that are here' popup has only a couple of
lines and they happen to be narrow, a sized-to-fit window isn't
always easy to spot when it is shown over the ends of old messages
rather than over the map, even with a border box around it. Give
such windows a minimum size of 5x25 so that they always stand out
enough to be immediately seen. This will cause more message text to
be rewritten occasionally (after dismissing the menu or text window)
but the curses interface seems to discount that as something to be
concerned about.
Fully support the mouse_support option for curses, via 'O' as well as
via config file. At the moment, mouse_support:1 and mouse_support:2
are equivalent.
Also, fix the screen-to-map coordinate translation. When the mouse
is active and over the map, the pointer's cursor becomes a cross-hair
(may very by platform) and the character cell chosen for a click
seems to be a few pixels to the right of the center of the '+'.
The PDC_NCMOUSE has to be defined on the command line
or above the #include entries in win/curses/cursmisc.c.
This does the former command line change.
So no one on Unix or Unix-like ever builds without tty support?
options.c:694:11: warning: unused variable 'opts' [-Wunused-variable]
Noticed when producing a curses-only binary to verify that erase_char
and kill_char weren't relying on tty being present.
Support user's terminal settings for erase char and for kill char.
Erase char is typically <delete> or <backspace>, both of which are
already explicitly handled so probably no effect there. Kill char
(generally ^U these days) will be honored unless it is a printable
character (don't know whether there are any troglodytes out there
who still use '@' for that...). The current handling for ESC works
the same if there is any input to kill, but yields 'cancelled' when
there isn't.
That's for message window getline(), which operates char-by-char.
The popup getline() uses a curses routine to get an entire string
and already honors kill char but treats ESC as input of ^[.
Right button is button3 rather than button2. Accept either and treat
both as "not left" to pass CLICK_2 back to the core.
Treat <Ctrl>+left-click as "not left" too, to simplify usage with Mac
one-button mouse (where <Ctrl>+left-click can be configured to send
"secondary click" but might not be set do so) or one-button laptop
trackpad (where having two fingers on the scrolling portion of the pad
while clicking the button is necessary to send "secondary click").
Another one which has been around for a while. When merging two
globs, the result is partly eaten if either (or both) of them was
partly eaten, not just when the one that's going to stick around as
the combined glob already was.
Something I've had sitting around for quite a while. Add a sanity
check to mpickobj(). (It will need tweaking if b&c are changed to be
in engulfer's inventory.)
Also, include more information in the feedback when a nymph steals
attached iron ball: "Nymph removed your chain and stole a heavy iron
ball".
And don't set the avenge-ok flag if uball is the item stolen since
thief was doing hero a favor, or for anything when the thief is under
the influence of Conflict.
A check for bad restoration (ball without chain or vice versa) issued
a warning but then left the problem around to trip up other code.
'Fix' the problem by clearing those owornmask slots and their pointers.
Doesn't try to recover memory if the one that's found is OBJ_FREE.
Also some formatting.
The position bars shown by curses when the map is clipped weren't
being drawn as intended (integer arithmetic). Changing parentheses
was enough to get it working, but it didn't handle the edge case
where non-zero got rounded to 0 (so when map was panned down, the
uppermost character of the vertical position bar still showed '*',
falsely indicating that top of map was currently within view.
Followup to 1c03d0970115c776d1c4791fea3c33f70b0b5378; that had been
too easy. When map was clipped and panned to the side, the highlight
for hero's spot was shown next to the '@' instead of on it.
