Add some basic spellcasting stuff to the tutorial: read a spellbook,
cast a spell. If the hero doesn't have enough energy, just adds
a note saying so.
Remove/restore the known spells when entering/leaving the tutorial.
Seems like several new players did not find the "hidden" stairs.
Add iron bars to show a glimpse of them - the hero still needs
to find the secret door in to the room.
This is partly for balance reasons (so that clearing the Castle
helps towards the level 14 Quest unlock) and partly as a clue to
players spoiled on previous versions that the Castle wand now works
differently.
Part 3 of implementing wish spreading. These items are each worth
most of a wish for non-illiterate games (most games wish for a
magic marker, and a magic lamp gives a wish 80% of the time).
The placement of the random item could be better (currently it is
purely random, which is occasionally interesting but often boring),
but this will serve as a base for experimenting with the balance
properties of the moved wishes.
The two options are very similar but probably mutually exclusive
except when using look-here and look-into-container (both via ':')
with the default setting for 'sortloot', or with inventory when
'sortpack' has been toggled off.
This removes 'use_menu_glyphs' and changes 'menu_objsyms' from a
boolean to a compound taking six possible values:
| 0: no object symbols in menus,
| 1: append object class symbol to object header lines (same as old
|menu_objsyms boolean),
| 2: include object symbol in menu entry lines for objects (same as
|recently added use_menu_glyphs),
| 3: both 1 and 2,
| 4: display as #2 but only if the menu lacks class header lines,
| 5: if header lines are present, display as #1; if headers are not
|present, then display as #4 (which will implicitly be #2).
Default is #4.
Effectively replaces the options portion of pull request #1406 and
retains the functionality, but not as default for normal menus.
Guidebook.tex is only partially updated. Someone else will need to
finish that.
Issue reported by elunna: when a room gets converted into a theme
room with fill type Garden, its walls are changed to trees but any
secret doors in those walls are still displayed as regular walls.
This adds a new D_ARBOREAL flag for secret doors, used to force them
to be displayed as a tree instead of a wall.
Fixes#1309
The themed room code previously assumed that on any given level, at
least one room or fill would resolve as OK to generate there. However,
that's not a great assumption to make, and if it happened to be broken,
the first themed room or fill would arbitrarily be executed, even though
it wasn't eligible. Fix that by setting the initial pick to nil, and
raising an impossible if it's still nil after trying to choose a random
room.
A common pain point I encounter when working on themed rooms is making
specific rooms generate. The only ways to do this were mass commenting
out the rooms not being tested, or hacking in different room frequency
values (even more annoying when testing a fill, not a room, or testing
pure-function rooms/fills that have no frequency).
This change solves that problem by allowing a wizard-mode user to define
THEMERM or THEMERMFILL environment variables to make specific rooms or
fills generate.
The first part of this change is converting all themed rooms and fills
that were plain functions into tables, and converting their comment
names into actual names in those tables. The names are not intended to
be shown during gameplay, but instead serve as values that THEMERM or
THEMERMFILL can be matched to to generate those rooms. It's no longer
possible to have a function themeroom; this will raise an impossible.
As far as I'm concerned, this is a good change because it allows some
code simplification of themerooms_generate and makes it easier to add
difficulty or eligibility parameters to rooms.
The second part of this change is adding a new nh.debug_themerm function
to make the environment variable values accessible to themerms.lua. I
looked for an existing way to do this but didn't see one (nh.variable
is the closest but appears to be for variables that get saved).
The final part is inserting behavior into the actual themeroom
generation code that changes how they generate when either a room or a
fill is set. I don't think it's safe to generate every single room with
the requested type or fill - that might lead to cases where the stairs
or a magic portal cannot generate. So it creates ordinary rooms half of
the time, which still results in plenty of themed rooms on levels.
Another thing to note is that any themed room using filler_region will
still only pick a fill 30% of the time. If one specifies both a fill and
a room that uses filler_region, many of those rooms will appear without
a themed fill.
I hope this doesn't break anything. There seemed to be one or two
misplaced 'end' statements, but after some massaging I'm not sure
about this anymore.
There were lots of wide lines; those are easy. The Water-surrounded
vault had very inconsistent indentation so was harder to untangle.
This implements a TODO to return an object's material as text rather
than as an int when a Lua file requests all the details about an
object's objclass. That is as simple as looking it up in materialnm[].
With that done, it's possible to clean up the one use where a Lua file
looks up the material of an object it generated, in the
"water-surrounded vault" themed room, previously an inflexible 19 but
which can now be compared directly to "glass". It also enables
shortening the comments that follow since the branches of the if
statement are now obvious.
When testing the analyzer lint fixes for pager.c, I noticed that //
wasn't finding the data.base entry for stairs when examining the up
stairs on level 1. It is labelled "branch stairs up" which doesn't
match "stair*".
Dented pots got their own encyclopedia entry, so they shouldn't still
match to "helmet". Even without this change, they match the "dented pot"
entry correctly, but only by virtue of it appearing earlier in the
encyclopedia.
Inverting the match to "~dented pot" isn't necessary since it isn't
something that would otherwise match "helmet", so just remove it.
When the des.monster() statements for the vampire ladies were changed to
use the lua-table form, the coordinate argument was not given the coord=
name in the table, so the lua loader was ignoring it and the vampire
ladies were placed on random spaces on the level. Fix this by supplying
the coord=; testing shows that they now appear back in the niches.
Also lowercase the monster species id "Vampire Lady" to "vampire lady".
The uppercase didn't affect the species being generated but having the
id be the same case as in monsters.h is consistent with how it's done
everywhere else.
Noticed when testing the recent bec de corbin change which makes ravens
generate as peaceful; if you happened to enter medusa-3 while wielding
one, all the ravens are peaceful. Even without one, if you entered the
level as a neutral character, some of them would randomly be peaceful
due to matching alignment. But in the medusa-3.lua file, the ravens are
all unconditionally flagged as hostile.
The reason for this behavior is that the lua loading code does not
recognize "hostile" (instead peaceful=0 needs to be set), so it does
nothing and leaves the ravens to generate as if it had been unspecified.
It appeared to affect only these ravens; no other des.monster() uses
hostile=1 instead of peaceful=0.
This bug has been around in the 3.7 development branch since the change
to Lua, but doesn't happen in 3.6 because the des parser does interpret
"hostile" as meaning never peaceful.
I considered augmenting lspo_monster so that it could handle "hostile"
and treat it like peaceful=0, but figure it's probably better not to
have two different booleans that control the same flag (what if someone
specified peaceful = 1 and hostile = 1?)
Noticed a few corners in some bigroom maps were | instead of -, which
doesn't have any gameplay effect but was mildly annoying for what I was
doing at the time (copying the maps out into documentation that is
supposed to show what the maps look like in-game).
There are other special levels out there that still use | for corners;
this doesn't address those, only the bigrooms.
Be more consistent in the use of path separators.
Add a second version of Makefile variables that contain paths,
one with a trailing separator, and one without (prefixed with R_
for use in Makefile rules).
Also, in dat/luahelper,
Updates due to correspond to the Makefile.nmake changes.
Add Makefile variable AWK to use $(AWK) instead of hardcoded awk.
Use by:
make -f dat/luahelper [target]
Target examples:
Visual Studio nmake : make -f dat/luahelper devhelp-nmake >file.txt
msys2 GNUmakefile : make -f dat/luahelper devhelp-msys >file.txt
Xcode project.pbxproj: make -f dat/luahelper devhelp-xcode >file.txt
all: generate txt files for all the above
When tutorializing a command that uses a ^X notation, show Ctrl-X
instead. Also show an explanation of the ^X nearby.
The only ctrl-key combination that can currently happen in the tutorial,
without rebinding keys, is the kick-command.
Fixes#1327
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 normally force DECgraphics for tty and for curses so hadn't noticed
this before. I recently let curses default to 'cursesgraphics' and the
engraving-in-room character was crossed horizontal and vertical bars,
the crosswall character. It certainly stood out in the middle of a
room, but the emphasis seems out of proportion for "engraving here".
There is no 'epsilon' among the DEC line drawing characters. Curses
might be able to render one, but not with DEC-style rendering of 0xEE.
Comment out S_engroom so that curses inherits the default backtick.
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>.
Another tweak to PR #1240. Vampires start out vampshifted to
bat/fog/wolf form. Marking them as 'waiting' forces them back to
vampire form. Testing that revealed one of the brides as a vampire
lord rather than a vampire lady. That could probably be construed
as being politically correct but doesn't match the source material.
The reversion from vampshifted to vampire entailed a 10% chance of
toggling gender, comparable to hero self-polymorph. Don't do that
for vampires. From the player's perspective they change randomly but
from their own perspective, the change is controlled.
