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.
sound_verbal(char *text, int32_t gender, int32_t tone, int32_t vol,
int32_t moreinfo);
-- NetHack will call this function when it wants to pass text of
spoken language by a character or creature within the game.
-- text is a transcript of what has been spoken.
-- gender indicates MALE or FEMALE sounding voice.
-- tone indicates the tone of the voice.
-- vol is the volume (1% - 100%) for the sound.
-- moreinfo is used to provide additional information to the soundlib.
-- there may be some accessibility uses for this function.
It may be useful for accessibility purposes too.
A preliminary implementation has been attempted for macsound to test
the interface on macOS. No tinkering of the voices has been done.
Use of the test implementation requires the following at build time with make.
WANT_SPEECH=1
That needs to be included on the make command line to enable the test code,
otherwise just the interface update is compiled in.
I don't know for certain when AVSpeechSynthesizer went into macOS, but older versions
likely don't support it, and would just leave off the WANT_SPEECH=1.
If built with WANT_SPEECH=1, the 'voices' NetHack option needs to be enabled.
It was a bit strange, when I first started up the test, to hear Asidonhopo,
the shopkeeper, talking to me as I entered his shop and interacted with him.
Reported by elunna: a monster trapped in a pit or web that was
adjacent to a polymorph trap could enter that trap to change shape.
It would remain flagged as trapped but there's no way to escape
from a polymorph trap so it would be stuck.
Fix supplied by entrez: when a monster is picking MUSE strategy,
don't allow it choose "enter polymorph trap" if it is currently
trapped.
I entered the changes from the diff manually and added a bunch of
minor formatting bits.
Fixes#972
Issue reported for a hardfought player by k2: dying in a shop wall
produced "place_object: <item> [0] off map <0,0>" when hero's invent
was dropped. It happened in Mine Town where multiple shopkeepers are
present and it is possible to have two shops share a wall.
I could not reprouce the problem, even after setting up--and dying
various times at a gap in--a wall shared by two shops.
paybill() -> inherits() -> set_repo_loc() sets up the destination
prior to disclosure and finish_paybill() -> drop_upon_death() later
places invent at the spot iff bones are going to he saved. inherits()
is convoluted and evidently took at least one path that failed to
call set_repo_loc(). Change it to always call set_repo_loc() when
returning 'True' so that the destination should always be set if
really_done() calls finish_paybill().
Some followups by entrez are probably still useful.
Closes#965
Add "walls of lava", basically lava which blocks vision and
require a bit more than just levitation or flight to move through.
No levels use this yet, as testing isn't thorough enough.
The intuitive behavior of des.levregion or des.teleport_region when
"exclude" is left unspecified is that there is no exclusion area.
However, this wasn't actually the case: since l_get_lregion defaulted
the exclusion area to (0,0,0,0) and exclude_islev to 0, this meant that
the 0,0 space on the map would always be excluded from regions. In cases
where a region was specified with its inclusion area constrained to the
0,0 space of the map, this would create a "Couldn't place lregion"
impossible message.
This fixes that issue by defaulting the exclusion area to (-1,-1,-1,-1),
and if the exclusion area is left unspecified, forces exclude_islev=1.
This means that the exclusion zone will be outside the walkable space of
the level where it can't cause any problems.
If a level designer puts negative coordinates in their inclusion or
exclusion parameters, this might not work correctly, but negative region
coordinates aren't currently used anywhere and probably shouldn't be
supported anyway.
