Sometimes tty left part of the screen blank after covering the entire
screen with a menu and then switching to a smaller menu that should
have redrawn the map as background. To reproduce:
| O - puts up a big menu
| : - enter a search string: "autopickup exception"
| <return> - dismiss the menu after the search makes one match
The autopickup exceptions sub-menu will be shown, with a small border
of map around it but most of the screen blank. (This behavior was
present before 3.6.0 but may not have been noticed because when the
discovered map doesn't extend to the corner menu's area, the blank
map probably seemed to be intentional. But if a fringe of map gets
drawn around the menu, that clearly isn't intended.) The incomplete
map is temporary; once menu is dismissed, it gets redrawn properly.
This adds a flush_screen() call after one particular docrt() call.
Perhaps docrt() should end with its own flush_screen() instead, but
that would require a lot more testing.
Closes#673
When a 'full-screen' (cw->offx and cw->offy both 0) menu was immediately
followed by an offset menu -- as in the case of selecting certain
options from the options menu, or using loot to take out/put in items
after using ':' to describe the contents of a very full container --
there were some odd interactions with the map.
Only certain parts of the map near/under the menu window would be
redrawn if the first offset menu was followed by another one, while
a getlin prompt would cause the entire map to be redrawn, with parts
intersecting the window being drawn on top of it and obscuring it.
Flushing the display immediately after the docrt call when closing a
full-screen menu seems to fix both these issues.
If the first monster the hero kills is killed by the hero's first hit
with a wielded weapon, report the hit first and kill second instead of
the other way around. Not as hard to manage as I feared, but bound to
be more fragile than the simpler handling that produced the odd order.
Also while testing it I knocked something into a polymorph trap and it
changed form without any feedback. Give foo-changes-into-bar message
if the hero is moving and can see it happening. It isn't needed with
a monster moves deliberately into a polymorph trap but probably would
be useful when that's is unintentional.
The "<hero> enters the dungeon" log message had a trailing period but
other log messages don't have sentence punctuation, so take that off.
Turning on -Wformat-noliteral for Mac triggered a new warning.
Blindly suppressing the warning would have silenced it but would
also have left a real bug in place. The former format was passing
a string argument to %d format.
This converts the format to a literal with an additional argument
for the non-literal part. It compiles cleanly but I don't know how
to test it, let alone force an error for it to report.
In a curses menu, if you type a digit to start a count, the cursor
jumps to the spot on the screen where the hero is. Strange and very
noticeable if that spot is covered by the menu, although I didn't
notice it when working on digits as group accelerators (changes for
that didn't trigger this).
Despite the cursor_on_u location, it isn't related to the recent
flush_screen/cursor_on_u changes either. In 3.6.x, curses used it's
own count entry code. Early on with to-be-3.7 it was changed to use
the core's get_count(), so uses a different routine to get next input
character. And the curses edition of that routine deliberately
positions the cursor at the hero's location on the assumption that
it only gets called when the map window is active.
When a thrown item lands in a pool of water, it immediately
rusts - but don't give that message unless the hero is at the same
location and also under the water. My reasoning: hero can't see items
under water, and by the time the item rusts, it's in the water.
Have curses catch up with tty, X11, and Qt: if a menu of objects has
any heavy iron balls, their entries can be toggled on or off by using
'0' as a group accelerator. That's been supported by tty and X11 for
ages and by Qt since yesterday. This also supports having any digit
as a group accelerator so that the 'O' hack to pick number_pad mode by
typing the digit that matches the value description works (except for
menu entry for mode -1; '5' happens to work for that one but doesn't
match its description).
Have Qt catch up with tty and X11: in a menu, when not already
entering a count and player types a digit, check whether it is the
group accelerator for any of the menu entries. If so, toggle their
selection state; if not, begin counting for the next item the player
eventually picks.
I don't try to toggle 'number_pad' very often, but when I do I almost
always type '0' instead of 'a' for Off or '1' instead of 'b' for On
on the first attempt. The menu shows
| a - 0 (off)
| b - 1 (on)
| c - 2 (on, MSDOS compatible)
| d - 3 (on, phone-style digit layout)
| e - 4 (on, phone-style layout, MSDOS compatible)
| f - -1 (off, 'z' to move upper-left, 'y' to zap wands)
This change makes '0' through '4' be undocumented group accelerators
for 'a' through 'e' (and '5' for 'f') in the sub-menu put up by 'O'.
tty and X11 worked as-is for '0' and required what amounts to a pair
of one-line changes to handle the other digits.
It doesn't work for curses and Qt (no idea about Windows GUI) because
they insist on treating any typed digit as the start of a count even
if one or more menu entries include that digit as a group accelerator.
(They also fail to support '0' as the group accelerator for iron-ball
class in the menu for multiple-drop.)
MONITOR_HEAP+heaputil pointed out some unreleased memory. The livelog
stuff wasn't being freed. Not surpringly the data used for collecting
and formatting build-options that just got changed from strdup() to
dupstr() wasn't being freed. And a couple of date/version bits.
mdlib.c was avoiding alloc() and dupstr() because mdlib.o gets linked
with makedefs and makedefs used to need to avoid those. But makedefs
doesn't avoid those anymore, so mdlib.c doesn't need to either.
Replace a couple of other strdup() calls in other files too.
The livelog message for losing a level had an off-by-1 error, showing
the level the hero ended up at rather than the level that was lost.
There was a message for regaining a previously lost level when rank
title stayed the same but no such message if the title changed (the
achievement of gaining a particular title only occurs once).
Say "regained" rather than "gained" when gaining a previously lost
level. (Blessed potions of full healing regain levels but can also
reduce u.ulevelmax so a different way to remember peak experience
level has been added.)
Report level change due to polymorphing into new man/woman/elf/&c.
I hadn't realized that that hasn't been recording achievement for new
rank when applicable and decided to leave things that way.
Report gender change when putting on an amulet of change or becoming
a new man/&c unless hero is polymorphed at the time or experience
level is also changing.
Call growl even if you are deaf, because growling also
wakes up nearby monsters. Just make growl not show the message
if you can't hear or see the monster.
Log all level gains and loses. For the existing logging of changes
in rank, mention the level number with the new title. Classifying
level loss as "minor achievement" seems weird but I didn't see any
choice more appropriate.
Make '#chronicle' autocomplete. That makes "#ch" ambiguous, but
better to have to type #cha to chat than to have to completely spell
out #chronicle. (Changing it to #journal would make #j ambigious
but might still be an improvement.)
Call display_nhwindow(WIN_MAP) after curs_on_u(). Instead of calling
it a second time, it's simplest to just update status before updating
the map.
If anything is still leaving the cursor dangling at the end of status
I think it will now dangle at the last updated position on the map.
Log game events, such as entering a new dungeon level, breaking
a conduct, or killing a unique monster, in a new "Major events"
chronicle. The entries record the turn when the event happened.
The log can be viewed with #chronicle -command, and the entries
also show up in the end-of-game dump, if that is available.
This feature is on by default, but can be disabled by
defining NO_CHRONICLE compile-time option.
This also contains "live logging", writing the events as they
happen into a single livelog-file. This is mostly useful for
public servers. The livelog is off by default, and must be
compiled in with LIVELOG, and then turned on in sysconf.
Mostly this a version of livelogging from the Hardfought server,
with some changes.
Redo how do_screen_description() handles water. Mainly by using
waterbody_name() for farlook/quicklook and autodescribe to get
hallucinatory descriptions, but it replaces some old hackery with
quite a bit of new hackery. Applies to lava and ice too. The latter
is now "frozen <foo>" when hallucinating, where <foo> has a small
chance to be "water" but will usually be something like "tea" or
"clotted blood".
