../win/curses/cursmain.c: In function 'curses_init_nhwindows':
../win/curses/cursmain.c:157:17: warning: unused variable 'pdc_font' [-Wunused-variable]
157 | static char pdc_font[BUFSZ] = "";
| ^~~~~~~~
../win/curses/cursmain.c: At top level:
../win/curses/cursmain.c:157:17: warning: 'pdc_font' defined but not used [-Wunused-variable]
Reported directly to devteam, mounted hero whose steed got hit
for knockback effect triggered impossible "no monster to remove".
In addition to fixing that, this makes a knockback attempt at a
hero who is stuck to a cursed saddle knock the hero and steed back
instead of knocking the hero out of the saddle.
mhurtle_step() should be able to use u.ux0,u.uy0 to update the
hero's old location after moving the hero in order to move the
steed, but the value was different from what was expected and the
map showed stale steed symbol when I used that. I'm not sure what
is going on there; saving u.ux,u.uy before moving the hero worked
as intended so I didn't pursue it.
An Xcode update has started causing the same problem that was experienced on
Linux with newer compiler or glibc a while back.
˜
In file included from monst.c:6:
In file included from ../include/config.h:670:
In file included from ../include/integer.h:54:
In file included from /Applications/Xcode_14.0.1.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/14.0.0/include/stdint.h:52:
In file included from /Applications/Xcode_14.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/stdint.h:52:
In file included from /Applications/Xcode_14.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/_types.h:32:
/Applications/Xcode_14.0.1.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/sys/cdefs.h:302:39: error: too few arguments provided to function-like macro invocation
^
1 error generated.
make[1]: *** [monst.o] Error 1
Please enter the commit message for your changes. Lines starting
More tty-specific hangup handling. There's still doubt about the
origiinal testing, but not about testing after "post bitrot repair",
if there was any. That wasn't useful because the new code was
accidentally suppressed by testing a misspelled macro. when deciding
whether to include it.
Pull request from entrez: the conditional hangup handling in
wintty.c hasn't been getting used because the HANGUPHANDLING macro
from the core was misspelled as HANGUP_HANDLING.
The old testing was probably invalid since it was most likely done
with the same misspelled #if. I haven't done any new testing so
since this should be considered potentially buggy.
Fixes#891
The SIGHUP handling for the TTY windowport added in 594cb5f was wrapped
in '#ifdef HANGUP_HANDLING', but the actual define is 'HANGUPHANDLING'
without the underscore.
Issue reported by eakaye: the alternate hobbit chat message is a
complaint about dungeon conditions, given if its current HP is 10
or more less than its maximum HP. But since hobbits are level 1,
they will almost never have 10 HP so won't be alive to chat when
at max minus 10.
Keep the old behavior if maximum happens to be more than 10, but
give alternate feedback when less than max if max is 10 or less.
Fixes#890
I was trying to reproduce the reported "no monster to remove" warning
from remove_monster() when a mounted hero was knocked off jabberwocky
steed but so far haven't been able to.
While trying, I came across a more minor bug. The hero got knocked
off a flying steed and got feedback of "you fly off" rather than
"you fall off". Flying capability came from the steed and dismount
feedback is aware of that but calls u_locomotion() which isn't. This
commit fixes that.
This adds some groundwork (DISMOUNT_KNOCKED) for better dismount
control. With a map fragment of
|....
|.Du.
|....
I got knocked off my steed by the attacking dragon and ended up with
|..@.
|.Du.
|....
It would be better to prefer spot 1, then the 2s, then 3s, then 4s
(not sure about farther spots if none of those are available)
|.432
|.D@1
|.432
when forced to dismount by knockback. This does _not_ implement that.
Pass the wait-for-response arg when displaying the wishing help text
window. tty, curses, and Qt waited regardless, but X11 honors the
no-wait request. It was showing the text window then letting the
core immediately resume, resulting in reissuing the wish prompt on
top of the help window. Entering a successful wish then dismissed
the prompt but left the help on the screen, possibly obscuring the
map depending on placement.
Reported by eakaye: orcish hero has maximum strength of 18/50 but
hero poly'd into an orc was given 18/100 strength. Also, a comment
from vultur-cadens pointed out that orcish heroes start with poison
resistance while monster orcs lack it.
Even though the boost to 18/100 is only temporary until the poly
times out, make orcs a special case where strongmonst from poly'ing
into them only gives 18/50 strength instead of 18/100. Adopt the
suggestion that Uruk-hai be an exception and continue to give hero
poly'd into them 18/100.
If any gnome becomes strongmonst (currently none are), treat them
as 18/50 too. Elvenking and elf-lord are strongmonst; treat their
forms as plain 18 though, matching the limit of elf heroes. Lesser
monster elves aren't strongmost.
While in there, add another special case so that hero poly'd into a
giant gets 19 strength. Monster giants are still plain strongmonst
so might warrant some sort of adjustment.
Give orcs poison resistance, but eating their corpses doesn't provide
an opportunity to confer it. Note goblins and hobgoblins still don't
have the resistance (to distinguish them from orcs a bit).
Take away strongmonst from orc shamans and give it to orc mummies.
Human mummies should have it too (at least according to movies) but
I didn't alter them becuase they're already pretty dangerous at the
point they start occurring. Take away strongmonst from plain 'elf'
placeholder.
New: when hero polymorphs into a form that lacks the strongmonst
attribute, take away any exceptional strength (drop 18/01 through
18/100 down to 18; as mentioned above, the drop is only temporary).
There's no attempt to set the maximum even lower for wimpy forms.
Fixes#679
Suggested by entrez: when you search while engulfed the feedback asks
whether you're looking for the exit, but the joke about the exit isn't
funny when repeated over and over which happens if the player waits to
be expelled by using 's','s',... rather than '.','.',....
[sic] should be "engraving in frost mentions dust"
Writing on ice with fingers is described as writing in frost, but if
you overwrite an existing engraving rather than add to it the game
said you wiped out the engraving in the dust (immediately followed
by writing in the frost).
Not mentioned in the report: finishing a multi-turn engraving on
ice had the same problem.
Pull request from entrez: X11's get-extended-command widget
allocated 1 extra byte for a couple of end-or-array terminators
and then wrote more than 1 byte to them when initializing its list
of extended commands.
Fixes#884
Instead of allocating space for ((n + 1) * size) (to make room for all
entries plus terminator), it allocated space for (n * size + 1).
init_extended_commands_popup would therefore write past the end of the
memory allocated for command_list and command_indx when trying to store
their respective terminator entries. This meant the X11 windowport
would crash when accessing the extended command menu, if NetHack had
been compiled with -fsanitize=address.
I also did some minor cleanup/refactoring to eliminate variables and
lines that were made redundant or useless by 9d64d13, which changed the
way the function worked and removed the need for things like tracking
indices in the source and destination arrays with separate variables.
A change to the curses interface from three years ago to make sure
that round-off didn't make the horizontal and vertical clipped map
indicators appear to not be clipped was using ROWNO for both instead
of COLNO for the horizontal one. For modest clipping the mistake
was unnoticeable; I don't know whether that remained true for more
extreme clipping.
[Not fixed: the curses scrollbar stuff ignores the fact that map
column 0 is unused.]
warning: for tile 250 (numbered 250) of objects.txt,
found 'huge chunk of meat' while expecting 'enormous meatball'
../win/share/objects.txt: 460 tiles
Make the prompt for single genocide be more precise
from: What monster do you want to genocide?
_to_: What type of monster do you want to genocide?
and the re-prompt for it be slightly more verbose
from: What... [type the name of a monster]
_to_: What... [enter the name of a type of monster]
Also, make the already verbose re-prompt for class genocide even
more verbose
from: What class... [type the symbol representing a class]
_to_: What class... [type the symbol or name representing a class]
Possibly should have changed 'type' to 'enter' on the last one to
keep them consistent but I left that as-is.
Pull request from entrez: genocide prompt has a short explanation
appended. Skip that on first try, and on all tries if 'cmd_assist'
option is Off.
For class genocide, don't retry an unlimited number of times if
player supplies an empty response. Any empty response will now
count toward the 5 chances available to supply a valid choice, as
it does with single genocide.
Fixes#882
The "[type the name]" prompt seems appropriate for handling via
cmdassist, so experienced players who don't need the help can hide it.
I also added a corresponding help note for the class genocide prompt.
So that a blank line wouldn't use up one of the player's "tries" for
class genocide, the game would continue to prompt until the input was
non-blank (or the user hit <esc>), with a tight loop around the getlin
call that only exited when it got some non-empty input. This apparently
risked leaving the game endlessly looping under some worst-case-scenario
hangup conditions. It was also inconsistent with normal genocide, which
doesn't have special handling of blank lines. Make the class genocide
prompt behave like the normal genocide prompt by removing the "blank
input" loop (and consequently treating a blank line the same way as any
other attempt to write a name).
Pull request from chasonr: if the curses interface did a full screen
update while the game was ending, it could attempt to refresh windows
that had already been removed.
For #if PDCURSES, raw_print() could attempt to write to the message
window after it had been removed.
[Why is raw_print() using the message window at all? Isn't the main
point of it to bypass that?]
Fixes#881
* When saving: curses_exit_nhwindows calls curses_uncurse_terminal,
which calls endwin. curses_exit_nhwindows then calls raw_print,
which calls more Curses functions after endwin has been called.
Fix this by having curses_raw_print use puts if window_inited
is false.
* When dying, quitting, etc.: really_done opens the "Goodbye" window,
which refreshes the other windows when it closes. But the status
window (and possibly the map and message windows) are gone by that
point. The window pointers are properly NULLed, but the NULL is then
passed to touchwin. Fix this by checking window pointers for NULL.
Pull request from entrez: fix an off by one error in the allowed
range of subroom indices.
I've never understood subrooms and am accepting this fix on faith.
Fixes#859
