If you chat with a peaceful gnome while hallucinating, you might
get a silly message from the TV show South Park.
To make it work for non-gnome characters, I changed the speech of
monsters who normally just grunt (gnomes, orcs, ogres, a couple
of other groups) to full humanoid when the hero is hallucinating.
(It already does that for orcs if the hero--hallucinating or not--
is an orc and for gnomes when the hero is a gnome.)
... when the guard is angry, and he's in the vault or in his corridor,
you're not in the vault nor in his corridor, and the level is full
so the guard cannot relocate.
If mksobj() was told to initialize the object it's creating and the
object class was something it didn't understand, it would issue a
warning and return Null. But an unknown object class is a severe
internal error and very few callers were prepared to deal with a
Null result, so change mksobj() to panic instead. Also eliminate the
few attempts to deal with Null result that are present in mkobj.c;
I didn't go looking elsewhere.
Noticed while investigating the message loop. If I had level files
from an interrupted game and was asked "Destroy old game?" when
starting a new one, answering 'n' left the terminal in an unusable
state. Executing 'stty sane' (invisibly since input echo was off)
repaired things but the user shouldn't have to do that.
Change unixtty.c's error() to shut down windowing if that has been
initialized. This might need some tweaking for tty, which will now
clear the screen before showing the startup error message. Other
systems besides unix use unixtty.c so are affected, but I think the
change doesn't introduce anything that should cause trouble (aside
from the potential screen erasure).
Sword given to angels used obj->spe = max(obj->spe, rn2(4)) [except
using a temporary to sanely work with max() macro]. But the obj was
explicitly created as no-init, so obj->spe was always 0 and the max()
was pointless. Shield given to angels was manipulating bless/curse
state directly instead of using the functions intended for that, a
no-no and also pointless to be clearing 'cursed' for a no-init item.
Mace for priests had useless handling for object creation failure.
Object creation failure could only happen if the mksobj() call had a
valid entry in objects[] (or out of bounds access that didn't crash)
for an object class that it doesn't know how to handle. That can't
happen unless somebody screws up big time. If it ever did happen,
it would have produced a memory leak.
Report #H9243 misinterpreted W_WEAPON as W_WEP and attributed a
hypothetical ball and chain sanity checking problem to that.
Rename the former to W_WEAPONS to emphasize that it includes
alternate/secondary weapon and quivered stack as well as wielded
weapon.
Scatter did not consider the ball or chain, and moved them around, causing
ball and chain sanity error.
One way to trigger was being punished, with chain on a land mine and having
a monster trigger the mine. Now the chain will shatter, unpunishing the hero.
I had this in place at one point but must have accidentally undone it
before deciding that yesterday's patch was finished. Defer fetching
'pw' until it's needed.
Fixes#26
Report stated that the attempt to look up the player's username
(on Unix) failed (reason unknown) and nethack refused to allow the
player to execute the #explore command even though sysconf was set
to use character names (CHECK_PLNAME=1) instead of user names.
Setting EXPLORERS to "*" overcomes this glitch, but the fix moves
a bit of code around to honor CHECK_PLNAME before fetching username
so that that isn't necessary.
I ended up doing some formattng clean up (replace tabs with spaces,
whitespace cleanup in 'port_insert_pastebuf()'). The actual change
to fix#26 is only a few lines.
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.
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.
