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
It's been possible for a while to throw your quest artifact to your
quest leader, completing the quest (he will then throw the object back
to you). The quest leader will also react to being brought the Amulet
of Yendor (i.e. having it in inventory when you approach or #chat), but
tossing it over like the quest artifact was treated as a hostile act and
would cause the quest leader and guardians to become hostile and attack
the hero.
Make throwing the Amulet of Yendor at the quest leader work like
throwing the quest artifact, and treat the invocation items similarly
just in case people try throwing those (maybe because they are lost,
unsure what to do, and have already seen their quest leader catch and
react to the quest artifact -- regardless of the reason, throwing over
the Book of the Dead is almost certainly not intended to be an attack).
Doing so for invocation items will ID them but not do much more than
that. The Amulet of Yendor triggers the existing quest pager message.
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.
For Autoselect-all confirmation, accept yes|n|q (or yes|no|quit)
rather than just yes|n (or yes|no). An extra query routine is needed
to support it, but the existing paranoid_query() can just call the
new paranoid_ynq() with an extra argument, keeping things painless.
For menustyle:full plus paranoid_confirmation:Autoall, if you include
'A' in the class filtering choices then you're prompted for whether
you really meant it. (Same behavior as in the past few weeks.) Yes
auto-selects items matching all other chosen classes, or from all
classes if 'A' is the only choice. (Again, same behavior.) n|no
moves on to menu:full's second menu. If anything else was chosen
along with 'A', that's what the second menu will offer. (Same as
past few weeks but revised from initial implementation.) If 'A' was
the only choice, it will now use 'a' and offer a choice of everything
in the second menu. (That's a change; it used to cancel if declining
to honor 'A' and nothing else was present.) Now <return> without
answering or q|quit or ESC skips the second menu, whether or not the
rejected 'A' was the only choice made in the first menu. (New.)
Other paranoid confirmations still just accept yes and n|no responses,
treating ESC as n|no.
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.
Gold on status line can be truncated, so testing the display value
might miss up/down/changed highlights. I don't think that it actually
matters since a hero cannot pick up enough gold to reach the 999999
truncation threshold.
Normal amounts still seem to highlight correctly after this.
The hitpoints and power/energy status values (and corresponding
maxima) shown on the screen are capped at 9999 to control status line
width. The actual values can be bigger than that. Highlights based
on percentages were doing their calculations on the potentially
truncated values rather than on the actual ones.
Add another field to the blstat[] structure, populate it for BL_HP,
BL_HPMAX, BL_ENE, and BL_EXEMAX and switch to it for their percentage
calculations.
Doesn't seem to break highlighting of 'normal' range values but hasn't
been tested for extreme ones.
The options menu for status hilites wouldn't work as intended if the
entries in the initblstats[] array were changed to not be in BL_xyz
order. (No effect on current behavior since they are in that order.)
The default engraving-in-corridor character is the same as the default
corridor symbol (and also default lit corridor one), distinguished by
color. Show it differently (in inverse vidoe, like lava vs water and
sink vs fountain) if color is Off.
It might be better to change the engraving-in-room symbol to be the
same as the room one so that they'll be more consistent with corridors;
color is probably sufficient without resorting to back-tick. But this
update hasn't done that.
Use inverse video for wall of lava if color is disabled, same as is
done for ordinary lava. The two won't have any visible distinction
from each other but at least wall of lava won't look like water.
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
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.
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.
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'.
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.
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.
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
