Provide a common routine that always does the right
thing with respect to timers and weight when altering
obj->corpsenm, and use it throughout the code.
From a bug report.c was first creating a corpse
complete with revive timer if it was a troll, or without
a timer if it was a lizard or lichen corpse. Then it might
change the corpse type, leaving strange corpse
types that revived, or that lasted forever.
Normal maze levels are initialized from x == 3 thru COLNO-1. However,
levels that use the INIT_MAP spec go thru mkmap, which initializes the level
starting at x == 1. This usually makes no difference, but does in the case
of levels that also use GEOMETRY:left. This was the case with the Ranger
start level and caused the leftmost 2 locations to be room locations but
unreachable. The Juiblex level actually had the same behavior, but this
was harmless because the MAP in that case was smaller.
Fix is to set the xstart=1 for levels with INIT_MAP and GEOMETRY:left.
The rest of sp_lev works just with this (when INIT_MAP was used, that is).
First reported 12/13/2003, I think, but my archives contain more recent reports
too. Special level specs like NON_PASSWALL and NON_DIGGABLE only apply
to the map sections for which they are specified. So, on special levels of
Sokobon, the large surrounding area is stone, but have no special flags set.
So, it was possible to teleport a Xorn and have it appear in this outer area.
Addressed this by checking the perimeter of the map(s) and if all are
nondiggable and nonpassable, propagate this to the surrounding stone.
This appears to be the intent on such levels, so there is no need to
force the affected special levels to explicitly specify this.
From a bug report, the placement
of random doors by the code that loads special levels would attempt to
evaluate rn2(0) and either get a divide by zero crash (normal build) or an
impossible warning (DEBUG enabled when compiing rnd.c, done automatically
when BETA is defined). The problem was only noticable for random door in
a 1x1 room; none of our distributed levels specify such a thing so regular
users won't have encountered this bug. It's a one line fix.
Altar placement in temples also had a quirk of a similar nature. It
wouldn't trigger rn2(0) problems but would always place the altar to left
of mid-point in rooms with even width and above the center point in ones
with even height. Now the placement is randomized so that sometimes it'll
be to the right and/or below mid-point in such cases.
This also simplifies a couple other instances of similar expressions
that I spotted.
Remove several duplicate includes I discovered while reconciling the
vms Makefile. All of these are already being brought in via hack.h so don't
need to be explicitly included after it.
The previous change only affected mimics that started mimicing after the
level was created. This change tries to perform a similar behavior for
randomly placed mimics that are forced to mimic a boulder on special levels.
In this case, since the symbol is fixed and the location is "random", try
several times to find a non-trap location for such a mimic.
<Someone> reported that randomly placed aquatic monsters can end up in
lava. The placement code allowed lava whenever the WET flag was passed to
it. This was so passing (WET|DRY) would match all locations, but it's not
appropriate for when only the flag WET is used. Since we have no levels
currently affected by this bug, I fixed it only in the trunk.
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.
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.
