From: "Ken Arromdee" :
> My point is that you should be allowed to take vengeance on thieving
> nymphs too. The reasoning "a real knight wouldn't kill a nymph for stealing"
> doesn't make sense because the things a real knight would do instead (like
> arresting) aren't part of the game.
This is a compromise. This doesn't allow vengeance when you were
told "you gladly hand over ...", but does for most other cases, and for
leprechauns.
<email deleted>
> Since Priests' knowledge of the buc-status of an object only
> kicks in when the name is being looked at for the first time,
> they get an "X" option when taking items out of a newly-looted
> container, but B, U, and C thereafter; could their ability be
> pre-applied to the container's contents when constructing the
> menu, to avoid this anomaly?
>
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.
>
This includes a reversal of my earlier
boulder/statue/landmine fix,
and places a check for obj->where==OBJ_FLOOR into
fracture_rock(). I think this is a better approach
because:
- if eliminates the pointless extract/place in
fracture_rock, followed by extract/place in
the caller in the two places causing the crash
- it covers any similar situations that we
might have missed or that someone might add
accidentally (you might not expect the location
of an object to change inside fracture_rock())
- it allows fracturing to take place on the
other object chains if we ever need it (statues
falling down stairs, perhaps?)
- it doesn't move objects from other chains onto
the floor briefly as the current code does
- 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.
This adds a generic feature_toggle mechanism to
the game. Code that wants to offer two different
ways of doing something can add an entry to
feature_toggles[] (in decl.c), and create a
preprocessor macro for its array index in decl.h.
Then the code can test it using
if (feature_toggle(FEATURE_NAME))
..do_this..
else
..do_that..
The player can toggle the alternate code path
on using OPTIONS=feature_toggle:feature_name_1 feature_name_2 ...
This seems better than creating brand new options
for controlling features (ala prayconfirm, which
could switch to this single option feature_toggle
mechanism as well)
My first use of it is to allow toggling of the selectors
on the loot menu, which I'm hesitant to just change back
because now people are actively using the new selectors and
the complaints would be really loud if the interface were
to just switch back after they adjusted.
The default behaviour is the new behaviour "iob", but with an
OPTIONS=feature_toggle:loot_menu_selectors
in your config file, it will revert to using "abc" as it did
in 3.3.1. I'll add a Guidebook page of "features/behaviour
that can be toggled" later.
The toggles can only be done in defaults.nh, and are
not saved with the game.
Date: Sun, 24 Mar 2002 15:40:30 -0800
<email deleted>
Subject: patch: nethack-graphical - menu window colors
- W340-4 (menu checkboxes have a hard-coded white inner part)
- use windowcolors settings for menu backgroud/foreground color
<Someone>
(from <Someone>)
>The tile size is actually set just once in mhmap.c so validation can be done
>in one place. The patch is attached.
>
><email deleted>
on Sunday, March 24, 2002 at 16:15:50
---------------------------------------------------------------------------
mailversion: 1.10
nhversion: 3.4.0
nhfrom: 3.4.0 Official binary release for Windows 95/98/NT/2000/Me/XP
(nh340win.zip)
hardware: 1 Ghz AMD Athlon, 512 MB RAM etc. etc.
I don't think that the hardware is related to the problem because I found it.
software: I used Win 98 (1st edition) and MS VC++ 6.0 to find/fix the bug in
Nethack 3.4.0.
comments: steps to crash: start nethackw.exe - start a game - select "fit to
sreen" in the map menue - rezize the map until it is very very small -> crash
#649
<email deleted> on Friday, March 22, 2002 at 13:27:03
software: os: w2k workstation
nh: stock tty nethack.exe
comments: When you move onto a space and your pet moves onto the space
next to you on your left, your @ is displayed w/ normal attributes
instead of bright.
hilite_pet option is enabled
IBMGraphics option is disabled
#656
<email deleted> on Friday, March 22, 2002 at 16:59:37
nhfrom: 3.4.0 Official binary release for Windows 95/98/NT/2000/Me/XP
software: Windows 98 SE playing the ASCII version
comments: Sometimes when I'm standing next to my pet the @ turns grey, it goes
back to white after I move.
This was a tricky one. While the error was ultimately because
he was specifying a non-existant directory in defaults.nh, the
error message lead me to the wrong area until I traced through
with a debugger.
It turns out that an fqn buffer was being re-used before it
was finished being used with the original information in
sys/share/pcunix.c, so the error message listed the
wrong file!
This adds one more buffer and fixes the problem.
Note that it could only affect plaforms with
PREFIXES_IN_USE defined (NOCWD_ASSUMPTIONS
or VAR_PLAYGROUND)
It also alters the WIN32 error message to give them a
hint as to what the problem might be.
<email deleted>
<email deleted>
Sent: Saturday, March 23, 2002 9:27 AM
Subject: #R668: Windows 2000 Lock File Creation Error
> nhfrom: 3.4.0 Official binary release for Windows 95/98/NT/2000/Me/XP
> I get an error after unzipping nethack to c:\nethack, and changing the
> configuration (defaults.nh) to reflect this in the hackdir, levels and save
> configuration items.
>
> The error I get is "cannot creat lock file (C:\nethack\NHPERM_lock.)" after
> entering nethack at the command line and answering the Who are you? question.
You could still get a panic. To reproduce:
- wizwish for a statue, and drop it
- wizwish for a landmine, and apply it at same location as statue
- move one square and wish for a boulder, drop it (automatically likely)
- push the boulder on the landmine to trigger it.
- the panic came from the statue this time.
<email deleted>
<email deleted>
Sent: Saturday, March 23, 2002 6:01 AM
Subject: Bug in 3.4.0: spellbook fading
> Dip a spellbook in a fountain:
> "The spellbook fadefades."
>
> In get_wet (potion.c), otense is used, which returns "fades",
> redundantly, as a suffix to "fade".
> <email deleted>
> Oops! [...]
> Suddenly, the dungeon collapses.
> place_object: obj not free
>
> The crash is reproducible in wizmode by wishing for a landmine, arming it and
> pushing a wished-for boulder onto it.
This patch implements two things:
- space now dismisses a menu, text or menutext window when you are
at the bottom of that window
- Page scrolling in menus now works as follows:
pressing PgDn (or Space in NH mode) moves the focus down one page,
and moves the scroll position down one page. The effect of this
is that you always get a full new page of items (which is what
NetHack players expect), and that the focus moved down one page
(what Windows users expect.)
The same (revers) goes for scrolling up a page.
A Windows user will still be a bit surprised when the focus is on
the top item, and he presses '>': he gets a new page of things instead
of the focus moving to the bottom of the page.
However, the PgUp/PgDn keys (which he probably uses) still have the
old Windows behaviour.
This band adds handling for the "5" key in the numeric keypad. This is
called VK_CLEAR in the VK_ constants. Using this band, and with
NumLock off, doing 5 will send NetHack the letter 'g'. Doing SHIFT-5 will
send 'G'. Without this band and with NumLock off, 5 does nothing. With
NumLock on, 5 sends 5.
This implements some items on the ToDo list:
- H0005: Space does the same as PgDn in text, menu and 'menutext'
windows if NetHack mode is on.
- M0004: The cursor (caret) is hidden in text windows and menu
windows.
PgUp/PgDn/Up/Dn don't move the cursor, but scroll the
window.
From <Someone>:
>And finally a bug-report:
>The new disclose-option didn't fully work.
>While the -ny prefixes works like explained the + prefix
>(show it don't ask) acts like -.
>A possible fix is, change the return-value of
>should_query_disclose_option for case DISCLOSE_YES_WITHOUT_PROMPT
>to TRUE and handle the case defquery=='q' in list_*-function
>as "don't ask". Or add a new boolean ask parameter to the
>list_*-functions.
> while testing the new wc_-Features for Gem I noticed
> in nh340b11 options.c parse_options there is a bug.
> If a optionname starts with "font" a opts+=4; is
> performed on it, but if via string_for_opt an
> error occurs badoption is reporting i.E.
> Bad Syntax: _menu use "?g" ...
> instead of font_menu.
>
> Possible fixes include shift the pointer back (bad)
> or use another pointer.
>
> <Someone>
This patch allows ALT-? to do #? in NetHack mode by not doing
TranslateAccelerator in NetHack mode. This relies on the short circuit
logic of || (much of NetHack code relies on it, it's just an explanatory note).
This patch disables ALT-H in NetHack mode. Before patch: ALT-H in NetHack
mode brings down the Help menu in the menu bar. After patch: ALT-H does
nothing in NetHack mode. In both cases, in Windows mode, ALT-H brings
down the Help menu in the menu bar. I can easily write a patch to have
ALT-H in NetHack mode act the same as '?'.
Explanation:
return 0: this window proc has processed this event.
return DefWindowProc(): process using default window proc.
ALT-H is the only key for which DefWindowProc() does something special AND
reaches the else.
To address <Someone>'s complaint, make the cluttered
trap detection tty only. Also put in some dead
code that could make it work elsewhere in future
when there is time to test.
- keep boolean and valued option sections together
- be more consistent in use of terms "graphical port"
and "graphical interface" in the document (use the
latter where noticed)
- don't mention options available in other ports so
much since this document is not a general
document.
- move the numeric keypad stuff to the end. It seems
to assume number_pad on. So I stated that it does.
(Many players never play with number_pad on, and
I'm one of them. I'm not sure of the merit in having
the section in here at all, since it exists in the
Guidebook doesn't it?) How accurate is the text
that is there if you aren't in number_pad mode?
This is so it can be shared with Qt.
If, for some reason, we have to cut another source tarball for
3.4.0, then this will be included. Otherwise, this will
turn out to be a post-3.4.0 patch.
Unfortunately a couple of glitches were encountered during the build of
the DOS binary.
Also, somewhere along the way the ability to separate the debug info
for the win32 tty binary into its own PDB file was removed from
Makefile.msc. I wasn't aware of that until I went to build the binary,
and discovered that I had no PDB file to stow away for bug
reports.
- splash_screen (boolean for whether to display splash screen at startup)
- player_selection:dialog|prompts
Also moves the font and window manipulation stuff in defaults.nh
further down the file, so that a tty users doesn't have to wade
through it all to find the character adjustment samples.
- changed splash screen fonts to measure in logical pixels rather that
points.
Points are 1/72 inch regardless of screen resolution. If screen resolution
changes so does visible image size. If font is measured in points then its
visible size remains the same. The text is getting cut off (or becomes to
small for the image) as a result.
- a couple of README updates
- some color changes for windowcolors
- prevent crash From a bug report, but better than a crash. It
probably renders the map_mode:fit_to_screen ignored in defaults.nh.
part 2 touches only port files
Makes Borland happy with current sources.
Fixes bug in WM_PAINT handling in rip/splash code.
Fixes getline() bug (H0009)
Tidies up source.
Fixes up copyright notices.
Adds TODO docs for Borland. (Removes "TODO" note)
Small changes to defaults formatting.
Fixes ALT key on Graphical Port non NetHack mode.
Hilites pet in Graphical Port text mode.
Also Implements windowcolors for status and message window in graphical port.
On graphical port,
tested to see it actually works.
Tested on platforms Makefile MSC/BCC Graphical/Console, MSC IDE for
compile and run and performing hilite pet in graphical text, not
displaying rawio, alt key.
part 1 touches core files
ntconf.h changes differ slightly from Yitzhak's original.
Makes Borland happy with current sources.
Hides "rawio" on Graphical Port which doesn't do anything with rawio
nethack.allison