Since croom and maxroom both point to elements in the rooms[] array,
the complaint that the memcpy() in
| if (croom != maxroom)
| memcpy(croom, maxroom, sizeof (struct room));
might have overlapping source and destination is bogus. The fix is
trivial but not vetted by the analyzer.
The consolidation of global variables from scattered source
files into decl.c and declared in decl.h was begun in 3.7.0.
Their placement in common files was done for centralized
initialization and potential re-initialization during a
"play again" scenario.
It wasn't really necessary for all of them to be housed in a
single huge structure to meet the "play again" requirement,
and the single huge structure has been a little unwieldy when
it comes to maintenance.
Following this commit, instead of one single extremely large structure
named 'g' to house all of the relocated global variables, they
are distributed into several ga through gz.
To make things easy for the developer, each variable is placed
into the struct corresponding to the starting letter of the variable.
That way, no lookup is required in order to know which struct houses
a particular variable, it is a simple match to the starting letter
for all the centralized global variables.
A global variable named 'amulets', would be found in ga.
ga.amulets
^ ^
A global varable named 'move', would be found in gm.
gm.moves
^ ^
A global variable named 'val_for_n_or_more' would be found in gv.
gv.val_for_n_or_more
^ ^
A global variable named 'youmonst' would be found in gy.
gy.youmonst
^ ^
mkmap creates mines-style full-level maps, so it should wipe
out all the room numbers in the level away. Also, it uses
temporary rooms for making sure the map is fully joined together;
those temporary rooms were left on the map, but should've
been cleared away.
When putting down map-parts on the level, don't remove the room
data which would be under that map; the map may have holes in them
(using the "x" map char), so a room may still exist there.
I don't think it matters if there is any room data which doesn't
have any room numbers referring to it in the level.
(Usually the special levels use map right after level_init anyway,
so there wouldn't be any rooms in the level)
One of the drivers of this change was that screen coordinates require a
type that can hold values greater than 127. Parameters to the window
port routines require a large type in order to be able to have values
a fair bit larger than COLNO and ROWNO passed to them, particularly for
their use to the right of the map window.
This splits the uses of xchar into 3 different situations, and adjusts
their type and size:
xchar
|
-----------------------
| | |
coordxy xint16 xint8
coordxy: Actual x or y coordinates for various things (moved to 16-bits).
xint16: Same data size as coordxy, but for non-coordinate use (16-bits).
xint8: There are only a few use cases initially, where it was very
plain to see that the variable could remain as 8-bits, rather
than be bumped to 16-bits. There are probably more such cases
that could be changed after additional review.
Note: This first changed all xchar variables to coordxy. Some were
reviewed and got changed to xint16 or xint8 when it became apparent that
their usage was not for coordinates.
This increments EDITLEVEL in patchlevel.h
Indent all labels one space. Having uniform placement makes spotting
them much easier. (Having no indent at all would impact the change
bars of 'git diff'. Those display the last unindented line--which
doesn't start with punctuation--occuring before each band of changes,
so usually the name of the function being changed now that we no
longer have unindented K&R-style function argument declarations.)
While in there, shorten or split various wide lines and replace a few
tabs with spaces.
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.
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.
I'll push a formatting guide at some point. There may still be
outstanding changes, but please feel free to resolve those as you arrive
a them.
To the best of my knowledge, there is no changes to the actual code
content, but the formatter does have the occasional bug. If you run into
an issue, please fix it!
From a bug report: in the irregularly
shaped temple on the C quest home level (the room where the leader is
located), the lit south wall contained a dark spot where a secret door
is located. It stayed blank until you got right next to it rather than
just until you got to a good angle facing it. (Magic mapping hides the
problem by showing that spot as a wall instead of leaving it as unseen;
you have to walk or teleport to that room in order to see the problem.)
The code that lights walls and doors which border lit rooms neglected
temporary walls produced by secret doors.
From a bug report, when ice on the Valkyrie
quest home level was melted and a boulder filled the resulting pool, that
pool was described as a moat. This was actually a terrain issue rather
than a formatting glitch, so instead of tweaking waterbody_name() with an
extra special case, extend the level compiler to allow specifying ice as
frozen pool instead of always being frozen moat. There's no provision
for having both types of ice on the same level, just a level-wide flag to
control which of the two applies for ice on that level.
This change has a side-effect for the V quest levels: once ice has
been melted, a second blast of fire will now boil away the pool and leave
a pit. The unfrozen water locations on the home level already behaved
that way (ie, they are pools rather than moats) so this should be ok. I
also added <Someone>'s suggestion to make one of the two drawbridges
on the goal level start in random state instead of always being open.
There's a newsgroup posting about building for Windows using minGW
(gcc) within the cygwin Unix emulation environment, and it includes diffs
for the changes used. One of the items being patched is a straight source
bug triggered by altering the definition of `boolean'. finish_map()'s
prototype doesn't match its definition (uses boolean args but has XCHAR_P
in the prototype).
remove_rooms() was trying to be clever and truncate the maximum room bounds
in partially overlapping rooms. In the process, it would truncate the
bounds of L shaped rooms incorrectly, leaving some locations outside the
bounds with the roomno field set. Since the maximum bounds really do not
have to actually match the largest extent of the room in the case of
irregular rooms, it was easiest to just remove the code that was performing
the incorrect truncation. Due to the way remove_room() is coded, this
could result in shopkeeper messages (or, less likely, priest messages,
although that has not been reported yet) occuring for locations to the
right (or the upper/lower right corner) of the MAP on the Bustling Town level.
This solution is mostly a band-aid. Make sure information set by join_map
that is overlaid by the MAP is cleared out. This ensures that place_branch
will never consider invalid data. A new function, remove_rooms(), with a
helper, remove_room(), takes care of this, but only for rooms created by
join_map, which addresses the only known case that causes this problem.
There's a possibility that some other strange behavior, especially in
minetn-6, will be fixed by this as well. The problem of disconnected caves
on minetn-6 is not yet addressed.
Also, add a check to lev_comp.y to make sure the required fg semantics of
joined levels (fg must be ROOM or CORR) are actually met. Doesn't affect
any levels currently included in the distro, but might address levels
others are trying to make.
