Any monster with rusting or corrosion attack can eat through
the bars. This includes rust monsters, grey oozes, and black puddings.
Original patch by Malcolm Ryan
Instead of just "while helpless", the death reason will tell
more explicitly why the player was helpless. For example:
"while frozen by a monster's gaze"
flooreffects() covers most dropped/thrown/etc. cases, and the hooks in
invent and mon handle "deathdrops" along with picking up items.
still need to check putting into/removing from containers
Move debugging output into couple preprocessor defines, which
are no-op without DEBUG. To show debugging output from a
certain source files, use sysconf:
DEBUGFILES=dungeon.c questpgr.c
Also fix couple debug lines which did not compile.
This also includes fixes due to Derek Ray to depugpline to work better
on other platforms.
There is a lot of code affected by this, and Pat Rankin correctly
observes that it would be better to store roguelike as a level flag
rather than just using Is_rogue_level. A note for the future.
From a bug report, being teleported onto
a sink while busy putting on levitation boots triggered a crash when
Boots_on() was called (as '(*aftermv)()' on the next turn) because
'uarmf' would be null by then. Not mentioned, but the same problem was
encountered by Boots_off() if the teleport happened while you were busy
taking boots off. It could be fixed by having having dosinkfall() call
cancel_don() if donning(uarmf) yields true, but this patch does a little
more than that: cancel donning/doffing of any multi-turn armor if you
fall onto a sink. It also prevents you from falling if you end up
flying (which will have been blocked while levitating).
The situation when putting on levitation boots has a sequencing
issue: setworn() causes you to be flagged as levitating immediately,
but the float_up() feedback doesn't occur until Boots_on() gets called
a turn later. Teleporting to the sink will tell you that you crash
onto the sink and and that you stop putting on boots, without having
been told that you've floated up into the air. It's suboptimal but it
doesn't seem to actually be incorrect.
Reported last December by <email deleted>, attempting to move
into a peaceful monster's position and then declining to attack at the
confirmation prompt uses no time, as expected, but does burn nutrition
the same as if you carried out the attack. A player could abuse that to
make room to eat an intrinisic-conferring corpse before it rots away.
This fixes that, and also makes attacking a monster via applying a polearm
and via kicking burn the same extra nutrition as ordinary attack. I didn't
add it for attacking via throwing.
He/she also reported that kicking at a peaceful monster and declining
to attack at the prompt wakes up nearby monsters even though no actual kick
ultimately takes place. I can confirm that, but this does not fix it.
From a bug report, you could crawl
out of water to avoid drowning by moving diagonally into an intact doorway
even though regular movement won't allow that. (Second version of Medusa's
level has a door adjacent to water.) You could also escape diagonally when
polymorphed into a grid bug.
Change how overview data is handled if/when you get expelled from
the quest: mark quest levels as unreachable rather than discarding their
overview data, so that it can be included in end of game disclosure (and
can be revived if you manage to return to your quest branch by invoking
the W quest artifact).
Order of endgame levels was odd: earth followed by astral, water,
fire, and air, because the code didn't know how to insert in front of the
first one visited. Now it does. Placement of endgame levels was sub-
optimal: since that has the highest internal dungeon branch number, it
came out last. Now it is forced to come out first, so that it appears
above the dungeon. And use "Plane of Earth" for level name rather than
"Plane 1", and so on for the others, when in the endgame.
Since I'm bumping EDITLEVEL due to adding mapseen.flags.unreachable,
I am also inserting u.uevent.uvibrated now so that it won't trigger another
EDITLEVEL increment. At the moment it doesn't do anything except get set
when you receive the "you feel strange vibrations <under you>" message.
The level where that occurs will eventually have an automatic annotation
of some sort.
1) add graves to the dungeon features being tracked;
2) report on known bones (determined by seeing map spot(s) where previous
hero(es) died since there's no guarantee of graves or ghosts);
3) add automatic annotations for oracle, sokoban, bigroom, rogue level,
Ft.Ludios, castle, valley, and Moloch's sanctum. For bigroom and rogue
level you just need to visit that level, for the others you need to get
far enough along to learn something specific (oracle: her room, sokoban:
annotation is either "solved" or "unsolved" depending upon whether all
the holes and pits have been filled, fort and castle: see the drawbridge,
valley and sanctum: see inside the tended temple). Discovering the
relevant locations via magic mapping counts as "far enough along".
There should probably also be automatic annotations for Medusa and the
vibrating square but I'm not sure what criteria should be used for the
former or what phrasing to use for the latter. Demon lord/prince lairs fall
into similar category as Medusa.
TODO: add final #overview as an end of game disclosure option. (I was
planning this even before I saw that nitrohack has implemented it....)
> On 01/30/2012 08:20 PM, <Someone> wrote:
> The boulder from a rolling boulder trap can be generated on a
> lava pool. mkroll_launch() in trap.c, line 1584 checks only for pools
> of water.
Levitation side-effects get skipped if Levitation toggles while it
is blocked, so BFlying (the reason Flying is blocked) could become stale
in some situations. Enlightment feedback about latent flight capability
was the only thing affected.
From a bug report. The first report complained about levitation
allowing you to move through water on the Plane of Water, something that's
come up in the newsgroup lots of times (mostly about how levitation is
the best way to get around, only occasionally wondering why it works:
water walking doesn't work there because there's no surface, so where are
you levitating such that you're kept dry?) The second report complained
about being told you were floating up if you put on a ring of levitation
while stuck inside a wall (perhaps after being stranded when polymorph
into xorn form ended).
This implements intrinsic blocking for levitation and also for
flying. Being inside solid rock (or closed door) anywhere and being in
water on the Plane of Water are the things that do it for levitation;
those two and levitating are what do it for flying. Entering such
terrain turns off ability to float/fly, and leaving there turns it back
on; starting levitation blocks flight, ending it unblocks (levitation
has always overridden flying's ability to reach the floor). Being able
to phase through rock doesn't prevent levitation and flight from being
blocked while in rock; you aren't floating or flying in that situation.
Simplify many of the intrinsics macros from
#define xxx_resistance (Hxxx || Exxx || resists_xxx(&youmonst))
down to
#define xxx_resistance (Hxxx || Exxx)
by setting or clearing an extra bit in Hxxx during polymorph so that the
resists_xxx() check becomes implicit.
Unfornately there were lots of places in the code that treat Hxxx
as a timeout number--primarily for Stunned, Confused, and Hallucination;
Stunned happens to be one of the revised macros--rather than as a bit
mask, so this patch needed a lot more changes than originally antipated.
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.
Make being tethered to a buried iron ball be a bit more interesting
than just being stuck in the floor. You can now move within a shortened
chain radius (1 step from the ball's burial location rather than normal 2
that applies when it's on the floor). This has only been modestly tested,
and the message gets to be annoying if you move around a bit while monster
attack and object pickup/drop messages are being delivered. There ought
to be some better way to override Norep.
This would work nicer if the chain was actually visible at the ball's
location instead of becoming implicit at the time of burial. But I don't
want to try to figure out all the ramifications of having an object on
the floor which can't be moved--perhaps uchain handling already suffices,
but I suspect that there's a can of worms waiting to have its lid opened.
Pull the u.trap portion of domove() into a separate routine. The
only significant change is to the wording of a couple of TT_BURIEDBALL
messages. Like with enlightenment, say "you are <steed> are chained to
a buried ball" instead of "<steed> is chained to a buried ball" if you
try to move while mounted and punished and attached ball has been buried.
Unlike floor trap activation, punishment doesn't directly affect steed.
Using F prefix when trying to move into a wall or closed door yielded
"you attack thin air". Like the recently fixed F-vs-boulder case, give
more appropriate feedback. Also like F-vs-boulder, initiate digging if
wielding a pick-axe. (Also handles axes versus trees and closed doors).
One thing which isn't handled but possibly should be: F vs closed
door when not wielding a pick or other axe might attempt to force the door.
(Right now it gives "you harmlessly attack the door".)
Followup to yesterday's "you attack thin air" fix for when there's a
boulder at the target location: if wielding a pick-axe or mattock and you
use F to explicitly try to attack a boulder, dig the boulder to break it.
Also, treat statues like boulders: F at them gets "you harmlessly attack
a statue" for non-pick weapon, or digs/breaks statue when wielding a pick.
Classified as a new feature in the fixes file.
This is another item from "#Q397: List of Bugs from #nethack" sent
in Janurary by <email deleted> and containing a list
of things collected from the IRC channel associated with nethack.alt.org's
public server. Using F prefix and moving toward a boulder would give
"You attack thin air." Now that'll be "You harmlessly attack a boulder."
This is one of the items from "#Q397: List of Bugs from #nethack" sent
in Janurary by <email deleted> and containing a list
of things collected from the IRC channel associated with nethack.alt.org's
public server. Moving diagonally between segments of a worm tail is
conceptually passing right through the worm's body. This patch prevents
moving in such a fashion for both the hero and monsters (it's still
possible to fight in that position though). It only applies when the two
tail segments are consecutive.
|...... In the diagram here, where tail segments are represented by
|.w1?.. digits indicating relative sequence number, the @ can still
|..@2.. move between segments 2 and 5 to reach !, but can no longer
|.65!3. move between 1 and 2 to reach ?. [However, if there is a
|...4.. monster at the ? spot, it can still hit @ and vice versa.]
Missiles and wand zaps still pass through such diagonals without
noticing or affecting the worm. I'm not sure whether this ought to be
extended to change that--it might get pretty messy since it would need
to be considered during monsters' targetting as well as during the path
traversal itself.
From a bug report, you could swap places with a pet grid bug when
you're making a diagonal move. Now you can't. [Completely ignored: it
is possible to swap places with pets which are incapable of movement....]
This imposes the same restriction on the astral Riders when they're
exchanging places with monsters in their way.
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.
For GOLDOBJ configuration, relax the 52 object limit for inventory
when gold uses the special $ slot instead of a letter. Takes care of an
old buglist entry from the beta testers. [It will need to be revisited
if we ever implement multiple coin types that can't all fit in one slot.]
Also for GOLDOBJ, prevents nymphs and monkeys from stealing coins,
since allowing that made their steal-item attack be a complete superset
of leprechaun's steal-gold attack.
The patch made a month ago to handle remaining at a lava or pool
location without moving had a problem with being in pools of water. It
was yielding "But you don't drown. You touch bottom." if you had magical
breathing and took actions other than moves. I think it's fixed now.
[New bug, or rather newly noticed old bug: slowly sinking while being
stuck in lava doesn't notice if you lose fire resistance and ought to be
burned up immediately. Also, fully sinking into lava doesn't appear to
burn up equipment--unless it's done in the bones handling--the way that
falling directly in without fire resistance does.]
Instead of duplicating the bits of spoteffects() which are relevant
to pools of water and lava when standing still, split spoteffects in two
in order to call the relevant half directly.
<email deleted>, escaping from being stuck
by lava via jumping--or simply walking--got you out of the lava while being
at the same location. You could then stay there for as long as you liked
without falling back in. This makes a lava and water check on turns where
time passes but hero hasn't moved, performing a subset of spoteffects().
I think the water case only matters when using wizard mode to wish for a
pool or moat, which gets created at hero's feet without making him fall in
(unlike wishing for lava, where hero does immediately fall in).
From a bug report: when riding,
#jump command and jumping spell didn't check whether steed is able to move.
This makes #jump command, either magic boots or knight's innate ability,
fail if the steed can't move. Spell still succeeds; its magic overrides
steed's immobility. Fix is trunk only since it relies on a function that
isn't in the branch.
Also, tweak hero movement to avoid an extra function call per move
when not riding.
<email deleted>:
> If you enter a magic trap on the same turn that you lose your levitation
> and "float gently to the floor", you are hit by the trap twice.
I don't think this is actually a bug, but it does look fairly strange
if there aren't any monsters attacking (after you move on to the trap,
monsters get a chance to move too before timeouts are run, but if there
aren't any messages triggered by monster activity then it feels like the
timeout and second activation happens immediately). To prevent this, if
levitation is due to time out on the same turn that a trap is being
entered, either extend the duration by an extra move or make it end
immediately instead of waiting until end of current turn. Deferring
timeout is a lot easier but doing that unconditionally would allow player
to move back and forth between adjacent traps without ever descending.
The early timeout might lead to anomalous behavior in obscure cases; it
seems to be working ok so far though.
From the newsgroup: it was possible to saddle, mount, and ride on a
sleeping jabberwork without it ever waking up. Movement was checking for
timed sleep (!mon->mcanmove, set when mon->mfrozen contains a timer count
for either sleep or paralysis) but not indefinite sleep (mon->msleeping).
This moves the checking into its own routine which handles both types.
And it gives monsters a chance to wake up when they get saddled or mounted.
Mentioned by <Someone>, who suspected that the fix for C343-114 dealt with
this. When a giant picks up a boulder from a location where more than one
is present, line-of-sight would be inappropriately cleared, as if the
remaining boulders were transparent. (He said that he got no pickup
message when the giant picked up the boulder. I do, and have not tried to
figure out whether this is a post-3.4.3 difference.) Pushing a boulder
onto a landmine had the same bug, although you wouldn't notice unless there
were at least three boulders to be pushed (mysterious ability to push more
than one boulder in a turn strikes again: first one triggers the trap and
is destroyed, allowing hero to see through any others; second fills in the
resulting pit; third gets moved to the former trap spot and [probably--I
haven't checked] re-blocks vision; fourth, if any, stays put; if only one
or two are present, the change in vision is expected and the fact that it
happens too soon in the two boulder case would probably go unnoticed.
Polymorph of a boulder also opened up vision without checking whether any
others are present.
An existing, evidently overly optimistic, fixes34.4 entry covers this.
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.)
