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.
Issue reported by vultur-cadens: when trap effect of an anti-magic
field reduced maximum energy, the result might end up with current
energy being one point higher than new maximum.
Fixes#1003
In curses, selecting a partial stack, then unselecting the entry,
and then selecting it normally, the entry still kept the quantity
from the partial selection. Make it behave like all the other
windowports by resetting the quantity when the entry is unselected.
- 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
If standing at the location of a closed door while having Passes_walls
ability, attemping to open that door with 'o' reported "you don't find
anything here to loot".
Using 'o' to loot for direction ./>/< is intentional but it ignored
the possibility of there also being a closed door present. When the
latter applies, only switch from open to loot for direction '>' so
that '.' (and '<') will open the door. Doesn't matter for creatures
that can ooze under a closed door--trying to use 'o' gets rejected for
them because they lack hands.
Also allow hero in Passes_walls form to use 'c' when at open door spot.
(For creatures that ooze under doors, 'c' is rejected just like 'o'.)
Unrelated: fix a typo in a recently added comment.
Fix the duplicate feedback given when landing on one or more items
after teleporting out of lava.
This also avoids "you find yourself back on solid water" if you are
able to survive at a water location and safe_teleds() puts you on one.
This fixes the missing message window border when restoring with
align_status:left (which narrows and forces that window to the right).
It can't possibly be the correct way to fix things but does work.
This was not a problem with 3.6.4 (the most recent pre-3.7 playground
I have on hand) but I don't have the energy to use 'git bisect' to
track done when it started to whether the cause is discernable. The
message history is put into place without going through putstr() so
differs from normal message handling.
Reported by jeremyhetzler: with recently revised curses interface,
when dismissing a menu or prompt with ESC the screen flashed.
This was caused by calling beep() when the terminal is set for
'visible bell' (of flagged as incapable of 'audible bell'); the
curses library flashed the screen deliberately. We don't want that.
Change the function key handling to not call beep() when an ESC
is typed by itself rather than being the leading part of a
multi-character escape sequence. beep() will still be called if
you type an arrow key (or other function key) when nethack is
expecting text input. That's what the recent change intended.
This also removes an early return from parse_escape_sequence()
when a number pad key generates an escape sequence. I don't have
a number pad to verify that this bit works as intended.
Closes#1002
Report was for spell-casting monster using the destroy armor spell on
hero's levitation boots while hero was floating over lava. The boots
became unworn but still in inventory, hero dropped into lava, the
boots happened to be an inventory item which got burned up, then the
call stack unwound back to the destroy armor routine which tried to
finish by deleting them but they were already gone by then. Could
also happen for black dragon breath, hero reading scroll of destroy
armor, or overenchanting the boots with scroll of enchant armor, so
not so unlikely that nobody would be expected to notice.
Initially I couldn't reproduce the object lost panic. It only happens
if the memory used by the boots is cleared or clobbered during first
time it's freed, otherwise second free doesn't notice any problem.
The 'wornarm_destroyed()' portion of this commit is sufficient to fix
this. The other bits are things I tried before figuring out how to
reproduce it, plus zeroing out any object passed to dealloc_obj().
Report was that recent Guidebook.txt contained a couple of instances
of spurious "(rq". In Guidebook.mn, "\\%USERPROFILE%\\NetHack\\(rq"
needed three backslashes near the end, the first two to insert one
into the output and the third for intended "\(rq" directive. It also
shouldn't have leading backslashes; expansion of %USERPROFILE% doesn't
need that. "\%" would work but isn't necessary.
Also, prevent "%USERPROFILE\NetHack\" from being hyphenated, plus a
minor change in wording so that it won't be in position to warrant
that.
Extend "killed by the touch of death inflicted by <monster>" to buzz().
"Killed by a bolt of cold" becomes "killed by a bolt of cold zapped by
<monster>" or "killed by a blast of cold" becomes "killed by a blast
of cold exhaled by <monster>" and so forth.
More work than expected; the zap code isn't passed enough context.
BZ_M_WAND() was producing the wrong value for wands zapped by monsters.
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
Pull request from entrez: when the curses interface was deciding
whether ">>" could fit on the bottom line of the message window, it
was off by two (based on the initial report) and ">>" clobbered the
last two characters.
Reported case was "Welcome to level " when that was appended to
another short message. It should have ended with "6. " but that had
been chopped off by ">> ". Reproducible by assigning a long name to
something, dropping an item, dropping the something, and dropping
just enough other stuff so that the named item will be reported on
the bottom message line during pickup-all, forcing --More-- before
continuing to the item below it. The item with the long name needs
to fit in the message window's width (when formatted with invent
letter prefix and trailing period) without being wrapped and not
leaving enough unused space to fix ">> ".
Closes#993
I felt it was strange that archeologist started out both
fast and stealthy, but didn't gain searching until level 10.
So, archeologists now start with searching, gain stealth at 5,
and fast at 10.
Similarly valkyries starting out stealthy felt odd, so now they'll
get it at level 3.
This leaves only the rogue starting out innately stealthy, which
feels appropriate.
Using the 'm' prefix with #tip was putting up a menu to pick between
one or more floor containers and 'choose from invent', but that
interfered with choosing Tip as a context-sensitive item-action for
carried container. Change 'm' to behave like it does with #eat and
\#quaff and several other commands: skip possible candidates on the
floor and go directly to picking something from inventory.
That prevents using 'm' to force a menu of
|a - <floor container>
|i - pick a container being carried
for any menustyle when there is one floor container. For menustyles
other than traditional, I think that's inconsequential; player needs
to answer 'n' for floor container and then get the choose-from-invent
prompt instead of 'i' and then choose. When there are two or more
containers on hero's spot, 'm' prefix isn't needed to get that menu.
Unfortuately using 'm' to override menustyle:Traditional is still a
thing players might want to do. Keep the prior behavior for that
style when multiple containers are present (dotip() already skipped
that menu despite 'm' when there was just one container). Use the
new behavior (skip floor containers) when one (or none) is present.
That's inconsistent but seems more useful than alternatives. It is
relatively unlikely that anyone who uses traditional non-menu item
selection will also use newfangled inventory item-actions so the menu
isn't likely to interfere with the latter. Update the Guidebook to
describe how Traditional differs just in case.
The intuitive behavior when passing a selection to des.region, e.g.
local foo = selection.area(07,02,10,24)
des.region(foo, "lit")
is that foo will remain unmodified for further use. However, this wasn't
the case whenever making a lit region from it, because in order to light
walls adjacent to the lit area, the selection was having a grow
transformation applied as well. (This also seems like a problem - it
grows the selection even if what is being lit is not surrounded by
walls. I added a note in lua.adoc about this behavior.)
This fixes the selection mutation by cloning the passed-in selection and
growing the clone which leaves the original one unaffected.
This should not affect any special levels currently because the only
instance of des.region being used with a selection appears to be in
bigrm-2, which specifies *unlit* areas, which did not get grown.
Issue reported by jeremyhetzler: left and right arrows produced
unexpected characters when trying to use them to edit text that is
being entered.
The curses interface converts arrow keys and function keys related
to the keypad into movement keys (hjkl or 4286 depending on the
number_pad setting). But it was doing that all the time, not just
when nethack wanted movement keys. This extends the existing
program_state.getting_a_command flag to getdir() so that it can be
used for controlling that in addition to 'altmeta' support.
Typing an arrow when interacting with the map (actual command or
getpos, now getdir too) will still work. Typing one when making a
wish or naming a pet will issue a beep and be treated as if '\0' had
been typed, and that normally gets treated as if ESC had been typed.
[Possible room for improvement there. Losing the whole text when
trying to back up a character feels a bit harsh.]
Treating left arrow as escape rather than as h or 4 will probably be
enough to train players not to try to edit text with it after they
get burned by that a time or two.
Bonus fix: curses' keystroke conversion only supported traditional
number_pad behavior, not the inverted phone number pad layout.
Closes#987
For the !defined(DEF_PAGER) config, if the file to be displayed
can't be opened, refresh the screen after complaining about that
rather than when no complaint is issued.
for <new form> portion of messages "<old form> turns into <new form>"
to avoid named vampires yielding "Dracula turns into Dracula".
Pull request from entrez: a couple of engulf messages used regular
monster naming for vamp-shifters transforming rather than dying.
3.6.1 had fixes for this for basic monster death but didn't handle
engulfing.
Fixes#978
Adds a more general way to handle gameplay tips, and adds
a boolean option "tips", which can be used to disable all
tips. Adds a helpful longer message when the game goes
into the "farlook" mode.
Also adds a lua binding to easily show multi-line text
in a menu window.
Breaks save compat.
From a report 9 years ago, a pet pyrolisk was repeatedly gazing at a
grey-elf and nothing happened. It turned out that the elf was wearing
an elven cloak which was negating damage some of the time (most of the
time back then) but with no indication that that's what was happening.
This makes many types of damage that are negated by MC say so.
Probably other types of damage should do likewise.
Issue reported by entrez: when getpos() is being used to have the
player pick a map location, if player types '$' (for some operations
like jumping or applying a polearm) then valid spots are highlighted
but the highlighting obscures what was shown on the map. I'm not
sure whether this 'fixes' the issue but it's probably good enough.
Allow typing another '$' to toggle the highlighting back off,
redisplaying the map in the process, without needing to move the
cursor or type ^R to accomplish that. Toggling seems more intuitive.
This is a lot more complicated than it needs to be because I assumed
that the background aspect of highlighting stayed visible when the
glyphs were reverted. It doesn't work that way but I haven't thrown
out the effort to make toggling the highlights work sanely. Prior
to this, typing '$' again just redrew the highlighting again, with
no visible effect.
Closes#983
selection.gradient has some pretty unintuitive behavior, in that it
selects points that are NOT close to the defined center. I've used
gradient selections several times and so far all of them have had to be
negated, because I wanted to select points close to the center with a
decreasing probability further out.
This implements that behavior, and also fixes a bug in which the x,y
coordinates of the gradient center(s) were not converted properly when
used within a des.room or des.map. Also updated the lua documentation
for gradient.
I removed the "limited" argument, as it was previously used to control
whether the rest of the map outside the max given distance would be
included in the selection; now that the area beyond maxdist is naturally
never in the selection, it doesn't have much use. (And I can't think of
a reasonable use case for the inverse: wanting to select points close to
the center, with decreasing chance towards maxdist, but then select the
entire map beyond maxdist.)
Currently this does not affect any special levels or themed rooms
because none of them use selection.gradient.
Comparable to #vanquished, be able to view info normally available
during end of game disclosure while the game is still in progress.
The new #genocided command lists all genocided and extincted types
of monsters. Unlike #vanquished, there aren't any sorting choices.
Potential future enhancement: provide a way to view the genocided
list at the "what do you want to genocide?" prompt.
* doc/Guidebook.mn: Remove workaround, in favor of...
* doc/tmac.n: ...setting automatic hyphenation mode appropriate to
hyphenation systems used by AT&T-descended troffs on the one hand
("suftab") and groff (TeX hyphenation patterns) on the other.
modify results of pull request #977 to target tmac.nh instead.
Guidebook update to trigger the process following pull request 977.
