> Give demon lords and other monsters who teleport to your location a
> oneshot arrival message. [...]
> The fixes entry is deliberately a bit vague (and I put it in the new
> feature section rather than the fix section).
And apparently I neglected to commit it with the rest of that patch last
week.
<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.
Turn being unconscious (via several reasons, including fainted from
hunger) into a pseudo-property named `Unaware' and use it in several
places where only being asleep was checked. #H202 was about a stunned
character who got the recovery message when it timed out while fainted.
This suppresses messages for several difficulties when they begin or end
while hero is Unaware. Messages about fatal illness, sliming, or
petrification aren't suppressed; they're too important to hide from the
player. "You feel ..." messages come out as "You dream that you feel ..."
when Unaware; fairly lame but hopefully adequate.
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.
From a bug report, having hallucination time out while
mimicking an orange (instead of gold, after eating a mimic corpse), you'd
still get the hallucinatory end-of-mimicking message about not wanting to
be peeled. If hallucination state is toggled, update the pending message
and change the hero's appearance. In practice, only the orange-to-gold
case can occur. Anything which might trigger gold-to-orange will have
terminated the hero's mimickery befort that happens.
<Someone> reported being swallowed by his pet purple worm during
Conflict, then being stuck inside once Conflict ended. I'm not entirely
sure what dog_move() intended by the "swallowed case handled above" comment.
It returns without letting the pet move when the distance between pet and
hero is 0; that wasn't much in the way of "handling" being swallowed.
Grabbing pets did let go, but peaceful monsters didn't until you actually
attempted to move away from them. Now all four combinations (grabbed or
swallowed by tame or peaceful monster) are handled the same: the monster
will let the hero go next time it gets a chance to try to move, using up
its move in the process.
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.)
Forwarded from the newsgroup by <Someone>: temple priest might
abandon his post via teleport if conditions are obscure enough. Change
rloc_pos_ok() to only accept spots inside the same shop or temple when a
shopkeeper or temple priest is teleported to a random destination. rloc()
tries rloc_pos_ok() 500 times before reverting to goodpos(), so this will
usually succeed for a large room; it may fail for a small one (reverting
to the current behavior, more or less). Shopkeepers or priests who get
polymorphed into a critter which teleports to the stairs when in need of
healing will still leave their shop or temple if wounded (no change).
Priests resist if the player tries to teleport them, but shopkeepers
don't. So for direct attack by the player, this only affects shopkeeper
destination. But it affects both types as far as being hit by quantum
mechanics (probably caused by player's use of conflict) or if polymorphed
into monsters which steal and then flee (again, probably caused by the
player since those strong monsters won't voluntarily polymorph).
From a bug report...): pushing a boulder onto a level teleporter trap
could repeat the
You push the boulder and suddenly it disappears!
message. That would happen whenever the teleport destination was the same
as the current level (20% chance). The boulder wasn't being moved onto the
trap location so was still present when the pushing code tried to handle
the next one in the pile. I've changed so that pushing stops whenever a
pushed boulder is affected by a trap, and also so that the boulder gets
moved as usual when a level teleporter fails to send it somewhere.
I've always thought it's pretty strange that pushing ever operates
on more than one boulder in the same turn in any situation, but I haven't
changed that for the non-trap cases. (Usually the first boulder pushed
ends up blocking the second one, so you get a "you try to move it, but
in vain" message which seems odd since you just moved one. But if there's
a pool of water or lava in the path, you can actually push multiple
boulders successfully.)
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.
<Someone> reported that he applied an unID'd bag and it became
discovered as a bag of tricks even though a spellbook appeared on the floor
next to him rather than having a monster show up (the monster was a mimic).
Suppress the bag discovery unless you can see or sense a monster appear.
(This doesn't really achieve much for most players, who'll recognize the
bag because they know that only one type of container doesn't prompt to
take things out and/or put things in, but I think it does make sense.)
While mucking with bag of tricks I decided that to be consistent with
the behavior of other containers, the #tip command should release all the
monsters in the bag instead of just one.
And after doing that, I realized that horn of plenty ought to behave
much the same, so #tip will operate on it now. However, it won't be listed
as a likely candidate in the "which item?" prompt unless/until it has been
discovered. (Attempting to empty any other type of horn yields "nothing
happens", same as for a horn of plenty with no charges left.) Emptying a
horn of plenty in a shop can be extremely verbose, but I don't think that
qualifies as a bug and don't currently have any plans to alter it.
From a bug report: [ slashem-Bugs-1206099 ] Torches are not extinguished with rust traps).
A rust trap that hits the torso candles causes all lit objects being carried
to be extinguished, but one which hit the weapon arm didn't have same affect
on a wielded light. This fix causes wielded candles or lamps (not Sunsword)
to go out if affected by any rust, such as hitting a rust monster with one,
rather than use his patch that just handled the trap case. It also excludes
wielded lights from the existing torso splash since having them be hit by
both instances is too obviously buggy.
I think brass lanterns ought to be exempt from being extinguished by
water (at least splashing which is less drastic than total submersion) since
there are references to them operating by batteries rather than fire, but I
didn't want to track all the places which would be affected.
<email deleted> wrote:
> - when in a hardware store, I put a glass wand out of a sack (the glass wand
> will cost you 266 zorkmids) and threw it in the shop => shattered into a
> thousand pieces BUT if I try to pay, I do not owe the shopkeeper anything !!!
> If I break a potion with a /oS, I have to pay !
The user (<email deleted>) who recently suggested a
dump command for containers also wanted atmospheric sounds on levels which
have altars. Right now we'd have to find unattended altars the hard way
(by scanning the entire level) but we could add a counter (or set of
counters, one per alignment) like for fountains and sinks if we really
wanted to do that. [Now that I think about it, the #overview patch may
have already done something of the sort.] But what noises would an altar
be expected to produce? This only adds sounds for temples, where the
attending priest can be the source of the noise.
I'm not real thrilled with the initial set of sounds, particularly
the hallucinating one, but the implementation works. The "carcass" one is
a little clumsy; it's intended to add a hint for new players who haven't
figured out what the #offer command does.
Saving the game while punished, not carrying the attached ball,
and while swallowed by a purple worm resulted in losing the
ball and chain.
Since the required information was not being written to the
save file at all, I couldn't come up with a clean way to do this
for the branch, and preserve save file format. I could think
of lots of kludgy ways to do it (insert ball and chain into
the hero's inventory prior to saving, and remove it on restore, etc.)
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.
Attempt to fix a buglist item: if hero poly'd into iron golem form
enters a pool of water and drowning triggers reversion to human/whatever
form due to water damage, he will fall into that pool again, crawl or
teleport out, then redundantly crawl or teleport out for the initial entry.
[ spoteffects -> drown -> losehp -> rehumanize -> polyman -> spoteffects
-> drown ]
I don't have a lot of confidence in this fix. It does handle the
reported problem, and hasn't broken a couple of earlier tricky cases
(ice melting to water, land mine turning into a pit). But drown() and
lava_effects() seem to leave a trail of special case handling wherever
they appear so they--or spoteffects, or both--ought to be redone somehow.
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.
From a bug report, the game gave feedback
about a monster becoming stuck in a web but there seemed to be no monster
around because it immediately began hiding under an object at the web's
location. Prevent monsters--or poly'd hero--from hiding when trapped in
anything other than a pit or spiked pit. Also, prevent them from hiding if
they're holding you or you're poly'd and holding them. I'm not sure whether
either of those cases ever actually happened but big mimics are capable of
both hiding and grabbing on.
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).
The bug report about losing/regaining the Protection intrinsic reminded
me of a couple of things. First, as an intrinsic, Protection seems to be
completely useless and we ought to redo it. Second, periodically people in
the newsgroup have complained about how it's nearly impossible to figure
out the important--possibly crucial--armor attribute of magic cancellation.
Wearing a cloak greatly increases characters' survival rates, but beyond
that, magic cancellation is just spoiler fodder.
This doesn't do much about Protection other than to change "you are
protected" into "you have a <small,moderate,&c> defense bonus" similar to
how the attributes conferred by rings of increase damage and increase
accuracy are handled. For magic cancellation, it adds new feedback:
You are protected. -- mc factor 3
You are guarded. -- mc factor 2
You are warded. -- mc factor 1
(with no extra feedback for mc factor 0, the normal naked state. The mc 3
case might cause some confusion over the changed meaning of a previously
existing item, but I think it'll be ok and not need re-wording.)
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).
From a bug report, monsters with the wait
strategy (described as "meditating" by stethoscope probing) could be
affected by music but left meditating. Various wake up attempts shared
the same situation. Finish waiting if the monster would have been woken
(or pacified). I didn't search for places that diddle the msleeping bit
directly instead of calling one of the assorted wake() routines.
A fair bit of this is making usage of DEADMONSTER() be consistent.
Sooner or later there'll be another monster movement overhaul and those
if (DEADMONSTER(mon)) continue;
statements will all go away. (Probably just wishful thinking.)
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 a bug described in the slash'em bugs page at Sourceforge. When
attributes are undergoing adjustment (from drinking a potion of gain
ability, for instance), don't display "you feel wise" or "you feel weak"
messages if worn equipment is keeping the relevant attribute at some point
below max or above min and the current value doesn't actually change.
The old logic just checked whether you were at max or min and assumed that
when not, the value would be changing. Now it checks whether the value
actually did change. But it doesn't intercept attempts to go over max or
under min at the same point any more; I hope it hasn't introduced any new
bugs in the process.
Add a patch attached to one of the bug reports sent by <email deleted>
which prevents shopkeepers who have been polymorphed into animals from
speaking. Some messages are altered so that the player gets informed about
shop interactions without it seeming to be spoken by the shk, other messages
are suppressed outright. I cleaned it up a bit (mostly formatting, but the
``getcad'' section seemed to have a logic error--using goto to jump into
the middle of an if-then-else is evil...) and implemented a TODO comment he
added (to use mbodypart() when second shopkeeper at end of game shakes his
head; also, skip that phrase if shk is in headless form--futility while
attempting to test this led to discovery of the misplaced parenthesis bug).
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.
Add the capability of sorting the entire spellbook by various criteria,
augmenting the existing ability to swap pairs of spells. In the menu that's
put up for the '+' command, add a non-spell entry after the last known spell
+ - [sort spells]
Selecting that brings up a new menu
View known spells list sorted
a + by casting letter
b - alphabetically
c - by level, low to high
d - by level, high to low
e - by skill group, alphabetized within each group
f - by skill group, low to high level within group
g - by skill group, high to low level within group
h - maintain current ordering
z - reassign casting letters to retain current order
'a' corresponds to the normal ordering; 'b' through 'g' cause the order
to change, but during the current invocation of the '+' command only.
(Entry 'h' is a no-op, something aside from ESC to get out without doing
anything. 'a' is only a no-op if you haven't picked any of 'b' through
'g' yet.) After making a choice, you're taken back to the '+' command to
view the spells in the requested order. And once back there, you can pick
'+' again to come back to this menu, where picking 'z' will cause casting
letters to be shuffled such that present display order becomes the actual
spellbook order. Newly learned spells get appended to the end as usual;
the most recent sorting order isn't sticky even if finished off with 'z'.
No doubt seeing it in action will be clearer than this description.
This also updates the Guidebook to mention the spell retention field added
to the '+' menu some weeks back.
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.
This patch by <email deleted> was released
when 3.4.1 was current and has been incorporated into slash'em. It is
extremely useful while using ranged weapons. When both autopickup and
pickup_thrown are enabled, walking across previously thrown objects will
pick them up even if they don't match the current pickup_types list.
[See cvs log for patchlevel.h for longer description.]
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.
We've been getting numerous complaints from people
about "dungeon failure", often related to attempts
to start NetHack from within various zip utilities
that present a folder-like view.
The dungeon failure was actually misleading. The
real problem was a dlb file open failure, but the
return value of dlb_init() was not being checked
in pcmain.
This moves the dlb_init earlier in the startup,
checks for failure, and provides some feedback
around the common zip utility problem for win32.
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.
