When attempting to disarm a trapped chest, wisdom should only be exercised
when not confused. It stands to reason that even if you manage to find a
trap in a confused/hallucinating state, wisdom shouldn't be exercised.
Since monster cancellation sticks, it doesn't makes sense for Magicbane to
cancel a monster more than once. Tweaked the messages to deal with this fact.
I decided to not make Magicbane's random effect "intelligent", which is what
changing it to use some other attack against a canceled monster would be.
Incorporate a mod submitted by <Someone> to implement the TODO in the
class genocide code by walking thru the species to find a class to genocide
if the user input does not match the class description.
Several cases in the trap block of code in dosit() were caused by utraptype
being set to values not corresponding to an actual trap. <Someone>
reported back in 12/02 that the "sitting in lava" killer message could not
occur, but the special-case sit messages for TT_INFLOOR and TT_BURIEDBALL
couldn't occur either.
<Someone> pointed out a disagreement between the comment and code in
throwing_weapon(): comment says daggers & knife can be thrown, but
code also allowed short swords. Assuming the comment was correct, changed
the code to match.
<Someone> (also later forwarded by <Someone>) reported that choking
while eating non-food always resulted in calling it a "quick snack".
lesshungry() depends on an occupation to tell if you are actually eatig or
not, but since non-food is eaten in one turn, no occupation was set. Took
his suggestion of setting the occupation temporarily to cause lesshungry()
call choke() appropriately in this case.
The bug report referred to greased hands, but that doesn't affect the
behavior. If you drop an object while swallowed or engulfed in a shop, and
that object had previously been picked up from the shop floor, the object
was treated as costly. In some cases, this could result in impossible
errors later on. Perhaps object ox & oy should be modified when in
player/monster inventory, but this fix addresses the specific problem by
not doing the costly check while swallowed.
Even though the in game help now lists the actual disclosure values
instead of "all" as the default value, implement support for "all" (also
for "none") since doing so is trivial.
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.
<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.
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.
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).
> 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.
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).
<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.
