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.
- 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
The prior behavior was an ugly kludge that treated rumors as
only-eligible-to-appear-from-fortune-cookies if they contained the
string "fortune" or "pity". This commit gets rid of that system and
introduces a system where each rumor can be specified as such by
prefixing it with "[cookie]".
In order to avoid changing existing behavior, I have applied the
[cookie] prefix to all the rumors which were affected under the old
rules. However, several rumors seem like they were misclassified under
the old rules, and I am in favor of changing them as follows:
Should be made cookie-only (they only really make sense in context of
eating a fortune cookie):
- "Ouch. I hate when that happens."
- "PLEASE ignore previous rumor."
- "Suddenly, the dungeon will collapse..."
- "Unfortunately, this message was left intentionally blank."
Should be made non-cookie-only (they make sense if they appear as
engravings, Oracle messages, or artifact whispers):
- "They say that a gypsy could tell your fortune for a price."
- "They say that fortune cookies are food for thought."
This was added before level flipping, and its purpose effectively was to
randomize the interior secret door layout (and thus the entire level,
because the rest is vertically symmetric) by manually flipping it.
Now that the entire level can be flipped and produce this same effect,
this is no longer necessary.
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
1. Add "engraved room floor" pchar sym (S_engroom). The symbol that
displays at the engraved part of a room (not a corridor though).
The default symbol is '`' which is currently never shown if people
have defined the boulder symbol to '0' and statues are displayed as
monster symbols. It is bright blue.
Add some stylized variations of the S_engroom symset to some of
the symsets.
2. Add "engraved corridor" pchar sym (S_engrcorr). The symbol that
displays at the engraved part of a corridor. The default symbol is
'#', and it matches the symbol for corridor from for whatever the
current symset uses. It is bright blue to match the color of the
S_engroom symbol. Using the normal corridor symbol for display
preserves the lines of the corridor so is not as visually-disruptive
as a smaller symbol would be. Explicit entries that match the S_corr
symbol have been added to the symset file.
Magic mapping and clairvoyance impacts yet to be determined.
The Guidebook updates will come later.
