It turned out that using '^' as a group accelerator (new behavior for
the 'whatis' command to view traps) already worked for curses and Qt.
Fix that for tty and X11. I don't know the situation for WinGUI.
Offering any of the menu paging keystrokes as group accelerators
should be avoided if there's any chance that the menu will need more
that one page. The menu for '/' is short though so losing "^ to go
back to first page" for it isn't an issue.
Pull request from NullCGT: applying gold from inventory will flip
one coin and report "heads" or "tails". If impaired, that coin will
be dropped, otherwise it will remain part of the stack in inventory.
Can be done via 'a $' or with context-senstive item action via 'i $ a'.
I've used 'git merge --squash' and 'git commit -C <commit#>' to
flatten four commits into one and it seems to have accomplished what
I wanted, including retaining the log message from <commit#>.
I also changed
|You flip a gold piece. The gold pieces slips between your fingers.
to
|You flip a gold piece. It slips between your fingers.
when impaired and applying one from a stack.
Closes#1107
Reported by entrez: it was possible for #overview to show a line of
just "." if a temple was known and its altar was unknown and no other
features such as thrones or fountains were known on the level.
It now lists "M temples and N altars" when both are present and the
case that yielded "." becomes "a temple". That's an improvement but
there might be edge cases it gets wrong. A listing of "a temple and
an altar" is ambiguous because there isn't any way to tell whether the
altar it mentions is inside the temple. That seems acceptable to me.
I think it should include more alignment information about temples and
altars, instead of just adding "to <your god>" when all known altars
are of hero's alignment, but this doesn't attempt to address that.
Wand of make invisible doesn't make you permanently invisible,
just for a short duration. Potion of invisibility makes you
invisible for much longer period, or if blessed, has a small
chance of giving permanent invisibility.
This makes the wand actually useful, and improves the spell
too.
Skeletons are extremely rare, and not generated at random,
and bone devils are basically just a speed bump when they appear.
Make both more interesting.
Idea by copperwater <aosdict@gmail.com>
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.)
Reported by a hardfought user, a ceiling_hider monster hid on the
Astral level, triggering a sanity check warning that gets repeated
each move until the hider comes out of hiding. Normally sanity_check
can only be set in wizard mode, but hardfought must force it on for
to-be-3.7.
I was able to reproduce it before this fix and unable to do so
afterward, but there is a random factor involved hence no guarantees.
I think that lack of ceiling for Astral is recent, but this could
have happened on other levels which lack a ceiling. I didn't try to
figure out whether it might happen with 3.6.x, just put the fixes
entry in the "exposed by git" (found in code not yet released, that
is) section.
Pull request from entrez: if hero throws (or kicks) an invocation
item or the Amulet at the quest leader, identify it and give it back
instead of treating the throw (or kicked item) as an attack.
In addition to the fixes entry I've made several tweaks to related
code, mostly to refer to the leader as "Someone" rather than "It" if
unseen.
Closes#1093
Wielding one or more rocks while other rocks were quivered and casting
stone-to-flesh at self wasn't subject to the "null obj after quiver
merge" panic but it did result in a combined stack of meatballs that
was neither wielded nor quivered. Keep inventory items that turn into
meat and are wielded/alt-wep/quivered separate and still wielded/&c.
Using apply to unlight a lit potion of oil makes it unlit, removes
it from inventory, and then re-adds it to try to force it to merge
with other potions of oil. If it was wielded and the other potions
were quivered, the game would panic. When merging, they get forced
into the weapon slot in preference to the quiver slot.
Unwearing it before freeinv+addinv would solve this but also leave
the hero with nothing wielded, even if it didn't merge with another
stack. Instead, don't try to merge if the potion being unlit happens
to be worn.
3.6.x was subject to this too and the fix is small+isolated but the
situation is so uncommon that I haven't bothered backporting it.
Applying a lump of royal jelly and then not picking anything to rub
it on had a similar problem. It also panicked if the applied lump
was wielded and other lumps were quivered. The fix is different
because the stack it gets split from during apply is known. This one
doesn't impact 3.6.x; applying jelly to eggs wasn't implemented yet.
When paranoid confirmation for menustyle:full's "Autoselect all" is
enabled, it is handling yes vs no backwards.
The initial implementation had it right, then a negation got dropped
when it was expanded to support yes|no via paranoid_confirm:Confirm.
ESC is being treated as 'n' rather than as cancel. Fixing that will
take some more work. This just adds the missing negation to make 'y'
and 'n' behave properly.
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
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).
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.
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.
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
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.
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. :-]
If there was a status_hilite rule for hitpoints:up, it got used for
both up and down changes. If there was one for hitpoints:down, it got
ignored even if there was no 'up' rule. The flag for which direction
the value changed was always positive even when the value went down.
I'm reasonably sure that at some point HP up/down worked correctly.
This problem was present in 3.6.4; I didn't go back any farther.
Update the documentation for
OPTIONS=status_hilite:hitpoints/criticalhp/<color&attributes>
A criticalhp rule now overrides up/down/changed rules as well as
absolute/percentage/always rules.
If status field 'hitpoints' has rules for both 'criticalhp' and 'up'
or 'down' or 'changed', make critical-hp take precedence. Otherwise
critical-hp might never be seen because of the value changing every
move (if hero has regeneration attribute). Normally up/down/changed
take precedence over other types of highlighting.
Something is messed up with up/down/changed HP though. I'm seeing
the 'up' highlight when it goes either up or down and not seeing the
'down' highlight at all. 'up' and 'down' for gold work as expected.
Issue reported by Umbire: Uruk-Hai have strength 18/100 and can grow
into orc captains, but orc captains' strength was limited to 18/50.
Cap strength at 18/100 for hero poly'd into an orc captain, same as
when poly'd into an Uruk-hai. Since poly'd heroes don't grow into
larger forms, the only way to notice is to polymorph into an Uruk-Hai
at some point and into an orc captain at some other point.
Fixes#1085
New feature to sometimes hit twice for skilled martial-arts/bare-handed
was unconditionally using uswapwep for the second hit. If it was a
breakable object, hitting could break it and produce impossible "objfree:
obj not free".
Only use uswapwep for u.twoweap; use Null for second bare-handed hit.
