I've noticed many instances of the game pausing and not being sure why,
then pressing <space> and having it resume. The curses interface had
a tendency to put its equivalent of the --More-- prompt, >>, somewhere
where that wasn't visible, either off the right hand edge (possibly) or
underneath the window borders if those were enabled. Especially the
very last one it issues prior to exit. (An extra one compared to tty
behavior.)
This ended up being a pretty substantial overhaul of message window
handling. I wouldn't be surprised if it has off-by-one errors which
happen to be paired up and cancel each other out. ">>" is still drawn
in orange if guicolor is on, now in inverse video when that is off.
If it happens to be drawn at the same screen location in consecutive
instances, the first ">" will toggle between blink and not blink so
that there'll be no doubt as to whether the keypress registered when
dismissing it (moot if the text preceding it is different but there's
no attempt to be smart enough to check that, just screen placement).
Make the same fix to curses that was done for tty in 3.6.1: don't
let MSGTYPE entries be matched against prompt strings. Like tty,
curses was using ordinary pline() to issue prompts; something like
MSGTYPE=hide"yn"
could wreak havoc. Switch to custompline(OVERRIDE_MSGTYPE,...).
This changes the recently added msg_window:f for curses to start
viewing the old messages on the last page rather than the first. For
msg_window:Reversed (the default for curses) and for either direction
when all of the message history happens to fit on one page, there's
no change. But for multiple pages, the FIFO feedback now pads the top
of the first page with blank lines so that the last page is full, and
it starts out showing that last page first. So if you only want to go
back few or several messages, they will be in view immediately.
Old layout:
|first message (oldest) | |1st message of last page |
|2nd message of 1st page | | ... |
| ... | |final (most recent) mesg |
| ... | | (blank filler) |
|last message of 1st page | | (blank filler) |
| (1 of 2) => | | <= (2 of 2) |
and ^P started with first page visible and needed normal menu handling,
<space> or '>' or '|', to go forward to view the most recent messages.
New layout:
|1st message of last page | | (blank filler) |
|2nd message of last page | | (blank filler) |
| ... | |first message (oldest) |
| ... | | ... |
|final (most recent) | |last message of 1st page |
| <= (2 of 2) | | (1 of 2) => |
and ^P starts on last page (two of two in this example) but can go
back with '<' and '^'.
So if the total size takes one and third pages (which isn't uncommon
for the default number of kept messages), you'll see 3/4 of the most
recent messages on the initial screen, then you can page backward if
you want to see the other 1/4.
The page indicator is deliberately drawn a bit differently just to
draw attention to the fact you're starting on the last page. I'm not
sure whether that is actually worthwhile but it was trivial to do.
I didn't noticed this because I've been building for tty+curses+X11
and either of the first two cause iflags.extmenu to exist. Make it
unconditional; there's not much benefit from trying to suppress it
for configurations that don't need it.
Support for scrolling within menus via first-/previous-/next-/last-
page keystrokes ("^<>|" by default) was added to X11's general menu
handling but the extended commands menu uses a special menu rather
than a general one. This clones the relevant code to add support for
those keys to extended commands.
The expansion of the extended commands list to include every command
has made picking extended commands out of X11's menu become tedious.
This uses the existing 'extmenu' option (previously tty-only) to
control whether all the commands are present or just the traditional
subset not bound to non-meta keystrokes ('adjust', 'chat', 'loot', &c).
PatR [Sun, 31 Mar 2019 22:34:46 +0000 (15:34 -0700)]
curses message suppression
The curses interface was using 'moves' as if it meant "moves" rather
than "turns". Typing ESC at >> (curses' terser version of --More--)
prompt would suppress messages for the rest of the current turn rather
than just the rest of the current move. So if the hero got an extra
move due to being Fast, there would be no feedback during that move.
PatR [Sun, 31 Mar 2019 15:23:36 +0000 (08:23 -0700)]
streamlined status update for 'time'
When the 'time' option is on and context.botl isn't already set,
call a simpler status update routine that ignores all other fields.
When that flag is already set, full status update takes care of time
along with the other fields.
Expected to reduce bottom lines processing time but not screen I/O.
Only lightly tested.
PatR [Sun, 31 Mar 2019 14:04:23 +0000 (07:04 -0700)]
curses status highlighting
window.doc states that the colormasks argument to status_update() is
only relevant for BL_CONDITION, but curses was relying on it to be
passed for BL_FLUSH as well. Yesterday's changes stopped the latter
and broke highlighting of status conditions. Other interfaces appear
to honor the description in window.doc.
PatR [Sun, 31 Mar 2019 07:33:33 +0000 (00:33 -0700)]
bogus status updates
I finally figured out why status gets updated periodically even if
none of the fields have changed. Once a temporary highlight times
out, it starts a cycle of timeouts every 'statushilites' turns. When
I worked on this before, it was convoluted but not this convoluted.
In moveloop, if 'context.botl' call bot; in bot
call evaluate_and_notify_windowport;
for each field, call evaluate_and_notify_windowport_field:
call hilite_reset_needed and set 'reset' to the result;
if 'reset' is True then do status_update
and set 'curr->chg' and 'prev->chg' to True.
Then in moveloop call status_eval_next_unhilite:
for each field
if 'curr->chg' set 'curr->time' to moves+hilite_delta;
on the call after hilite_delta ('statushilites') moves,
call hilite_reset_needed which returns True if there is any
rule for temporary highlight and set 'context.botl'.
Go back to start. If multiple fields had temporary timeouts and
they were activated on different turns so expired on different turns
you could conceivably end up with context.botl being set every turn.
My first writeup trying to explain all this was wrong. I won't
testify about the accuracy of this one in court....
This extends the highlighting data structure to track the current
rule that's in use. And for that to make sense, it eliminates the
merging of settings from multiple matching rules. So anybody with
hit-points/up/inverse
hit-points/up/green
hit-points/up/bold
will need to manually merge their rules like
hit-points/up/green&inverse+bold
or else whichever rule matches last will be the only one in effect.
There are a lot of miscellaneous changes made as I flailed about.
The three most significant ones are that there is no guesswork over
what kind of highlight rule is in effect, status_eval_next_unhilite
will only set a timeout value if the current rule is for a temporary
highlight, and hilite_reset_needed will only return True if a timeout
is for a temporary highlight (probably moot after the _next_unhilite
change).
PatR [Sun, 31 Mar 2019 00:46:16 +0000 (17:46 -0700)]
status line title field
Status formatting used to truncate the Name portion of "Name the Rank"
or "Name the Monster-type" at 10 characters even if the rank or monster
portion left room for more. Change that to keep as much of the name as
will fit. The truncation might vary over time as new experience levels
produce new rank titles of differing lengths, but I don't think that's
a problem. For truncated names, it still keeps at least 10 characters
even if that leaves the field longer than the target length for title
(which used to be 29 but now is 30).
PatR [Sat, 30 Mar 2019 00:03:03 +0000 (17:03 -0700)]
curses: save/restore message history
Have the curses interface save and restore message history for use
by ^P. It doesn't spit the saved messages out into the visible
message window after restore; that's too distracting.
PatR [Fri, 29 Mar 2019 21:35:36 +0000 (14:35 -0700)]
tty: panning while clipped
Noticed while testing statuslines on a small terminal window. Using
the cursor to pick locations that panned the map to view a new subset
would end up showing a new view of the regular map rather than a
different section of what was currently displayed. For farlook that
caused monsters to take on new hallucinatory forms which was fairly
inconsequential, but for #terrain and various forms of detection it
reverted to the ordinary map instead of showing the map features that
the player requested or the temporarily revealed monsters and such.
Most interfaces keep track of the whole map and just show their view
of the new subset when panning, similar to redisplay after being
covered up and then re-exposed, but tty isn't doing that. I made
same change to Amiga as to tty since the code it was using was very
similar. I haven't touched any of the other interfaces and assume
that they don't need this. I've verified that curses and X11 don't.
PatR [Fri, 29 Mar 2019 11:21:18 +0000 (04:21 -0700)]
tty statuslines:3
Implement the 'statuslines' option for tty. 2 and 3 line status are
similar to curses. Tty's version doesn't include insertion of extra
spaces for enhanced readability, or ignoring 'showexp' when space is
needed for other fields, or right justifying 'score' and suppressing
it when there isn't room for the entire number. It continues to have
abbreviated condition and encumbrance descriptions that curses lacks
which get used when the normal ones take up too much space.
'statuslines' can be set with 'O' so it is feasible to switch back
and forth between 2 and 3 lines on the fly. But only if the display
is at least 25 lines (actually ROWNO+4) or else CLIPPING is enabled
at build time.
This fixes the bug where after resorting to abbreviated condition
values it sometimes (always?) wouldn't switch back after more room
became available. Abbreviated encumbrance values had problems too
(lack of leading space and not changing value if encumbrance changed
to anything other than unencumbered) and this fixes that as well.
PatR [Thu, 28 Mar 2019 15:40:40 +0000 (08:40 -0700)]
fix githib issue #179 - random drawbridge state
Fixes #179
The Valkyrie goal level has two drawbridges and one of them was set to
have 50:50 chance to be closed (raised). But 'random' for drawbridge
open/closed (or lowered/raised) state was always choosing open (lowered).
This fixes that and also changes that level to have the old settings
(southern open, northern 50:50) for 75% of the time and new settings
(both 50:50) for 25% of the time. So there's now a 12.5% chance that
both will be closed instead of both always being open (due to the bug
with handling random).
PatR [Wed, 27 Mar 2019 02:27:11 +0000 (19:27 -0700)]
tty hitpointbar
Catch up with curses and have hitpointbar work even if statushilites
is 0 to suppress other highlighting. Indirectly fixes #H8389 by
making the circumstance which triggered that bug no longer do so.
PatR [Wed, 27 Mar 2019 02:16:01 +0000 (19:16 -0700)]
disclosure fix
Back in December, a change was made to suppress status when u.uhp == -1.
But if the hero died with exactly that amount, the status display would
be blanked out during end of game disclosure. Force u.uhp to be 0 when
dying. That was already happening if death occurred while hero still
had positive HP, but not when damage took him/her to negative.
PatR [Tue, 26 Mar 2019 23:58:52 +0000 (16:58 -0700)]
fix #H7454 - Cleaver vs long worm tails
Cleaver's ability to hit up to three adjacent targets could kill a
long worm and then try to cut it in two. When this was first reported
I was unable to reproduce it, but this time I've managed to do so.
But not reliably, so it's hard to claim that it's now fixed. However,
the new report's explanation of why it happens and suggested fix was a
big help. I had been trying to hit three tail segments, but you need
to attack a segment next to the head, then have Cleaver hit and kill
the head first (50:50 chance depending upon whether current swing is
clockwise or counter). Worm cutting would be looking at the location
of the targetted segment but there won't be any monster there when the
head dies. (Cleaver's attack itself already copes the situation where
its 2nd and/or 3rd potential targets aren't there any more by the time
it's ready to try to hit them.)
PatR [Tue, 26 Mar 2019 09:30:59 +0000 (02:30 -0700)]
curses message history
The curses interface maintains message history in a doubly linked list
with a capacity limit. Once capacity is reached, the list head is
advanced and the old head discarded, but it was leaving the new head's
'previous element' link pointing at that discarded element.
tmp_mesg = first_mesg->next_mesg;
(at this stage, tmp_mesg->prev_mesg points at first_mesg),
free(first_mesg);
first_mesg = tmp_mesg;
(with necessary 'first_mesg->prev_msg = NULL' missing). The situation
wasn't a significant problem because traversing the list was limited
by a counter. Going from tail back to head exhausted the counter
without ever accessing the stale pointer.
Since it wasn't noticeable, I haven't added a fixes entry for this.
I've also changed it to do fewer memory allocations and frees by
reusing the old list head instead of always allocating a new element
and freeing the one being replaced.
PatR [Tue, 26 Mar 2019 08:47:33 +0000 (01:47 -0700)]
curses horizontal status
The unresolved "first problem" mentioned earlier in commit 382286cb9930f95445d2b1b521dbcbc72a20f5c6 was caused by stale values
in status fields which had become disabled. Polymorphing left an
old BL_XP value and returning to original form left an old BL_HD one.
They weren't displayed but the stale value was included in the line
length calculation, resulting in 4 or 5 columns being set aside for
a phantom value. That implicitly reduced the available length of the
line and could result in extra spaces separating other fields being
squeezed out while unused spaces remained at the end of the line.
Experience points, time, and score didn't trigger this problem because
they were being explicitly excluded if disabled. So stale values for
them when they had been enabled then later disabled didn't matter.
PatR [Mon, 25 Mar 2019 23:54:51 +0000 (16:54 -0700)]
curses status display
I noticed a couple of things wrong--that I was fairly sure that I
had working correctly before--and after fixing the second one, the
first has mysteriously disappeared.
First problem, which may or may not still be a problem: extra spaces
were being removed from the second line of 2-line status even though
there were still 4 or 5 available spaces to the right of the status
conditions. It was behaving as if it thought the line was narrower
than actual size, or conversely, that the sum of the widths of the
fields plus the extra spaces was bigger than it actually was.
Second problem, fixed here. The code to put '+' in the far right
column of the last status line when there is at least one condition
all the way off the display wasn't working right when windowborders
were displayed. That's down to curses wrapping to the next line but
user can't see it due to the window border overwriting. Single char
overflow stayed on same line, but two or more wrapped and then the
'x' coordinate didn't match tests for 'too wide'. Perform explicit
truncation instead of leaving that up to curses. Also truncate
encumbrance when warranted since it's feasible for it to overflow.
Anyone using a display narrower than 80 columns might still run
into odd status behavior because other fields than conditions and
encumbrance could go past the end of line. But they shouldn't be
wasting screen real estate with windowborders, and without borders,
curses will keep the cursor in the bottom right corner when the
program tries to go past, which should keep things reasonably sane.
PatR [Mon, 25 Mar 2019 02:20:21 +0000 (19:20 -0700)]
curses ^P - support msg_window:full
curses uses 'reversed' (LIFO) style when displaying previous messages.
Use the existing (previously tty-only) 'msg_window' option to also
support 'full' (FIFO). The actual code needed as just a couple of
lines; tweaking options parsing and the documentation was more work.
PatR [Mon, 25 Mar 2019 00:50:26 +0000 (17:50 -0700)]
curses message recall, memory leaks
Using ^P right after resize or 'O' of align_message, align_status,
statuslines, or windowborders would result in
'curses_display_nhmenu: attempt to display empty menu'
because some memory cleanup I added several weeks back was being
executed when the curses interface tore down and recreated its
internal windows.
This fixes ^P handling by making sure that that menu (which is just
text but uses a menu to support '>'/'<'/'^'/'|' scrolling) will never
be empty and it also fixes the window deletion to not throw away
message history until it's final deletion at exit time.
^P uses a popup window to display previous messages and it was never
deleting that window, just creating a new one each time. Same with
the routine which displays an external help file. Using either or
combination of both close to 5000 times would probably make internal
window creation get stuck in an infinite loop. Delete those windows
after they're used so it'll never be put to the test.
The memory cleanup I added for map/status/messages/invent was only
being preformed at end of game, not when saving. Fix that too.
PatR [Sun, 24 Mar 2019 00:38:23 +0000 (17:38 -0700)]
revamped curses status display
I've overhauled the status display for curses. Horizontal layout
supports both 2 lines and 3 lines which can be changed dynamically
via using 'O' to set 'statuslines'. Fields are spread out a little
more than they used to be, making it more readable--at least to me--
but the extra spaces get squeezed out when lines become too long.
If 'showexp' is on and either conditions or hunger+encumbrance go
off the right edge, experience points are suppressed (but the option
is left on, so they'll come back once there is room).
For traditional 2-line hozizontal status, if hunger+encumbrance+
conditions go off the right edge even after experience points are
knocked out, there will be a '+' in the rightmost column if there
are any conditions that are all the way off. At present it doesn't
use the tty method of switching to abbreviated condition names to
reduce their legnth. I'll probably tackle that eventually if no one
beats me to it.
For 3-line horizonal status, there was an older implementation (but
disabled via #if 0) with gold and score moving to the third line.
(I'm not sure how status conditions were handled.) This one ignored
that and modified 2-line from scratch, moving alignment from line one
to line 2 and level description, time, and conditions from line 2 to
line 3. It looks like this (view with a fixed-width font...).
Score is actually right aligned with the edge but I've deleted several
spaces to keep the line shorter here. The status conditions line up
with the hunger slot as that shifts due to changes in gold/HP/power/AC/
experience, and conditions prefer that column even when hunger and/or
encumbrance are blank. Howver, if the number of conditions increase to
the point where they would go off the edge, the whole list shifts left
instead of trying to stay lined up with hunger. (It's just coincidence
that the lefthand parts of lines 2 and 3 seem to line up in this sample.
In general, they don't.)
The vertical layout has reordered most of the fields and now has a few
blank lines to separate those fields into some groups for readability.
Lines have the form of
Field-name : Value
and when highlights apply, now they only affect the value portion.
Single digit characteristics are padded with a leading space so that
all six of them line up (for "18/xx", "/xx" protrudes to the right).
HP and Pw are aligned with each other. Hunger and encumbrance share a
line. When there are more than three conditions, they're shown three
per line instead of wrapping across lines. And if too many lines are
present, it will squeeze out enough blank ones to fit.
To see the vertical status, you need a display size of at least 106
columns with 'windowborders' explicitly off, or 110 with them on; also
set option 'align_status' to 'right' or 'left'. (With borders on,
including the default 'auto' setting, the vertical status appears at
width of 108 columns, but does so by hiding 2 columns of the map; using
110 columns avoids that.) Resizing from outside the game or changing
align_status via 'O' both cause dynamic reconfiguration of the layout;
there's no need to save, make config changes, then restore.
PatR [Sat, 23 Mar 2019 17:50:26 +0000 (10:50 -0700)]
status updating: a*.c
I went through the places that set context.botl/botlx in src/a*.c to
see whether I could find any unnecessary status updates. I didn't
find anything interesting, mostly some minor sequencing issues plus
a couple of redundant sets (call foo() which includes setting botl,
then explicitly set botl after it returns). If you issue pline first
and then set context.botl, bottom lines won't be updated until the
next message or next pass through moveloop. If you order those the
other way around, status will be updated as the message describing
the reason for the update is being delivered.
PatR [Fri, 22 Mar 2019 23:13:21 +0000 (16:13 -0700)]
status updating
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.)
PatR [Fri, 22 Mar 2019 01:26:31 +0000 (18:26 -0700)]
highlighting status condition via 'O' bug
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.)
PatR [Thu, 21 Mar 2019 21:33:39 +0000 (14:33 -0700)]
curses options and status groundwork
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.
PatR [Mon, 18 Mar 2019 22:08:01 +0000 (15:08 -0700)]
curses update
Miscellaenous stuff either groundwork for or noticed while updating
curses status. The status changes themselves need some more testing.
One or two of the comments refer to that revised status which hasn't
been checked in yet.
PatR [Mon, 18 Mar 2019 21:38:30 +0000 (14:38 -0700)]
decode_mixed()'s return type
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.
PatR [Sat, 16 Mar 2019 00:51:39 +0000 (17:51 -0700)]
status lines' "End Game"
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.)
nhmall [Wed, 13 Mar 2019 23:55:43 +0000 (19:55 -0400)]
yet more mingw w64 build
Fix:
../sys/winnt/nhraykey.c: In function 'CheckInput':
../sys/winnt/nhraykey.c:459:37: warning: type of 'mode' defaults to 'int' [-Wimplicit-int]
int __declspec(dllexport) __stdcall CheckInput(hConIn, ir, count, numpad,
^~~~~~~~~~
PatR [Wed, 13 Mar 2019 23:50:56 +0000 (16:50 -0700)]
curses: hilite_pet, hilite_pile without color
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.)
PatR [Tue, 12 Mar 2019 21:11:26 +0000 (14:11 -0700)]
nethack.sh: test -e vs test -f
Change the test for whether fonts.dir exists (added to the script
in 3.6.0, for automatically setting up possible use of the NH10 font
under X11) from 'test -e file' to 'test -f file' since the latter
seems to be more universally available. When present, fonts.dir is
plain text, so a test for "exists and is a regular file" rather than
one for general existance is appropriate.
PatR [Tue, 12 Mar 2019 20:31:00 +0000 (13:31 -0700)]
avoid crash for X11 tombstone
If nethack is built to use graphical tombstone but file rip.xpm is
missing from the playground, there would be a crash if the rip output
was shown. My first attempt to fix it prevented the crash but didn't
display any tombstone, just the last couple of lines of output which
follow the tombstone. This keeps that in case of some other Xpm
failure, but checks for rip.xpm via stdio and reverts to genl_outrip
for text tombstone if it can't be opened.
PatR [Tue, 12 Mar 2019 01:11:21 +0000 (18:11 -0700)]
long #version feedback
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).
PatR [Sun, 10 Mar 2019 23:06:29 +0000 (16:06 -0700)]
win/curses comment
Twice I've gone through the curses code to deal with CHAR_P, BOOLEAN_P,
and so forth. Both times I eventually changed my mind. This time I'm
just adding an explanatory comment instead.
PatR [Sun, 10 Mar 2019 21:53:31 +0000 (14:53 -0700)]
curses vs extended commands
Extend the earlier support for Delete/Rubout in getline() to the
text entry for extended commands. In other words, treat <delete>
and <backspace> as synonyms in both places.
Some reformatting too, but only in a couple of the files.
PatR [Fri, 8 Mar 2019 19:48:31 +0000 (11:48 -0800)]
more UCHAR_P
When setting up an alternate definition for UCHAR_P to accommodate
DEC C's non-ANSI mode(s), leave the default definition to tradstdc.h.
DEC C's VAXC mode will end up expecting 'unsigned char' rather than
either 'int' or 'unsigned int'. Not applicable for Unix but this
makes similar change there as is being made for VMS.
PatR [Fri, 8 Mar 2019 01:12:01 +0000 (17:12 -0800)]
vms update
Suppress Isaac64 on VAX were there isn't an easy way to do 64-bit
arithmetic. (Hard way isn't worth it for just an alternate RNG.)
Eliminate or suppress some diagnostics:
1) In strict ANSI mode, DEC C was reporting that '$' in identifier is
an extension (one time for each file in sys/vms/*.c). (It doesn't do
that for the default 'relaxed ANSI' mode.)
2) DEC C uses WIDENED_PROTOTYPES but widens uchar (unsigned char)
differently depending upon the mode it is operating in. (Applies to
Unix as well as VMS; based on documentation rather than testing.)
Update the comment in tradstdc.h about WIDENED vs UNWIDENED_PROTOTYPES.
An old comment in config1.h about a problem with the earliest version
of DEC C was probably based on an incorrect assumption of what was
really going, but I have no way to go back in time to verify that....
PatR [Thu, 7 Mar 2019 00:59:39 +0000 (16:59 -0800)]
fix #H8330 - kicking obj stack uses wrong weight
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.
PatR [Wed, 6 Mar 2019 19:37:52 +0000 (11:37 -0800)]
revise integer.h for vms
The VMS compiler supports C99 and defines __STDC_VERSION__ to the
corresponding value, but it doesn't supply <stdint.h> so isaac64.c
wouldn't compile. It does supply another header containing what is
needed.
PatR [Mon, 4 Mar 2019 22:40:01 +0000 (14:40 -0800)]
fix #H8319 - hero-owned container used inside shop
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.
PatR [Sat, 2 Mar 2019 02:32:41 +0000 (18:32 -0800)]
fix #H8310 - riding a saddled tripe ration
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.
PatR [Sat, 2 Mar 2019 01:09:54 +0000 (17:09 -0800)]
Guidebook update
number_pad got removed from Guidebook.tex when mouse_support was added
by cc0e7a8750fd4e07d3a44592c38f5912d4e603de; put it back. Evidently
a cut-and-paste mishap when copy-and-paste was intended, probably
provoked by '\numbox{}'.
Remove \numbox{} from mouse_support; it isn't needed there since the
choices aren't trying to line up with '-1'.
Both Guidebook.mn and Guidebook.tex:
Remove number_pad's "for backward compatibility" from mouse_support
since the latter is brand new.
New petattr list of uppercase letters seemed intrusive when rendered
with a bold font, so switch to lowercase. (Option processing already
supports either case.)
Mention the '=' prefix for hilite_status 'absolute' threshold.
[As usual, the Guidebook.tex changes haven't been tested.]
PatR [Thu, 28 Feb 2019 23:12:12 +0000 (15:12 -0800)]
fix #H8297 - healer vs undead turning
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.
PatR [Tue, 26 Feb 2019 23:16:42 +0000 (15:16 -0800)]
curses run-time options
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.
PatR [Mon, 25 Feb 2019 23:48:29 +0000 (15:48 -0800)]
toggling persistent inventory window
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.
PatR [Mon, 25 Feb 2019 23:44:21 +0000 (15:44 -0800)]
more wearing armor vs perm_invent window
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".)
PatR [Mon, 25 Feb 2019 23:33:43 +0000 (15:33 -0800)]
fix #H8271 - wearing armor vs perm_invent window
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.
projects / nethack / log