From a bug report: you could end up with
gravestone/logfile result of "burned by burning" or "drowned in a drowning".
If you get life-saved when drowning in water or burning in lava, the game
tries to teleport you to safety. If the teleport fails for some reason--
such as lack of unoccupied non-water or non-lava locations--you drown or
burn again. But life-saving was resetting the killer reason and the repeat
drowning/burning wasn't setting it up again, so the default got used and
produced a silly result.
<Someone> wrote:
> I can' t find this bug in the known bug list. If I missed I do apologize.
> It occurs on the standard windows nethack.exe. Just wield a cream pie
> and then apply it. Press x to switch weapons. Program in disorder.
> s - 1752440940 glorkum 32 26485 101's named ? (alternate weapon; not wielded).
> Greetings, <Someone>
It crashed with an access violation for me.
Recently reported to the list, a fireproof container dropped in lava would
catch fire and burn. Add the missing check; this looks an oversight when
the idea of fireproof was added, since other fireproof objects get handled
later in the cascading if().
<Someone> reported the longstanding behavior that when dragging, the chain
does not always remain directly between the player and the ball. This occurs
when the player zigzags. Added a check to the simple drag code to try to
keep the chain directly between the player and the ball. But, don't do this
if the player is walking thru rock or if it would move the chain into rock.
Pat recently forwarded a discussion that Elbereth was ignored unless there
was an object on its location. Mostly. It was also respected if the hero
was Displaced, no matter where the hero was. No one commented on his
message, which I took for assent to address this. Removed the qualifiers, so
now Elbereth is always respected, just like a scroll of scare monster.
<Someone> noticed that when a monster escaped upladder in the wizard
tower, it ended up outside the tower. This is due to the "wander" code in
monster migration. Rather than add code to try to keep the monster from
crossing the undiggable wall, just add REGIONs on the tower levels within the
area, which then utilizes the existing in-a-room constraint behavior of
monster migration. Of course, one can still fill a tower level with fodder,
and then when another monster climbs the ladder, it will still end up
outside the tower.
stinking clouds extend their timers, causing the "ttl == 0" check in
visible_region_at to be inappropriate; technically it was never quite
right, since the ttl is set to 0 one turn before removal is considered. But
with the Eyes on, this caused a visible change in the region although the
region still existed. Introduced a new -2L value to designate that the
region is being removed (-1L means it's permanent), which is what
visible_region_at was really trying to test.
<Someone> wrote:
>>comments:
>>When you commit suicide with a potion of oil (lit), sometimes nethack
>>reports an `obj_is_local' error just after disclosing all the game
>>variables. This has been found in-game (don't ask) and reproduced in
>>wizard mode and in-game (start-scumming).
>
> 0) a neutral human wizard (the scrolls/spellbooks burning, potions boiling ;))
> 1) wish up 3 potions of oil (so that the 2 remaining will definitely kill you)
> 2) a'pply one of them
> 3) stand 1 square away from a wall, like "| @"
> 4) throw the lit potion into the wall (`h' in this case)
> 5) answer `yes' on all prompts.
The thrown potion of oil, which was extracted from any chain
during the throw, still had its timers attached when the call to
splatter_burning_oil() was made. If that killed the hero, a
panic would result during bones file creation (saving timers)
because (obj->where == OBJ_FREE) on the potion.
Remove the timer prior to splattering the oil inside.
From a bug report, being hit with a
yellow light explosion while fainted from lack of food caused blindness
but being hit while sleeping did not. Make being in fainted state become
a protection against light-induced blindness.
From a bug report, the fallback selection criteria
(used when everything is extinct?) in rndmonnum() was excluding hell-only
monsters when outside of Gehennom, but failed to exclude never-in-hell ones
when inside. [Some of the never-in-hell monsters are Angels, but the rest
are all cold based creatures. That must date to when fire resistance was
required for the hero, which is no longer the case. Should those cold
monsters retain their never-in-hell setting?]
This also fixes a latent copy/paste bug in the unused mons[] definition
of Cerberus (it was the only unique monster which failed to specify G_NOGEN).
<Someone> says he reported this five years ago, but I don't think I ever
saw it. Receiving an artifact as the result of #offer would add it into
the discoveries even if the hero was blind and never saw it. It either
needed to have the dknown bit set, as if it had been seen, or else should
not be added to the list. I've opted for the latter.
When the hero arrives on a level and a monster at his destination can't
be relocated to make room for him, goto_level() would place the hero on top
of the monster. From a bug report, who said that the
game panicked (without providing specifics, at least so far). I wasn't able
to reproduce a panic but get a pair of impossible warnings and can confirm
that there is a monster on the same spot as the hero, which could easily
lead to strangeness depending upon what actions the monster attempts to
perform. This fix causes a non-relocateable monster in that situation to
be moved to the migrating monsters list for later arrival back on that same
level. That's inconsistant with the migrating monster arrival routine,
which kills off any monster it can't place; I'm not sure which action is
more reasonable, deferred arrival or outright removal.
There are three or four dozen ``(void) rloc(mon)'' calls which don't
do anything special when rloc fails to move the monster. Those need to be
reviewed and the ones where it's making a space for some other monster have
to do something about failure. (Failed teleport attempts can simply leave
the monster in place, so most of those calls won't need any extra handling.)
From <Someone>:
Pet picks up 8 spears.
Pet wields 8 spears.
Pet thrusts its spear at Foe.
The routine to handle a monster attacking the hero are already uses "mon
thrusts one of its spears" in this case, so make monster against monster
messages do the same. Also, it's no longer necessary to save one monster
name before formatting another when using two monster names in the same
message, so switch to the more straightforward usage here. (The Blind
check is needed in the mhitu case but not in the mhitm one, where it's
redundant because the caller has already verified that both monsters'
locations are visible, but I left it in.)
From a bug report, it was possible
to fall from above the quest locate level to below it even though it has
nondiggable floors (hence no trapdoors or holes to pass through). Since
the game can't verify that it is nondiggable (which could vary on a role
by role basis depending upon their quest descriptions) when it is not the
current level, restrict falling past it only when it hasn't been visited
yet. Impose the same restriction for random level teleport. This enforces
proper sequencing of the quest feedback, which was the more significant
thing that went wrong in the reported case (player finally got the full
locate level message on a return visit, when descending from above, after
having already cleared out that level on his way back up from falling).
Once the locate level has been reached or passed, it is no longer a
barrier to falling or random teleport. (When it is eventually visited,
there's no attempt to remember whether it allows holes, since that
information and the corresponding fall check would need to be extended to
every level in the dungeon. Also, controlled teleport is still allowed to
bypass it even when it hasn't yet been visited, so the "enforces proper
sequencing" claim above is an exaggeration.)
From a bug report, applying a pick-axe will
wield it in place of the primary weapon but wouldn't update the alternate
weapon. Make objects which become wielded when applied (pick, lamp, whip,
grappling hook, pole-arm) honor the pushweapon option (where the previously
wielded weapon becomes the alternate weapon without use of 'x' command) the
same as when explicitly wielded. Old behavior matched the documentation,
but that seemed overly restrictive.
<Someone> wrote on Tuesday, July 27, 2004 at 06:46:15
> In the region.c function rest_regions allocates storage for the possible
> enter_msg and leave_msg strings. But the function free_region does not relese
> this storage.
Also ensures that some code that is currently ifdef'd out
makes copies of the strings into memory from alloc()
to ensure that no problems with free() result if the function
gets passed a literal string.
> NetHack feedback form submitted by
> <email deleted> on Friday, June 30, 2006 at 17:31:12
> ---------------------------------------------------------------------------
>
> mailversion:1.35
>
> nhversion:3.4.3
>
> nhfrom:Our 3.4.3 source release, unmodified
> comments:
> telnet nethack.alt.org with the terminal set to 21 rows.
> Choose to pick a char, not accept pot luck, and game segfaults.
> (same happens from linux console)
I was able to reproduce something similar in win32 by setting
the console to 21 rows. As he stated, don't let the game pick you
character for you to reproduce the problem. As soon as I chose
Archeologist the problem occurred:
Where:
In hack.c, weight_cap()
if (Levitation || Is_airlevel(&u.uz) /* <email deleted> */
#ifdef STEED
|| (u.usteed && strongmonst(u.usteed->data))
#endif
)
Variables:
carrcap 200
u.usteed 0x00000000
&u.uz 0x005e54aa
youmonst.data 0x00000000
Examination of the preprocessor output of that section
of code reveals that
"Levitation" becomes:
(u.uprops[47].intrinsic || u.uprops[47].extrinsic ||
((youmonst.data)->mlet == 5))
so it is the is_floater(youmonst.data) causing the crash.
Call stack:
weight_cap() line 2300 + 24 bytes
inv_weight() line 2342 + 5 bytes
calc_capacity(int 0) line 2354 + 5 bytes
near_capacity() line 2365 + 7 bytes
bot() line 607 + 5 bytes
docorner(int 47, int 19) line 2378
erase_menu_or_text(int 5, WinDesc * 0x00a22550, char 0) line 994 + 25 bytes
tty_dismiss_nhwindow(int 5) line 1664 + 15 bytes
tty_select_menu(int 5, int 1, mi * * 0x0006fc40) line 2248 + 9 bytes
tty_player_selection() line 442 + 16 bytes
pcmain(int 3, char * * 0x00a20eb0) line 457
main(int 3, char * * 0x00a20eb0) line 91 + 13 bytes
This adds a check for a valid youmonst.data in
bot().
From a bug report, attempting to attack
a hidden monster who is revealed by ongoing monster detection (blessed
potion or skilled spell) gave "wait! there's a <monster> hiding there"
response and prevented the attack. Make it behave the same as when the
hidden monster is revealed by telepathy; the monster comes out of hiding
and the hero's attack proceeds.
When testing the spoteffects/drown hack I noticed that draining myself
with Stormbringer (toss up, get hit on head) while in iron golem form gave
messages about it drawing or draining life. (I'm sure that this has come
up before....) I've altered the artifact hit message rather than making
golems become resistant, although the opposite approach seems at least as
valid. The drain life spell uses different wording and isn't affected.
I can't find the report about this; I must have deleted it after
reading, or else recently reread something so old that I'm not going back
far enough now. When you perform the invocation ritual to create the
stairs down to Moloch's Sanctum, any trap at your location gets deleted.
But if you were in a trapped state at the time then you got left in that
state. Descending stairs doesn't check for traps so you wouldn't notice
unless you tried to move around on the same level first. Then you'd get
"you're stuck in a pit/beartrap/web" even though it wasn't there anymore.
While testing the hiding vs traps patch, I became a mimic and hid.
It gets stuck to you.
Huh? Nothing was visible; nothing became visible (aside from the ']' at my
position changing back to 'm'). Display the invisible monster glyph when
an unseen monster bumps into you while you're hiding or mimicking gold.
That's usually handled by the hit and miss routines, but they aren't used
when you're just brought out of hiding instead of attacked.
Fix the problem From a bug report, where
giving a temple donation of the appropriate amount would fail to restore
protection previously stolen by gremlin attack iff the old protection amount
was big enough that the donation wouldn't have yielded a bonus in the normal
not-stolen case. It shouldn't be checking the magnitude of u.ublessed at a
time when lack of the intrinsic renders that value inoperative. After this
fix, the lost intrinsic will be granted and the old protection value will
be restored, same as happens when a prayer boon yields divine protection
(where no u.ublessed magnitude check is made) and as happened with donations
when the old protection was a more modest amount (magnitude test passed).
From a bug report, specifying role and race
along with invalid alignment for that role/race combination resulted in a
prompt of "pick the alignment of your chaotic human Valkyrie". This fixes
that particular problem, but the role selection code is incomprehensible
and I don't have a lot of confidence about whether other combinations have
similar trouble.
This also fixes an obvious typo in ok_align(). Unfortunately I can't
figure out what to do with the if-then-else block in root_plselection_prompt
which has identical code for its `then' and `else' halves (in the alignment
code that the new ok_align() test skips).
When high priests have their affiliation suppressed to avoid giving
away which altar is which on the Astral level, the name formatting also
bypasses the code that converts "priest" into "priestess" for females.
(The bug report was about Moloch's high priestess; the occupant of the
Sanctum's temple gets similar handling to those on Astral.)
Also a tidbit for a change made a couple of days ago. Avoid using
"Manlobbi the invisible shopkeeper" or "Asidonhopo the newt" in the message
given when a shk refuses an attempt to be renamed via the 'C' command.
From a bug report, the 'C' command wasn't reporting that
"<shopkeeper> doesn't like being called names" even though the user's
supplied name was ineffective. Same thing for temple priests and other
minion monsters; the name was accepted but didn't do anything. Make such
monsters reject new names.
Fix something I accidentally broke nearly three years ago (post 3.4.2,
so the bug appeared in 3.4.3). A misplaced closing parenthesis caused an
in-sight check to always fail, so the "<shk> looks at your corpse, shakes
his head, and sighs" message when game ends would never occur. That
situation is extremely rare anyway; it only happens after some other shk
has taken the hero's possessions.
<email deleted> wrote:
> While levitating, I put on an unknown pair of boots. They turned out to be
> elven boots. I received the message, "You finish your dressing maneuver. You
> walk very quietly." Incidentally, I was hallucinating at the time.
>
> It seems to me that levitating individuals shouldn't be able to tell that they
> walk quietly.
Putting on the Eyes while blind causes sight to be regained, which in
turn causes xname() to set the dknown bit and start using the previously
unseen object's name. But obj_is_pname() was being called before xname in
the "you are now wearing ..." message, while dknown was still clear. So
obj_is_pname thought the name was being suppressed and returned false,
resulting in "an Eyes" instead of "the Eyes". Fix is to call xname first.
Fix the bug From a bug report.alt.org server, where killing a monster by closing the
castle drawbridge resulted in a panic after the dead monster's possessions
were dropped into the moat and a potion of acid exploded in the process.
water_damage() deleted the object but had no way to tell flooreffects()
that it was gone, so flooreffects() couldn't tell its own caller not to
place and stack the object. After that, a chunk of freed memory became
part of the floor objects chain and eventually triggered a panic which
tried to make a save file but whose reason didn't get logged properly.
From a bug report.c was first creating a corpse
complete with revive timer if it was a troll, or without
a timer if it was a lizard or lichen corpse. Then it might
change the corpse type, leaving strange corpse
types that revived, or that lasted forever.
I've forgotten who pointed this out recently, but the hero was having
wisdom exercized (if true rumor chosen) or abused (for false one) whenever
level creation made a random floor engraving which used a rumor for its text.
From a bug report, a steed hit by disintegration
breath survived via life-saving, but the program was confused about whether
the hero could still ride and issued some impossible warnings. The code
to disintegrate a monster's inventory didn't bother to unwear worn items as
it destroyed them, presumeably assuming that the monster was sure to die,
so steed was left with a flag bit set claiming it was saddled even though
the saddle was gone. This fixes that, and the rider will end up being
dismounted as the saddle gets destroyed, regardless of whether the steed
ultimately survives. [Since the steed is still present at the time of
dismounting, the hero will get bumped to some other location, possibly to
the next spot about to be hit by the same black dragon breath attack which
just vaporized the steed. That's suboptimal, to put it mildly....]
I couldn't test the circumstances of the original report. Post-3.4.3,
ki-rin has been marked no-hands and is no longer capable of wearing armor
or amulets. I looked to see whether any other potential steed could wear
an amulet of life-saving and couldn't find one. But the original bug also
applied to conferred properties of special armor worn by non-steed monsters
too, so the fix was needed anyway.
The branch and trunk patches are different. For the trunk, I moved a
big chunk of code out of buzz() into a seperate routine. That actual fix
is the same in both variants.
Move part of the recent "munstone fixes" patch to the branch code
since one of those fixes prevents accessing freed memory. The part that
lets monsters eat tins of lizard meat or tins of acidic monsters in order
to get the same benefit as the corresponding corpse has been left out.
<Someone> wrote:
> When applying a drum of earthquake, should you "fall into a chasm" if
> you're already at the bottom of a pit? (Likewise monsters.)
monster already in a pit won't "fall into a chasm" from drum of earthquake
<Someone> wrote:
> When applying a drum of earthquake, should you "fall into a chasm" if
> you're already at the bottom of a pit? (Likewise monsters.)
hero already in a pit won't "fall into a chasm" from drum of earthquake
<email deleted> wrote the following on April 10, 2006:
> When blind and levitating, you can produce a message - "You try to feel what
> is lying here on the ice. But you can't reach it!" - which reveals too much
> about the terrain below you.
Something I encountered while playing slash'em a while back, but
relevant to nethack: "Its orcish spears shatter from the force of your
blow!". I was using a two-handed weapon (at skilled or expert level) to
fight an invisible monster which was wielding a stack of multiple spears
(slash'em gives them out in groups of 3 for monsters' starting inventory).
After killing it, I found 2 orcish spears along with an invisible corpse
of somebody-or-other the Kobold King. The message suggested that the
whole spear stack had been destroyed (and the weapon shattering code in
hmon_hitmon() clearly expects that to be the case), but only one of them
had actually gotten used up.
I can't recall whether "shatter" was actually given as singular or
plural at the time; nethack handles that aspect correctly. Only object
destruction needed tweaking.
From a bug report, then leave the corridor (causing it to
> vanish), the pit will be embedded in rock instead of being removed.
clear any pits that the hero digs in the vault guard's temporary corridor
I'm pretty sure this check at_u should be included since x,y
can be passed to digactualhole(). The lack of any related
bug reports suggest that at_u is currently always
true for any code that calls digactualhole().
From a bug report: when creating a
level, anthole rooms can be generated even when no ants are left, unlike
beehives which get suppressed once killer bees are gone. Also, if some
ants are available but the type chosen for the current level isn't (in his
case, soldier ants had been genocided), the anthole was filled will random
monsters instead of picking another type of ant. This fixes both issues.
Random monsters will only occur if the last type of ant gets used up while
filling an anthole that was started when some ants were available, same as
how monster generation for beehives and barracks works.
I don't know for sure what all the possible values of hittee passed to
Mb_hit() are, but this checks to see if it matches the name of the
mdef monster and forces the word "is" if it does.
