> - I'd like to see another option added: scroll_amount. In
> combination with scroll_margin, this would control the amount
> of squares the screen is scrolled when the scroll_margin is
> reached (currently, this amount is 1, but if I recall
> correctly, it used to be more). For example, if both were 5,
> when you came within 5 spaces of the left screen border, the
> screen would shift 5 spaces to the right).
>>> - When I set font and font size of the message window, the
>>> message window size doesn't calculate correctly to show the
>>> number of message lines specified. For example, I set the font
>>> size to 6, and the number of messages to display to 8. Now
>>> there is whitespace at the top of my message window. When I
>>> set the font size to 14 now, I see only 5.5 message lines.
>>> This is unintuitive: the interface should recalculate the
>>> window size needed to display the correct number of lines.
>>>
>> I agree, especially since the message window size is
>> recalculated correctly if you save and restore. An easy way out
>> would be to set those options to DISP_IN_GAME.
>
> That seems like a good work-around until the proper fix is done.
The patch is attached. I moved the code that was computing the font
size to mswin_message_window_size(). This will cause the message
window to resize properly if the message font size changes. There
are also 2 minor bits in mswproc.c to invalidate the message window
when the font changes.
When GOLDOBJ is defined, dropping partial amounts of gold using the D
command would not work because gold currently has the same inventory letter
as the coin group accelerator. In this case, the group accelerator should
not be used, since it confuses counts. tty and X11 ports are fixed. The
tty change should fix the Windows console version as well (untested).
three new features for the message window we discussed:
- Graying out lines that are old -- slightly cleaner than <Someone>'s version.
- Message concatenation.
- --More-- prompt if there are more messages this turn than fit in the
window.
As a by-product of these changes, some other things have changed, too:
- The message lines array is now used in a round-robin way, i.e. the
messages are no longer copied one line up when adding a new message.
- clear_nhwindow no longer redraws the window, which significantly
reduces screen flicker.
- A caret bug was fixed.
- The last line is no longer highlighted, as this seems unnecessary
since the most recent messages are in a different colour
- A bug was fixed that caused two lines too many to be drawn on each
paint.
Move get_saved_games() functionality to files.c
Use moved get_saved_games() functionality in Qt windowport.
[also some non-enabled perminv code in Qt windowport]
> It's probably best to empty
> mswin_update_inventory() in win\win32\. If I
> remember correctly there is some code in there now
> which probably behaves badly if perm_invent is
> switched on
> Below is the result of your feedback form. It was submitted by
> <email deleted> on Tuesday, June 4, 2002 at 21:04:54
> After alt-Q or F)ile, Q)uitting, it is still possible to F)ile, S)ave your
> game. By doing this after you are shown your inventory [fully identified] and
> attributes (It must be done before the last "Do you want to view your %1"
> dialog is answered--usually conduct), which means you can know what you are
> holding-- although it won't be officially identified. But you can use it to
> avoid putting on, say, an amulet of strangulation by mistake.
In item-selection menus, as you know one can press "=" to select all
rings, say. This doesn't work if the letters run out before you get to
the rings, however (because there are so many items).
Menu code did not check group accelerators on items without assigned letters
(if the letters run out). Fixed.
- fix destruction of primary game windows
- One, it makes the color of the cursor box dynamic (these are the gnmap.c
changes), based on hp/hpmax (continuous colors white -> yellow -> red ->
magenta rather than discrete like in Qt).
- Two, it adds a new window, NHW_WORN (all the other changes and new files
gnworn.[ch]), placed at the end of the first row, to the right of the status,
with tiles of all the items currently equiped. I had to change the spacing of
the first row (no longer homogeneous) to accomodate this, but I think it still
looks okay. It's mostly like the Qt version but the equiped items are in
slightly different places, and a bit more compactly (added quiver, ball/chain,
monster skin armor; see the definition in gnworn.c for the layout).
by <Someone>
(the following text accompanies the patch at <Someone>'s web page)
add more configurability to the new msg_window option of [..]3.4.0.
It allows the configuration option to take an optional parameter to
specify the style of message history display to use.
allows the following configuration options:
msg_window:s - single message (as was the default in 3.3.0)
msg_window:c - combination; two messages in 'single', then as 'full'
msg_window:f - full window; oldest message first
msg_window:r - full window reversed; newest message first
In the event of no parameter being provided,
the patch is compatible with the current 3.4.0 behaviour:
msg_window = 'full'
!msg_window = 'single'
msg_window can be configured for these options in the
Options menu (Shift-O)
msg_window stores the current window type in the non-persistent
iflags structure, which means that savefile/bones files should be
100% compatible with Vanilla, but at the disadvantage that your
customisations to msg_window will be replaced with your
defaults.nh (or ~/.nethackrc) value every time you restart a saved game.
Credits:
The patch draws inspiration (and code snippets) extensively
from <Someone>'s original msg_window patch, [...] as well as <Someone>'s code for reverse ordering implemented until recently in
Slash'em.
W340-6 fix
fixed: mswin_menu_size incremented width of the actual menu window
each time being called. This only happens if "show window content
while dragging" option is set in Windows desktop settings.
The pet image was garbled because it was reduced to the size of the pet mark
bitmap
in the function that draws pet mark transparently over the pet tile (32x32
image was reduced to 16x16 and then stretched again)
Also added: use Windows-provided TransparentBlt where available.
- typing ESC would lose messages if msg_window was not displayed
- incorporate <Someone>'s fix, which causes them to be tracked, just not
displayed, and thus still available for ^P viewing later on
Add "travel" boolean option to enable/disable travel command.
Add "mouse_support" wincap option to enable/disable mouse.
- When running the win32 tty version full-screen, some people
complained about the square mouse cursor.
Newsgroups: rec.games.roguelike.nethack
Subject: Re: Getting rid of the cursor?
<email deleted> <email deleted>
Followup-To:
On Thu, 04 Apr 2002 00:20:06 <email deleted> wrote:
> Ok, let me be more specific: when playing the windows non-GUI version, is
> there a way to get rid of the large rectangular white cursor?
>
> <email deleted> wrote in message
> <email deleted>
>> Can you get rid of the cursor in the windows version? I really hate that
>> thing.
>>
<email deleted>
>Newsgroups: rec.games.roguelike.nethack
>Subject: Disabling Mouse Input
>
>I purchased an older P120 laptop to be able to play Nethack at the hotel.
>I find that I rest my thumbs on the mouse touch pad all too often and my
>@ moves unexpectedly at times. I took a peruse through defaults.nh, but
>came up empty.
>
>Anyone know if mouse input can be disabled?
>
>MRSisson
Another fatal bug in win32 graphical interface
"Too many "dead" NHW_TEXT windows around. Repeating #? 15 times will produce
the same result."
>Wizard, wearing gray dragon scale mail and wielding Magicbane. The
>Dark One teleports next to me and I get the message "The Dark One
>casts a spell at you! A field of force surrounds you!". Then I get
>3 windows popping up: "Oops." "The dungeon collapses." "ERROR: No
>windows available..." and the game exits.
> I wish I could reproduce this reliably. Here's the method I've been using
> to do it:
>
> - Equip character (+4 gdsm, Magicbane, unicorn horn, see invisible,
> telepathy, key, "gain ability" potions to max out, enhance dagger skill
> to max, level change to 14)
> - Teleport down to the portal entrance. Go through the portal, get
> permission to go down to see the Dark One.
> - Go down to the Dark One's level, teleport over, open up his door, and
> basically just try to head back to the entrance and kill him.
>
> Two different things have happened while doing this so far. (I've been
> able to get errors something like 5 times out of many tries, and I haven't
> been about to do it at all in the TTY version - only the windows
> one.) Either I get the above message I mentioned to you, which seems to
> happen at a random time, or I get a slightly different result - "Oops,
> program initialization failed, ERROR: No windows available". This second
> result happened once _after_ I had killed the Dark One and was trying to
> #quit.
>
- the response field of the pop-up dialog was getting smaller by a few
pixels each time it was used. This was because the width calculation
was effectively stripping off the margins (4 pixels total) each time.
Don't do that.
- mostly from Yitzhak, with a modification based on subsequent discussion.
After installing everything (mail, cvs, etc) I found the compile was
broken.
Yitzhak: This fixes the compile. I used LONG for the types because using DWORD
conflicted in Borland with signed/unsigned compare mismatches.
[Also works around some perm_invent code destined for a later patch that got
rolled in prematurely]
Two things:
1. This patch causes the window placement of the main window to be
written to the registry, and to be restored upon the next start
of the program. I had to move the creation of the main window to init_nhwindows,
as the registry is not read until then.
2. Implement support for wc_popup_dialog (or rather, support for not having
popup windows.) It asks getlin questions and get_ext_cmd on the
message window, much like the TTY port does it.
The get_ext_cmd procedure is almost but not quite the same as the
one for TTY, and I think it is better: It autocompletes the extended
command you type, but if you keep on typing it doesn't add those letters
after the completed command, but just keeps track of how many (correct)
characters you typed. If you type a different character than the
autocompleted command has, it shows you what you typed again. If you
press backspace, it deletes the characters you typed, and if autocompletion
is no longer possible, it removes the autocompleted part. The effect
of this is that you can type as many letters as you want when typing
an extended command, as long as it is enough to identify one command;
and you only have to delete the characters you actually typed if you made
a mistake. I think autocompletion is a lot less obtrusive this way.
Some notes about the patch:
- Both mswin_getlin and mswin_get_ext_cmd now have two versions, with
and without a popup.
- yn_question was changed so that it displays a caret, which is a lot
nicer IMHO.
- I had to implement a new NetHack Windows Message parameter,
"MSNH_MSG_CARET", to make it possible to show and hide the caret in
the message window. Normally the caret is created and destroyed by the
window that owns it, but in NetHack the input focus is always on the
main window, while the caret is in the message window, which happens
to be the only one that knows how large the caret should be.
- mswin_putstr_ex's last parameter changed from boolean to int; the
semantics are enhanced so that a negative last parameter means "delete
that many characters from the input line". The string to be deleted is
passed in as well, although it is currently not used.
- A rather large chunk of code finds out where the last string that was
displayed on the message window ended. This is necessary to place the
caret at the right spot. The caret is always positioned there, even if
it is hidden or non-existing.
- mswin_get_nh_event was changed to actually process and empty the
message queue, and called from mswin_putstr_ex to make sure the
message window is updated before the next step is done. Without this,
the caret is positioned before the last message is painted, which
makes its x-position after the last character of the previous line.
