The pull request #226 commentary follows:
One major limitation of the autopickup exception system is that you can't
define an exception from an exception, despite both menucolors and msgtypes
prioritizing rules based on the order they are defined in .nethackrc. This
is because the "always pickup" and "never pickup" exceptions are tracked in
different lists, and at runtime, when the player steps over an object, the
game checks these lists seperately, with "never pickup" taking precedence.
This means that if you want to pick up some but not all items matching a
given expression, you may need to write a long and kludgy list of regexes
to get the behavior you want.
I've edited the autopickup exception code to remove this necessity: now
the exceptions are stored in one list, and conflicts between them are
resolved based on their relative position in that list. Whether an
exception was inclusive or exclusive was already tracked individually;
I don't know why they were stored separately in the first place. This
edit makes the system both more convenient and more consistent with the
semantics of menucolors and msgtypes.
With these changes, the 33 autopickup exception rules in the wiki article
linked above may be replaced with the following 7 much simpler rules for
the exact same effect:
AUTOPICKUP_EXCEPTION=">.* corpse.*"
AUTOPICKUP_EXCEPTION="<.* newt corpse.*"
AUTOPICKUP_EXCEPTION="<.* lichen corpse.*"
AUTOPICKUP_EXCEPTION="<.* lizard corpse.*"
AUTOPICKUP_EXCEPTION="<.* floating eye corpse.*"
AUTOPICKUP_EXCEPTION="<.* wraith corpse.*
AUTOPICKUP_EXCEPTION=">.*\>.*"
closes#226
Report stated:
"Poes deliberately slither onto a polymorph trap!" ... it's only one cat, er,
black naga. Why does the parser treat the name as plural? There are lots of
singular words and names that end in -s or -es!
H9249 1780
Reported directly to devteam rather than via the web contact form:
throwing wielded aklys while swallowed would hit the engulfer and
return to the hero's hand but leave a stale 'thrownobj' pointer if
the monster survived. Under usual circumstances, throwing anything
else or throwing the aklys again when not engulfed would clear that
pointer, putting things back to normal. However, killing any engulfer
with the same weapon would try to add it to engulfer's inventory to
be dropped as it died. If the killing blow was via melee rather than
another throw, the object in question would still be in hero's
inventory instead of free, hence panic.
The initial returning-aklys implementation shared Mjollnir's code
which doesn't have this issue. This reverts from having attached
aklys always returning successfully when thrown while swallowed to
Mjollnir's 99% chance of return and 99% to be caught when it does
come back. (That was already the case if the engulfer was killed by
the throw, where hero wasn't swallowed anymore after the damage was
inflicted.)
Zapping wand of opening or spell of knock at self while trapped:
"You are released from pit."
ought to be
"You are released from the pit."
Likewise for most of the other held-in-place situations.
Also, when released like that vision wasn't being recalculated right
away to update line of sight to reach beyond the edge of the pit.
Fixes#223
The touchstone code treated all rings as if they had gemstones, but
quite a few don't and feedback could be unexpected. Cited case was
an iron ring yielding a cyan (hi_metal) streak instead of the normal
iron result ("scritch, scritch"). A gold ring yielded a yellow
streak rather than a golden scratch. I didn't test silver ring but
suspect it yielded a silver streak rather than a silvery scratch.
This changes touchstones to treat non-gemstone rings like other
classes of objects instead of like gems. I made mineral rings keep
acting like gemstone rings--I'm not sure whether that's right.
Fixes#221
Routine unfixeable_trouble_count() is used for both applying a unicorn
horn (possibly internally via #monster if poly'd into a unicorn) and
drinking a blessed potion of restore ability. For the latter case, it
always gave the wrong answer (unless the hero happened to be all of
Sick and Stunned and Confused and Hallucinating and Vomiting and Deaf).
Since the actual count wasn't used to decide whether hero felt "great"
or just "good", having any of those conditions would hide the problem.
chasonr's comments in github pull request #220:
It was necessary, when updating the MS-DOS port for 3.6, to revise the
screen-clearing and character-drawing functions, because the background
color is no longer zero. But the 3.6.1 method is rather slow, using
write mode 2 and a lot more calls to outportb.
outportb is expensive when running under a virtual machine, the typical
use case for the MS-DOS port these days, because it traps to the
hypervisor rather than actually writing to hardware.
This change restores the speed of the 3.4.3 version. The adapter is left
in write mode 0. Clearing is accomplished by writing zero to planes where
the background color has a zero bit, and 0xFF where the background color
has a one bit. Characters are drawn by writing 0x00, 0xFF, the font data,
or the inverse of the font data, as appropriate, to each plane.
When testing, be sure to use OPTIONS=videomode:vga, because autodetect
will go to VESA mode if it can.
closes#220
Fixes#218
Hallucinating hero has 75% to be unaffected by a gaze counterattack
that paralyzes. Check for that before checking free action (100%
chance to be unaffected). The only change is that player might get
different feedback when both forms of protection against the gaze.
Fixes#217
Feedback when spellcasting monster aimed at the wrong spot due to not
being able to see an invisible hero only gave the intended message if
hero couldn't see self. The code was using 'if (Invisible)' which
checks whether the hero is invisible and can't see invisible, when it
should have been using 'if (Invis)' which just tests whether the hero
is invisible.
It wouldn't surprise if the same problem occurs elsewhere. Those
macros are rather error prone.
The issue report mentions that one of the affected messages might be
unreachable. I didn't investigate that.
Have the 'menucolors' option control menu color pattern matching
(instead of curses-specific 'guicolor') for all menus, not just for
the persistent inventory window.
Commit e3af33c9db in June changed
curses handling for perm_invent to strip off doname()'s "a ", "an ",
or "the " prefix in order to shorten inventory entries and get a
couple of significant extra characters before end-of-line truncation.
That had an unintended impact on menu colors pattern matching for
patterns which expected the article prefix. Do the matching before
stripping off the prefix instead of after so that the matching gives
the same results as when used on a normal inventory menu (even though
this means that from the user's perspective most perm_invent entries
will have invisible text at the start).
Also for menu colors, don't require curses-specific 'guicolor' option
be enabled when the general, more-specific 'menucolors' option exists
to control menu coloring. (curses was requiring that both be True.)
Update persistent inventory window if 'implicit_uncursed', 'menucolors',
or 'guicolor' is toggled. (curses should be changed to use menucolors
instead of guicolor to decide whether menu coloring is used. Right now
it requires that both be On.)
Also, EDIT_GETLIN was providing junk default response when message type
or menu color looped and prompted for another entry after handling one.
Mixed in with this is a fix for easily induced buffer overflow which
has security ramifications....
Subject was "display crash while in curses mode". Restoring with
perm_invent set in config file or NETHACKOPTIONS when the save was
made while swallowed (regardless of perm_invent at that time) resulted
in a crash when invalid u.ustuck was referenced before restoration had
done its pointer fixups.
init_nhwindows() is called with perm_invent On;
restgamestate() temporarily turns it Off (3.6.2 restore hack);
if/when update_inventory() gets called, curses notices that the
persistent window has been disabled so it tears down all its windows
in order to redraw the screen without that one;
docrt() sees non-Null u.ustuck and calls swallowed();
swallowed() tries to use the value of that pointer rather than just
Null/non-Null but the value is from the previous game session, not
valid for the current session;
crash.
Make yet another attempt to prevent update_inventory() from being
called during restore. curses won't try to redraw and the crash
won't happen. But the invalid pointer is still lurking (until an
eventual fixup later during restore).
An earlier fix for update_inventory() during restore actually handled
this problem (for the most common trigger, setworn(), but not in
general), so the 3.6.2 behavior is a regression.
causes "dmonsfree: N removed doesn't match N+1 pending" warning. The
sandestin monster definition flags it as MR_STONE, immune to being
turned to stone. If the hero hit it with a cockatrice while it was
shape-changed into something which isn't MR_STONE, it had its mon->mhp
set to 0, so died, and its form (mon->data) was set back to sandestin.
known_hitum() decided that it didn't turn to stone because of MR_STONE
for that form so proceeded to kill it off due to lack of hit points,
causing it to die twice.
I started to change that so that it didn't kill off the critter a
second time, bit it really shouldn't be able to kill it by stoning in
the first place. So sandestin how shares some vampire code to revert
to innate form and not turn to stone when "killed" by stoning. It
only yields the normal visible polymorph message: "the <foo> turns
into a <bar>" without any attempt to explain why. Once in sandestin
form, smacking it with a cockatrice corpse doesn't do anything special
(due to MR_STONE now being unambiguously in effect). It will soon
shape-change to some other form and then become subject to being
forced back to innate shape by stoning again.
When Stoned, Slimed, Strangled, Sick (TermIll or FoodPois or both)
counts down to 0 without being cured, keep it listed as an active
condition while killing off the hero. It will show in the status
section when disclosing final attributes and in both that section
and map's status lines when producing a dumplog.
Report was for Sokoban but it applied anywhere: if a teleported
boulder landed in a pit or trap door or hole and flooreffects() used
it up (so returned True), rloco() didn't update the location it was
teleported from and it appeared not to have moved. (Line of sight was
updated to reflect its absence but map spot wasn't redrawn without it.)
Changing
if (ammo_and_launcher(otmp, uwep) && mwep->otyp == ELVEN_BOW)
(with 'uwep' typo) to
if (mwep->otyp == ELVEN_BOW && ammo_and_launcher(otmp, mwep))
(with fixed 'mwep') moved ammo_and_launcher()'s hidden non-null
test to after 'mwep->otyp'. If mwep was Null (so monster must be
throwing non-ammo such as darts or daggers rather than shooting
with a launcher), a crash occurred. (Throwing such things while
the monster is wielding any weapon doesn't have this problem.)
I don't think 3.6.2 can crash here. If hero's uwep is a bow, otmp
must be arrows to get past pre-3.6.3's incorrect ammo_and_launcher()
check. And a monster won't shoot arrows unless wielding a bow, so
monster's mwep would be non-Null regardless of what uwep is.
I tested a kobold with darts and an elven bow. But I also gave it
one elven arrow to provoke it into wielding the bow and my test
didn't throw darts with nothing wielded....
A typo caused the bow and arrow check when a monster was wielding an
elven box to test the hero's weapon with monster's ammo. [I looked
at the old slash'em code where I think this came from and it doesn't
have the typo but does have a different bug. A monster could get a
multi-shot volley by wielding an elven bow when throwing darts or
spears. The extra bow and arrow check is intended to prevent that.
The typo was probably by me but I have no memory of that code....]
Elves with bows (or other monsters who manage to pick up and wield an
elven bow) will shoot bigger volleys after this fix. That will make
them more dangerous but also cause them to run out of arrows more
quickly.
From the newsgroup (reported for slash'em but applies to nethack too):
a chaotic monk was crowned and told he or she had been "chosen to
steal souls for My Glory!" while being given a spellbook of restore
ability which has nothing whatever to do with soul stealing. There's
alternate wording for when Stormbringer can't be given because it
already exists; also use that for when it's not going to be given
because the character is discouraged against wielding weapons.
Add the contributed code that checks for attempting to start a
duplicate timer. It's based on a comment which must have been there
at least 25 years and doesn't solve any known problems, but it is
conceptually similar to the large amount of sanity checking which has
gone into 3.6.x.
It didn't work as is because it was comparing two unions with '=='.
I don't know offhand whether C++ supports that but C doesn't (through
C11 at least; don't know about C17). The union ('anything') is simple
enough that two instances can be compared without jumping through hoops.
I've also added another check for timer 'kind' (level, object, monster,
or global).
