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.
<Someone> reported that encumbrance feedback when removing GoP
was delayed until the next turn. Several other places call encumber_msg()
to provide immediate feedback. Call it in Gloves_off() too.
Change the monster constants to match the current position of the switch
statement. Also test canseemon(), since the message isn't needed if you
see the change. I didn't make any other change to the message frequency.
If it's too frequent, then perhaps the changes themselves are too frequent.
Three related bug fixed, two reported in U409.
+ If you zapped a wand of cold downward while hiding underwater, the uundetected
flag was not reset (but the monster case was code correctly), resulting in
an impossible error on the next attack
+ If you finished eating something you were hiding under and were attacked,
another impossible would occur
+ While checking the eating gold case, I noticed that several cases would lose
gold on the floor if the attempt to eat it failed
The first case is fixed by resetting the flag just like the monster case.
The other cases are fixed by adding code to useupf to deal with this.
eatspecial and floorfood were modified to allow useupf to be called, and
fix the 3rd bug in the process.
This patch gives game and savefile compatibility
whether GOLDOBJ is defined or not.
You can build with GOLDOBJ defined or not, and
still load your saved games. Rebuild with the
opposite, and load the same game.
That way GOLDOBJ can be experimented with
more easily.
1. Leave the "you" struct and the "monst"
struct the same under the hood between
GOLDOBJ and !GOLDOBJ.
2. Always write out gold as an
object on the player and monster
inventory chains.
On a restore of the savefile with GOLDOBJ
not defined, take the gold objects out of
the inventory chains and put it into u.ugold
or mtmp->mgold as appropriate.
On a restore of the savefile with GOLDOBJ
defined, nothing special is done.
<Someone> noticed that is_damageable used the address of is_rottable
instead of calling it. Unfortunately, there doesn't seem to be a good
compiler warning to detect uses of function addresses as booleans.
Another fix to address the complaints about two-handed weapons being
rendered useless by 3.4.1's change to require free hands in order to apply
containers. Some players now fear to wield two-handed weapons because a
curse would make accessing their bag impossible, which is doubly nasty if
that's where they have scrolls of remove curse or potions of holy water
intended to deal with cursed items. The same situation applies for cursed
one-handed weapon combined with cursed shield, so some are now claiming
that 3.4.1 has made two-weapon combat be even more attractive than before.
This implements #tip, a new command that causes a container at the
current location or carried in inventory to have its contents emptied
onto the floor. Hero's hands don't need to be free at the time but tipping
a floor container requires limbs; tipping an inventory container doesn't
need hands or even limbs. The contained items don't pass through inventory
during the process, so don't cause objects (loadstones, crysknives, scrolls
of scare monster?) to go through their special handling unless it's part of
normally dropping to the floor. Tipping a bag of tricks behaves the same
as applying it (one monster is released, and it only becomes empty if
that happened to be the last charge) and items tipped out of a cursed bag
of holding have their normal cursed bag chance (1/13) of being destroyed.
Tipping an inventory container while levitating or during unskilled riding
behaves similar to normal drop--from a height, so some fragile items break.
Players have wanted this feature to get gray stones out of chests or
heavy corpses out of ice boxes but I didn't care much about that; losing
access to your bag is more significant. I'm pretty sure that there was a
user patch to do something like this floating around at one time, but I
couldn't find it when I looked, so I implemented #tip totally from scratch.
Bug? Extended commands which lack meta-key shortcuts are not listed
in the help files displayed by the '?' command....
