This solution is mostly a band-aid. Make sure information set by join_map
that is overlaid by the MAP is cleared out. This ensures that place_branch
will never consider invalid data. A new function, remove_rooms(), with a
helper, remove_room(), takes care of this, but only for rooms created by
join_map, which addresses the only known case that causes this problem.
There's a possibility that some other strange behavior, especially in
minetn-6, will be fixed by this as well. The problem of disconnected caves
on minetn-6 is not yet addressed.
Also, add a check to lev_comp.y to make sure the required fg semantics of
joined levels (fg must be ROOM or CORR) are actually met. Doesn't affect
any levels currently included in the distro, but might address levels
others are trying to make.
add another bit to the flags passed to launch_obj so it can print
the initial "rumbling" message at the appropriate time rather than
having the caller print the message, possibly out of order.
Write "died of starvation" on the tombstone, not just "starvation".
Suggested by <Someone> a couple weeks ago, although his suggested
prefix was different and didn't work as well for the "exhaustion" case.
> While looking at the tiles.bmp file, I've found some more mistakes like
> this : the Wizard of Yendor's shadow is touching Croesus' tile, and one
> of Orcus' wing is touching Yeenoghu's tile.
Reported to the list a while back by <Someone>. The Knight's quest
messages are inconsistent in the use of royal pronouns. Capitalize them all.
Another option would have been to remove all royal capitalization (since such
Capitalization didn't come into use until relatively recently).
<Someone> suggested a scroll to counteract an unknown scroll of charging
that had negative effects. Scroll of punishment already costs the same,
so that unknown behavior is already covered. Plus, a cursed scroll of
charging already has negative effects, except in the case where the player
was confused where no negative effect from reading a cursed scroll of
charging occured. Added such an effect (since the curse should still cause
something bad, even though the reader is confused), to drain the player's
energy.
Make the instructions a bit more blow-by-blow. Re-order them so they
correspond to the Install.unx step numbers. Explicitly refer to
Install.unx and Install.X11 where appropriate.
1) killer reason for scattered land mine shrapnel used "a" or "an" prefix
even when multiple projectiles hit as a group -- one of various things
From a bug report.oextra field) --
noticed while investigating #1 and later From a bug report.4.0 due to an unintentional side-effect of missile killer reason
handling in 3.4.1 (removal of redundant "poisoned" prefix by m_throw()
confused the poison handling routine) -- noticed while investigating #3.
Proposed by Michael Allison.
Seconded by Pat Rankin.
(it can always be withdrawn if there is a later objection)
-Author of Spanish NetHack
-Author of some NT keyboard internationalization fixes
-Author of "Hell patch"
On January 20, 2002 Ken Arromdee wrote:
>I dug this out of my files. (Well, it didn't take a lot of
>digging; I already copied the disk in question to my PC long ago.)
[...]
>I may or may not have another one of these but I'd actually
>have to go install a 5 1/4 inch drive to check.
When polymorphed, only attacks involving hands/feet/weapons should result
in damage to object. Theoretically, hug and butt attacks should affect
objects too, but no forms with such attacks currently allow wearing armor.
This is my final src mod to ensure that a qbuf does not overflow due to
a lengthy named object. These recent patches, coupled with the core yn_function() patch earlier, should make it much rarer for a QBUFSZ
buffer overflow to occur in a window port routine (unless the window
port routine has its own bugs, but that isn't the core's fault).
This is my final src mod to ensure that a qbuf does not overflow due to
a lengthy named object. These recent patches, coupled with the core yn_function() patch earlier, should make it much rarer for a QBUFSZ
buffer overflow to occur in a window port routine (unless the window
port routine has its own bugs, but that isn't the core's fault).
> The `prompt' buffer in tty_yn_function still only holds QBUFSZ
> characters. But fixing the tty incarnation wouldn't be good enough;
> all the other interfaces would need to handle it too. I think it
> should be fixed in the core instead. Prompt strings simply should
> not be allowed to become so lengthy.
Another step in the fight against prompt sting buffer overflows.
The goes after the ones that may not have been found yet.
This makes yn_function a real core function and removes
the #define yn_function macro.
The yn_function validates the prompt string buffer being
passed prior to calling (*windowprocs.win_yn_function)(),
and if necessary, truncating it and adding "...".
This won't help if the overflow occurs in the core in
a buffer that is still QBUFSZ in size, but it will help if
a BUFSZ buffer is being passed to one of the query
functions.
By naming the candelabrum as long a name as the game will allow, and by naming a candle the longest name also, a qbuf overflow and crash is
triggered when you attach the candle to the candelabrum.
By naming the candelabrum as long a name as the game will allow, and by naming a candle the longest name also, a qbuf overflow and crash is
triggered when you attach the candle to the candelabrum.
From the newsgroup: leash found inside a bones level shop was flagged
as "in use". 3.4.0 had a fix for that which works for most cases, but not
when the shopkeeper has taken the dead character's inventory just before
saving the bones file.
This also adds an entry to the branch copy of fixes34.2 to synchronize
it with the trunk copy.
<email deleted> wrote:
> The game crashed badly when I made some experiments with items
> with very long names:
>
> You have much trouble lifting a blessed greased thoroughly rusty >thoroughly corroded +3 plate mail named terribly long killer longer than my
>ong long-worm called long. Continue? [ynq] (q)
tty_yn_function(const char * 0x0012fa50,
const char * 0x00572ddc _ynqchars, char 113) line 379 + 6 bytes
lift_object(obj * 0x009e8970, obj * 0x00000000,
long * 0x0012fcd0, char 0) line 1131 + 20 bytes
pickup_object(obj * 0x009e8970, long 1, char 0) line 1258 + 19 bytes
pickup(int 0) line 474 + 28 bytes
dopickup() line 1853 + 11 bytes
rhack(char * 0x005c0d50 in_line) line 1908 + 3 bytes
moveloop() line 406 + 7 bytes
main(int 3, char * * 0x009e2ac0) line 102
Noticed when investigating one of the killer reason bugs recently
reported: a land mine explosion shouldn't create a concealed pit trap;
make a revealed pit instead. And while testing that, I noticed that the
"Kaboom" message given when pushing a boulder onto a land mine was given
while the map still showed the boulder at its original location even
though it had actually been moved already. It's a little odd that you
get hit by shrapnel at your original position--as if you're shoving the
boulder ahead of you and then pausing a moment before stepping into its
former location--but that's trickier to fix; sometimes you won't advance
due to there being multiple boulders present (in that case you evidently
do shove the boulder instead of performing a steady push, so maybe the
current behavior is fine as it is).
"List of game options" from `? f' misaligns the entries for runmode
and scroll_amount (at least for tty display). Shorten their descriptions
so that they fit without squeezing out spaces.
Make exploding bags of holding be less mysterious, and perhaps cut
done on the number of claims that they've vanished for no reason. There
wasn't any feedback other than the explosion message itself; in particular,
the message about putting something into the bag didn't occur since that's
handled by the didn't-explode case.
Recently discussed in the newsgroup, and it sounded familiar so may
have been reported directly earlier:
You fly through the trap door. You fly down along the stairs.
when polymorphed into a flying creature or riding a flying steed. It
only happens at the castle, and only happens because the go-down code is
explicitly setting the arrival point to be the Valley stairs. That's how
the castle trap doors used to work as traps too, but they were changed to
dump you randomly near the stairs quite some time ago. Fix it by making
intentional triggering work the same now; this also prevents the false
feedback (even if you happen to arrive on the stairs by coincidence).
In some X11R6 configurations, .Xresources is the name for the .Xdefaults
file. My older Linux system uses _both_, depending on which window
manager you run.
