When a camera flash hit a mimic which was posing as something, the
feedback mentioned the mimic but didn't bring it out of hiding.
Change to make light pass over a mimic impersonating an object but
unhide one impersonating furniture. Ones impersonating some other
monster are woken up but wakeup doesn't force it back to mimic shape.
Trying to get the messages right brought on more code changes than
antipated. I changed one of the arguments to mhidden_description()
so had to change its callers; fortunately there aren't very many.
The big typos fix commit changed the misspelling "wharever" to
"wherever" but it should have been "whatever".
Plus a punctuation bit I had sitting around.
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.
