At either of the genocide prompts,
|What type of monster do you want to genocide?
or
|What class of monsters do you want to genocide?
answering "?<return>" will show the list of monster types that have
already been genocided, then re-prompt.
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
Pull request from entrez: a monster can become permanently blind via
camera flash but being hit by vapors from thrown potion of blindness
would set a blindness countdown timer and blindness would be cured
when that expired.
Closes#1092
Monsters can become permanently blind (in very narrow circumstances -- I
think limited only to a very short-range camera flash), in which case
they have both mon->mblinded and mon->mcansee set to 0. Such
permanently blinded monsters can counterintuitively regain their sight
by being blinded a second time from a different source: for example, by
being hit with a cream pie. That second blinding will increase
mon->mblinded (which functions as a blindness timeout) by some amount,
and when it runs out the monster will regain its sight. Try to make
sure that doesn't happen by skipping any blinding attacks if the monster
has already been permanently blinded.
When the hero is killed by a zombie, she is supposed to arise from the
grave as a zombie of a type matching her race. Commit 580c5a6 broke
this inadvertently -- done_in_by was passing gy.youmonst.data to
zombie_form() and relying on the old behavior where it attempted to
include the hero's race in is_elf, is_orc, etc if the permonst matched
the hero's role. Because this no longer works, zombie_form was only
returning PM_HUMAN_ZOMBIE when passed the role permonst of an
unpolymorphed hero. Use gu.urace.zombienum instead. This would have to
be a little more sophisticated (falling back to zombie_form() if Upolyd)
if a polymorphed hero with unchanging could die via done_in_by but
that's not currently possible as far as I can tell.
When calling panic() or impossible(), create the option
of opening a browser window with most of the fields
already populated. Code for MacOS and linux is included;
other ports are affected by argument change to early_init
which are done but not tested.
To enable, define CRASHREPORT in config.h and set
CRASHREPORTURL in sysconf to (for the moment at least)
http[s]://www.nethack.org/common/contactcr.html
Adds --grep-defined option to makedefs for Makefiles.
Adds "bid" (binary identifier), an MD4 of the main nethack
binary. This is ONLY for helping (in the future) contact.html
to set the "NetHack from" field automatically for our own
binaries. This can be faked, but the user can lie so nothing
lost. There's nothing magic about MD4; other ports can use
anything that prodcues a long apparently random string we can
match against.
- new option --bidshow for us to get the MD4 of a
released binary so I can add it to the website.
Only available in wizard mode and not in nethack.6.
- typo macos -> macosx in hints file
No support for packaging builds as I'm not sure what that
would look like.
Adds a javascript helper for MacOS.
Adds a lua helper for linux (and builds and installs
nhlua).
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".
From a reddit thread: a tame mind flayer ate Medusa's corpse and was
turned to stone. Pets won't eat cockatrice corpses unless stoning
resistant but would eat Medusa's corpse if merely poison resistant.
Mind flayers aren't normally poison resistant but could be if wearing
green dragon scales/mail.
Augment the touch_petrifies() test when classifying food for pets.
Older versions of git, when cloning a repo and
the expected source templates directory does not
exist, does not create .git/hooks, which causes
nhgitset.pl to fail. So do it here.
The dependencies in util/Makefile duplicate those in src/Makefile for
objects.o and monst.o but the latter got changed last year and the
change wasn't replicated.
When testing the high priest livelog/#chronicle feedback I used #wizkill
on the Sanctum level to kill Moloch's high priestess and immediately
level teleported to the Astral level to target the other high priests.
I got impossible "dmonsfree: 0 removed doesn't match 1 pending" there.
If you killed a second high priest (either two on Astral or first in
the Sanctum and another on Astral) the livelog/#chronicle message
would report "killed high priest of Foo (2nd time)" even though the
first was the high priest of Bar, or even just "killed high priest
(2nd time)" if second kill happened when not adjacent.
High priests pass the 'unique monster' test (even though they aren't
actually unique--there will be four of them) so get logged for killing
such. Always report "killed high priest of Foo" and only do so if the
specific high priest[ess] monster hasn't been revived and re-killed.
Logging deaths of unique monsters normally reports the 1st, 2nd, 3rd,
5th, 10th, and various later instances. If you were to kill Moloch's
high priest and all three on Astral, the last one wouldn't be logged
because 4th instance gets skipped. This forces each one to be treated
as the 1st (provided that the mrevived flag is clear), so for logging
purposes it will now behave as if there are 4 distinct high priests.
If a monster sees you remove some piece of gear that grants a
resistance, it will remove that resistance from its list of remembered
resistances and be willing to try attacking you with that adtyp again.
This avoids the situation where you put on a ring of cold, get hit with
one cold attack, and then can remove it because all the monsters nearby
will permanently remember you as being cold resistant (but even after
this change a wily hero could still step into a niche and do it without
any monsters seeing, so trick them into thinking she's still cold
resistant...). The hero could still be resistant if there were multiple
sources to begin with, of course, but the monsters will test it and
learn that again if necessary.
It's a little weird that the monsters can recognize the intrinsic
granted by the item being removed, but they display knowledge of
unidentified (by the hero) objects in many other circumstances too, so I
hope it's forgivable in the pursuit of having them act more cleverly
about resuming previously-resisted attacks like this. Another approach
that avoids the gear recognition, blanking seenres on any gear change,
can result in odd situations like orcs treating their own cloaks as
potential sources of many different resistances, which also seems silly.
Pull request from entrez: if Magicbane's cancellation effect hit a
shapeshifter and caused it to revert to base form, further messages
for the rest of that attack referred to it by the cached name of its
shifted shape.
Fixes#1087
The cancellation effect of Magicbane can cause shapeshifters to change
to their base forms. Since the name of the monster being attacked is
cached earlier, the name used for subsequent messages from Mb_hit would
be outdated after this happened. For example, as encountered in a
recent game: "The magic-absorbing blade cancels the vampire bat! The
vampire bat turns into a vampire lord! The vampire bat is confused."
Insert the new name into hittee[] if cancellation caused the targeted
monster to change form.
Asmodeus kept using the cold magic attack when hero was cold resistant.
The distance magic attack already considered hero resistances, so
use the same logic for the close-up magic attack.
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.
Pointed out by entrez: prevent doname() from consuming two obuf[]
buffers when it constructs the plural of "hand" while formatting a
wielded two-handed weapon.
Since only one such item should be able to occur in any list of
objects, it is not likely to be the cause of any message oddities
that might happen when a cached value is in a formatting buffer gets
re-used too soon. However, not releasing a second buffer right away
prevents an attempt to release the first one from succeeding because
it won't be the last one allocated anymore, so some buffer churn was
happening.
The sortloot classification routine had some inappropriate casts to
'coordxy' for things had nothing to do with map coordinates. I was
going to change the relevant fields to 'short' but that seems iffy
for 'indx' so I changed them all to 'int'.
Pull request by entrez: sortloot could churn through every obuf[].
Change it to release them as soon as they're used, like the fix for
inventory display in commit e43ec0cef1
two years ago.
I don't have a test case.
Closes#1086
Some further application of e43ec0c logic, which was intended to fix odd
messages produced by obufs clobbered by inventory updates (like "the
ogre lord yanks Cleaver from your corpses!"). That issue was still
lurking around because sortloot(), via sortloot_cmp(), was continuing to
call for obufs via loot_xname() without releasing them immediately. It
was going through the entire inventory doing that, much like
display_pickinv() was prior to Pat's fix in e43ec0ce, so could cause
the contents of obufs to still be clobbered by perm_invent updates.
This changes sortloot_cmp() to releases the obufs it calls for as soon
as possible so that won't happen any more.
The previous curses escape sequence conversion for 8-bit sequences was
looking for those to start with M-O when the correct value for that is
actually M-^O.
Add support for the number pad's non-digit keys. Most useful for real
VTxxx keyboard since emulators are usually stuck mapping '+' and '.'
to ',', '.', and '-'. There's no universal solution for that.
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.
This attempts to address the issue on hardfought (as described by K2
on reddit two weeks ago) which happened after updating their terminfo
database. It's based on the reported workaround of having users force
their terminals to avoid "application keypad mode". The fixes entry is
my guess at what is happening so could be wrong....
I don't have a numeric keypad so this is untested; it /ought to work/.
NetHack's curses interface is doing it's own keypad recognition when
the curses library returns a multi-char sequence rather than converting
that into corresponding KEY_xxx token. Numpad keys that the interface
recognizes begin with 2 char 'ESC O' when transmitted as 7-bit sequences.
This adds support for SS3 (as sent by DEC Vtxxx terminals and emulators;
value is single char 'M-O') for 8-bit sequences.
It shouldn't break typing Alt+O but that's something else that I can't
test properly. Setting nethack's 'altmeta' option and manually typing
2 char 'ESC O' still works as intended.
This is curses-specific; the tty interface is completely unaffected.
[However, the vms port has supported SS3 with tty for decades. :-]
