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.
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.
I realized that the previous attempt was misusing the item's locked
state when attempting to create the chest that the item would go into,
which was absurd. I hadn't realized that I was also misspelling
"olocked" as "locked".
This fix was already in progress before the mail about the previous
commit. I did try switching to 'lckd = nil' for the attempt to retain
the chest's random locked/unlocked state but that resulted in all the
chests being created locked. Using separate box=... expressions does
work as intended. Doing something with totable() doesn't seem to be
necessary.
The indentation seems to be messed up compared to the rest of the
file (initial indent of 5 with increments of 4 rather than 3 and 3);
I have't done anything to try to fix it.
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
Backslash doesn't need to be escaped by backslash inside a verbatim
block (presumably the first character is an exception). The doubled
backslashes in SOUNDDIR example were producing doubled backslashes in
the output.
There didn't seem to be any other instances of this.
Pull request from vultur-cadens: add a new status highlight pattern
OPTIONS=hilite:hitpoints/criticalhp/color&attribute
to highlight hit points when they drop to the point where prayer
classifies them as a major problem. The threshold for that varies
depending on max HP and experience level.
It affects hitpointbar as well as the status field for hit points.
Right now a highlight rule for HP down or HP changed or HP up takes
precedence over criticalhp until the temporary highlight times out.
I'm not sure how best to deal with that. With regeneration and an
up or changed rule for HP, the criticalhp highlight probably won't be
seen even with a very short statushilites timeout.
I've added a fixes entry and updated Guidebook.mn but Guidebook.tex
is lagging.
Closes#1071
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.
A printf call was introduced in 20fb008012 that caused the terminal
window to be filled with repeated debugging messages as the window
containing the Qt windowport was resized. I removed it because I
assumed it was meant to be temporary and was left in the commit by
mistake, considering it isn't mentioned in the commit message; if it was
meant to be permanent it'd probably be good to block it out with #ifdef
DEBUG or something at least, because it produces a real deluge of
terminal output if the player spends any time resizing the window by
hand.
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.
