When --More-- was written to leftmost column of line 2 while the
hero was swallowed, after player acknowledged it and the top line
was cleared, the cursor ended up in the wrong place. I still
don't understand what in the world is going on here, but adding
'flush_screen(0)' after 'swallowed(1)' in docorner() makes the
problem go away. Why is the behavior different when --More-- is
in the first column than when it's anywhere else?
After that fix, I commented the whole thing out. The swallowed
optimization is just not significant enough to justify peeking at
core internals.
Core bit: prior to those two changes, I tried inserting 'bot()'
into swallowed(). It moved the mis-positioned cursor from the
end of the second status line to on the map just right of the
bottom right corner of the swallowed display. That didn't fix
anything, but I've left it in place. bot() to update status is
needed following cls(); now it happens before redrawing the map
instead of at some point after.
Quiting without ever examining inventory caused the Qt interface
to issue an impossible(), then crash due to deferencing a Null
pointer. The prior fix was to suppress the validation code that
was crashing. This changes things so that the inventory window
always gets at least one use, allowing the Qt validation code to
succeed. tty and X11 are ok with it; win32 needs to be verified.
Put in Ron Vaniwaarden's fix for crash occuring if player quits
right after choosing a character and declines to disclose anything.
Just a guess, but deleting the never-viewed inventory window might
be the cause. (3.4.3 didn't delete it.)
There's a small amount of reformatting, but cleaning that up
manually is a monumental task.
Start coloring after the space which follows the selection indicator
instead of on that space. The difference isn't noticeable when the
highlighting is just a color, but it is if that highlighting includes
inverse video or underline which visibly apply to spaces. So for
a - entry A
the old code produced
a -########
and this revised code produces
a - #######
where '#" indicates characters subject to menu coloring.
This reverts commit 2ff96797a8.
Since this pull request was made to the DevTeam, a commit has appeared
in the official repo's NetHack-3.6.0 branch which effectively does the
same thing: NetHack commit 98b5f58 (tty menu coloring) by PatR.
There was a report during beta testing that menu lines which were
displayed in color showed the whole line in color, unless/until an
item was selected or unselected, in which case the '-', '+', or '#'
was rendered in monochrome. The suggestion then was to redraw the
selection character in color, but I went the other way. Menu
entries will render the selector letter and selection indicator in
monochrome all the time, and only the text of the menu entry will
honor menucolors.
Umpteenth revision of the X11 extended command menu. Add a new
resource to NetHack.ad to control its initial size.
I still hope there's a better way to do this, but this is my last
shot at it.
Report states that using OSX Xcode IDE results in use of 'clang
Modules', whatever those are, and role.c's 'filter' struct ends up
conflicting with a function declared by <curses.h> (or possibly
<ncurses.h> since one includes the other). src/role.c does not
include <curses.h>, so this smacks of the problems caused by using
precompiled headers on pre-OSX Mac.
Instead of trying to import nethack into Xcode, I temporarily
inserted '#include <curses.h>' at the end of unixconf.h. gcc did
complain about 'filter' in role.c (but not in invent.c, despite
-Wshadow), and then complained about termcap.c using TRUE when it
wasn't defined (after in had been #undef'd, where there's a comment
stating that it won't be used in the rest of that file), and also
complained about static function winch() in wintty.c conflicting
with external winch() in curses.
This renames 'filter' and 'winch()' to things that won't conflict.
Also, our winch() is a signal handler but had the wrong signature
for one. And the troublesome use of TRUE was in code that was
supposed to be dealing with int rather than boolean.
When the extended command menu auto-scrolls as the player types in
characters, scroll so that all matching entries come into view rather
than just the first one. For example, it someone types 'w', instead
of just highlighting and showing "wipe", it will highlight "wipe"
(because that has become the default response when <return> is used)
but also show "wiz-this", "wiz-that", and "wmode". It actually shows
one extra entry beyond the last matching one--so you can see that
there aren't any more ambiguous choices--except for 'w' where "wmode"
is the very last extended command.
Previously, on subsequent popups of the extended command menu, the
scrollbar's slider was left drawn in the position it was in during
the previous time even though menu content wasn't scrolled. Now it's
forced back to the top (non-scrolled) position when that menu is
popped up.
When the extended command menu is big enough to need a scrollbar,
leave more elbow room when forcing its height to fit on screen.
The last entry was frequently obscured by OSX's "docking tray"
desktop decoration and the resize hotspot (bottom right corner of
the menu popup) could be hard to access.
I'm not particularly happy with this code. There really has to be
a better way to accomplish what's needed.
Color was only being tracked for locations that had the pile of
objects flag set. And hilite_pile made a monster on a pile take
on the color of the top object of the pile.
This restores the tracking of color for the whole map, and makes
highlighted piles be drawn in inverse like highligted pets. The
drawing routine doesn't know the difference (but could tell, if
necessary, by testing whether the glyph is an object or a monster).
Also, variables 'inbuf', 'inptr', and 'incount' were global; limit
their scope to winmap.c.
The three line change I made previously to implement highlighting for
prompts that ask for single-character input was easy and worked well
for a tiles map, but it didn't look very good for a text map. This
handles both text map and tile map and also adds a configurable
'highlight_prompt' X resource to let the user enable or disable the
feature. The resource template file (win/X11/NetHack.ad, copied to
$HACKDIR during install) now has it enabled by default.
The highlighting--more specifically, the "lowlighting" when no prompt
is active--still looks bad if the map window has a vertical scrollbar
on left edge. I don't have any inspiration about how to fix that up.
If the user hasn't explicitly loaded application defaults (which I
haven't been doing), the X11 interface behaves differently if invoked
via the shell script than if the executable is run directly, because
the script sets up a path so that X can find $HACKDIR/NetHack.ad.
This hides the difference by reading in that file during initialization
and feeding its contents to XtAppInitialize as fallback resources.
The scroll bar on the message window doesn't work for me, just like
the one on the extend commands menu. Moving the pointer to it does
change the cursor, but neither trying to drag the slider nor clicking
above it will make it do anything. However, at some point I managed
to accidentally scroll the message window, and new messages never
restored it to the unscrolled state. New messages were hidden until
enough even newer ones had been delivered to push the hidden ones
into view. So this adds key translations to scroll the message
window via the arrow keys. Clicking on the scroll bar doesn't change
focus to the right place, so I have to click the text display area of
the message window. That triggers a beep (I suspect it's interpreted
as an attempt to move the hero beyond the map.) But then the messages
can be scrolled via the cursor keys. Getting focus back to the map
seems tricky since doing it via pointer is interpreted as a travel
command. Not quite optimal....
Anyway, being able to scroll the message window let me figure out how
to unscroll it when new messages are delivered.
For the 'slow' config (prompting for single-char input done on a
fixed line at the top of the map rather than via a popup window),
invert the background and foreground when creating it so that it
looks like part of the map, then invert again when a prompt is
active in order to highlight that prompt.
Free askname's widgets after use and free getlin's and yn_function's
persistent widgets at end of game.
When loading an entire text file into one long string in memory,
use strcpy on a pointer to the end of the string instead of having
strcat repeatedly churn through the entire string as it grows for
each line. [Since that's only used for small help files (biggest
is dat/history), this optimization is probably not noticeable.]
Also, a handful of new comments and quite a bit of reformatting.
I upgraded from OSX 10.5.8 via 10.6.3 to 10.6.8, plus Xcode to whatever
version was on the 10.6 dvd, and ended up with a more recent version of
gcc that is configured to use 64 bit longs and 64 bit pointers (by
default; presumably that can be changed if necessary). It triggered
several warnings about converting int to pointer of different size or
vice versa even when explicit casts were in use, and a couple of other
things.
Changes to be committed:
modified: win/share/other.txt
modified: win/share/tilemap.c
modified: win/share/tiletext.c
On 2/2/2016 7:27 AM, paxed wrote:
> https://www.reddit.com/r/nethack/comments/43n8i2/can_anyone_tell_me_what_these_zigzag_tiles_are/
>
> Looks like the tiles in question have been labeled as "wall" since
> 3.4.3 at least
>
Put better labels on the 'other' tileset and accept those
labels in the tile processing utilities.
The big memory allocation for tiles that was unfreed according to
heaputil was actually freed by X according to a comment in the code.
But free it explicitly for #if MONITOR_HEAP so that the alloc/free
tracking stays accurate.
Also, the cached extended commands menu was not being freed, so take
care of that. I wasn't sure where to handle it; I ended up making it
happen when the map window is torn down.
X11 had been ignoring add_menu(..., MENU_SELECTED) to specify a
pre-selected menu entry. This adds support for that.
Attempt to implement pre-selected entry for PICK_ONE menu sanely by
returning the pre-selected entry instead of toggling it off if the
user chooses it explicitly. Inner workings of menus are convoluted
so I'm not sure it's 100% correct, although testing hasn't found any
problems. (tty currently returns 0 for "nothing picked" when
explicitly picking a pre-selected entry in a PICK_ONE menu, and the
core jumps through hoops to handle it. That can't be cleaned up until
all interfaces which support pre-selected entries achieve sanity.)
Make "random" be chosen for <return> or <enter> during role selection
and highlight it to reflect that. (Role selection for X11 uses its
own code instead of nethack menus, so pre-selection isn't applicable.)
Without this, the keyboard commands don't work in the extended
command window on Linux. If the translations are removed from
menuformview, then the keyboard commands don't work on Mac.
Having the translations in both doesn't seem to hurt.
Instead of just using 'random' as the default choice if the user hits
<return> when picking role, race, gender, or alignment, flag it as
pre-selected in the menu so that it can be seen to be the default.
Someday somebody is going to have to fix up the interaction between
PICK_ONE menu and pre-selected choice....
Make the six buttons (ok, cancel, all, none, invert, search) on
menus for X11 all have the same width.
'ok' should probably be changed to 'okay' to be consistent with
X11_getlin(). (Another inconsistency: the extended commands
menu uses 'dismiss' rather than 'cancel'.)
Two cosmetic changes for the X11 version of the getlin() routine:
1) Make the text entry box big enough to hold 60 characters before
sliding the beginning input off the left edge, instead of just 13,
so that user can see much more of what is being typed;
2) Make the cancel button be a little wider, and the okay button be
the same width as the cancel button so they look a little nicer.
When entering an extended command, allow the user just type
and match a new command immediately, if no match was found,
instead of needing to wait the 2.5 seconds.
Update X11's status display to include the expanded set of status
conditions. This time the order is
Petrifying <hunger> Blind
Slimed <encumbrance> Deaf
Strangled Levitating Stunned
Food Pois Flying Confused
Term Ill Riding Hallucinating
with the application defaults file specifying red text for the first
column and black for the other two. Previously it was all one column
with seven entries. [Slimed was missing along with the six new ones
(deaf, stone, strngl, lev, fly, ride) and both types of sickness were
shown as 'FoodPois' or 'Ill' or 'FoodPois Ill' on one line.]
So now basic bot2, #if STATUS_VIA_WINDOWPORT genl_status_update, and
#if !STATUS_VIA_WINDOWPORT X11 fancy status have three different
orderings. genl_status_update has hunger and encumbrance first
because all the other status conditions are grouped together as one
bitmask item. bot2 has 'lev', 'fly', 'ride' last so that they're
the first things to be sacrificed if the string of status conditions
ends up being truncated. (genl_status_update also has those last.)
In addition to updating status conditions, I reordered the Hp, Pw, &c
section too so that it's closer to tty in organization.
Hit points Maximum HP
Power Maximum Power
Armor Class Alignment
Exp.Level Exp.Points (if 'showexp')
Gold Moves (if 'time')
Score (if 'showscore')
I didn't have SCORE_OR_BOTL set so haven't seen the last one, but
it's in the same position as it was before.
Adding deafness to the status line spurred me on to something I've
wanted to do for a long time. This adds 'Stone' and 'Strngl' as
new status conditions, and moves the five fatal ones: "Stone Slime
Strngl FoodPois TermIll" to the front of the status list since
information about them is more important than any of the others.
"Ill" has been renamed "TermIll"; "Df" has been renamed "Deaf";
"Lev", "Fly", and "Ride" are three additional new conditions, with
Lev and Fly being mutually exclusive. After the fatal ones, the
order of the rest is now
<hunger> <encumbrance> Blind Deaf Stun Conf Hallu Lev Fly Ride
To handle the longer potential status line, the basic bot2() is now
smarter. If the line is wider than the map, 'T:moves' is moved from
the middle to the end. If the line without time is still wider than
the map, then experience (HD if polyd, Xp:M/nnnnnn is showexp is on,
or Exp:M) is moved in front of time at the end. If the line without
experience and time is still wider than the map, dungeon level plus
gold is moved from the beginning to be in front of experience. The
fields are just reordered, not truncated, so if the interface code
can display lines wider than the map they'll retain the extra info.
The gist is than health and associated fields (Hp, Pw, Ac) get first
priority, status conditions get second priority, then the rest. In
the usual case where there aren't many conditions, status display is
the same as it has been in the past.
STATUS_VIA_WINDOWPORT has been updated too, and it builds for tty
and X11. But the bot2() revision to reorder sections has not been
implemented for that.
win/win32/mswproc.c has been updated but not tested.
STATUS_VIA_WINDOWPORT without STATUS_HILITES had several compile
problems; now fixed for core and tty. STATUS_VIA_WINDOWPORT with
STATUS_HILITES has not been tested.
Restore the ability to select extended commands by keystroke.
The key translation stuff had gotten attached to the wrong widget.
When using keys to highlight an entry in the extended command menu,
don't reset the key-by-key handling so quickly. (On second and
subsequent keystrokes, if you waited more than 0.5 second, the new
key started picking an extended command from scratch rather than
continuing the current one, making it pretty hard to disambiguate
commands which have the same initial letter. Now the delay
threshold is 2.5 seconds. In theory that should become a user-
preference resource but I don't think it's worth the effort.)
Display the help choice in response to '?'.
Clean up the formatting of the top two buttons (dismiss + help).
Start with a scroll bar if the menu is too big to fit on the screen.
Prior to this, on OSX, the full menu would be constructed but any
of it that was 'displayed' beneath the bottom of the screen was
inaccessible because it couldn't be dragged higher and couldn't be
resized to get a scroll bar (since the way to resize on OSX is by
dragging the bottom right corner--which was off the screen).
The problems I mentioned recently are still present: when scroll
bar is present, I can click beneath it and it moves down, but
neither dragging it up nor clicking above it will move it back up.
Fortunately the recently implemented up and down arrows both work,
even after clicking/dragging starts failing.
There was a lot of trial and error involved here. Most of it
eventually got phased out, but the mystery of 'defaultDistance'
(which is reported to be 0 but is actually 4) remains. The screen
height stuff at the end ought to be fixed up if someone can figure
out how to get the width of a horizontal scroll bar or the height
of a title bar. (I'm sure I used to know how to do the latter,
but that was 25 or so years ago, and in Fortran with Xlib rather
than Xt or Xaw....)
Several people have asked if 3.6.0 supports playing with tiles on
a public server. Because there's no way for the user's end to know
what that white @ is, this adds special console escape codes for
tile hinting.
The idea was originally a patch called TelnetTiles by Justin Hiltscher,
but this expanded version comes via NAO, where it's been in use for years.
This is basically an interim hack, which should go away when/if
we support actual client-server model.
This was a request from a blind player. It's hard to find
the left edge of the menu when it's drawn on the map, so
clear the screen and align menus to the left edge of the screen
when this option is turned off.
Originally this was called the window edge patch.
