Makes Sokoban far less tedious when you don't have to worry about
monsters randomly popping up in the trap hallway while you're pushing
the boulder.
Adds a new exclusion zone for monster generation, and the goodpos
routine avoids the zones when GP_AVOID_MONPOS is used.
I forgot to add the code to flip the exclusion zones when implementing them.
Also improve the zone coordinates so they're correct outside of map contents.
The g? structs had a mix of variables that were written to
the savefile, and those that were not.
For better clarity and to distinguish those that end up in
the savefile, relocate some g? variables that get written
directly to the savefile into different structs.
This updates EDITLEVEL, although technically it probably
didn't need to, since savefile contents are not changing.
Details:
gb.bases -> svb.bases
gb.bbubbles -> svb.bbubbles
gb.branches -> svb.branches
gc.context -> svc.context
gd.disco -> svd.disco
gd.dndest -> svd.dndest
gd.doors -> svd.doors
gd.doors_alloc -> svd.doors_alloc
gd.dungeon_topology -> svd.dungeon_topology
gd.dungeons -> svd.dungeons
ge.exclusion_zones -> sve.exclusion_zones
gh.hackpid -> svh.hackpid
gi.inv_pos -> svi.inv_pos
gk.killer -> svk.killer
gl.lastseentyp -> svl.lastseentyp
gl.level -> svl.level
gl.level_info -> svl.level_info
gm.mapseenchn -> svm.mapseenchn
gm.moves -> svm.moves
gm.mvitals -> svm.mvitals
gn.n_dgns -> svn.n_dgns
gn.n_regions -> svn.n_regions
gn.nroom -> svn.nroom
go.oracle_cnt -> svo.oracle_cnt
gp.pl_character -> svp.pl_character
gp.pl_fruit -> svp.pl_fruit
gp.plname -> svp.plname
gp.program_state -> svp.program_state
gq.quest_status -> svq.quest_status
gr.rooms -> svr.rooms
gs.sp_levchn -> svs.sp_levchn
gs.spl_book -> svs.spl_book
gt.timer_id -> svt.timer_id
gt.tune -> svt.tune
gu.updest -> svu.updest
gx.xmax -> svx.xmax
gx.xmin -> svx.xmin
gy.ymax -> svy.ymax
gy.ymin -> svy.ymin
Related note:
There are some pointer variables that are heads of chains that were not
moved from 'g?' to 'sv?', because they are not actually written to the
savefile directly, but the objects/monst/trap/lightsource/timer in the
chains they point to are. That can be changed, if desired.
Examples: gi.invent, gm.migrating_objs, gb.billobjs, gm.migrating_mons,
gf.ftrap, gl.light_base, gt.timer_base
Add a theme room with multiple visible teleportation traps
which will always teleport to specific locations in the same level.
Teleport trap change from xNetHack by copperwater <aosdict@gmail.com>.
From a reddit thread: a 'mausoleum' theme room picked a vampire for
its occupant and applied the wait-for-you strategy to it. Hero's ESP
or monster detection showed a meditating vampire bat. Change monster
creation by the special level loader (which also handles theme rooms)
to force such a creature into its normal vampire form.
That revealed an older bug which wouldn't have been exercized prior
to theme rooms: a meditating vampire could and would shape change
without ceasing meditation. Make it not shape change rather come out
of its trance.
new .h files: hacklib.h selvar.h stairs.h
new .c files: calendar.c, getpos.c, report.c, selvar.c, stairs.c,
strutil.c, wizcmds.c
cleanup of hacklib.c and mdlib.c
hacklib contains functions that do not have to link with the core
relocate wiz commands from cmd.c to wizcmds.c
relocate CRASHREPORT stuff to report.c
relocate getpos stuff from do_name.c to getpos.c
remove temporary struct definition from extern.h
cross-compile PRE-section split into cross-pre1.370 and cross-pre2.370
Windows sys/windows/Makefile.nmake and sys/windows/Makefile.mingw32 and
visual studio project file updates
Unix sys/unix/Makefile.src, sys/unix/Makefile.utl
populate selvar.c and selvar.h
build on MS-DOS (not cross-compile) Makefile updates
for sys/msdos/Makefile.GCC (untested)
vms updates for above (untested)
- add nhl_pcall_handle() to wrap all nhl_pcall calls that didn't check
return value and either panic() or impossible()
- add --loglua (unix only) to dump Lua memory and steps info to livelog
- remove old logging
- set memory and step limits on all Lua VMs
If tutorial is entered, we get following leak on exit:
=================================================================
==81358==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 96 byte(s) in 3 object(s) allocated from:
#0 0x7f6996edefdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x5601c255bcbb in alloc /home/miku/src/NetHack/src/alloc.c:71
Indirect leak of 5064 byte(s) in 3 object(s) allocated from:
#0 0x7f6996edefdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69
#1 0x5601c255be1e in alloc /home/miku/src/NetHack/src/alloc.c:71
#2 0x5601c255be1e in dupstr /home/miku/src/NetHack/src/alloc.c:236
SUMMARY: AddressSanitizer: 5160 byte(s) leaked in 6 allocation(s).
Fix this by freeing the cloned selection before returning.
selection_getbounds() has a check and early return.
Initialization will ensure a known state if that early return
were ever taken.
This is an alternative approach to pr #1163.
Adds a new lua command
des.exclusion({ type = "teleport", region = { x1,y1, x2,y2 } });
which allows defining "exclusion zones" in the level, areas where
random teleports (or falling into the level) will never place the hero.
Does not prevent targeted teleportation into the area.
Breaks saves and bones.
Revealed this bug when testing the previous commit:
Themed room generation with a randomly placed map involves picking a
single random point on the map at which to plop it down, and then
declaring the themed room failed and exiting if it would go beyond the
map bounds or overlaps with an existing room. In the process,
xstart/ystart/xsize/ysize have been modified, but weren't getting reset.
(They would get reset if the map successfully got placed and it had a
contents function, as of commit 4af086b, but there wasn't handling for
the failure to place it.)
I traced a memory corruption bug in xNetHack to a themed room that
looked something like this:
function()
des.room({ type="themed", contents = function()
des.feature({ type='sink' })
...
end })
end
Placing a feature at a random spot within a room or region is a
reasonable thing for the parser to handle, but the code was not equipped
to handle it, and so the unspecified x and y set as -1 got passed
directly to SP_COORD_PACK, ending up as coordinates way off the map.
Since sel_set_feature does not do an isok() check, this ended up writing
data to unrelated memory.
This commit does the following things:
- Enables des.feature() with no coordinates specified, both via a table
with 'type' set, and as the single string argument. When no
coordinates are specified, it will pick a random normal-floor spot
within the enclosing room or region if there is one, or anywhere
on the level if there isn't.
- Prevents sel_set_feature from corrupting memory outside
g.level.locations. Additionally, if EXTRA_SANITY_CHECKS is defined and
this gets attempted, it causes an impossible.
- Guards the existing "door coord not ok" Lua error with an immediate
return from lspo_door.
- Adds similar "coord not ok" errors to all the other locations in
sp_lev.c which did not already check for a unspecified/invalid
coordinate and for which a random coordinate is nonsensical:
des.terrain(), des.drawbridge(), and des.mazewalk().
I thought there were more object fields that currently only accept ints
but ought to accept booleans, but when I checked I found that most of
them do already, and the ones that take ints are the ones that the
number carries meaning (spe, recharged, etc).
Except for trapped. In struct obj, otrapped is a 1-bit flag, so there's no
good reason for the level parser to treat it as a type error if someone
intuitively makes a des.object call with trapped=true or trapped=false.
Change it to an optional boolean argument, like the other boolean flags
(locked, greased, etc).
Note that get_table_boolean_opt still accepts ints, so existing uses of
trapped=0 or trapped=1 won't be affected.
Something that's reasonable to expect to see in Lua files is something
like:
local sel4 = sel1 - sel2 - sel3
or more generally, producing a selection from subtraction that will then
be used in subsequent selection math.
I discovered this wasn't actually working correctly, and that it also
applied to the xor operation. The reason behind this is that
l_selection_sub and l_selection_xor create a new selection from nothing,
which by default has "lower" bounds of COLNO, ROWNO and "upper" bounds
of 0,0. Iterating across the intersecting rectangle of both selections
does not reliably set the bounds of the resulting selection properly,
since the first selection_setpoint with a value of 0 will cause the
selection's bounds_dirty flag to be set, at which point they will cease
to change as more points are added.
Then this selection with its incorrect boundaries is pushed back onto
the Lua stack, and becomes the first operand of the next subtraction
(i.e. selr in the first l_selection_sub becomes sela in the second
l_selection_sub). Depending on how broken the bounding box is, results
may vary, but if the bounding box is still (COLNO,ROWNO,0,0), the
resulting selection will have no points selected at all.
This fixes this problem by forcibly recalculating the bounds of the
result selection, so any subsequent operations on it will be valid.
This replaces most of commit 0ca2af4d8b
from a couple of days ago with something more robust. That change
actually introduced redundant code that caused fountain and/or sink
count to be off instead of preventing it.
Revise set_levltyp() to update level.flags.nfountains and
level.flags.nsinks if setting the type to or from fountain or sink.
A bunch of places that were setting levl[x][y].typ directly needed
to be revised to use set_levltyp() instead. set_levltyp() itself
hadn't been updated to handle LAVAWALL (to force such to be lit).
- add a themeroom with random buried zombifying corpses
- disturbing buried zombies makes them revive much faster
- lua des.object() now returns the object it created
Defining des.object({ id="large box", locked=false })
was the same as random locked state. Make it actually mean unlocked,
and not defining locked at all means random.
Special level creation could make levels with boulders on top
of lava or water; this was caused by mazewalk populating the maze
before the rest of the level was created.
Add a post-level-creation map cleanup routine, where boulders
and traps on liquid terrain are removed.
Doors weren't getting added to the correct subrooms in certain cases.
Also fix one of the themerooms, because doors have to be added
after subrooms; there was a possibility of no door to the subroom(s)
in that themeroom, because the subrooms overwrote the doors in
the parent room.
Test case for the subroom doors:
Large room, with a medium subroom, with a tiny subroom inside that.
The doors go from outermost room <-> tiny innermost room <-> middle room.
des.room({ type = "ordinary", x = 1, y = 1, w = 10, h = 10,
contents = function()
des.room({ type = "ordinary", w = 6, h = 6, x = 2, y = 2,
contents = function()
des.room({ type = "ordinary", w = 2, h = 2, x = 0, y = 0,
contents = function()
des.door({ state="random", wall="south", pos = 1 });
end
});
des.door({ state="random", wall="north", pos = 1 });
end
});
end
});
Before this fix:
ROOM: ndoors:1, subrooms:1
SUBROOM: ndoors:1, subrooms:1
SUBROOM: ndoors:1, subrooms:0
after this fix:
ROOM: ndoors:1, subrooms:1
SUBROOM: ndoors:1, subrooms:1
SUBROOM: ndoors:2, subrooms:0
The intuitive behavior when passing a selection to des.region, e.g.
local foo = selection.area(07,02,10,24)
des.region(foo, "lit")
is that foo will remain unmodified for further use. However, this wasn't
the case whenever making a lit region from it, because in order to light
walls adjacent to the lit area, the selection was having a grow
transformation applied as well. (This also seems like a problem - it
grows the selection even if what is being lit is not surrounded by
walls. I added a note in lua.adoc about this behavior.)
This fixes the selection mutation by cloning the passed-in selection and
growing the clone which leaves the original one unaffected.
This should not affect any special levels currently because the only
instance of des.region being used with a selection appears to be in
bigrm-2, which specifies *unlit* areas, which did not get grown.
