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.
This patch gives game and savefile compatibility
whether GOLDOBJ is defined or not.
You can build with GOLDOBJ defined or not, and
still load your saved games. Rebuild with the
opposite, and load the same game.
That way GOLDOBJ can be experimented with
more easily.
1. Leave the "you" struct and the "monst"
struct the same under the hood between
GOLDOBJ and !GOLDOBJ.
2. Always write out gold as an
object on the player and monster
inventory chains.
On a restore of the savefile with GOLDOBJ
not defined, take the gold objects out of
the inventory chains and put it into u.ugold
or mtmp->mgold as appropriate.
On a restore of the savefile with GOLDOBJ
defined, nothing special is done.
- Version change from 3.4.x
- timed_delay feature ignore in makedefs
- several flags from iflags to flags
- use offsets from mons array entries in save file rather than storing
the ptr and calculating the distance from beginning of array
Make the support of user sounds apparent in the
#version command. Also add a small section on
them to the Guidebook.
(The doc/Guidebook.mn version of this section
needs testing)
Add a missing check to makedefs so it prints a warning about misplaced %Es.
Fix a couple places in quest.txt pointed out by the new warning.
There's no visible effect on play, since the code that actually reads the
message keeps reading until the next %C.
> Oops:
>
> "NetHack.exe - Entry Point Not Found
>
> The procedure entry point Process32Next could not be located in the dynamic link
> library KERNEL32.dll."
>
> And the program refuses to run. Same goes for NetHackW.exe.
>
> Windows NT 4 (to be precise: 4.00.1381, SP6)
> IE 5.0 (to be precise: 5.00.2919.6307)
>
> The Help for Process32Next shows the following compatibility list:
> QuickInfo
> Windows NT: Requires version 5.0 or later.
> Windows: Requires Windows 95 or later.
> Windows CE: Unsupported.
> Header: Declared in tlhelp32.h.
> Import Library: Use kernel32.lib.
It turns out that the processentry32 structure contents
are slightly different on 2000/XP than they are on
95/98/Me according to the docs.
szExeFile
Pointer to a null-terminated string that specifies the name
of the executable file for the process.
Windows 2000/XP: The file name does not include the path.
Windows 95/98/Me: The file name includes the path.
Ensure that we check for the target values at the end of
the string.
makedefs has been listing TIMED_DELAY as one of the options which
affects save file contents even though that hasn't been the case for
a long time. Unfortunately, simply fixing that by itself would break
save file compatibility for anyone who has been building with it set.
This workaround prevents the fix from doing that. And now folks can
rebuild after toggling TIMED_DELAY without unnecessarily invalidating
save and bones files.
On mazelike levels, containers had to be listed before their objects. But,
for roomfilled levels, containers had to be listed _after_ the objects. All
our current levels that use containers with objects are mazelike, so I
changed the room behavior, updating the comment in lev_comp.y to match.
Other items/monsters are still processed in reverse on roomfilled special
levels, but I think this is OK.
Allow the special level and dungeon compilers to handle input
files which have CR+LF delimited lines. Apparently Cygwin doesn't
convert MSDOS style line ends into newlines the way stdio should
do for text I/O. The resulting unexpected CR characters result in
syntax errors.
And explicitly using '\n' on both the lex and yacc sides of
MAP processing allows removal of the old NEWLINE hack for Mac MPW.
It won't matter what numeric value that character escape sequence
has internally.
-Allow overriding of OPTIONS_FILE in makdefs.c
-Change obsolete WIN32_GRAPHICS to the correct MSWIN_GRAPHICS
-Remove the 8514 and VESA screen control stuff since it never existed.
in util/lev_main.c:write_maze(), line which reads
"Write(fd, &(pt->ngold), sizeof(pt->naltar));"
should read
"Write(fd, &(pt->ngold), sizeof(pt->ngold));"
Add absent prototypes to some core routines.
Also add some port function() to function(void) in some win32 routines.
Also updates the Borland C Makefile for win32.
This patch allows the digits 0-9 to be used to indicate line numbers
in the MAP...ENDMAP arrays of level files. This makes it a wee
bit easier to place features. The digits get stripped out before
the map is interpreted.
