armorstatus, and terrainstatus
This adds three special status items to show at a glance what the hero
is wielding, wearing, and standing on.
Each of the three items has its own boolean option rather than try to
fix them in with the existing opttional status conditions. After a
lot of testing, I think the weapon and armor ones will prove useful
but the terrain one probably won't be.
Presently it is implemented for tty and curses. When I developed it
six years ago, it was also working for X11 but I'm not able to test
the resurrection of that part so have left it out.
This removes or updates several true rumors that have become
misleading or inaccurate due to changes to the mechanics they were
describing, and adds several new rumors describing mechanics that
are either new, or are intended to be a larger part of the game
than they were in previous versions.
More oracularities describing the new mechanics are needed, but I
haven't managed to get into the write frame of mind to write in the
Oracle's voice yet...
When playtesting NetHack heavily, I observed that most of the time
it wasn't placing much strain on my wrists, but Sokoban was an
exception: travel, farmove, etc. can normally be used to avoid the
need to spam keys, but they don't work while pushing a boulder, and
the boulders often need to be pushed along precise routes, so you
have to tap out every movement. This becomes particularly straining
when pushing in the last few boulders, as you have to push them a
long way along the goal corridor.
This commit adds rolling boulder traps to Sokoban that will
automatically roll boulders along the goal corridor, meaning that
you don't have to push them there manually. This considerably
reduces the number of keystrokes needed to solve Sokoban, without
making any significant change to the difficulty of the levels.
Some of the designs had to change slightly in order to make room
for them, but not in a way that meaningfully changes the solution.
- bmp2iff_host: convert nhtiles.bmp to Amiga IFF tile files. Uses
the AMIV UI palette in pens 0-15, remaining pens filled with tile
colors sorted by frequency.
Usage: bmp2iff_host -planes N input.bmp output.iff
- xpm2iff_host: convert XPM to IFF for tomb.iff (RIP screen).
Adapted from xpm2iff.c, Copyright (c) 1995 Gregg Wonderly.
- Auto-select tiles32.iff (5 planes) or tiles16.iff (4 planes)
based on screen color depth at runtime.
- Fix NO_GLYPH in amiv_lprint_glyph: return early to prevent
blitting with uninitialised data (caused black spots).
- Add AmigaFont symbol set to dat/symbols for AMII text mode.
Add a new parameter to des.monster, m_lev_adj, which is a level
adjustment for the monster. This only applies to the monster's
level, so basically only affects the spellcasting, it does not
change the monster's hit die or inventory.
Change one of the shamans in Orctown to be 3 levels higher.
Change 'v' from #versionshort to #chronicle.
Change 'V' from #history to #versionshort.
History can still be accessed either directly with the extended command,
or via the help menu.
Versionshort now accepts the m-prefix, and then shows the longer version.
As of the change to allow for item probabilities that don't add up
to 1000, it's become a little difficult to figure out the exact
probabilities from the source code, which makes it hard to balance
item generation. Adding a tool to list the probabilities helps.
Part of the problem is that changing an item's probability without
balancing it elsewhere is usually wrong: doing that would in effect
take the probability equally from (or add the probability equally
to) all other items in the class, which might break the balancing
of those items due to the probability change.
As such, it is usually better to make an intentional decision about
which items should be less and which items should be more likely to
generate, then change them in a balancing way (meaning that the
probabilities of objects that weren't intentionally changed remain
unchanged). Doing a complex such change makes arithmetic errors
fairly likely, though, so it's useful to have a command that verifies
that it's been done correctly.
This command is primarily intended as a development aid, so it's
included only in debug builds and pre-release builds (the same as
other similar commands like #wizmondiff).
These are displayed in discoveries, and a new 'price_quotes' option
allows them to be displayed for un-IDed objects in other contexts
too (the idea is that you turn on the option while identifying
objects and off for general play).
Invalidates existing save files.
This adds a "reroll" option that lets players reroll their
character's attributes and starting inventory. Although I generally
think doing this makes the game worse, a) some players are going to
do it regardless and b) if a player is going for a challenge game,
rather than to win, it may be required. So in the absence of an
option like this, players repeatedly start and quit games instead,
creating a large number of junk logfile entries and generally
causing problems for other players on the same shared machine
(because repeatedly reloading the game is very CPU-intensive).
This should in theory be windowport-agnostic (although in practice
it may not be). Tested on tty, X11 and curses; on tty and X11 it
works fine (although X11 treats the change in attributes as
something that needs a status highlight), on curses it is slightly
jankier in terms of what other windows are drawn in the background
(but still plays correctly and I suspect this is a pre-existing
bug).
To form a complete implementation, we will need to consider the
following:
- Should there be a delay on a) starting the game and/or b)
rerolling? If so, what should it be (maybe configurable via
sysconf?)
- Should we take more steps to discourage players from rerolling?
It would be bad if players see the option exists and turn it on
just because it exists, or (worse) treat it as condoning the
particular style of play.
- Should we take steps to detect that players are rerolling
manually and a) tell them to use the option instead, b) tell them
that this is not an intended way to play (and may make the game
less enjoyable and/or prevent them getting the practice they need
to eventually win)?
Breaks save and bones files.
Data typo affecting '?' command's "longer explanation of game options".
Change the indication of menu_objsym's default value from [5] to [4]
since 4 is the actual default value in the code and the Guidebook.
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?)
