I've noticed (with curses interface) that there are a lot of
update_status(BL_FLUSH) calls when nothing on the status lines
has changed. It happens while just wondering around, not due to
deliberate botlx update. This eliminates one of the causes.
Updating hero's experience points or score (via u.urexp) was
requesting a bottom lines refresh even if the relevant options to
see those changed values was off. The botl code would send a flush
directive even though nothing visible was modified. (I have a fix
for that too, but am holding back while hoping to find some of the
other causes of unnecessary botl requests.)
It took me a while to track this down: if you use 'O' to create
hilite_status rule(s) for status condition(s) and you specify multiple
attributes in the rule creation menu, it accepts them but it was
parsing the new rule(s) incorrectly and only supported one attribute.
if (mask & bit)
something;
else if (mask & other_bit)
something_else;
else if (mask & yet_another_bit) ...
effectively stops at the first bit matched. (At the time that that
was written, the menu leading to it only accepted a single attribute.)
More groundwork for overhauling the status display for curses, plus
a few functional changes. It was doing a full status update for
every changed field (except conditions), instead of waiting for a
flush directive after gathering multiple changes at a time. Since
it already does gather every change, the fix to wait is trivial.
This decouples 'hitpointbar' from 'statushilites'. When highlighting
is off, it uses inverse video only. When on, it behaves as before:
using inverse video plus the most recent color used to highlight HP
(which can vary if that has rules to highlight changes or percentage
thresholds) but ignoring any HP attribute(s). This also enables the
latent 'statuslines' option and changes 'windowborders' option from
being settable at startup only to changeable during play.
'statuslines' can have a value of 2 (the default) or 3 and applies to
'align_status:bottom' or 'top'; it's ignored for 'left' and 'right'.
At the moment, setting it to 3 only allows status condition overflow
to wrap from the end of line to 2 to the beginning of line 3, and if
window borders are drawn they'll clobber the last character on line 2
and first one on line 3. There's no point in trying to fix that
because it will go away when the main status overhaul changes go in.
Condition wrapping for vertical orientation (left or right placement)
was already subject to the same phenomenon and will be superseded too.
This also changes the meaning of the 'windowborders' value so could
impact players using source from git (or possibly beta binaries for
Windows, but not for OSX where curses interface wasn't included).
Old:
0 = unspecified, 1 = On, 2 = Off, 3 = Auto (On if display is big
enough, Off otherwise; reevaluated after dynamic resizing);
Unspecified got changed to 3 during curses windowing initialization.
New:
0 = Off, 1 = On, 2 = Auto;
0 gets changed to 2 for default value at start of options processing.
So old value of 2 is changing meaning and explicit old value of 3 is
becoming invalid. Implicit 3 changes to default 2. Explicit 3 could
be the subject of a fixup but there isn't much point since 2 can't
have a similar fix. Users who are using old 2 or explicit 3 will need
to update their run-time config files.
This adds 'statuslines' to the Guidebook and moves some other recently
added documentation of curses options from among the general options
(section 9.4) to "Window Port Customization options" (section 9.5).
None of them have been added to dat/opthelp which seems to be missing
all the wincap options.
Originally I made a lot of changes (mostly moving C99 declarations to
start of their blocks) to the old '#if 0' code at end of cursstat.c,
but have tossed those, except for one subtle bug that assumed 'int'
and 'long' are the same size.
decode_mixed() writes its output into a 'char *' buffer that's passed
in to it and then returns that buffer. Some excessively paranoid
error checking forced to return 'const char *'. Relax that and use
'char *' so callers can work with the result without extra casts.
Change the generic status line location "End Game" to relevant element
name "Earth", "Air", &c. ("Plane of <element>" might be too long if
hungry and encumbered and afflicted by conditions. "Astral Plane" is
already specific so not affected.)
The curses interface was ignoring video attributes (bold, inverse, &c)
when color is toggled off or if built with TEXTCOLOR disabled. Honor
attributes regardless of whether color is displayed.
Also, toggling 'hilite_pet' On during play wouldn't do anything if the
curses-specific 'petattr' option had been left as None. (It worked as
intended if set in starting options.)
Hide a bug in the X11 interface by manually wrapping 'short' version
line (the first line of #version output) when runtime ID or git hash
and/or branch is present. Otherwise the very wide 'short' line causes
a horizontal scrollbar to be present at the bottom of the popup window,
but the window size doesn't take that into account so ends up being
one line too short. Worse, there's no vertical scrollbar to bring the
last line into view.
Even if somebody figures out how to fix that properly, the really wide
line above a couple of paragraphs which have been carefully wrapped
for a much narrower width looked strange.
Also, move the 'short' version's period to the end of the text.
old: basic version info. (extra info)
new: basic version info (extra info).
Kicking a stack splits off one item (except for gold coins) and
propels it, but the range for how far it would move was calculated
before the split using the entire stack's weight. So a large stack of
small items might fail with "thump" (which the report suggested hurt
the hero, but it doesn't) and none of the stack would move. Splitting
sooner looked complicated because of several potential early returns
between the range calculation and the eventual kick, so this hacks the
stack's quantity to get the intended weight instead.
showed non-empty containers in inventory (including the one being
applied) with a 'for sale' suffix during put-in operations, as if the
shop was trying to sell it to the hero. Amount shown was cumulative
value of its contents. (Using /menustyle:T doesn't show the container
being applied so this wasn't visible with it unless other non-empty
containers were being carried.)
Two or three fix attempts solved one problem but introduced another.
This one seems to finally get things right but considering that there
was trial and error along the way, my confidence isn't great.
If steed ate a mimic corpse and started mimicking an object or dungeon
furniture, the hero was able to keep riding. Force a dismount when
that happens, even if steed takes on monster shape rather than object
or furniture. After that, #ride to remount non-monster will fail
unless using wizard mode's "force mount to succeed" action, in which
case steed's eating finishes immediately and it returns to normal.
This doesn't address the older report that mounted hero can continue
to move around while the steed is eating.
Report forwarded from spam filter so not included in bugzilla list.
Make corpse revival feedback be more consistent. Some of the healer-
specific flavor is still there.
Generally, fish should lay their eggs in the water and
not on land, but the game was only allowing the opposite.
Eels are catadromous and lay their eggs in the Sargasso Sea,
not in the dungeon.
This started out as an attempt to document the curses options in the
Guidebook, but I didn't actually get that far. Instead, integrate
the curses options better via more consistent WC/WC2 usage. This
prevents 'guicolor' from showing up as a boolean option for non-curses
interface in curses+other binary.
For curses itself, let 'petattr' be set/reset via 'O'. Also, accept
'Dim' as a possible pet highlight attribute since it already handles
all the other ordinary attributes. I'm not sure what leftline and
rightline highlighting are supposed to do. They were missing for
ncurses (or maybe they're misspelled for PDcurses?) but adding them
didn't produce any visible effect (using TERM=xterm-256color on OSX
with default font/character set).
Not addressed:
1) general confusion about compile-time vs run-time option filtering;
2) curses pet highlighting only works if 'color' option is enabled.
Something else noticed while testing #H8271: toggling perm_invent on
with 'O' didn't show anything (at least with curses) until some later
action caused it to be updated. Make updating persistent inventory be
included with full redraw and set the need_redraw flag when toggling
perm_invent.
Realized while fixing #H8271: if persistent inventory got an update
while wearing or taking off was in progress (not within user's control
since hero is busy) the item in question was flagged as "(being worn)"
even though it wouldn't be worn if putting on got interrupted. Update
doname() to show "(being donned)" or "(being doffed)" instead of
"(being worn)" when corresponding operation is in progress. (During
testing, I was able to observe "being doffed" but never managed to see
"being donned".)
A relatively recent change moved 'obj->known = 1' when wearing armor
from before setworn(), which issues an update_inventory() call, to
afterwards. There wasn't any particular update then, so observing
the enchantment of armor by wearing it wasn't being reflected in the
persistent inventory window if that was enabled.
Take another crack at describing yesterday's do-again fix. Having
'autoquiver' enabled wasn't necessary to encounter the problem.
Also, 'in_doagain' is an int rather than a boolean.
It's possible to get a rolling boulder trap which doesn't have any
boulder. That isn't invalid, but if/when it happens on a shallow
level it shouldn't be covered by the corpse of a fake adventurer
since such a trap won't kill anyone.
One-line fix is much shorter than attempting to describe the problem.
^A could misuse previous input if 'f'<direction> needed to fill the
quiver and there was nothing suitable, so that the sequence became
'f'<what to throw>. If previous <direction> was an inventory letter
that was occupied, and the item it that slot wasn't already worn in
some other slot, it would be put in quiver slot. Then player would
be asked for direction rather than immediately throwing it since the
what-to-throw prompt had just used up the last of the ^A queue.
Miscellaneous formatting included....
Noticed while fixing the 'monster intrinsics from worn gear' bug(s):
set_uasmon() calls set_mon_data(&youmonst,...) which updates movement
when the monster polymorphs into something slower, then it did the
same thing to youmonst.movement itself, hitting the hero with a double
dose of reduction for any movement points not yet spent on current
turn. Remove the set_uasmon() side of that, and change set_mon_data()
side to add a redundant non-zero test to prevent static analysis from
warning that it might be dividing by 0.
Fixes#177
The monst struct has 'mintrinsics' field which attempts to handle
both mon->data->mresists and extrinsics supplied by worn armor, but
polymorph/shape-change was clobbering the extrinsics side of things.
Potentially fixing that by changing newcham() to use set_mon_data(...,1)
instead of (...,0) solved that but exposed two other bugs. Intrinsics
from the old form carried over to the new form along with extrinsics
from worn armor, and update_mon_intrinsics() for armor being destroyed
or dropped only worked as intended if the armor->owornmask was cleared
beforehand--some places were clearing it after, so extrinsics from worn
gear could persist even after that gear was gone.
So, fixing the set_mon_data() call in newcham() was a no go. This
fixes update_mon_intrinsics() and adopts the suggested code from
github pull request #177 to have mon->mintrinsics only handle worn
gear instead of trying to overload innate intrinsics with that. This
is a superset of that; the flag argument to set_mon_data() is gone
and mon->mintrinsics has been renamed mon->mextrinsics. (The routine
update_mon_intrinsics() ought to be renamed too, but I didn't do that.)
Leather jacket doesn't take multiple turns to wear, so wearing it
wasn't calling Armor_on() and recently moved 'uarm->known = 1' didn't
get executed. Not reported yet but had the same issue: fedora and
dented pot wouldn't call Helmet_on().
Do late message suppression in a different fashion. Also, there are
more messages than shk taking hero's possessions and guard taking
hero's gold that need to be suppressed if regular message delivery
is no longer possible: "do not pass Go", "you arise from the grave
as a foo", "the corridor disappears", "you are encased in the rock".
Those last two are from vault handling but take place in a convoluted
manner: paygd -> mongone -> grddead -> clear_fcorr.
