Add two new themeroom functions that are called when generating
the level: pre_themerooms_generate and post_themerooms_generate,
calles before and after themerooms_generate.
Allow the buried treasure -themeroom to put down an engraving
anywhere on the level, hinting at the location of the treasure.
des.object contents function now gets the generated object passed
to it as a parameter.
Previously, the tetris-shaped rooms were always either
normal rooms, or turned into shops or other special rooms
in NetHack core. Now, the themed room lua code first picks
the themed room (which can be a themed or shaped), and some
of those will then pick a random filling (eg. ice floor,
traps, corpses, 3 altars).
Adds a new lua binding to create a selection picking locations
in current room.
The content-function in special level regions now get passed
the room data as a parameter.
This is a large iteration on a previous implementation of making
nh.getmap() parse its coordinates as relative to the last defined map or
room rather than absolute to the entire level. Now, everything in the
nh.* and obj.* functions interprets coords as relative rather than
absolute. (By default; if no map or room has been defined, or if the lua
code is executing after level creation is done, they will interpret the
coordinates as absolute).
The general motivation is basically the same - routines that use
absolute coordinates are difficult to use in level creation routines,
because then the designer has to remember to convert the relative
coordinate to an absolute one (and that was impossible before
nh.abscoord was added, particularly in themed rooms). And once
nh.getmap() takes relative coordinates, it would be very strange to have
all the other functions (setting timers, burying objects, etc) remain
with absolute ones.
In a couple places, code is changed to account for coordinates that are
relative to a *room* (which uses g.coder->croom->[lx,ly] as an offset,
instead of relative to a *map*, which uses [xstart,ystart].
Specifically, selection.iterate did not account for this, and without
this the ice themed room timer was not being started in the proper
place.
All tests are updated to respect the new behavior. Most of the modified
functions are not actually used anywhere in level files; the one
exception is starting a timer in a themed room, and that has been
adjusted.
Documentation updated as well to clarify when various things are tossing
around relative and absolute coordinates, both in comments and in
lua.adoc.
Allow creating webs without spiders in the lua level scripts:
des.trap({ type = "web", spider_on_web = 0 });
Based on xNetHack commit by copperwater <aosdict@gmail.com>.
Also changes the Spider nest themed room to generate without
spiders when the level difficulty is 8 or less.
Allow specifying "waiting" for monsters created via lua level scripts.
This sets the monster strategy to make it wait for the hero
to be in visual range before allowing the monster to move.
Also makes the monster inside the Mausoleum themed room use this feature,
to prevent out of depth liches bothering the player unprovoked.
For example:
des.monster({ class = "D", waiting = 1 });
des.region() accepted booleans for the joined field, whereas des.room
accepted xchars. These were only being used as truth values, so this
converts the room ones into booleans for consistency. I don't think
accidentally using an int or a boolean wrongly would actually crash the
level generator, but consistency is good.
This converts an schar field in struct mkroom into a boolean; on most
systems these are probably 1-byte types and save files won't be broken,
but it might be best to treat this as a save breaker anyway.
This themed room boasts two shops, a weapons and an armor store,
that can generate in a number of different configurations.
Makes the random corridor joining routine obey unjoined areas.
Fixes a bug in shopkeeper naming routine, where multiple shops
of the same type on the same level might reuse the shopkeeper name.
This is modified and consolidated commit from xNetHack by
copperwater <aosdict@gmail.com>.
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.
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).
"When a room is created and passed down to a contents function in
Lua, the width and height properties of that room are computed by
subtracting lx from hx and ly from hy, which means e.g. a room
which is 8 floor squares wide and 5 tall appears to the contents
function as having a width of 7 and height of 4. This patch fixes
that off-by-one."
I don't understand the details here: should a room's dimensions
include its boundary walls or just the inner amount? This change
didn't seem to cause any problems so I've put it in.
Closes#345
Allows creating shaped or themed rooms for the Dungeons of Doom
via lua script.
Invalidates bones and saves.
Makefiles updated for unix/linux by adding themerms.lua, but other
OSes need to have that added.
