This finally eliminates all direct increases of `oeroded` and `oeroded2`
and moves them all to go via `erode_obj()`. They are still manipulated
directly in a few places, but not to erode objects.
This now merges the `fire_damage()` function to a common codepath, used
for items on lava and burning oil, but fire needs more work. There is
still a duplication between `destroy_item()` and `fire_damage()`; the
two codepaths should eventually be merged in some manner so that there
is only one codepath to say "an object was affected by fire". This path
might require some parameters, such as whether the fire will just erode
objects or burn them outright, but that can happen another day.
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.
Introduce some variation in monster movement by adding and substracting
small random amounts to the fixed increment from the main monster table. The
amount added is potentially bigger (average is +2) than the amount substracted
(average is +1), so monsters will tend to be slightly faster. Probably not
noticeable except for super-slow monsters not being so glacially slow, since
net +1 is a bigger relative increase for such critters' low movement rates.
In practice, the noticeable effect will be that ordinary speed monsters will
occasionally get an extra move even if/when player keeps the hero unburdened.
Possible extension (although I'm not planning to do it): sort the
monster list by pending movement points, so that faster monsters move before
slower ones. The random variation would become noticeable because groups of
same-speed monsters would alter their movement order depending upon who got
a bigger increment or smaller decrement on that turn.
Fix several obscure bugs that can happen when a guard leads someone
out of a vault:
1) non-pit traps created in the temporary corridor would persist inside
solid rock after the corridor was removed (pits dug by the hero were
explicitly removed but several other trap types are possible);
2) lighting the corridor with scroll/wand/spell left the affected spots
flagged as lit after they reverted to rock; tunneling through that
area, either by digging or by teleporting back to the vault and having
another guard appear, unearthed lit corridor there;
3) if you became encased in solid rock because you were in the temporary
corridor when it was removed (which will happen if the guard is killed
while you're in his corridor), you were only told so if you saw part of
it revert to rock; when blind, you simply found yourself unable to move;
4) dragging an iron ball in the temporary corridor could result in part
of that corridor becoming permanent if the guard was killed; in 3.4.3,
it would only occur if the cause of death took away all the guard's
hit points (which happens for most but not all deaths); in development
code after my recent patch, that would be every cause of death.
#4 could also yield "dmonsfree: <N+1> removed doesn't match <N> pending"
warning in 3.4.3 when the fmon list was scanned and a guard at <0,0> with
no hit points was found but hadn't passed through to the end of mondead()
and m_detach(). The previous patch fixed that, I think/hope. Most guard
deaths won't trigger that; grddead() moves the guard to <0,0> but then
removes the temp corridor on its second try, returns true, and mondead()
finishes normally.
From the newsgroup: after killing a vault guard on a level where
every object had been removed or was held by the hero, object detection
gave feedback about finding something but was unable to show anything.
It was finding the dead guard's inventory at <0,0>, a part of the map
which never gets shown. A dying guard is sent to that location instead
of being killed and deleted, because the data for his temporary corridor
to/from the vault is kept in the egd structure attached to him. That's
somewhat obscure but works; dying guards just need to drop inventory
before being transfered there rather than after.
Depending upon how they're killed, it's possible that the umpteen
places in the code that loop over fmon might have been processing them
as if still in play. This sets their mhp to 0 so such loops will ignore
them, and teaches dmonsfree() not to release them. Once the temporary
corridor has been removed, their isgd flag is cleared and they become
ordinary dead monsters and get deleted from the fmon list the next time
it's purged.
This also lets you throw gold to/at the guard when he tells you to
drop it. He already would catch it, but now he won't treat the throw as
an attack. Any gold he carries will eventually disappear when he does,
so dropping it remains a better option for the player.
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.
Rename ``kickobj'' to ``kickedobj'' so that the tense matches that
of ``thrownobj''. Also, move their declarations to decl.h and their
definitions to decl.c since usage has spread from dokick.c/dothrow.c to
various files and is about to expand to another one.
A mimic posing as a statue was displayed as a tengu statue (and
recognizeable as such now that statues are displayed as the corresponding
monster rather than rock-class back tick), but the lookat code described
it as a giant ant statue (since there was no obj->corpsenm available to
indicate the monster type, it defaulted to 0). This adds monst->mextra
field `mcorpsenm' so that mimics have a place to remember what sort of
statue or corpse they are mimicking. And it picks a random monster type
when they take such forms so that the old tengu hack becomes irrelevant.
newmextra() and newoextra() initialized pointers via memset(...,0)
which is not portable; switch to explicit assignments. The wizard mode
code to display memory used for monsters and objects added in amounts
for the miscellaneous things pointed to by monst->mextra and obj->oextra
structs but didn't include memory for those structs themselves; add it.
Simplify monster save/restore slightly; there's no need for extra zeroes
to represent monst->mextra->X sizes when monst->mextra is null.
Update the startup banner for 2009. I should have done this with a
separate patch but I'm taking a shortcut. :-]
I) When testing the shopkeeper polymorph fix a couple of days ago, I
tried to pick a form without a head (which is now rejected for shk) by
specifying "trapper" via #monpolycontrol. It worked, in the sense that
the shopkeeper didn't take that form, but it also retried with "lurker
above". After trapper was rejected, it matched "trapper or lurker above"
for monster class and picked at random from that class (and in this case,
the second try was rejected for being headless too). The code I added
(a couple of years ago?) to prevent picking invalid forms for vampire
shapeshifting was a bit sloppy with its retry attempts.
II) I also noticed that monpolycontrol would let you pick forms that
newcham subsequently rejected, like placeholder monster "giant", so that
select_newcham_form got called again, resulting in a new prompt from
monpolycontrol to choose a form without seeing any explanation why the
first try was ignored. Now you'll get the same "it can't become that"
feedback and immediate reprompt as for an invalid monster, instead of
returning newcham a form that it won't accept.
III) The change in shopkeeper polymorph was rejecting forms without hands.
That was way too restrictive; the notake() filter is sufficient.
This is all modification of post-3.4.3 stuff, so no fixes entry.
[Not 100% true. newcham() doesn't explicitly reject humans anymore,
relying on polyok() test instead. Kops are the only humans who pass it.
If they're not supposed too, they need M2_NOPOLY in their definition.]
From a bug report, a shopkeeper who's been
polymorphed into a limbless creature shouldn't be able to come take your
possessions when you die since you can't pick up items when in that shape.
Rather than add new special case handling for shopkeepers, prevent them
from taking on shapes that render them unable to behave like shopkeepers
so that they can continue to catch thrown pick-axes and assorted other
things that would otherwise need a lot of extra checking introduced.
Ditto for temple priests, vault guards, and quest leaders. Restriction
also applies to wizard mode use of #monpolycontrol, the only place where
players can actually notice this.
It could--perhaps should--restrict them even further, forcing forms
that retain speech capability, but I didn't go that far.
From the newsgroup: hero's steed can become untame if killed while
it is wearing an amulet of life saving, leaving the hero still mounted
and resulting in repeated "placing steed onto map?" warnings when the
steed tries to move. Force the hero to be thrown off the mount in that
situation.
From a bug report, pets able to eat
acidic and poisonous corpses (black naga was the case cited) would eat
green slime corpses without turning into green slime, unlike the hero.
This prevents such monsters from eating green slime unless they're
starving, implements transformation into green slime for the case where
it does get eaten, and prevents non-pet gelatinous cubes from devouring
such corpses. meatobj() is reorganized to hopefully become clearer, and
it removes the assumption that the object eater is a g.cube in case we
ever adopt slash'em's "tasmanian devil" monster.
Monsters with digestion attacks who swallow green slime monsters
are turned into green slime, but ones who swallow hero poly'd into green
slime are not. This doesn't address that.
From a bug report: an exposed eel in an isolated
pool--swamp rooms sometimes produce those--would never re-hide no matter
how long you left its vicinity. Re-hiding is part of post-move handling
and an eel with no adjacent water to move into would never reach that bit
of code since it didn't move anywhere. The code used to re-hide monsters
when you return to a previous level was ignoring eels altogether. Give
unhidden eels a chance to hide earlier during monster movement and also
when the hero returns to their level.
Also a really minor bit to slow down hit point loss of eels out of
water. I don't think anybody reverse genocides krakens to get experience
any more since they don't provide a big bonus when they're out of water,
so this change won't have much of an affect.
I was testing something with #monpolycontrol enabled and got a
series of "Change it into what kind of monster? [type the name]" prompts
when I went to a new level. It was asking about monsters that were being
created (in this case, multiple vampires for top level of Vlad's Tower)
and naturally I couldn't see them since the level wasn't finished yet.
This switches to noit_mon_nam() to at least be informed about the type
of creature you're being asked to specify a shape for, and adds the map
coordinates so that it doesn't appear to be reprompting for the same
monster over and over when multiple similar ones are being created.
In the process I discovered that #monpolycontrol would let you give
any type of monster for the shape of vampires. Unlike chameleons, they
don't change into arbitrary shapes so that was inappropriate. [And
trying to test the fix for this is what led to the previous ^G patch.]
Get rid of most of the vestiges of the old warning code that was
replaced over 7 years ago. I left the list of colors which were used for
warning flashes.
From the newsgroup: objects created when killing a monster over
water weren't being affected by falling into the water. The objects were
being created directly on the floor instead of being dropped as if they'd
been in the monster's inventory. This fixes the random "treasure drop"
item, but special items--like dragon scales and the miscellaneous golem
remains--produced by make_corpse() are still put directly onto the floor.
The check to prevent small monsters from dropping big objects was
overly complex, possibly due to the 3.1.x weight threshold bug which was
just recently fixed. Food rations and leashes pass the weight test so
don't need to be special cased; spears, polearms, and morning stars fail
the weight test. (Javelins are an exception; they pass the weight test
so are allowed to be dropped by small monsters now since spears aren't
special cased any more.)
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.
From an entry in $cvsroot/shared/bugs/buglist From a bug report:
when item weights were all scaled up by a factor of 10 for 3.1.0, the
code controlling random item drops by monsters still limited small ones
to dropping things of 3 weight units of less. Scale that up to 30.
From a 7.5 year old news posting (with a reply by Kevin Hugo speaking
on behalf of slash'em...): when a monster "nimbly jumps to evade" hero's
kick, it can pass through walls and grid bugs can jump off their grid.
Likewise when a joust or staggering blow knocks a monster back, it could
move grid bugs diagonally. This fixes both cases.
Offhand I can't think of any other non-standard movement situations
which might need similar handling, but it wouldn't surprise me if there
are some. Leashed movement is close but I don't think maybe_mnexto helps.
From a bug report, mimics
which were exposed at the time the hero leaves a level remain unhidden
upon return no matter how long the hero is away. It was actually expected
behavior since the old level is stuck in stasis and hiders only hide when
it's their turn to move, but it was noticeably odd. This makes unhidden
hiders attempt to hide when hero returns to a previous level or enters a
bones level. I reorganized the monster handling in getlev() because the
relevant part was taking place before floor objects got restored, so
hidesunder() monsters had nothing to hide under at the time.
My last fix from the Dec'04 report sent by <email deleted>. Many of its remaining observations/complaints are
about things which aren't bugs. This implements the suggestion that
doppelgangers should take on humanoid form, although it doesn't take away
the 1/7 chance for pick_nasty() and it can still fall back to arbitrary
shapes when it doesn't pick a humanoid within 5 tries. This also allows
doppelgangers to take on the shape of the various quest guardian monsters
[mostly the quest leaders' attendants, although there is at least one
extra foe (ninja)]. It excludes the quest guardian for the player's own
role, and I don't think there are any cases where it can yield unexpected
quest guardian behavior.
This also allows specifying monster class (via description or letter)
when #monpolycontrol asks for type of monster to give to a polymorphing/
shapechanging monster.
<email deleted> reported a long list
of inconsistencies and suggestions. This attempts to address the ones
about werecritters and vampires.
> Polymorphed player does not get werecreature changes. (intentional?)
> Player in were form does not turn into werehuman form, ever. (Previous
> bugged behavior was that player turned into a plain human)
> Player afflicted with a were cannot polymorph into werecreature or
> werehuman form.
The first guess is right; being polymorphed blocks lycanthropy state
changes. The second is not a bug either; hero is either a <werecritter>
when in beast form or a <role> when in human form, never human werecritter
monster. The last one feels more like a bug though; it happened because
all lycanthrope monster entries are marked NOPOLY. This patch extends
an earlier post-3.4.3 change to allow player with polymorph control to
explicitly specify werecritter when in role form or human werecritter when
in beast form to toggle shape. It also allows closely related monsters
to toggle from role to beast (ie, "giant rat" yields wererat).
> Vampire or Werecreature changing form may change sex.
Now the three semi-controlled changes--becoming a dragon due to armor,
toggling were form, and vampire into various critters--are prevented from
having the 10% chance of sex change kick in. For monsters, lycanthropy
didn't apply (sex never toggles) and vampire shifting is now covered but
turning into a dragon due to scales/mail remains susceptible to sex change.
Also, post-3.4.3 code made polymorphing into a vampire enable the
#monster command but neglected to tell the player.
Reported two months ago by <email deleted>,
having a water elemental become trapped in a bear trap seems pretty
strange. Fixed by marking water elementals as M1_UNSOLID (like air and
fire elementals), which has a side-effect of making them immune to webs
as well. Tweaked some unused digging code which checks unsolid(), added
unsolid() to the types allowed to bar through iron bars, and brought the
check for whether a monster is willing to enter a bear trap location up
to date. That code also needed an update to reflect the change made to
anti-magic traps last year. Lastly, there was another report which
suggested that being hit by a bear trap should dish out some damage
(along with a suggestion that wand of opening should work to escape such
traps, which has already been done). This makes bear trap do 2d4 damage
(on entry, not when trying to pull out after becoming stuck).
Prevent monster with barge-through capability--currently only the
astral Riders--from swapping places with another monster which has that
same capability. Otherwise, if the target one moves after the barger,
it might just repeat the maneuver, undoing the first swap. If there's
no room to move anywhere else--maybe they've barged through a crowd into
a narrow spot--they could get stuck swapping and re-swapping every turn.
I've also allowed swapping with baby long worms and with adult ones
which lack a tail. When testing that, something strange happened and
the displacer was drawn on the map as a long worm tail. mdisplacem()'s
place_worm_seg() must have been responsible, but I don't understand how
the bit of code involved could kick in for a worm without tail segments.
I've reorganized mdisplacem() to avoid this occurrence, I hope....
Also, barge-through swapping with a mimic exposes it as a mimic;
swapping with an eating pet causes the meal to end. No fixes entries;
this is post-3.4.3 code.
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).
From a bug report: gelatinous cubes
could engulf Rider corpses, allowing g.cube and cargo to be teleported
away without triggering corpse revival, or to be hit with theft attack by
poly'd hero to get the corpse into inventory so it could then be put into
a container in order to prevent revival (or to be destroyed via bag of
holding explosion or cursed access).
From a bug report: a shapechanger
which becomes a mimic would always stay as 'm' rather than take on object
or furniture shape. Same applied to monsters which hide in other ways.
The code did that deliberately, but I don't think that it's actually
necessary so this lets them mimic/hide when they're in the right shape.
If they change form to non-mimic/hider while concealed, concealment ends.
It would be fun to have shapechangers-as-mimics actually change their
mimicked shapes periodically, but this doesn't do that. They'd probably
change to non-mimic quicker than they'd mimic something else so it's not
worth the effort.
[See cvs log for src/cmd.c for more complete description.]
This turns clearlocks() into a no-op during the period when the UNIX
port is asking the user to confirm whether to overwrite an existing game.
Also, this removes the duplication of code and function between hangup()
and end_of_input(), and it simplifies the check for whether hangups are
supported by adding new macro HANGUPHANDLING. (I don't think global.h is
the best place to be defining that but I couldn't figure out where else
it would fit, other than repeating for individual xxxconf.h files.) And
adds a couple more done_hup checks to try to cope with situations where
rhack() is being bypassed. Lastly, having readchar() return EOF was
ignored for non-UNIX configs; now everybody gets ESC instead of letting
EOF be seen further inside the core.
High resistance made the Riders unlikely to be polymorphed, but
they were susceptible to being turned into green slime (and then never
reviving if killed in that state). Now they'll be immune to both types
of transformation.
From the newsgroup: if a pet was hiding under an object next to you
when you changed levels, it could arrive hidden at the destination if there
was something available to hide under there too, and sometimes you'd start
the new level with a hidden monster glyph at its location. I was able to
reproduce that once with current trunk code, but while trying to figure
out what is actually happening I've been unable to make it happen again.
However, it doesn't make sense for a monster to be able to remain in hiding
during the level change in the first place, so this patch prevents that.
(I'd still like to know how/why map_invisible() is sometimes getting called.
[The test character was a level 1 tourist without auto-search capability.]
I'm reasonably sure that it won't happen any more once this fix in place.)
This also brings adjacent pets out of hiding when they accompany you
during ascension or dungeon escape, but it seems that that wasn't actually
necessary. The end of game disclosure already lists such by name rather
than as "it", contrary to my expectations. (I had forgotten that end-of-
game forces true names so that blindness and hallucination don't interfere
with disclosure; obviously that ends up handling hidden monsters too.)
More explicit control over the behavior of spoteffects() is probably
the way to go in the long run, but this much simpler fix handles the case
at hand. I'm not sure what `thrownobj' was intended to be used for in the
first place, but it came in handy here. (It was being left as a dangling
pointer when thitmonst() reports that the missile has been used up; that's
fixed now.)
Fix the reported problem of lookhere/autopickup not seeing the missile
which just killed the engulfing monster whose death caused the hero to be
put back onto the map and so look/pickup upon arrival. Normally the missile
gets placed after damage has been dealt and the throw has finished. This
overrides that so that the missile is put into the engulfer's inventory as
it is being killed (which will then put that inventory onto the floor prior
to expelling the hero on top of same). If the monster happens to get
life-saved it just ends up collecting the thrown-from-inside object a little
sooner than usual.
This wouldn't correctly handle the same case for a kicked object, if
that were possible. But it isn't possible to kick objects while engulfed,
so that's moot. Other calls to thitmonst() and hmon() don't appear to have
any objects in transit so shouldn't need any comparable fix (I hope...).
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.
Give demon lords and other monsters who teleport to your location a
oneshot arrival message. Brought about by the report of the late "<demon>
appears" message delivered during its bribery demand, after the character
had already been able to see it for long enough to extract gold from a bag.
Now, if you can't see or sense a monster before it teleports to you, and
you can see or sense it after, you'll get "<monster> suddenly appears!".
The message will be given at most once for any given monster, and it won't
be shown at all if you already see/sense the monster before it teleports or
still don't see/sense it afterwards. The fixes entry is deliberately a bit
vague (and I put it in the new feature section rather than the fix section).
The change from long to unsigned long for monst.mstrategy may bring
some lint complaints along with it. The various constants (STRAT_xxx) used
to populate it are still signed. I didn't increment EDITLEVEL for this;
existing data should still work ok.
