For tty, make hitpointbar blink if current HP falls to the critical
HP threshold. Doesn't require status highlighting. Not changed:
when status highlighting is active, use the HP color but force the
attribute to be inverse (plus blink if the criterium is met) rather
than whatever the HP highlight specifies.
For curses, do the same thing. It used to honor HP attribute for
hitpointbar, now it behaves the same as tty: always inverse, maybe
combined with blink. The new code assumes that inverse and color
can be turned off without turning off active blink in the process.
I had intended to make hitpointbar be a full-fledged status field
(which happens to be rendered on top of title) so that it could be
highlighted differently from hit points (mainly so that one could
highlight up and down changes while the other showed percentages).
This is less versatile than that but much simpler.
If a tame or peaceful monster was trapped and blind hero hadn't seen
the trap yet, attempting to swap places would report that the monster
couldn't "move out of that trap". And if the 'tips' option was True,
the game would suggest attempting #untrap. But #untrap would report
that the hero wasn't aware of any trap at the spot, and fail.
Change the original message to "move out of that <type-of-trap>" and
if hero hasn't seen it yet, map it and vary the wording slightly
"... a|an <type-of-trap>". If #untrap is attempted, it will now be
dealing with a known trap.
Issue reported by Ryton: a sleeping orc caught a thrown gold piece.
Throwing one at some other sleeping monster woke it up.
That is actually intentional. Sleeping monsters with the 'greedy'
attribute will wake up without becoming angry and catch thrown or
kicked gold that is aimed at hit them. The fix here is to augment
the catch message to say so. Non-greedy monsters wake up and treat
it as an attack, but the gold always misses.
Both cases only happen for monsters who are asleep for an indefinite
period of time. Any monster that is asleep (or paralyzed, or busy
putting on armor) for N turns effectively doesn't notice. If it can
be seen, the gold "harmlessly hits" (if it can't be seen, the gold
misses), and the target continues doing--or not doing--whatever it
is doing. That's suboptimal; another case where lumping multiple
can't-move situations into a single monst->mfrozen countdown timer
causes timed sleep to be indistinguishable from timed paralysis.
Closes#1230
In 3.6.2 parts of the wakeup code were merged together, and this
caused pets consider any noise made by the hero - such as hitting
iron bars or digging - as whistling for them to come to the hero.
Change it to only consider actual whistling and ringing a bell.
Use vi (cursor_invisible) and ve (cursor_normal) to hide and show
cursor, if the terminal supports those. This way on a slower
connection the cursor doesn't jump all over the place when doing
map or menu updates.
From a reddit thread: after genociding "arch-lich", player's next
target was "master-lich". The character was a monk who immediately
died of genocide.
("Master<almost anything>" other than "master mind[ ]flayer" or
"Master Thief" or "Master Assassin" matches level 30 monk rank "Master".)
Rather than muck about with fairly complicated matching code, just add
"master-lich" and "masterlich" as explicit variations.
Disclosing final inventory while wearing an alchemy smock reported
the apron's slogan accurately but then disclosing attributes gave
different text if it was conferring poison resistance and/or acid
resistance. The extra text was unneeded/unwanted there anyway, so
simply suppress it rather than force it to be accurate.
3.6.x had the same issue but it wasn't detectable there because it
only had extra text for T-shirts and they don't confer attributes.
Reported by NetSysFire: if hero dealt a weapon-shattering melee
blow to an unseen target, the weapon was accurately described in
the accompanying message
|Its <formatted-weapon-description> is shattered from the force...!
If the hero can't see or sense the monster, report
|Its weapon is shattered from the force of your blow!
If the monster isn't seen but is sensed, then
|<Monster>'s weapon is shattered from the force of your blow!
Fixes#1220
Reported directly to devteam: using '#adjust a a' to collect
invent stacks compatible with the one in slot 'a' all into 'a' gave
feedback of "Merging: a - ..." even though "Collecting: a - ..."
was intended. Also, if there weren't any such compatible stacks,
so that the whole operation didn't accomplish anything, it reported
"Collecting a - ..." without the intended colon between the action
and the inventory letter.
Test case was trivial: start with a stack of 2 of something in 'a'
and use '#adjust 1a b' to split into two stacks, then '#adjust a a'
to collect them back again.
While fixing this, I noticed that '#adjust a b' and '#adjust b a'
(from same starting situation) just swapped a and b instead of the
intended behavior of merging them back together.
The construct "\\'#rrggbb'" seemed strange and while fixing that
I made several other changes. There's an escape sequence for
apostrophe but "#rrggbb" doesn't actually need any quoting in the
first place (except for "\#" in the TeX version).
There was unwanted indentation after the OPTIONS=windowcolors line
in the 'roff version. For the TeX version, avoid 'verbatim' since
it contains both literal text and placeholders that are now being
distinguished with italics.
Also, "trueblack" is Windows-specific rather than an ordinary named
color.
The fixes entry about object info carrying over when normal play
was resumed could have been mistrued as stating that the objects
themselves were carrying over.
Reported by AndrioCelos, a handful of objects in the tutorial can
be discovered via use, and such discoveries were carrying over to
normal play when the tutorial ended.
This causes the hero to forget such discoveries. The player will
still be able to remember them. The proper fix would be to discard
the initialized but not-yet-started game when entering the tutorial
and then start a whole new one when exiting so that saving and
restoring game state would become unnecessary. This doesn't do that.
This also causes monster birth and death statistics to be reset when
exiting the tutorial. Affects the #vanquished command and potentially
extinctionist play.
Closes#1134
Reported directly to devteam: if a magic trap gave its uncurse
effect, scroll of remove curse could become discovered.
Turns out that it would happen if hero was wielding a stack of
unholy water potions. It didn't matter whether they were known
as water or known to be cursed or whether hero was carrying any
scrolls of remove curse.
Using
|OPTIONS=windowtype:Foo
|OPTIONS=perm_invent
or
|NETHACKOPTIONS='perm_invent,windowtype:Foo'
would enable perm_invent if interface "Foo" supported it, but using
|OPTIONS=perm_invent
|OPTIONS=windowtype:Foo
or
|NETHACKOPTIONS='windowtype:Foo,perm_invent'
or combined
|OPTIONS=perm_invent
|NETHACKOPTIONS='windowtype:Foo'
would only enable perm_invent if both "Foo" and the default interface
supported it.
Using '--windowtyp:Foo' on the command line didn't have this issue
because command line interface selection replaces the default one
before configuration file and environment options are processed.
Reported almost 9 years ago: if an adjacent statue was in a pit,
you could use a pick-axe to break it even though if you managed to
move to the pit location without falling in, you wouldn't be able
to reach objects there including the statue.
Allow a pick to reach if hero is in a conjoined pit, or if it is a
mattock rather than an ordinary pick-axe. Otherwise you'll get the
"you swing at thin air" result. Similarly when hero is in a pit and
and adjacent statue or boulder is on the floor: mattock will work
but pick-axe now yields "you can't reach".
This fixes a lot of problems where a menu or a text window was up
and the main window accepted input - for example you could move around,
making another window of the same type pop up ...
Noticed when testing the OPTIONS=symset:blank fix, map spots holding
engravings weren't blank.
Are there any other relatively recently added symbols that need to be
added to the blank set?
Any plain text symbol set specified in .nethackrc or NETHACKOPTIONS
didn't get loaded but did set the symset name.
Faulty 'if' logic excluded loading of symbol sets that used the
default handling type of H_UNK.
Add options 'showvers' (boolean) and 'versinfo' (numeric mask) to
show nethack's version on the status lines during play. It won't be
particularly interesting to ordinary players but should be useful
when making screenshots or video to be streamed, or for someone who
switches between git branches or between nethack and variants.
I worked on this several months back but it was combined with
unfinished changes to 'hitpointbar'. I've separated it out so that
it can be put into use. When enabled, one or more components of
"<name> <branch> <version>" will be shown right justified after
status conditions. At present the default is "<branch>" if that is
available and overall status isn't 'released', or "<version>" if
'released' or if branch isn't available. That might need some
refinement.
It works as intended for tty and curses, although some abbreviation
mechanism would be useful if/when the program resorts to abbreviating
status conditions to make things narrow enough to fit.
For X11, it works ok for fancy_status:True (the default, controlled
via NetHack.ad settings) but is messed up for tty-style status. The
text is positioned correctly but there are gaps in it, making it
appear garbled, similar to what I saw when I tried and failed to
implement statuslines:3 for X11. [It might be due to having empty
condition widgets be 1 pixel wide instead of being totally removed
but I don't think the situation is that simple.]
For Qt, if the text needs to be truncated in order to fit, the center
portion of the string will be shown, discarding parts from the left
and right. That ought to discard from left and retain rightmost
portion instead.
For win32|mswin|Win GUI, no attempt to support it has been included.
Things should be ok when 'showvers' is left as False (the default)
but I don't know what will happen if that gets toggled to True. At a
minimum, the version info won't be right justified. The information,
or at least some of it, is displayed in the game window's title bar
so there isn't any pressing need to add it to status, but toggling
the option will need to behave sensibly if it doesn't already.
Adds a new extended command #lookaround, which will describe
the map around the hero they can see or remember.
Adds a new boolean option mention_map, which will give a message
when an interesting map location in sight changes.
When makemon was called with all-zero arguments (e.g. for random
monster generation over time), ptr==NULL means "a random monster".
This was being forwarded to mon==NULL in makemon_rnd_goodpos, and
then mtmp==NULL in goodpos, which means "an object, not a monster".
Because objects can be generated under monsters, this meant that an
attempt to create a random monster could end up choosing a location
that already had a monster, which would then cause the monster
generation to fail.
This mostly wasn't noticeable in normal play: it effectively
reduced the monster generation rate depending on how many locations
outside LOS happened to contain a monster. Normally that's a very
small proportion, so the bug had no obvious effects: but when there
are very few locations outside LOS (i.e. the player can see almost
every location on the level), the bug effectively caused monster
generation to stop once those locations became occupied by
non-moving (e.g. hiding) monsters, something that became observable
in games where the player decided to dig out and light almost an
entire level.
This commit fixes the problem by adding a new flag to goodpos that
requests that it not choose a position that already has a monster.
This bug was diagnosed, and this fix committed, by ais523; but
nhmall wrote almost all of the code implementing the fix.
Add a new boolean option showdamage, if on, outputs a message
like "[HP -2, 14 left]" - several variants have something similar,
but I chose the message based on how eSpeak said it, while keeping
it short.
