Sourced from xnethack. Seems like an excellent candidate for
replacement, since the quote gets across what shades are and also
hints at their weakness.
This commit adds entries for the following items:
- Credit card
- Silver bell
- Bell
- Walking shoes
- Iron shoes
- Hard shoes
- Dragonbane
- Gauntlets of Power
- Gauntlets of Fumbling
- Gauntlets of Dexterity
- Potion of Sickness
- Splashes of Venom (Various)
- Shields (Various)
The following monsters also now have associated entries:
- Stalker
Reported 11 years ago, the level definition for the Samurai quest
home level specifies a throne room and entering it gives the "opulent
throne room" message, but there isn't any throne.
Initially I was going to add a throne but decided that its lack is
probably intentional. The throne room designation is used to give
periodic atomspheric messages. That's my guess anyway.
Alter the room entry message there to omit "throne" from "you enter
an opulent throne room". Add a no-throne comment to Sam-strt level
definition.
While in there, make Lord Sato's katana and splint mail explicitly
rustproof and either blessed or uncursed. (The mail was already
implicitly rustproof because splint mail created on the Sam quest
home level always is, like for a Samurai's initial inventory.)
Fairly old pull request from copperwater: add new paranoid_confirm
setting 'trap'.
The old commit suffered from bit rot and merging needed too much
fixing up despite there not being many bands of change in the commit's
diffs. I ultimately redid it from scratch, although the two biggest
chunks of code started with copy+paste of the pull request's commit.
It operates like paranoid:pray. Setting paranoid:trap adds a new
"Really step into <trap>?" y/n prompt when attempting to move
into/onto a known trap, even if an object covers it on the map.
Setting both 'paranoid:Confirm trap' turns that into a yes/no prompt.
(Adding 'Confirm' affects other paranoid confirmations; in addition
to requiring yes<return> rather than just y to accept, it also forces
no<return> to reject.)
However, moving into a known trap that is considered to be harmless
behaves as if no trap was present. Some of the trap classification
might be out of date; several types of traps have undergone changes
since implementation of the original pull request, notably anti-magic
field. When the hero is hallucinating, all known traps are considered
harmful since the map no longer reliably describes them.
Preceding a movement command with the 'm' prefix also behaves as if
no trap was present, bypassing confirmation for that move, similar to
how paranoid:swim currently behaves. Being stunned or confused also
behaves as if no trap was present, taking priority over hallucination.
This updates the documentation.
Supersedes #259Closes#259
Update the 'optmenu' data file to describe the simple options menu
(new paragraph containing just a one sentence) as well as the full
options menu (still several paragraphs). Visible by choosing '?' in
the full options menu or the 'how to set options' choice in the main
help menu.
Add a line to the simple options menu about how to get the full
options menu. Only shown if you type '?' to toggle on "show help";
taken away again if you use '?' to toggle back to "hide help".
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.
I was going to add a joke entry for "microscope" to data.base and
disocovered that stethoscope was missing. (There is a rumor about
cursed ones.) Add a lame entry for it so that the joke has something
to relate to.
Searching for "stethoscope" led to the "cope" comment, which is near
the "cornuthaum" entry. Add a comment giving Janet credit for coining
the term.
I realized that the previous attempt was misusing the item's locked
state when attempting to create the chest that the item would go into,
which was absurd. I hadn't realized that I was also misspelling
"olocked" as "locked".
This fix was already in progress before the mail about the previous
commit. I did try switching to 'lckd = nil' for the attempt to retain
the chest's random locked/unlocked state but that resulted in all the
chests being created locked. Using separate box=... expressions does
work as intended. Doing something with totable() doesn't seem to be
necessary.
The indentation seems to be messed up compared to the rest of the
file (initial indent of 5 with increments of 4 rather than 3 and 3);
I have't done anything to try to fix it.
When generating an "escape item" inside one of the chests in the
"water-surrounded vault" theme room, make sure that the chest is not
locked if the item is made of glass or crystal. Otherwise kicking the
chest to get access to its contents might destroy the item.
I imagine that this could be done more cleanly, but after quite a bit
of thrashing about I have something which seems to work. To test, I
temporarily modified object shuffling to force wand of digging to be
made out of crystal and gave the water-vault a very high generation
frequency.
Water vaults are one of the few places that can/will generate completely
sealed off in a normal level. Other such spots are designed to provide
a guaranteed means of escape (vault guard, scrolls of teleportation in
niches, etc) -- water vaults were an exception that didn't do this, so a
hero who fell into one from above could have ended up in a position
where she had no choice but to wait to starve to death or #quit. Provide
an escape item in one of the vault's chests to give a hero more options
in that position.
Also fix a minor mistake (I'm pretty sure, though I'm not a Lua expert
enough to be certain) in an nhlib.c comment describing how to use
obj.addcontent() -- when called as box.addcontent(contents) as the
comment suggested it produces an error, but works OK when called as
box:addcontent(contents) or obj.addcontent(box, contents).
An issue from nearly three years ago, reported by Anerag: asking
player whether to really pray isn't paranoid enough because it
accepts 'y' rather than requring "yes".
This changes it to require "yes" followed by <return> or <enter> if
paranoid_confirm:Confirm is also set. (A side-effect of that is
explicit "no<return|enter>" is required instead of just 'n' to
decline--for all the paranoid confirmations, not just for prayer.)
This extension of paranoid:Confirm applies to paranoid:AutoAll too.
A comment asks why paranoid_confirm:pray is different from the other
paranoid questions in the first place. The answer is that when it
isn't set, no confirmation prompt is issued at all. The others all
have y/n confirmation prompts when the corresponding paranoid option
isn't set.
Once upon a time there was a boolean option called 'prayconfirm' that
issued "really pray?" prompt when True. It was added after players
whinged about typing Alt+p when they meant to type Alt+o. When the
more advanced 'paranoid_confirmation' was introduced, paranoid:pray
superseded prayconfirm, but it still only issues a confirmation
prompt where there normally wouldn't be one rather than change an
existing one to require "yes<return|enter>" instead of 'y'.
Closes#303
Issue most recently reported by Xdminsy (previously reported by
others): it is too easy to accidentally pick choice 'A' in object
class selection menus for menustyle:Full. Previous change relevant
to this was to exclude choices 'A' and 'a' from being set by '.'
(choose all entries) and '~' (toggle all entries). That was an
improvement but doesn't help with pressing shift when meaning to
type 'a' by those who type faster than they cogitate.
This implements a suggestion by janne-hmp: add new choice for the
paranoid_confirmation option, 'Autoall' (synonym 'Autoselect-all').
If the player sets this and includes 'A' among the choices for
class selection, prompt to confirm whether to honor it. Like
confirmation for praying, it adds an extra y/n prompt rather than
change an existing y/n prompt into a yes/n or yes/no one. If the
player declines, then nothing is selected and the operation is
cancelled rather than putting the menu back up to choose again.
OPTIONS=paranoid_confirm:autoall requires at least two letters
('au') even if the 'a' is capitalized. paranoid_confirm:a means
confirm attacking peaceful monsters. And it should be
OPTIONS=paranoid_confirm:autoall pray swim
if someone just wants to add autoall to the default paranoid bits.
The Guidebook hasn't been updated to describe the new choice since
it seems likely that it might undergo adjustments.
Closes#1065
While running the tutorial, the Save command is disabled. When the
tutorial was extended to two levels, stashing and restoring the
hero's equipment stopped working as intended if player entered the
second level. The attempted fix for that broke re-enabling Save
even if the player left the tutorial without entering its second
level.
This seems to fix things, but I'm flailing around with barely a clue
here. A couple of simpler attempts didn't work and I haven't figured
out why, so this is a bit more complex than what I wanted.
Reorganizing nhl_callback() isn't part of the fix, just avoids use
of some redundant code.
If the priest quest artifact Mitre of Holiness (a helm of brilliance,
so crystal helmet) is acquired via the quest (rather than by wishing)
make it start out tempered (aka crackproof|erodeproof).
Issue reported by AndrioCelos: if you arrived at the Wine Cellar
variation of Mines' End by falling or by level teleportion instead
of via the stairs, you could end up in the treasure chamber. If
you lacked a way to dig or to level teleport, you would be stuck.
Since most of that level is undiggable, it would likely fill up with
monsters before one that could dig would appear close enough to dig
to you and you'd eventually starve.
The initial report suggested including an escape item in the treasure
chamber. This adds a teleport region to control hero's arrival spot
instead. There was a suggestion fix things this way from copperwater
but I didn't notice that until I had already chosen this method....
Fixes#1025
Add a new debugging option, 'montelecontrol', that allows a wizard-
mode player to choose a teleporting monster's destination. If player
picks a bad spot, confirmation will be requested. If accepted, the
spot will be used even though the consequences could be bad; that's
on the player. If rejected, the destination will be assigned as if
no control had been attempted rather than try again.
The fuzzer isn't allowed to override a bad spot if it tries to pick
one. That would probably trigger a sanity_check warning; the fuzzer
causes impossible warnings to behave as if panic, so accepting a bad
spot would just be fuzzer suicide. It is allowed to randomly set the
option and maybe--though extremely unlikely--randomly pick a valid
controlled destination.
Reported by Noisytoot: going from level tut-1 to tut-2 returned the
hero's starting equipment too soon, and exiting the tutorial from
tut-2 let the hero keep any equipment acquired within the tutorial.
Entering and leaving the tutorial was being handled by lua code in
the level description of tut-1 and adding a second level messed that
up. I didn't see any way of handing that with level-specific lua
code so I made it become the core's responsibility. gotolevel()
knows when the hero is moving from one dungeon branch to another so
it can recognize entry to or exit from the tutorial easily.
While fixing this, prevent #invoke of the Eye of the Aethiopica from
offering the tutorial as a candidate destination (was feasible if it
had been entered at start of game).
Not fixed: levels visited in the tutorial become part of #overview.
Show location as "Tutorial:1" instead of "Dlvl:1" on status lines.
Only tested with tty; some interfaces handle location themselves and
may need their own fixup for this.
Fixes#1046
16 years ago the "combat" entry got inserted in between a comment and
the "cope" entry, making the comment end up being out of place. Move
that and add a bit more detail.
The second paragraph about Medusa is an excerpt from Bulfinch's
Mythology, but first paragraph is not. Insert an empty attribution
line between them. Also, remove the reference to Graeae from the
introduction since it contradicts Bulfinch, which describes them as
"three sisters who were gray-haired from their birth" and Gorgons as
"monstrous females with huge teeth, brazen claws, and snaky hair".
Reported by vultur-cadens: it was possible to encounter ettin zombies
and giant zombies at shallow levels if those levels were generated
with the "buried zombies" theme room.
This uses a simpler fix than the suggestion(s); it's only applicable
to the zombie room though.
Also, vary the zombify_mon timeout. If the hero happened to be in
the room at the time that that expired, they would all claw their way
out of the ground at once. The new variation is quite small so they
still escape burial as a group, but over the span of 21 turns rather
than all on one turn.
Fixes#1016
Two error cases with the map generation in minetn-6:
first one was the lregion placement impossible, caused by randomly
generated mines not going past the map either left or right, and
the stair generation being restricted outside the fixed map.
second was one side of the map being unreachable, because the
mines layout joined to the other side right at the edge of map
behind the small room with the "x" mapchars.
The "butterfly" shaped bigroom was missing the four fountains
in the corners of the room - this was due to my copy-paste error
when converting the bigrooms from des to lua.
Also add some variation to the bigroom.
