the return value from condition_size() was unused so
eliminate an unused variable warning and rename the function
to better reflect that it updates tty_status[NOW][BL_CONDITION].lth
Another part of github issue 227. Casting a function pointer when
passing it to another function is iffy when lying about the return
type. tputs() expects a routine which returns int, so give it one.
Other xputc() usage is equivalent to putchar(), so define xputc()
with the same function signature as that has.
The tputs() declarations in system.h should probably be changed
(third argument is a function which takes an int rather than
unspecified parameters) but I've left them alone. I made that change
to tputs() in sys/share/tclib.c though.
NT and MSDOS changes are untested. tclib.c compiles ok with clang-
as-gcc on OSX but hasn't been tested with the port that uses it (VMS).
Fixes#227
Travel, <ctrl><direction>, <g|G><direction> all stop on engravings,
but <shift><direction> told the player what the engraving said and
kept going. The message output is buffered until map update or
another message, so player couldn't tell where hero was at the time
the engraving got shown. Make <shift> running stop on engravings.
More from github issue 229: mark routines in util/dlb_main.c which
don't return as such and add some 'break' statements for compilers
that don't have support for that.
Another part of github issue 229, mixtype() didn't have either 'break'
or '/*FALLTHRU*/' separating healing from extra healing, extra healing
from full healing, and full healing from unicorn horn. So dipping
"bad" potions (sickness, confusion, blindness, hallucination) into
healing/extra healing/full healing or vice versa operated the same as
dipping a unicorn horn into the bad potion (producing fruit juice for
sickness and water for the others). It wasn't clear from the code
whether or not that was intentional. It actually seems reasonable
(albeit suboptimal use of {plain, extra, full} healing), so continue
to allow it and make the code clear that it's intentional.
Fix the first part of github issue 229. sortloot_classify() tries to
group musical instruments separately from other tools, but missing
'break' in a 'switch' prevented that from happening--they were mixed
together.
Since that grouping isn't documented anywhere, only source divers
would ever notice that it wasn't working as intended.
when polymorph causes loss of levitation boots or water walking boots
while over water. If discarding stuff while trying to crawl out got
rid of the taken-off boots, they wouldn't be in inventory any more
when break_armor() tried to drop them after taking them off.
when attempting to crawl out of water fails and hero is life-saved
or wizard-/explore-mode player declines to die. If the hero is saved
by positioning him/her one step further away from ball and chain,
teleds() tries to drag them, but if 'emergency disrobe' left the hero
stressed or worse, dragging fails. Ball and chain were being left
where they were, with chain no longer being adjacent to hero.
If drag_ball() fails, have teleds() teleport ball and chain to hero's
new spot, same as when that isn't within range of a one step drag.
A couple of early returns could result in temporary windows getting
left around instead of being released for re-use, which in turn might
lead to a panic due to lack of available window slots. The first
one is accompanied by an 'impossible' warning which no one has ever
reported and the second one could only happen if data file 'keyhelp'
was missing, so panic due to either of these is hypothetical as far
as released versions go. Somebody making modifications could run
afoul of either of them though.
query_category() - switch from early return to 'goto' so that the
temporary window used for a menu will always be destroyed;
whatdoes_help() - defer creating the display window until after the
data file has been successfully opened so that early return won't
need any window cleanup.
github pull request #228 commentary follows:
This adds a boolean option, autounlock, defaulting to true. When this is
set to TRUE, messages stating that some door or container is locked are
automatically followed by a prompt asking if you would like to unlock
it, if you are carrying an unlocking tool (key, lock pick, or credit
card).
Architecturally, this extends the pick_lock function to take three
additional arguments (door coordinates or a box on the ground you are
autounlocking).
Because this adds a new field to struct flag, this is not a
save-compatible change. I have not adjusted EDITLEVEL or
VERSION_COMPATIBILITY, though.
The code that selects an unlocking tool will always look first for a
skeleton key, then a lock pick, then a credit card. Since curses, rust,
and other attributes don't really have an effect on the viability of the
unlocking device, it didn't seem to warrant making a more complex
function for that.
closes#228
This adds a boolean option, autounlock, defaulting to true. When this is
set to TRUE, messages stating that some door or container is locked are
automatically followed by a prompt asking if you would like to unlock
it, if you are carrying an unlocking tool (key, lock pick, or credit
card).
Architecturally, this extends the pick_lock function to take three
additional arguments (door coordinates or a box on the ground you are
autounlocking).
Because this adds a new field to struct flag, this is not a
save-compatible change. I have not adjusted EDITLEVEL or
VERSION_COMPATIBILITY, though.
The code that selects an unlocking tool will always look first for a
skeleton key, then a lock pick, then a credit card. Since curses, rust,
and other attributes don't really have an effect on the viability of the
unlocking device, it didn't seem to warrant making a more complex
function for that.
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.)
