From the newsgroup: a player accidentally cast the stone-to-flesh
spell at himself (I don't recall whether he chose wrong spell or wrong
direction, or tried to cancel and game used last remembered direction)
and the barbarian quest artifact he was carring turned into a meatball.
Artifacts already have a high chance (95%) to resist being polymorphed
but that doesn't apply for the stone-to-flesh transformation. This
gives stone artifacts a high chance (98%) to resist being turned into
flesh. Non-artifacts also get a small chance (2%) to resist as well.
add SYSCF docs to the Guidebook because it's info needed in a binary distro
Guidebook.tex - also add some missing italics to some "NetHack" occurances
call nethack.org "official"
Guidebook.txt - didn't regenerate cleanly so no diff
add SEDUCE to SYSCF (only partly inspired by the recent email)
From a bug report, black dragon breath
destroys closed doors didn't acknowledge hitting secret doors. bhit()
reveals secret doors, but zap_over_floor() (called by buzz() for ray-type
wands and spells, and for breath attacks) didn't check for hitting those.
When testing the fix, I noticed that feedback for an explosion caused
by breaking a wand was worded oddly for zaps like magic missile which don't
damage doors. "The door absorbs your bolt" didn't make much sense; what
bolt? That was first changed to "absords your blast", which still sounded
weird, then to "absorbs the blast", which seemed better but was inaccurate.
Next was "absorbs some of the blast" since the explosion continues to hit
adjacent spots, but since it still has full strength that wasn't accurate
either. It's finally become "The door remains intact." Unlike with zaps,
there is no additional range being lost, so no reference to absorption.
From the newsgroup: player saw "The spell hits the <monster>?"
where the question mark punctuation reflected negative damage occurring.
Another player diagnosed it as a 2 point force bolt (from 2d12 dice role)
modified by -3 penalty for hero who has Int less than 10. This changes
spell_damage_bonus() to avoid reducing damage below 1 point.
From a bug report, polymorph of self due to
breaking a wand also polymorphed various items that were dropped in the
process, unlike the case of zapping polymorph at monsters which excludes
dropped items from being poly'd. This polymorphs the pile at the hero's
feet before polymorphing the hero. I first tried to handle it using
obj->bypass like with monsters, but that didn't work. Post-3.4.3, the
bypass handling is also used for polyself (by retouch_equipment()) and
it was getting reset at an inconvenient time.
He also complained that he failed to get "you feel shuddering
vibrations" when some polymorphed objects got destroyed. That message
is issued by weffects() which do_break_wand() doesn't call. It ought to
be fixed, but this patch doesn't address it.
Lastly, add code to prevent objects guarded against polymorph via
obj->bypass from getting used up when creating polypile golems.
Reported recently by <Someone>: probing feedback while engulfed
shouldn't claim that the monster is not carrying anything when the hero
is inside of it. The simple case where it's not carrying anything else
was a trivial one line change; handling inventory plus hero was trickier
and I wouldn't have bothered if I'd realized what it was going to take.
But it's done now; trivial case
The purple worm is not carrying anything besides you.
and harder case
The purple worm's possessions:
Weapons
a - an uncursed dagger
Swallowed Creature
> - human archeologist called wizard
Groundwork for re-doing ^X so that it'll be more integrated with
enlightenment and display bottom line information without abbreviations
or long-line truncation. `mode' doesn't do anything yet so may provoke
lint complaints.
More tuning to throttle pudding farming (plus endgame Rider farming).
Earlier changes made cloned black puddings less likely to leave corpses,
to cut down on sacrifice fodder a bit, and cloned anything less likely to
drop random items when killed; this one makes killing cloned or revived
monsters be worth less experience as the number killed goes up, to cut
down on final score inflation. [With several boulders and magic missile
or a polearm, it's possible to kill any of the Riders repeatedly with
virtually no risk of even getting hit, much less of getting killed. Now
if you kill Pestilence 240 times it will be worth 62720 points instead of
297840 (not including doubling bonus for ascension), with an additional
19 points per kill instead of 1241 after that, requiring a couple orders
more magnitude of abuse--excuse me, superhuman "patience"--to get the
score to reach the overflow threshold.]
While testing this, I got "The Famine's corpse glows iridescently."
This fixes that too. Also, previously unused kill count for experience()
had an off by one error; was including ``+ 1'' even though mvitals[].died
has already been incremented by the time that that code uses it.
From a bug report, reviving a snake corpse
produced a snake monster which was hidden under nothing--it hid under its
own corpse and wasn't revealed when that corpse got used up. Rather than
fiddling with sequencing to remove the corpse before making the monster,
force any monster who revives in hidden state to unhide.
From some notes I made prior to release of 3.4.3, about applying a
carried mirror in the direction of a monster:
invisible player applying mirror toward monster which can't see invisible
should have no effect (monster can't see hero's equipment);
similarly when inside engulfer regardless of whether it can see invisible;
applying mirror at worm tail shouldn't work but does;
applying mirror toward unseen monster that can see invisible (so should be
able to see its own image) doesn't work because bhit() won't target it;
mirror shouldn't work when target is only visible via infravision.
The fourth one is iffy since it assumes that invisible monsters produce
invisible reflections rather than no reflections. The reverse of that is
probably more reasonable but isn't as interesting. The fifth one may be
contradictory; it fails to extend that logic to "infravisible monsters
produce infravisible reflections."
Spotted by Janet: in the ``using #monster to breath[e] at self''
patch I accidentally reversed the Half_spell_damage adjustment (to breath
only from non-breath attacks only, not by doubling instead of halving
damage :-). Changing it to include zaps by the hero is intentional.
When testing the monster-breath-at-self patch I noticed that trying
to cure green slime by having hero breathe at self didn't work. The code
was calling buzz() with arguments that produced an attack directed against
the hero's location, but there was a chance for it to miss outright and
when it didn't, reflection would block it. This makes breathing at
yourself with `#monster' comparable to zapping a wand or casting a spell
at yourself: it always hits.
Like their use of lizard corpses to defeat being turned into stone,
let monsters use wands of fire, fire horns, and scrolls of fire to try to
defeat being turned into slime. If the scroll is read while confused, it
won't succeed. Otherwise, monsters who don't resist fire will take some
damage in the process and might end up killing themselves (although with
the testing I've gone I've yet to see that happen--I guess that means
that handling for dying-in-the-process hasn't been adequately tested...).
So far, they don't know how to jump onto adjacent fire traps, nor
will fire breathing monsters breath at themselves. I don't know whether
I'll get around to tackling either of those.
Noticed while looking at something else: zapping a wand of opening
or spell of knock downwards while riding causes your steed's saddle to
fall off, which in turn causes the hero to fall and take some damage.
If that damage was fatal, the saddle would be left worn in bones data.
This reorganizes mdrop_obj() to defer until last the part that ultimately
makes the hero fall off, and changes bhitm() to call that instead of
handling saddle removal inline, also gives new saddle-off feedback there.
Zapping cold at an ice location which has a melt timer would set
new timeout to a random value which could actually cause that ice to melt
sooner. Make sure the new value is always at least as big as the old one.
Also, MAX_ICE_TIMEOUT wasn't actually the maximum ice timeout; now it
is--if the generated value is higher, omit the timer so that that ice is
permanent. No fixes35.0 entries necessary; this is post-3.4.3 code.
Back in <email deleted> in #U1216
suggested that statues of stone golems which are hit by stone-to-flesh
spell should leave flesh golem corpses instead of meatballs. But they
should actually have revived as flesh golems. Stone-to-flesh revival of
golem statues and golem figurines didn't work as intended because golems
other than flesh or leather were considered to be vegan/vegatarian, which
caused them to produce meat rather than living monsters. Also, S-to-F of
a leather golem statue worked as intended and created a flesh golem, but
S-to-F of a leather golem firugine created a leather golem out of stone
object. This fixes it so that any type of golem statue or golem figurine
revives as a flesh golem.
Two other bugs noticed and fixed: (1) S-to-F cast on self while a
figurine of a non-veggy monster was "worn" in one of the three weapon
slots triggered an "extract_nobj: object lost" panic similar to several
similar cases which were recently fixed (that was 3.4.3; for development
code, it gave "obfree: deleting worn obj" warning instead). (2) S-to-F
activating a shop-owned figurine didn't charge for it.
Back in Nov'04, <Someone> pointed out that even with only 5%
chance for dropping a horn upon the death of a unicorn which has been
revived from corpse, it's still possible to produce a nearly unlimited
number of them for polypile fodder. This bumps the chance for a horn up
to 50%, but flags the horn as coming from a revived corpse and makes such
horns be treated by polymoprh as if they're non-magic (which practically
guarantees that they'll poly into mundane tools instead of magic ones).
<email deleted> reported back on 8/31/06 that elven weapons were not
affected when he poked a fire elemental with them. This is true, but
moreover, there was no code to have passive fire to affect attackers.
Now erode_obj() supports all the same damage types as rust_dmg(), and added
the connecting code to allow passive fire attacks do something.
There probably should be macros for the damage types used by rust_dmg
and erode_obj, and possibly these functions should be combined, but they
are slightly different and dealing with that requires more thought.
Someone in the newsgroup complained about zapping probing at a large
box dropped by a quantum mechanic and being told that it was empty rather
than that it held a corpse or live cat. This sidesteps the issue by
reporting "the box seems empty" instead of "the box is empty", and not
setting its contents-known flag. (That message is the main difference
between probing and the assorted other methods of observation [telepathy
and monster detection and possibly Warning for live cat, object detection
and food detection for dead cat's corpse] which might be expected to
trigger the cat's fate but don't.) This also makes probing of self and
of monsters set the contents-known and locking-known flags for containers
in inventory, same as is done for probing which hits objects. (Display of
container contents still only occurs for loose objects, not in inventory.)
Make yellow dragon breath destroy iron bars (unless their wall_info
is marked as non-diggable, which I think is currently impossible for bars).
The shop handling is untested; no shop has iron bars for its walls or
includes them as interior obstacles. (The latter would require changes
to shop repair because lost bars will become solid wall if/when rebuilt.)
Thrown potions of acid and spat or thrown splashes of acid venom
don't affect bars--at least so far--because those always pass through
without hitting. Monsters who have a non-ranged attack which does acidic
damage can't use such attacks against iron bars.
From a bug report: if you
attempted to engrave with an empty wand while levitating, it wouldn't use
a turn unless you successfully wrested an extra charge out of the wand.
So you could always get such charge in a single elapsed turn of game time
if you didn't care about zapping in any particular direction; extremely
useful for wishing.
Noticed when checking this: when you did wrest the extra charge,
the engraving code accessed freed memory for the wand after it had been
used up.
Lastly, wands producing certain effects always become discovered,
even when you don't yet know what they look like. (This part of the patch
is trunk-only since it utilizes the routine which fixes similar case for
zapping.)
Thrown boomerangs travelled in a clockwise path, appropriate for
left-handed throwing. But nethack heroes are treated as right-handed by
the weapon wielding and shield wearing code, so make boomerangs travel
counterclockwise instead. Switching is straightforward, in case we ever
implement user-specified or random handedness.
Make worm teeth and crysknives be stackable. Positively enchanting
a stack of multiple worm teeth produces a single crysknife, negatively
enchanting a stack of multiple crysknives produces a single worm tooth.
A dropped stack of N fixed crysknives has 90% of remaining N crysknives,
10% of becoming a stack of N worm teeth, rather than produce an average
of 0.9*N crysknives and 0.1*N worm teeth. (The code which handles that
transformation operates on loose objects so cannot handle stack splitting
because it wouldn't have any idea of what to do with extra objects.)
Terminate multi-shot volley throwing of boomerangs if one comes back
and isn't caught. The sequence throw-catch-throw-catch is odd, but would
take a substantial amount of code and effort to be changed to the more
intuitive (for rapid volley throwing) throw-throw-catch-catch. Even if
feasible, doing that for underused boomerangs would be a waste of effort.
A suggestion from the newsgroup: when potions are hit by fire and
get the "boil and explode" result, potions of oil should burn instead of
boil. Even though oil can be heated to boiling, nethack's potions of oil
are noticeably flammable [just (a)pply one...] so having them burn makes
sense. It's just a message change; no actual explosion has been added.
destroy_strings[] was implemented as an {N} x {3} array that used
manually computed indices into one-dimension. This changes it into a two-
dimensional array instead. However, it's still being indexed by a bunch
of magic numbers.
Something's wrong with the way lava was being handled in moveloop().
If you were trapped in lava (ie, moved into some but didn't die on the
spot thanks to fire resistance), you could sink and ultimately die without
ever taking another actual turn (typing ``i<space>'' repeatedly is an easy
way to reproduce). [`didmove' was only being checked for the sinking
deeper case and not for the decrement which ultimately leads to the fully
sunk case.] On the other hand, if you could manage to start an occupation
and avoid being interrupted, you would never sink while it was in progress.
[Lava handling followed ``if (multi && occupation) { ...; continue; }''.]
While testing some other code (lava vs slime, coming shortly) I ended
up with the cursor sitting on the status line while the game was waiting
for me to enter my next move. I don't really understand what's going on
there, and moving the lava handling before bot() might have hidden that
particular problem now by changing the point at which Slime will get taken
off the status line, but this attempts to fix it anyway.
From a bug report: zapping a wand of striking or locking or spell of
force bolt or wizard lock up or down when standing at an open drawbridge's
portcullis didn't affect the bridge if the portcullis was positioned north
of the open span. One of the two drawbridges on the Valkyrie quest goal
level has that orientation. is_drawbridge_wall()'s name is somewhat
misleading; it isn't boolean and returns -1 rather than 0 for "no".
From a bug report. That's hard to fix in the general case because armor
and tools might not fit back into the same equipment slot, but most other
types of worn items can be re-worn after being transformed. This makes
any transformed worn item stay worn if it is wearable in the same slot.
