Something I've had in mind for a long time and finally gotten around
to implementing: when you fill in the last pit or hole of a sokoban level,
it's considered to be completed so luck penalties for unsokobanish things
(breaking a boulder, dropping everything and squeezing onto a boulder's
spot, reading a scroll of earth) stop being assessed and most Sokoban-
specific movement restrictions (against pushing boulders diagonally,
squeezing diagonally between boulders, floating over a pit or hole without
falling in, digging of new holes by monsters) are lifted. Teleporting,
level teleporting, and phasing through walls are still prohibited when in
the sokoban branch of the dungeon. (Keeping the non-phasing one in place
prevents taking a shortcut to the final prize in order to bypass the
treasure zoo monsters.)
This adds level.flags.sokoban_rules, defines Sokoban macro to access
it, and replaces most In_sokoban(&u.uz) tests to check it instead. It
gets set when a sokoban level is pre-mapped at the end of level creation,
and if it is set then whenever a trap is deleted, the flag gets cleared
if there are no more pits or holes present on the level.
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.
