The fix to prevent "crushed by a gas spore's explosion" set killer.name
to an empty string after a gas spore explosion finished, but that made
nested explosions end up with empty killer.name after the innermost
call completed. explode() shouldn't have been hanging on to a pointer
to a global value that is subject to change while it executes. Making
a local copy of the current value at the time explode() is called will
solve that (I hope...).
Simply reverting the reset of killer.name wouldn't have been correct.
The innermost explosion would still be clobbering killer.name for any
outer MON_EXPLODE explosions in progress. When the only exploding
monster is gas spore, that wouldn't be noticeable. But having other
types of exploding monsters and a chain reaction which affected more
than one type would have exposed that bug. I think this fixes both
aspects of this problem but don't have a second type of exploding
monster to verify the second part.
When dgn_comp.l and lev_comp.l are processed by older versions of
flex, 'gcc -Wunused' complains when compiling dgn_lex.c and lev_lex.c
because flex creates 'static void yyunput()' and nethack doesn't use
it. Newer versions honor macro YY_NO_UNPUT to hide the offending
code, but that doesn't help with older versions (like the one
masquerading as 'lex' on OSX). Adding a dummy usage would probably
cause problems with other lexers, so change it from static to
'void yyunput()' as a 'sed' fixup in util/Makefile after flex has
finished. That will be a no-op when yyunput doesn't exist or isn't
static.
In addition to the sys/unix/Makefile.utl change, this checks in new
sys/share/{dgn,lev}_lex.c with the fixup in place.
Fix a comment typo. While in there, change the cleave attack to
swing counter-clockwise the very first time instead of setting up
for that but then toggling to the opposite direction before the
actual attack. Also, refactor a bit of common code for choosing
< xdir[], ydir[] > index for next target.
Noticed while investigating the broken chest whose lock was already
broken: wishing for locked, unlocked, or broken chest (or large box)
was treated as asking for something unknown. Add support for those
three prefixes, although they only have meaning for chest and box.
If more that one is specified in the same wish, whichever one comes
last overrides the others.
Also, "empty" was already an accepted prefix (for tins); honor it for
containers too.
Lastly, wishing for "box" failed. Give a large box instead. I went
back and forth about whether to do the same for "small box" and ended
up not including it, but turns out that small/medium/large prefix for
globs ends up making "small box" and "medium box" match "box" which
has now become a synonym for "large box". I'm not sure whether that
is a bonus or a bug; small box is clearly not the same thing as large
box, but getting the only available box when asking for any box seems
better than claiming not to understand the request.
When using #force at a spot which has a broken or unlocked chest (or
large box) whose lock state has been previously discovered, avoid
|There is a broken chest here, but its lock is already broken.
|There is an unlocked chest here, but its lock is already unlocked.
by suppressing "broken"/"unlocked" from the chest description for
that particular message.
We might still want to change "broken chest" to "damaged chest" but
I don't think there should be any reference to its lock as the reason
it's broken or damaged. The fact that #loot, #force, and applying a
key still treat it as a container is sufficient to reveal that it
functions as one.
> When you try to #force a large box or chest whose lock is already broken from a
> previous #force, the game tells you "There is a broken large box here, but its
> lock is already broken." It's minor, but this implies that the box being broken
> is separate from the lock being broken (as well as that the box itself *can* be
> broken).
change the wording to "lock-damaged box" and suppress
", but its lock is aleady broken" when "lock-damaged box" has
already been displayed.
(Nobody particularly likes the wording "lock-damaged box" either, but at least
it seems less misleading)
Handle more *man and *men cases.
Some plural usage of completely made up fruit names that should
be entered in singular form but have what appears to be a
valid plural name it will end up singularized. Not much
we can do about that for ficticious words.
For instance, if you try to name your fruit bigmen or snakemen
and you intended that to be the singular name, NetHack will likely
singularize it to bigman or snakeman.
Many real dictionary words that end in "men", however, should
be handled a wee bit better now. A real word such as stamen,
for example.
"boxen" may be hacker slang for plural of "box", but "foxen" is
definitely not the plural of "fox". Restrict the "ox"->"oxen"
entry to full word "ox", not "*ox" suffix.
Trying to open at the same location as you did nothing,
make it loot instead. Apparently #looting is also annoying
when using vi-keys.
Based on code by aosdict
The use of debugpline() in tty_curs() got me wondering what would
happen if debugpline() was called while pline() is in progress. I
don't know how to trigger the bad coordinate situation, so I put an
unconditional debugpline() in the NHW_MESSAGE case of tty_putstr()
and used DEBUGFILES=wintty.c to enable it. Instant segfault, and
the backtrace was short and not useful so the stack might have been
clobbered. I didn't spend any time trying to figure where or why
the segfault occurred.
Change pline() so that if it is called while the previous pline()
hasn't finished yet (ie, recursively), use raw_print() and return
early. The raw_print message isn't very useful--it pops up wherever
the cursor happens to be, just like the cursor position bug that has
been an issue recently--but does get delivered without any segualt
and isn't completely useless if DUMPLOG is enabled and you save or
quit before the message buffer gets recycled. Message readability
situation could be improved but avoiding the segfault was my goal.
Putting any debugpline() into *_raw_print() would be inadvisable....
ensure tty_curs() behaves the same whether DEBUG defined or not
when it comes to positioning the cursor.
The return statement, in the debug case only, was preventing
the cursor from being moved following a range check, so the
next output was written whereever the cursor happened to be
previously.
The messaging that detects the failed range check will get
written in the DEBUG defined case hopefully allowing resolution
to the range check failure, but now the cmov will still
be attempted just as it is in the case where DEBUG is not
defined.
Report classified this as 'segfault' but it's actually a controlled
panic(). When hero has lycanthropy and is wielding a potion of unholy
water while in human form, if that potion is boiled then it triggers
a transformation to beast form which in turn causes wielded weapon to
be dropped. When the code unwinds back up through potionbreathe() to
destroy_item(), the boiled potion won't be found in inventory any more
and useup() -> useupall() -> freeinv() -> extract_nobj() panics.
When make uses 'makedefs -v' to create date.h, force it to create
gitinfo.txt all the time instead of just when that doesn't already
exist. Use 'make GITINFO=0' to get the previous behavior.
To skip it entirely, you need to do that and also make sure that
some file by that name already exists. 'touch dat/gitinfo.txt' or
perhaps 'echo "#no git" > dat/gitinfo.txt' would suffice.
If an mplayer Valkyrie on the Astral Plane is given a war hammer,
give her gauntlets of power instead of random gloves since that will
either be Mjollnir or a very wimpy endgame weapon. (Maybe someday
mplayer Valkyrie's will be able to throw Mjollnir; their chance of
having it on the Astral Plane is moderately high if it hasn't already
been created prior to arriving there.)
I also gave monsters wearing gauntlets of power a 3..6 damage bonus
for hand-to-hand. While making that change, I noticed that monsters
wielding a scalpel or tsurugi wouldn't split puddings, unlike the
hero (a post-3.6.0 change), so fix that.
I'm not sure of the status for possibly maintaining 'Files' via
automation, so manually add the new file 'gitinfo.sh' to sys/unix.
There was a sys/unix/hints file that wasn't listed, so add linux-qt4.
The whole win/Qt4 subdirectory is missing though. I don't even
remember that being added.
Update dat/gitinfo.txt if the current branch is different from the
one recorded in the file, not just when the commit hash is different.
Make the usual output less verbose so that it fits within 80 columns.
