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
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.
uhitm.c:843:63: warning: operator '?:' has lower precedence than '|'; '|' will be evaluated first [-Wbitwise-conditional-parentheses]
| (hmd->twohits == 0 || hmd->twohits == 2) ? W_RINGL : 0L);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
uhitm.c:843:63: note: place parentheses around the '|' expression to silence this warning
| (hmd->twohits == 0 || hmd->twohits == 2) ? W_RINGL : 0L);
^
)
uhitm.c:843:63: note: place parentheses around the '?:' expression to evaluate it first
| (hmd->twohits == 0 || hmd->twohits == 2) ? W_RINGL : 0L);
This is a re-creation of a project that was lost years ago while not
quite finished. The old version included some instrumentation to
measure how many hits it takes to kill things during actual play; that
wasn't ready for prime time and this hasn't attempted to redo it.
Changes:
1) improves martial arts and bare-handed combat: they now have a
chance to hit twice when skill is better than 'basic'; 20% chance
for second hit at skilled, 40% at expert, 60% at master, and 80% at
grandmaster; when attacking more than once, strength bonus is
handled as in #2;
2) nerfs two-weapon combat a bit: hitting twice uses only 3/4 strength
bonus on each hit, but when both attacks hit that's 3/2 bonus from
strength which is still more than you get for one hit at a time;
3) beefs up two-handed weapons: hitting via melee with a two-handed
weapon uses 3/2 of stength bonus to reflect the increased influence
of strength; isn't done for applied polearms though.
The reduction in strength bonus for two-weapon has far less impact
than it might sound, due to rounding up with the low values involved.
| full 3/4
| +1 -> +1
| +2 -> +2
| +3 -> +2
| +4 -> +3
| +5 -> +4
| +6 -> +5
The small reduction also doesn't matter if/when current hit happens to
deal a killing blow anyway.
Rings of increase damage apply at full value to every hit, same as
before.
When hitting bare-handed (#1 without gloves), a silver ring on either
hand continues to give a damage bonus against silver haters when you
make an ordinary single attack. However if you attack twice, a silver
ring only applies on the first hit when it is worn on the right hand
and only applies on the second hit when worn on the left hand. (Two
hits with a silver ring on each hand will give silver bonus for both.)
We might conceivably need to add support for a count prefix of 1 to
let player explicitly avoid a second bare-handed/martial-arts hit
attempt (similar to how throw and fire accept a count to limit missile
volley amount).
Kicking has been ignored.
When testing water-vault chests, I kept getting
|Klick! Klick!
when zapping them with a wand of opening. This had me scratching my
head for a while, but it seems to have been caused by partially adding
a sound effect. pline("Klick!") became duplicated and presumeably one
of the two was intended to be edited into a sound-effect call but got
overlooked.
Sound_effect(se_klick,) doesn't make any sound though.
When generating an "escape item" inside one of the chests in the
"water-surrounded vault" theme room, make sure that the chest is not
locked if the item is made of glass or crystal. Otherwise kicking the
chest to get access to its contents might destroy the item.
I imagine that this could be done more cleanly, but after quite a bit
of thrashing about I have something which seems to work. To test, I
temporarily modified object shuffling to force wand of digging to be
made out of crystal and gave the water-vault a very high generation
frequency.
Don't use "slither" for movement action when observing an aquatic
monster go into hiding underwater. Use "dive" instead.
Shark, pirahna, and jellyfish had been flagged M1_SLITHY but aren't
anymore. Giant eel and electric eel are still M1_SLITHY and kraken
wasn't and still isn't.
There may be some odd cases that used to use slither and it went by
unnoticed where now use of the default verb might become noticeable.
When returning to play from within the tutorial, remove the level files
similar to how they're discarded for the rest of the dungeon when going
into the endgame. It turned out to be a bit messier than anticipated.
The dungeon.c bit is sufficient for #overview, which now hides regular
level 1 while in the tutorial and hides all tutorial levels once exited.
Those will still appear in end-of-game disclosure.
vs lycanthropes
Issue reported by Umbire: when hero had Protection_from_shape_changers
extrinsic, a lycanthrope in human form that attacked could change into
critter form. It would change back to human on its next move.
Prevent werecreatures from transforming from human form to critter form
if hero has Protection_from_shape_changers. That attribute does not
prevent a human werecreature from summoning animal companions.
Fixes#1082
This allows players to specify a highlight for critically low HP in
the config file, for example:
OPTIONS=hilite_status:hitpoints/criticalhp/purple&inverse
This will cause the hitpoints field to be highlighted when HP is low
enough to be considered a major trouble. The new "criticalhp" setting
only applies to the hitpoints field.
Since the critical HP threshold changes with level (and most of the
fractions are not integer percents) it was impossible to set
highlights to match the critical HP threshold using percentage
settings.
ff727e9 introduced an issue where unseen water and cloud on the
respective planes were shown with open and closed drawbridge glyphs
instead of the appropriate glyphs. This is because they fall into cmap
section B, but the translation from symbols/cmap index to glyphs was
being done as though they were in cmap section A (ff727e9 manually used
that particular cmap section macro instead of the general cmap_to_glyph
to work around some compiler warning).
From a reddit thread: statue weight is one and half times corpse
weight and some monsters that don't leave a corpse are defined as
having mons[].cwt==0 so statues of those weighed nothing.
Rather than assigning a non-zero corpse weight to every type of
creature, statues that weigh less than an arbitrary value based on
monster size have their weight increased to that value. The weight
of a statue of a killer bee jumps from 1 to 100, that of a leprechaun
increases from 90 to 100, that of a yellow light is changed from 0
to 300, wraith from 0 to 500, and air elemental from 0 to 900. That
last one is actually too low but making the formula more complex
doesn't seem worth it.
Add support for
|OPTIONS=paranoid_confirm:+foo !bar
to enable confirmation for foo and disable it for bar while leaving
other settings intact. Drop support for
|OPTIONS=!paranoid_confirm:bar
since paranoid_confirm:-bar and paranoid_confirm:+!bar accomplish the
same thing. !paranoid_confirm still works as paranoid_confirm:none.
Update the documentation for paranoid_confirmation. It doesn't spell
out all the ins and outs but should cover enough for actual use.
The revised Guidebook.tex is untested.
Sitting on a squeaky board wasn't triggering it even after the
handler for that type of trap allowed VIASITTING to override Flying.
The check_in_air() test for floor traps didn't have the same override,
so the squeaky board handler didn't get called.
This fixes that, which led to inconsistency with some other trap
types, and additional fixes for pits and bear traps. There might be
others that still behave oddly. For example, if flying over a hole,
using #sit yields
|You land. There's a gaping hole under you! You don't fall in.
I think that's a message phrasing issue rather than a falling trap
issue; if you want to go down, use '>' instead of #sit. On the other
hand, you do now fall into pit traps for #sit while flying over them.
If the hero deliberately sits on the floor while flying over a squeaky
board, then either they're trying to squeak it on purpose or they haven't
noticed it. Either way, sitting should trigger it.
Issue reported by vultur-cadens: tame monsters capable of using items
would pick up cursed ones and even wear cursed armor.
The report cites commit 6c9700ab25 but
I don't see any reason why it would be the cause. However, I was able
to reproduce the misbehavior and this commit seems to fix it.
Fixes#1072
Allow hero to write an unknown spellbook if the spell is freshly known
(from divine knowledge). If the spell is going stale, the chance of
successfully writing the spellbook depends on Luck, but only rnl(5)
(like a Wizard) instead of rnl(15). Forgotten spells do not help when
writing unknown spellbooks.
