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. :-]
There was an error:
../win/Qt/qt_main.cpp:767:37: error: attempt to use a deleted function
action->setData(actchar);
^
/usr/include/x86_64-linux-gnu/qt6/QtCore/qvariant.h:199:5: note: 'QVariant<char *, false>' has been explicitly marked deleted here
QVariant(T) = delete;
^
1 error generated.
I'm hoping the fix applied is the correct one for the error.
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.
The 'status' section early in the Guidebook says that encumbrance is
one of "Unencumbered, Encumbered, Stressed" and so on. The second in
the list should say "Burdened" rather than "Encumbered".
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.
