The failing Travis build issued about 500 lines of diagnostics
when complaining about one line of the source. It compiled ok
for me but I use older versions of Qt library and C++ compiler.
For Qt with 'popup_dialog' On, fix number entry when user types
a digit (or '#') directly onto the dialog instead of clicking
inside the Count box and then typing. Before, that first typed
digit was starting out as selected, so typing the next digit
replaced the selection instead of getting appended to the string
of digits being constructed. Fixed by moving the relevant code
to the KeyPress handler instead of re-executing the dialog.
Also, if a keypress is just a modifier, ignore it. The next
event should be the actual character. Prevents treating <shift>
(and <caps lock>!) as useless dialog responses. Before this,
attempting to type '#' to initiate a count wouldn't work because
the <shift> part of shift+3 ended the dialog. Now '#' works
(and is still optional; starting with a digit suffices).
Noticed when fixing 'D$'. Some commands, including D, which should
have been handling venom weren't doing so.
I'm not sure whether I got all the applicable cases.
Noticed when testing something unrelated: for menustyle=traditional
and =combination, when using 'D' to drop multiple items, if the
player only supplied '$' for the list of object classes of interest
then that list remained empty and all classes were processed.
Caused by retaining an old special case for gold which isn't needed
any more.
I think that it only mattered for 'D'. Other callers of ggetobj()
don't include gold as applicable so player can't pick gold hence
can't pick just gold to trigger this.
Support MSGTYPE=stop by having qt_display_nhwindow(WIN_MESSAGE,TRUE)
issue a tty-style --More-- prompt. For popup_dialog Off, the prompt
gets appended to the most recent message; for popup_dialog On, it is
issued via a popup and not displayed in the message window.
It accepts <space>, ^J, ^M, and ^[ (ESC) to dismiss. There's no way
to dismiss it with the mouse (for !popup_dialog) which might need
some fix....
Several adventures along the way. The '^C-in-parent-terminal triggers
infinite loop repeatedly complaining about "event loop already running"'
is now a one-shot complaint. It isn't fixed but the severity of
having it happen is greatly reduced.
... on the floor, in monster inventory, and in hero's inventory.
Items in your inventory being ignited produce a message even if you're
blind - you can see the lit-state by viewing inventory anyway, so just
give player the message.
(via xNetHack)
Update the cross-compiling doc at the top.
Remove sys/msdos/Makefile1.cross, sys/msdos/Makefile2.cross, and
sys/msdos/msdos-cross-compile.sh as they are no longer required.
Remove occurrences of CROSSCOMPILE_HOST as the host-side of a
cross-compile can be determined from:
defined(CROSSCOMPILE) && !defined(CROSSCOMPILE_TARGET)
without the additional macro.
This probably won't happen in practice, but it is a good safeguard
if this ever does happen (it happened for me in debugging when I wished
to have no "regular" rooms and only generate themed rooms).
This sets the minimum level depth of "Spider nest" to 10, somewhat above
the difficulty of an individual giant spider, because a whole room full
of them is a tougher challenge. Note that this isn't the only possible
fix to this problem; another solution would be to alter the special case
in mktrap that hardcodes a giant spider to generate with each web to
produce cave spiders if giant spiders would be too tough. Even then, a
lower difficulty cutoff is probably still warranted for this room, since
a large number of cave spiders might be too tough for level 1 or 2.
This also sets the minimum level depth of "Boulder room" to 4, based on
the fact that individual rolling boulder traps normally can't appear
until level 2, and having a bunch of them in one place which may be
required to reach the downstairs could be problematic.
This doesn't do anything to address the "Mausoleum" room problem, in
which a master or arch-lich can generate and immediately warp out and
attack the player. Even with a high difficulty threshold, it won't fix
the problem of these liches generating out of their normal difficulty
and Gehennom constraints.
Other potential candidates for difficulty thresholds:
- "Trap room": This room might be perilous on the first few levels,
especially if the level generates with it blocking the way to the
downstairs.
- "Massacre": Doesn't have any particular hazards, but might be
interesting if it only generated at deeper levels.
The system of themed rooms currently makes it so that any themed room
can potentially generate anywhere a themed room can be placed. This is
problematic in the long run, since it makes it difficult to design new
rooms that are an appropriate amount of challenge at all levels of the
dungeon. (A few themed rooms already have this problem: a hero starting
out on level 1 probably won't live very long when the neighboring room
is full of giant spiders, or an arch-lich has generated in a mausoleum
nearby).
This commit adds optional "mindiff" and "maxdiff" properties for
themerooms defined as tables and exposes level_difficulty() to Lua. A
themeroom whose mindiff exceeds the current level difficulty, or whose
maxdiff is lower than the current level difficulty, is prevented from
being selected.
Because the set of rooms eligible to generate on a given level is no
longer fixed, the total frequency of all the rooms can't be computed
once per game when the file is first parsed, as it was before. In place
of this, the themerooms_generate() function now uses a reservoir
sampling algorithm to choose a room from among the eligible rooms,
weighted by frequency.
Disclaimer: This is a minimal recipe, just to get someone else
started if they have a desire to get a full cross-compile of
NetHack-3.7 going for the Amiga. Some NetHack code bitrot was
corrected, and it does seem able to compile the game itself
to a point. See caveats below.
- If you want to obtain the cross-compiler and tools/libs for Amiga
https://github.com/bebbo/amiga-gcc
To our knowledge, a pre-built copy isn't available, so you have to
obtain the source via git and build it on your system.
The build prerequisite packages for Ubuntu are easily obtained:
sudo apt install make wget git gcc g++ lhasa libgmp-dev \
libmpfr-dev libmpc-dev flex bison gettext texinfo ncurses-dev \
autoconf rsync
The build prerequisite packages for macOS are apparently easily
obtained via homebrew, but that was not tested:
brew install bash wget make lhasa gmp mpfr libmpc flex gettext \
texinfo gcc make autoconf
After installing the prerequite packages and the cross-compiler
it was a straightforward build:
git clone https://github.com/bebbo/amiga-gcc.git
cd amiga-gcc
make update
[Note that you may have to take ownership of the files in the
bebbo repo via chown before succesfully carrying out the next
steps]
make clean
make clean-prefix
date; make all -j3 >&b.log; date
The compiler pieces are installed in /opt/amiga by default which
was satisfactory for our initial attempt, but if you want you can
alter the prefix before you build if you want. That is all
spelled out on the page at: https://github.com/bebbo/amiga-gcc
The Amiga cross-compile can then be carried out by specifying
CROSS_TO_AMIGA=1 on the make command line.
For example:
make CROSS_TO_AMIGA=1 all
make CROSS_TO_AMIGA=1 package
You can explicitly include tty and curses support if desired, otherwise
you'll end up with a tty-only cross-compile build. The SDL1 pdcurses
support has not been tested.
make WANT_WIN_TTY=1 WANT_WIN_CURSES=1 CROSS_TO_AMIGA=1 all
Also note that building the amiga targets using the make command
above, does not preclude you from building local linux or macOS
targets as well. Just drop the CROSS_TO_AMIGA=1 from the make
command line.
The cross-compiler hints additions are enclosed inside ifdef sections
and won't interfere with the non-cross-compile build in that case.
CAVEATS: The original NetHack Amiga build steps included the source for
some utilities that were built and executed on the amiga: txt2iff and
xpm2iff as part of the NetHack build procedure on amiga. Those did not
compile out-of-the-box on the linux host. They will either have to be:
- ported to build and run on the linux or macOS cross-compile host
or
- their functionality will have to be rolled into amiga NetHack
itself and executed on the target Amiga the first time the game
is run, perhaps.
Good luck amiga aficionados, perhaps you'll be able to take this
initial effort forward and get NetHack-3.7 available on the amiga or
amiga-emulator. Let us know if you do, and we can roll changes in
if you provide them.
- If you want to obtain the djgpp cross-compiler and tools/libs for MSDOS,
which is available for linux and macOS, you can use the following script
to obtain it:
sh sys/msdos/fetch-cross-compiler.sh
That script won't install anything, it is just file fetches. It will
store the cross-compiler in subfolders of lib and the hints files are
configured to find it appropriately there.
Note: Both the fetch and the msdos cross-compile package target require
unzip and zip to be available on your host build system.
Cross-compiler bits:
https://github.com/andrewwutw/build-djgpp
and the pre-built binary for your platform from:
https://github.com/andrewwutw/build-djgpp/releases/download/v3.0/
and a DOS-extender (for including in msdos packaging) from
http://sandmann.dotster.com/cwsdpmi/csdpmi7b.zip
and pdcurses from:
https://github.com/wmcbrine/PDCurses.git
The MSDOS cross-compile can then be carried out by specifying
CROSS_TO_MSDOS=1 on the make command line.
For example:
make CROSS_TO_MSDOS=1 all
make CROSS_TO_MSDOS=1 package
You can explicitly include tty and curses support if desired, otherwise
you'll end up with a tty-only cross-compile build:
make WANT_WIN_TTY=1 WANT_WIN_CURSES=1 CROSS_TO_MSDOS=1 all
Also note that building the msdos targets using the make command
above, does not preclude you from building local linux or macOS
targets as well. Just drop the CROSS_TO_MSDOS=1 from the make
command line.
The cross-compiler hints additions are enclosed inside ifdef sections
and won't interfere with the non-cross-compile build in that case.
Expand the use of the sys/unix Makefiles to be used for both normal
local builds and installs, as well as cross-compiles for other
platforms/targets.
Up until now, the primary unix Makefiles have treated util/host-side
component compiles, links and target object files just the same as
the game component compiles, links, and target object files.
Unfortunately, that meant that cross-compile effort typically had
to re-invent Makefiles specific to the cross-compile, creating a
maintenance burden and deviation from the typical local unix build
and providing a daunting obstacle to those that want to establish
build for a target environment/platform.
This change distinguishes between util/host-side component builds,
links, and component builds and targets object files destined for
the game (and other target platforms) in the Makefiles.
In theory, this will ease the effort for people that want to try to
resurrect NetHack perhaps on an old platform where it is no longer
viable to build NetHack-3.7 on the platform itself using old, outdated
compile tools, possibly with an old, outdated C dialect.
Some details:
- Game-related targets in the Makefiles (as opposed to util/host-side
targets that will be executed on the host), which could be destined
for another platform in a cross-compile scenario are prefixed with
$(TARGETPFX) so that they are distinguished.
The default scenario where no cross-compiler is involved, is to
define TARGETPFX to nothing, and therefore meant to have no effect.
- Game-related compile and link commands in the Makefiles and their
associated command line flags are distinguished from util/host-side
compile and link commands in the Makefiles by using $(TARGET_CC),
$(TARGET_CFLAGS), $(TARGET_LINK), $(TARGET_LFLAGS), $(TARGET_CXX),
$(TARGET_CXXFLAGS), $(TARGET_LIBS).
Those are used in the Makefile in place of $(CC), $(CFLAGS), $(LINK),
$(LFLAGS), $(CXX), $(CXXFLAGS), $(LIBS).
The default scenario where no cross-compiler is involved, defines
the TARGET_ version of those Makefile variables to match their
typical non-TARGET_ ounterparts.
- The dependency lists in the Makefiles includes the $(TARGETPFX)
prefix for stuff that would potentially be produced from a
cross-compile build.
- It adds pregame targets and $(PREGAME) variable, so that hints files
can add some additional stuff if required for a cross-compile
scenario.
The default scenario where no cross-compiler is involved doesn't
do anything for $(PREGAME).
- It adds $(BUILDMORE) target and variable, so that hints files
can add some additional things to be built for a cross-compile
scenario.
- It adds a "package" target and $(PACKAGE) variable, so that hints files
can add steps for the target platform in a cross-compile
scenario.
The "install" target assumes local build and placement and
isn't really applicable to a cross-compile scenario where the results
really just need to be bundled up for transport to the target platform.
- Also, this adds a pair of include files that can be updated with some
cross-compile recipes as they evolve. They are named "cross-pre.2020"
(for stuff to be included in the PRE section) and "cross-post.2020"
for stuff to be included in the POST section via sys/unix/setup.sh.
Those are included in sys/unix/hints/linux.2020 and
sys/unix/hints/macOS.2020 hints files.
Consider the following scenario: There's a level where there's a zone of
des.replace_terrain() between the stairs and some other objective, and
the terrain is something non-walkable like trees. There's a chance that
the path is entirely blocked off by random replace_terrain, so you
make the level set terrain to '.' along a randline (or normal line, or
whatever) between the randomly placed stairs and the other side of the
replace_terrain zone. The problem: this overwrote the stairs with a '.'
as well.
This can be worked around in the lua file by first picking the desired
location of the stairs, then setting the terrain that overlaps with the
stairs, then doing des.stair() after that, but this is awkward and hard
to read.
So this makes it impossible for anything calling SET_TYPLIT (only called
in sp_lev.c) to overwrite stairs. I can't really think of a situation
where a level designer would want to define stairs, then maybe overwrite
them.
This was leading to problems with special themed rooms which were
irregular. Walls of ordinary rooms count as part of the room, and
irregular rooms should be no different.
This also makes doors on the room edge be considered as part of the
room, which affected special room entry messages and filling.
All irregular rooms' walls getting marked as SHARED instead of their own
room is probably a latent bug in upstream NetHack, but will prevent
future issues for when/if themed rooms that involve special
rooms/subrooms get added.
This is a simple && vs || bug. The clear intention of the code is that
stairs aren't supposed to generate in themed rooms unless there is no
other choice.
Fixes#348
Aimed at fixing the problem where the player knows they're going to
forget a spell in a few thousand turns, so they go back and get the
book... only to find out that they "know it quite well already", and
need to wait an indeterminate amount of time until they are on the verge
of forgetting it (< 2000 turns) before the book will let them read it
again.
This commit simply removes that 2000 turn limit, so the player can fully
restore their memory at any time with the spellbook. Naturally, this
still consumes a read charge, so the book won't ultimately last as long
if you keep rereading it early.
If you do have more than 2000 turns left, the game will prompt you to
confirm that you do want to refresh your memory anyway. As before,
rereading with fewer turns will not prompt.
This is an omission in the filled/prefilled unification. The default for
filled on regions now being 0 meant that regions that had previously had
no need for any fill declaration at all (regions' prefilled defaulted to
0 before this, the effect being to fill them) now failed to get filled.
The rule of thumb is that all des.regions with a type for which filled
is meaningful (e.g. special rooms) should declare the fill status. I
added it to a bunch of temples even though this doesn't really seem to
affect anything there (the priest and altar come with the altar
definition). I assigned temples filled=1 and filled=2 loosely based on
if there is ever being some other generation that would put other
furniture or items in a temple, but the distinction should not affect
anything right now.
Cases fixed where non-temple regions weren't getting filled:
- Barracks, a graveyard, and shops in Tou-goal
- The beehive in the Wizard's Tower
This unifies the two separate special-room-stocking code paths, one in
the standard dungeon generator and one in the special level generator
(neither of which reacted to themed rooms, which is the reason for this
commit) into the end of makelevel(), placing the special room stocking
as the very last step of level creation.
Under the new system, when a regular or special level decides to create
a special room, it sets that room's rtype, but the room is not stocked
until later. It already worked this way for special levels, so the main
difference here is in the normal level generation, where the mkroom
family of functions identifies and marks a room as a special room, but
stops short of filling it. (I suppose perhaps the mkroom, mkzoo, mkshop
family of functions would be better off changing their names to
"pickroom" and so on.)
This also restructures makelevel() itself a bit, but the only real
change is that the paths that call makemaz don't return immediately
afterward; they continue to the special room stocking code. Also, this
code was lifted from fill_special_rooms, which is now not used
anywhere, so it has been deleted.
I don't really like how fill_ordinary_room is in mklev.c and
fill_special_room is in sp_lev.c; they seem like they'd be better off in
mkroom.c, but in the interest of not making unnecessary code changes,
I'll just recommend it.
The plan is to unify special room filling code and cause special rooms
to be filled as the very last stage of level creation. Since this will
occur after fixup_special, it was necessary to address the one remaining
piece of code in there that affects special room filling. (The Medusa
code remaining in there doesn't have to do with special rooms.)
There is code in fixup_special for stocking Medusa's lair with statues
of players from the leaderboard. It makes two assumptions: that there
will always be at least one room defined on Medusa's level, and that
the statues should be placed in the first room defined. In the process
of removing prefilled, some of these rooms suddenly became non-rooms,
and this caused problems. This commit ensures that the regions for
turning into rooms to hold the statues are present and come first.
In the process of writing this commit, I discovered a bug: the statue
stocking code for medusa in fixup_special naively chooses the spot at
which to place its final statue by selecting independent x and y
coordinates with somex and somey. This is responsible for a statue
occasionally being embedded in a wall or in iron bars on medusa-2 and
medusa-4: the rooms defined to receive statues are irregular, and some
of the possible coordinates happen to be walls, bars, and water.
The proper fix here is to add lua functionality so that the level
designer can specify that they want a leaderboard corpse or statue, and
remove the medusa special case from fixup_special, but that's rather
out of scope for what I'm doing here.
The fill_special_rooms function was only stocking two types of rooms:
top-level rooms in g.rooms, and their immediate subrooms. If there were
a special room 2 or more levels down, it would not get filled. (No
special levels currently define such a special room, so this bug is
latent.)
To address this, I changed fill_special_rooms to iterate only through
the top level rooms, and fill_special_room to recurse through all of its
subrooms (if any) before filling itself.
The existing system was a confusing mess of competing names (filled,
needfill, prefilled, etc) that had varying semantics, with prefilled
being the worst offender as it meant at least three different things in
various contexts. This commit unifies everything in the code under
"needfill", and everything in Lua under "filled", which defaults to 0
everywhere.
This also removes the second argument to fill_special_room; that
function now just checks the needfill of the room it's passed. As
before, a filled == 2 value is used for a special room to indicate that
the room should set the appropriate level flag, but shouldn't actually
be stocked with anything (for instance, King Arthur's throne room); the
difference is that this now comes directly from the lua script instead
of being manipulated within sp_lev.c.
The prefilled argument had one use case that is occasionally used in the
level files: if the level designer had specified an ordinary region with
prefilled = 1, it would become a room to control monster arrivals on a
level -- monsters that arrive within the bounds of a room are supposed
to stay there.
However, not all of the places where the comments indicated this was
being used were using it correctly; I tested this by letting a few
monsters fall through the knox portal (they're supposed to be
constrained to the entry room) and waiting a hundred turns, then going
through the portal; they were not constrained to the room and had
"wandered" through its walls.
Instead of trying to maintain this special case, I have added an
optional "arrival_room" boolean argument to des.region, which forces it
to create a room for the purposes of constraining monster arrival.
I have gone through and replaced occurrences of prefilled in lua files
with the appropriate filled option (or arrival, as needed). In some
cases, that resulted in questionable regions such as a filled ordinary
area in a non-themeroom (I just dropped the filled=1), or an area which
didn't do anything, not even lighting (which I deleted).
No code in this function would actually do anything if it were called on
a themed room, but since it is pretty clearly intended for the "regular"
special rooms, it's probably best to explicitly avoid themed rooms as
well.
I noticed that any subrooms created within a themed room were bare -
they never had any monsters, objects, traps, or anything really,
regardless of whether filled = 1 was set on them. As a result, they're
pretty boring.
It turns out that the code in makelevel() responsible for stocking
ordinary rooms with stuff only looped through g.rooms, and completely
ignored subrooms. (Subrooms would not get stocked with items by virtue
of being part of the larger room; I tested this by dialing the item
generation in rooms way up, and none of those items ever got placed in a
subroom.)
To fix this, I've extracted the code that populates an ordinary room
into its own function, fill_ordinary_room, and made it recurse into its
own subrooms. (I also renamed fill_rooms and fill_room to include the
word "special" in their names, because they only deal with special
rooms.) Note that since special rooms follow a separate codepath, an
ordinary subroom of a special room won't get stocked; perhaps these
functions should be unified in the future.
The fill_ordinary_room code is pretty much a verbatim cut and paste from
makelevel, so there is not currently any consideration for the size of
the subroom or the fact that it is a subroom with respect to how many
monsters, traps, objects, etc get placed.
I'm not sure whether other things such as stair selection will ever
select themed room subrooms, or whether they too only look at g.rooms.
This commit is intended to fix the bug where a pet will get fixated on
an unmoving monster and stop moving itself. I described the cause in the
github issue; the gist is that the pet AI chooses the unmoving monster
as its ranged target, doesn't do anything when it calls mattackm
(because it doesn't have ranged attacks), then returns a value
indicating it didn't move and can't take further actions.
I initially implemented a fix that refactored mattackm to distinguish
between "attacker missed" and "attacker did nothing", which the pet AI
could then use to determine whether the pet could continue doing things.
But then I realized that if mattackm is called with non-adjacent
monsters, a return of MM_MISS more or less unambiguously indicates that
the attacker did nothing (because the ranged functions it calls like
breamm don't actually check to see whether the target was hit, just
whether the monster initiated the attack.) So, this only really needed
to check whether mattackm returned with MM_MISS.
I also found a probable bug in mattackm, in that the thrwmm call isn't
treated the same as breamm or spitmm. In the latter two, mattackm
returns MM_HIT even though it doesn't check whether the ranged attack
actually hit its target. But there was no logic doing the same for
thrwmm, so this commit also adds that. (Otherwise, a pet could possibly
use a ranged weapon attack and then get to keep moving on its turn.)
