Nethack crashes when you are riding a flying monster over a
pool/moat and some engulfing monster plucks you off your saddle.
After falling into the water you'll get the normal message
sequence (sink like rock ... phew, that was close; you also get
chance to teleport if you can). After the last message the game
will crash with a segmentation fault.
- reproducible; null pointer dereference in swallowed()
The crash results because dismount_steed() calls float_down(), which
calls drown(), which calls teleds(), which clears u.ustuck. So when
gulpmu calls swallowed after dismount_steed(), this line attempts to
derefernce a null pointer:
swallower = monsndx(u.ustuck->data);
This patch bypasses the float_down() in dismount steed() altogether.
That routine is meant to return the hero to the floor, and that
isn't appropriate if a purple worm just plucked you off the steed
anyway.
While this fixes the crash, a problem still exists. The
way swallowing works, the swallowing monster's location
switches to that of the hero. Since that location is
over water, the purple worm ends up drowning almost
immediately after you are swallowed, while you are
swallowed. The purple worm's death is not revealed
to you since the "The purple worm drowns." message is
conditional. This patch also adds a message when
the purple worm dies, but should this guaranteed
drowing take place?
save process, after the save file had already been written by
forcing execution of an interrupt handler at one of the
termination prompts. This resulted in "You were not healthy
enough to survive restoration" and worse.
This clears program_state.something_worth_saving immediately
after the save has been completed.
<email deleted>
Sent: Sunday, June 30, 2002 6:30 PM
Subject: Sparks from statue-axing
> First, the message given when your axe-handle vibrates is a little
> ambiguous; I'd be explicit and include the name of obj.
>
> More seriously, potions of oil catching light from the sparks are a) a
> great idea, but b) slightly broken. They catch light fine, but
> snuffing them produces a "del_light_source: not found"
> impossible(). (This probably means the same applies to being lit by
> fire_damage(), but that's rare enough this hasn't been caught before.)
>
> (Also, a)pplying a potion of oil to light one identifies its object
> type, so lighting one by this means probably ought to as well. And
> oughtn't it to be charged for if you don't own it, as light_cocktail()
> does?)
<email deleted>
Sent: Thursday, June 13, 2002 12:03 PM
Subject: Beta 1 comments
> The description of Y monsters will be updated in the Guidebook
> 'monsters' option list to match mon_explain[], I assume? (Yes, yes,
> documentation :-)
<email deleted>
Sent: Thursday, June 13, 2002 12:03 PM
Subject: Beta 1 comments
>A minor thing, but it'd be nice if the "trapped" now in lookat()
>had a defsyms[trap_to_defsym(tt)].explanation to tell you _how_
>the monster's trapped.
<email deleted>
Sent: Thursday, June 13, 2002 12:03 PM
Subject: Beta 1 comments
> Headstone writing still uses the adjective "weird" when engraving with
> a wand of digging.
<email deleted>
Subject: Beta 1 comments
> Is "You swing your axe through thin air" the right message to give
> when you try to use it to chop through a statue or boulder? Relatedly,
> this line in dig() looks as if it needs updating to the new dig_typ
> indices:
> 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.
The NOCWD_ASSUMPTIONS conditional code allows readonly
parts of NetHack to be separated from areas that require write-access.
This allows the recent panic log needed a prefix.
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.
Moves the remaining platform-specific options
to their own section of the Guidebook and documents
the "video:autodetect" option required for tiles on MSDOS.
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.
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.
nethack.allison