nethack.rankin [Mon, 20 Aug 2007 00:05:24 +0000 (00:05 +0000)]
re-fix #H1371 - dead monster fleeing
From a bug report, a monster which
died by moving into a trap which was next to the hero standing on Elbereth
resulted in "The <mon> is killed! The <mon> turns to flee!". An earlier
change made monflee() return if it's given a dead monster, so the fleeing
message is no longer given. This fixes the place where monflee() was
inappropriately being called for a dead monster in the reported situation.
nethack.rankin [Thu, 9 Aug 2007 03:20:24 +0000 (03:20 +0000)]
tin access (trunk only)
From the newsgroup:
The tin opens like magic!
<some interruption occurs>
You stop opening the tin.
Either it opens immediately or it doesn't, so the "opens like magic"
message is inaccurate. Rather than simply changing the phrasing, this
gives blessed tins a 50% chance to really open immediately so that their
contents are available for eating on the same turn, and 50% to behave as
before but with a message which is suitable for the single turn delay.
Hero poly'd into a metalivore always gets the same-turn case when eating
any tin. Use of a tin opener has a chance to do so (always when blessed,
50/50 for same-turn vs 1 turn delay when uncursed, 33/33/33 same-turn or
1 or 2 turn delay when cursed).
Overall, blessed tins are better than they used to be, since half
of the time you'll save a turn, but they're still not reliable to eat in
the midst of combat since sometimes you'll need another turn and will be
likely to get interrupted in that situation. Uncursed tin openers still
give the same behavior as opening blessed tins, so are also better than
they used to be. Blessed tin openers are now superior, and cursed ones
are slightly inferior in addition to being welded to hero's weapon hand.
nethack.rankin [Fri, 3 Aug 2007 01:05:50 +0000 (01:05 +0000)]
fix #H1232 - hole in ice is described as moat [1 of 2] (trunk only)
From a bug report, when ice on the Valkyrie
quest home level was melted and a boulder filled the resulting pool, that
pool was described as a moat. This was actually a terrain issue rather
than a formatting glitch, so instead of tweaking waterbody_name() with an
extra special case, extend the level compiler to allow specifying ice as
frozen pool instead of always being frozen moat. There's no provision
for having both types of ice on the same level, just a level-wide flag to
control which of the two applies for ice on that level.
This change has a side-effect for the V quest levels: once ice has
been melted, a second blast of fire will now boil away the pool and leave
a pit. The unfrozen water locations on the home level already behaved
that way (ie, they are pools rather than moats) so this should be ok. I
also added <Someone>'s suggestion to make one of the two drawbridges
on the goal level start in random state instead of always being open.
Michael pointed out what needed to be fixed in order to change gold
on rogue level from regular "$" back to intended "*". This was post-3.4.3
code so no fixes entry needed.
Fix the crash From a bug report, where
having the hit that cuts a long worm into two also take the original down
to 1 HP would result in clone_mon() returning null and nethack crashing due
to a segmentation fault or access violation. The same thing could happen
if there's been enough long worms created to get them flagged as extinct.
This bug was only present in 3.4.3. Prior to that, cut_worm() did
its own monster creation inline instead of calling clone_mon(), ignoring
extinction and too-low hit points.
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".)
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.)
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.
ansimpleoname() and siblings always reported statue and figurine
type to be "of a giant ant" because the corpsenm field was left as 0.
Explicitly set it to -1 in the minimal object and teach xname() to leave
off the monster type in that situation, yielding just "a statue" or "a
figurine". [It's tempting to classify this as an xname() bug since other
object types which use corpsenm do so in doname().] No fixes entry; this
is post-3.4.3 code.
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 the newsgroup: you could get "suddenly you cannot see the <mon>"
even though it remained visible. Cited case was for an orc who drank a
potion of invisibility while being observed by a hero wielding Sting, which
causes orcs to be displayed even when they're invisible. But it could also
happen when non-blind telepathy or extended monster detection is in effect.
"fix" #H894 - reading mail violates illiterate conduct (trunk only)
From a bug report, reading a scroll
of mail violates illiterate conduct and he requests that it not do so.
I didn't go that far, since unlike needing to read the Book of the Dead
to be able to finish the game, reading scrolls of mail is completely
voluntary and someone attempting voluntary challanges can choose not to
do it. Instead, this issues a prompt to require confirmation if reading
such a scroll will be the first violation of that conduct. Ordinary
players can answer no and then use '!' to read mail from a shell. I'm not
sure what'll happen to players on public servers who aren't given access
to a shell. Usually they wouldn't be able to get mail either, so more
elaborate servers like the one at nethack.alt.org which allow players to
use mail to communicate with each other will have to come up with their
own solution (perhaps by providing a mail-reader-only shell).
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.
nethack.rankin [Fri, 29 Jun 2007 01:18:51 +0000 (01:18 +0000)]
fix #H620 - dangerous/disruptive strings in bones data
It's possible for the player to put escape sequences into strings via
dogname/catname/fruit options (or probably interactively by using "\233"
instead of "\033["--the two character 7-bit version wouldn't work because
its leading ESC gets treated as player's request to abort current input,
but the 8-bit version probably works, I just can't test it because I don't
know how to type such things with this terminal emulator). Such sequences
can do funny things like clear the screen and say "game over" (or worse
with creative abuse of some terminals' "answer back" capability--when
reproducing the reported situation, I kept things simple and had my dog's
name underlined and fruit name blinking; they displayed correctly but
nethack was confused about how long they were since it doesn't expect to
be given characters which don't advance the cursor). This fix still lets
users experiment with such stuff during their own games, but it replaces
suspect characters while loading bones data, so if one player creates a
bones file with suspect strings in it, another can--I hope--be able to
use that file safely.
Monster and object names, engravings, and named fruits are handled.
For the last, if uncensored string matches one already present then it
leaves that alone, so bones data created with same OPTIONS=fruit:whatever
as being used in the current game will continue to keep the same value.
nethack.rankin [Tue, 26 Jun 2007 03:10:39 +0000 (03:10 +0000)]
couple of DUNGEON_OVERVIEW fixes (trunk only)
New hero would remember part of old one's terrain discoveries (such
as presence of fountains) for bones levels. Also, some topology changes
(such as fountain destruction) can be detected by touch while blinded but
dungeon overview continued to remember the old feature. Post-3.4.3 code.
nethack.rankin [Thu, 21 Jun 2007 02:35:30 +0000 (02:35 +0000)]
Amulet-covetting monsters attack Wizard
Another entry in $cvsroot/shared/bugs/buglist, this one reported by
<email deleted>: if the Wizard had the Amulet and used
his "double trouble" spell, his clone would attack him in order to try to
get the Amulet. This prevents any monster who's after the Amulet from
attacking the Wizard to get it.
nethack.rankin [Thu, 21 Jun 2007 02:15:26 +0000 (02:15 +0000)]
very old death drop bug
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.
nethack.rankin [Thu, 21 Jun 2007 01:32:41 +0000 (01:32 +0000)]
more precise dipping prompt (trunk only)
Someone in the newsgroup accidentally dipped the wrong item into a
fountain and wants the second prompt to be "Dip <obj> into the fountain?"
instead of just "Dip _it_ into the fountain?", hoping that he would have
noticed that he had selected the wrong object. I think he's fooling
himself there, but this gives a brief object name for fountain, pool, and
potion prompts.
nethack.rankin [Tue, 19 Jun 2007 03:58:36 +0000 (03:58 +0000)]
drowned in a moat on the Plane of Water (trunk only)
From the newsgroup: drowning on the Plane of Water gave cause of
death as "drowned in a moat". There was already some post-3.4.3 code to
handle naming of moat on Juiblex level as "swamp", but it wasn't used for
drowning's cause of death and we were still getting "drowned in a moat"
there too. Now the Plane of Water yields "drowned in deep water" and
Juiblex's level yields "drowned in a swamp".
nethack.rankin [Tue, 19 Jun 2007 03:13:20 +0000 (03:13 +0000)]
WIZKIT overflow tweak (trunk only)
Redo the $WIZKIT overflow handling from a few days ago. Instead of
having two migration codes which both mean "with the hero", combine them
and add a mask flag to control scattering at the destination to be able to
get the alternate behavior.
nethack.rankin [Sat, 16 Jun 2007 04:18:14 +0000 (04:18 +0000)]
WIZKIT inventory overflow (trunk only)
Wizard mode's $WIZKIT can specify an unlimited number of items to
add to starting inventory and they'd be put there without regard to the
number of slots in use, potentially resulting in an arbitrary number of
'#' slot items. Cap at 52 slots, same as when picking up, and put any
excess items at the hero's feet. It's slightly tricky because the level
hasn't been created yet at the time the wizkit gets processed.
nethack.rankin [Sat, 16 Jun 2007 02:22:01 +0000 (02:22 +0000)]
GOLDOBJ pickup handling (trunk only)
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.
nethack.rankin [Sun, 10 Jun 2007 03:01:31 +0000 (03:01 +0000)]
fix #H348 - "you trip over it" after non-"it" message (trunk only)
Reported to us by <email deleted>:
'You are beginning to feel hungry. You trip over it.'
and also recently in the newsgroup by "<Someone>":
There is ice here. *You see here an electric eel corpse.*
Bib hits the electric eel. Bib misses the electric eel.
Bib misses the electric eel. The electric eel misses Bib.
The electric eel misses Bib. *You trip over it.*
slip_or_trip() was oversimplifying things by assuming that if there
is one object at the hero's location, a message about what that object is
has just been given. Any timeout message which precedes Fumbling (lots
of candiates besides hunger) could intervene, as could monster activity
between the hero's move and timeout handling. Aside from the reported
cases, that code hadn't been updated to account for the new pile_limit
option which could be set to 1 and force a popup display instead of the
usual "you see <an item> here". This fix adds a flag that can be used
to track the most recent message. It is cleared by pline for every
message, so pline's caller sets it _after_ the message of interest has
been displayed.
nethack.rankin [Tue, 5 Jun 2007 02:45:09 +0000 (02:45 +0000)]
#adjust bounds bug
Noticed while looking at something else: doorganize() goes out of
array bounds for alphabet[] when inventory contains something in the '#'
slot, or in the '$' slot for GOLDOBJ config. Both # and $ pass the
(let <= 'Z') test, then produce a negative result for (let - 'A' + 26).
In my case, it was harmlessly clobbering the tail end of buf[] but it
could potentially be a lot worse.
nethack.rankin [Sun, 3 Jun 2007 02:33:34 +0000 (02:33 +0000)]
igniting unpaid potions of oil (trunk only)
From another many year old news posting: if you picked up a stack
of potions of oil in a shop and then applied them, one potion was split
off and started burning but you were forced to pay for all of them.
Split the to-be-lit one off first so that the remainder of the stack
stays as ordinary unpaid shop goods.
This also fixes an old bug with bill_dummy_object sometimes charging
a different price than the player got quoted when an object was picked up.
nethack.rankin [Sun, 3 Jun 2007 01:05:43 +0000 (01:05 +0000)]
Heart of Ahriman hack (trunk only)
From a four year old news posting: hero was levitating via #invoke
on the Heart of Ahriman, then dropping that artifact yielded:
You drop a gray stone named The Heart of Ahriman.
You float gently to the floor.
A gray stone named The Heart of Ahriman hits the floor.
That might be strictly correct, assuming that both hero and stone fall at
the same speed; if the stone was dropped from perhaps waist height then
the hero's feet would touch first. But it looks strange, like a cartoon
where something hangs in midair until someone notices that it should fall.
Removing the artifact from inventory causes the #invoke property to
toggle off. Unfortunately it has to be done here before the object can
be placed at its destination. Modifying message order seemed unviable;
this fix fiddles with the Levitation property in order to defer hero's
descent until after object handling is finished. Now same setup gives:
You drop a gray stone named The Heart of Ahriman.
A gray stone named The Heart of Ahriman hits the floor.
You float gently to the floor.
You see here a gray stone named The Heart of Ahriman.
nethack.rankin [Sat, 2 Jun 2007 23:30:57 +0000 (23:30 +0000)]
astral high priests revisited (trunk only)
Prevent remote ID of the three high priests on the Astral Plane via
wand of probing or via their own actions (observing "high priest of Foo
drinks a potion of speed" and so forth). When not immediately adjacent,
you'll get "the high priestess" instead of "the high priestess of Foo".
nethack.rankin [Sat, 2 Jun 2007 23:18:56 +0000 (23:18 +0000)]
punctuation tidbit
The prompt to a hero with lycanthropy and polymorph control about
whether to change into beast form had an extra space between the question
and the [yn] answer choices.
nethack.rankin [Sat, 2 Jun 2007 22:00:29 +0000 (22:00 +0000)]
monst vs steed tidbit
I came across an old bug report which stated that steeds missed out
on their chance to counterattack if the hero had just taken some action
other than moving.
[1: monster attacks steed instead of hero ]
[2: if monster died while attacking, return 1 ]
if (i & MM_DEF_DIED || u.ux != u.ux0 || u.uy != u.uy0)
return (0);
[4: otherwise, steed counterattacks monster ]
Sometime since whatever version the 2001 report was for, but before the
current cvs repository was set up someone addressed this by changing it
to be
if (i & MM_DEF_DIED || !u.umoved)
return (0);
but I think that fixed the wrong thing. I believe that the original code
was attempting to make sure that the steed was still in position to be
able to counterattack. There's no reason to care about the hero's most
recent action; he had to have done something that caused time to elapse
in order for the other monster to have initiated an attack in the first.
(The new range check is actually redundant; mattackm() also enforces it.)
nethack.rankin [Thu, 31 May 2007 01:42:48 +0000 (01:42 +0000)]
fix #H363 - reviving corpses of hiding monsters (trunk only)
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.
nethack.rankin [Tue, 29 May 2007 03:52:02 +0000 (03:52 +0000)]
unicorn horn vs sustain ability (trunk only)
Forwarded from newsgroup by <Someone> in February, 2005: non-cursed
unicorn horn fixes lost Str/Con/&c stats even when ring of sustain ability
is supposedly locking those at current value. This makes unicorn horn
honor the Fixed_abil intrinsic. The potion and spell of restore ability
still override that, so they now have potential for use even after player
has acquired a unihorn. Prayer also continues to override Fixed_abil.
Major prayer result to heal crippled strength now attempts to uncurse a
ring of sustain ability (or gloves or weapon covering it up--similar
situation as with cursed levitation). Minor prayer result to fix lost
stats resets those without attempting to do anything about Fixed_abil.
nethack.rankin [Tue, 29 May 2007 02:51:47 +0000 (02:51 +0000)]
dull spellbook (trunk only)
Something else <Someone> forwarded from the newsgroup long time ago:
attempting to read a dull spellbook ought to have a chance of making the
hero fall asleep.
nethack.rankin [Tue, 29 May 2007 02:00:25 +0000 (02:00 +0000)]
Hallucination vs gaze attacks (trunk only)
Suggested by <Someone> in March, 2005 based on newsgroup discussion
at the time: hallucination protects against touch of death attack by
disrupting how the hero's brain reacts, so why not against gaze attacks
too? This gives hallucinating hero 75% chance of being unaffected by
gazes. If unaffected or if the gazer has been cancelled, the gaze will
fail with some feedback. Previously, all cancelled gazes failed but only
Medusa's gave feedback.
This will give players another way to defeat Medusa, but since it
isn't foolproof and there are several sure fire ways already, I don't
think it'll hurt play balance there. It may be useful to avoid getting
repeatedly stunned by Archons though.
nethack.rankin [Mon, 28 May 2007 03:30:26 +0000 (03:30 +0000)]
makeplural/makesingular vtense fix (trunk only)
"The death ray hit it." Changes to vtense() during the makeplural
makesingular overhaul four weeks ago contained a typo, or rather a set of
matching thinkos.
nethack.rankin [Mon, 28 May 2007 01:35:25 +0000 (01:35 +0000)]
engulfing at dangerous location (trunk only)
From a bug report, 2005:
engulfers affected by conflict might swallow and kill monsters in pools
(not mentioned: or lava or traps) and move to that spot, then not drown
til next move. Make drowning and trap checks when engulf attack succeeds
instead of waiting for next turn.
[This was #2 of the 3 minor bugs; the others have already been fixed.
They were: (1) placing and exploding a land mine on a lowered drawbridge
would leave a pit instead of destroying the bridge; and (3) cause of death
string "killed by Mr. Izchak, the shopkeeper" should omit "Mr.".]
nethack.rankin [Mon, 28 May 2007 00:20:43 +0000 (00:20 +0000)]
confirmation for polearm attacks (trunk only)
From a bug report, 2005: applying a
polearm towards a monster ignores the `confirm' option. It's a wielded
weapon attack but is handled internally as a throw since it's also a
ranged attack. The report included a small patch for use_pole() but I'm
calling the regular attack confirmation routine instead.
Also, move the penalty for samurai attacking peaceful monsters into
the same routine that handles knight attacking defenseless monsters so
that they're more consistent.
cohrs [Sun, 27 May 2007 22:56:02 +0000 (22:56 +0000)]
digging/chopping a drawbridge
<Someone> mentioned this back in 12/05. Digging a closed drawbridge would
result in a "This wall is too hard..." message.
nethack.rankin [Sat, 26 May 2007 05:56:26 +0000 (05:56 +0000)]
kick/joust monster positioning (trunk only)
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.
nethack.rankin [Sat, 26 May 2007 02:36:38 +0000 (02:36 +0000)]
latex Guidebook [2 of 2] (trunk only)
The documentation for symset also changed Guidebook.tex to use the
hyperref package, which the old DECUS TeX distribution I'm using doesn't
have. I can't remember any discussion about inserting URLs into the
Guidebook and using LaTeX to generate html output. If there was, no
comments to that effect made it into the .tex file or the cvs log text.
So I'm guessing that \usepackage{hyperref} was a work-around for the
font issue (below) and that the latter was a side-effect of converting
from deprecated \documentstyle{} to recommended \documentclass{}.
I tried installing hyperref after tracking it down, but using it
generated complaints about several other packages either being too old
or missing entirely. Coping with them would be too much hassle. I also
tried just commenting it out, but that results in a font warning that I
assume isn't present when it gets used. I managed to cobble together
a fix for that, but since hyperref.sty isn't actually needed by our
Guidebook, it was simpler to revert to the way things were done back in
the old days....
nethack.rankin [Sat, 26 May 2007 02:35:50 +0000 (02:35 +0000)]
latex Guidebook [1 of 2] (trunk only)
Last fall when Michael added the symset stuff to supersede the old
handling for IBMgraphics and DECgraphics, Guidebook.tex was changed to
support multi-page tables in the output. But that requires that the
input be processed twice, because it requires feedback stored in
Guidebook.aux and the first pass can't rely on that file being present
or up to date. This updates the Unix, VMS, and OS/2 makefiles to do
two-pass processing. (I didn't see latex usage anywhere else, and the
branch version doesn't include the formatting change which needs this.)
nethack.rankin [Fri, 25 May 2007 03:26:56 +0000 (03:26 +0000)]
C/#name followup too (trunk only)
Rephrase "a type of object" to "the type of an object" in the menu.
#name
What do you want to name?
a - a monster
b - a particular object in inventory
c - the type of an object in inventory
d - the type of an object on discoveries list
nethack.rankin [Fri, 25 May 2007 02:02:44 +0000 (02:02 +0000)]
C/#name menu, calling old discoveries [2 of 2] (trunk only)
Implement <Someone>'s menu-mode for #name, primarily because it
is the natural place to add [re]naming entries in the discoveries list,
something that was requested in the newsgroup ten or so years ago. The
latter allows changing the type name of something which has previously
been named and is no longer being carried.
This also makes the C command become a synonym for #name or vice
versa; one or the other could now be reassigned to something else.
nethack.rankin [Fri, 25 May 2007 02:01:54 +0000 (02:01 +0000)]
C/#name menu, calling old discoveries [1 of 2] (trunk only)
Implement <Someone>'s menu-mode for #name, primarily because it
is the natural place to add [re]naming entries in the discoveries list,
something that was requested in the newsgroup ten or so years ago. The
latter allows changing the type name of something which has previously
been named and is no longer being carried.
This also makes the C command become a synonym for #name or vice
versa; one or the other could now be reassigned to something else.
#name
What do you want to name?
a - a monster
b - a particular object in inventory
c - a type of object in inventory
d - a type of object on discoveries list
Menu group accelerators provide unseen alternate choices: C for monster,
y for individual object, n for object type (and d for discoveries, but
that's only interesting if inventory is empty so that usual b & c are
omitted and discoveries entry moves up to b). These alternates allow
`#name y' and `#name n' to work the same as before, for users who have
trouble retraining their fingers. Using C to name a monster now takes an
extra keystroke, but using `C C' for it could make that be less annoying.
nethack.rankin [Tue, 22 May 2007 01:00:57 +0000 (01:00 +0000)]
rehumanize bit (trunk only)
Something else from a copy of an old news message:
You return to human form!
Do you want your possessions identified?
I don't think that this can actually happen any more because the pieces
of code which subtract hit points should all be polyself aware now, so I
didn't bother with a fixes entry for it.
nethack.rankin [Tue, 22 May 2007 00:53:36 +0000 (00:53 +0000)]
gem probabilities (trunk only)
This is probably on <Someone>'s bug list, but I don't remember where
that lives. I found a copy of an old news message by him which pointed
out that gem probabilities are set for a given dungeon level at the time
it is being created, but they don't get reset when an existing level is
revisited. So giants' inventory creation and any monsters' death drops
generate gems using values from the level most recently made rather than
from their/hero's current location. That can lead to high level gems in
the main dungeon after entering the mines.
nethack.rankin [Tue, 22 May 2007 00:41:12 +0000 (00:41 +0000)]
anmesia of last discovery (trunk only)
While testing something, I noticed that my last remaining discovery
would never be forgotten. The formula
count = ((count * percent) + 50) / 100
always yields 0 with count==1 and percent==25 (the value used for mind
flayer attacks). Not likely to come up in actual play very often....
nethack.rankin [Sat, 19 May 2007 04:09:01 +0000 (04:09 +0000)]
fix #H333 - boulder theft
From a bug report: nymphs could steal
boulders even though they aren't allowed to pick those up. It happened
becuase can_carry() is only called for monkeys (consequently, they don't
have this problem), not for nymphs.
From a bug report: amulet of strangulation
continues to kill hero if he polymorphs into a creature which doesn't
need to breathe or doesn't have a head or even a circulatory system.
Currently, the messages are different when the hero doesn't need to
breathe, but that doesn't seem good enough. This makes strangulation
stop when you polymorph into something which shouldn't be vulnerable and
restart if you poly into something vulnerable while still wearing the
bad amulet.
can_be_strangled() is doing more checks that necessary, in case the
strangulation property ever gets conferred by something other than an
amulet. Its criteria for protection from strangling might need tweaking.
nethack.rankin [Thu, 17 May 2007 06:30:18 +0000 (06:30 +0000)]
defunct tame engulfer
From the newsgroup: Conflict caused tame engulfer to swallow hero.
To try to get out, player hit it (with Magicbane, but that's not relevant
other than to provide an alternate "you hit it" message).
The magic-absorbing blade probes the invisible Audrey!
You get regurgitated!
placing defunct monster onto map?
Program in disorder, &c
[some look_here() feedback]
You kill poor invisible Audrey!
The problem was caused by hmon_hitmon(): it subtracted damage from the
target's hit points, did some bookkeeping and message delivery, then
called killed(). One bit of bookkeeping was to call abuse_pet() and
monflee() when the target is tame, regardless of whether the damage was
fatal. monflee() -> release_hero() -> expels() puts the hero and the
engulfer back onto the map, and that warning was triggered because the
former engulfer had no hit points left.
nethack.rankin [Thu, 17 May 2007 03:12:32 +0000 (03:12 +0000)]
fix #H331 - kicking at empty takes no time
From a bug report, getting the "you kick at
empty space" result doesn't use any turns but can have side-effects like
waking up monsters and negatively exercising hero's stats. It should take
a turn even though nothing gets kicked.
nethack.rankin [Sun, 13 May 2007 02:39:25 +0000 (02:39 +0000)]
#vanquished (trunk only)
Add #vanquished command to show the vanquished monsters list during
play. At present it's only available in wizard mode. Slash'em has it as
a regular mode command, and I found it handy sometimes: when I managed to
kill an unfamiliar monster, I could immediately get an idea of how the game
ranked its difficulty compared to other monsters. But having this command
available might encourage extinctionism. On the other hand, it might stop
some existing extinctionists from cycles of save+copy+restore+quit to view
disclosure data for their current game.
This also makes merging the wizard mode extended commands into other
extended commands be more robust. It will panic instead of going out of
array bounds if someone adds entries to debug_extcmdlist[] without also
expanding extcmdlist[] to make room.
nethack.rankin [Sat, 12 May 2007 02:01:18 +0000 (02:01 +0000)]
mirror fixes (trunk only)
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."
nethack.rankin [Fri, 11 May 2007 02:25:55 +0000 (02:25 +0000)]
splattered oil fix
splatter_burning_oil() is called when a lit potion of oil gets
broken, and it can dish out fatal damage to the hero. An earlier fix
to prevent a light-source panic (thrown item is not on any of the object
lists) during bones creation didn't address leaving that lit potion
intact if it was on the floor (which can happen if the breakage is caused
by striking or force bolt rather than its being thrown or kicked). Use
the existing obj->in_use mechanism as a more general fix, after teaching
bones code that it applies to other things besides the hero's inventory.
nethack.rankin [Thu, 10 May 2007 03:03:46 +0000 (03:03 +0000)]
Sunsword vs shades, take II (trunk only)
From the newsgroup: Sunsword is ineffective against shades. It
gets a special bonus of double damage vs undead, but since it's not made
of silver it was only doing 1 point of damage against shades. Make the
bonus-vs-undead attribute override the silver-required criterion. (No
comparable handling for flimsy weapons against thick-skinned critters
this time.)
nethack.rankin [Thu, 10 May 2007 02:20:22 +0000 (02:20 +0000)]
Sunsword vs shades _reversal_
Reverse the previous patch. It made other artifacts like Fire Brand
also do full damage against shades, which wasn't inteded. Back to the
drawing board....
nethack.rankin [Thu, 10 May 2007 02:14:10 +0000 (02:14 +0000)]
Sunsword vs shades
From the newsgroup: Sunsword is ineffective against shades. It
gets a special bonus of double damage vs undead, but since it's not made
of silver it was only doing 1 point of damage against shades. Make the
bonus-vs-undead attribute override the silver-required criterion. (If
there's ever a whip or other flimsy weapon which gets a bonus against
some type(s) of thick-skinned monster, its attack will override the skin
thickness in similar fashion.)
nethack.rankin [Tue, 8 May 2007 03:45:53 +0000 (03:45 +0000)]
f-iring without ammo refinement
A change a couple of weeks ago to have player's chosen ammo be auto-
quivered when using the 'f' command while quiver is empty was excluding
objects with quantity 1. That was on the basis that it was in the process
of being thrown so there was no point in putting it into the quiver slot
first. But if it was a boomerang, or Mjollnir under suitable conditions,
there was a chance for it to be available for another throw, so there is
a point to quivering it. Also, player can hit ESC at the direction prompt
and end up not throwing it after all. So, put even quantity 1 items into
the quiver when 'f' command is used with empty quiver.
nethack.rankin [Tue, 8 May 2007 02:02:22 +0000 (02:02 +0000)]
breaking empty wands
I found a copy of a news posting from 1996 which suggested that
using a[pply] to break a wand which has 0 charges should have a chance of
wresting out one extra charge, like zapping. That way the player can't
destroy spent wands with impunity, and it makes the two wand actions be
more consistent. Also, it's trivial to implement. :-)
nethack.rankin [Tue, 8 May 2007 02:01:08 +0000 (02:01 +0000)]
last? singular/plural update (trunk only)
Move some common code from makeplural & makeingular into a separate
routine. Also, add ``candelabrum <-> candelabra''. Wizard mode wishing
for "candelabra" now works; "Candelabra of Invocation" does not--not due
to case but because the " of " isn't preceded by 's' in the plural form.
nethack.rankin [Sun, 6 May 2007 00:57:49 +0000 (00:57 +0000)]
chatting with grunting monsters
From the newsgroup: attempting to #chat to a gnome elicited "the
gnome grunts" (because gnomes have MS_ORC sound, and MS_ORC is just a
synonym for MS_GRUNT) even when the hero was a gnome. This patch makes
MS_ORC (orcs, gnomes, kobolds, a couple of named demons) or MS_GRUNT
(ogres, ettins, trolls, gargoyles) behave as MS_HUMANOID when the hero
has same race. That by itself wasn't quite enough; hostile MS_HUMANOID
monsters other than fake players wouldn't respond, so this gives those
a generic message (threatening the hero). In a somewhat similar case,
peaceful MS_CUSS monsters wouldn't respond; now they say something too.
nethack.rankin [Sat, 5 May 2007 21:41:54 +0000 (21:41 +0000)]
zhitu thinko (trunk only)
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.
nethack.rankin [Sat, 5 May 2007 04:32:19 +0000 (04:32 +0000)]
using #monster to breath at self (trunk only)
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.
nethack.rankin [Sat, 5 May 2007 04:10:32 +0000 (04:10 +0000)]
green slime vs fire breathers (trunk only)
Extend defense against being turned into slime to monsters who can
breathe fire. Other attack types which dish out fire damage didn't seem
suitable for this.
Move some of the singular<->plural transformations from code to data.
Also fixes one more missed singularization: lurkers above. A big chunk
of this is just a bit of minor reorganization: moving otense() & vtense()
next to makeplural(), and moving the wishable subranges array from between
makeplural & makesingular to in front of the wishing code.
I was going to redo makeplural to use the same style as makesingular
(switch from ``len >= N && !strcmpi(buf, spot-(N-1))'', with spot pointing
at final character, over to ``BSTRCMPI(bp, p-N)'' which tests p-N against
bp as the bounds check and has p pointing to the string's terinating '\0')
but have decided not to tackle that.
nethack.rankin [Thu, 3 May 2007 01:17:46 +0000 (01:17 +0000)]
more plural/singular (trunk only)
Extend makeplural/makesingular case-insensitivity to vtense() and to
wizard mode wishing for dungeon features. And the previous set of fixes
missed one: makesingular("zombies") was producing "zomby". Plus a bit of
groundwork for a likely second overhaul of makeplural/makesingular.
nethack.rankin [Tue, 1 May 2007 03:59:32 +0000 (03:59 +0000)]
makeplural & makesingular overhaul (trunk only)
I stumbled across a copy of an old newsgroup bug report which
complained that wishing for "Gauntlets of Power" didn't work. I thought
that this was something which had already been fixed, but when I tried it
out, I discovered that you still couldn't wish for that. It was failing
because case-sensitive makesinglar() didn't recognize that "Gauntlets"
needs special handling. After the unwanted transformation, the case-
insensitive object matching would fail to find "gauntlet of power".
Removing case-sensitivity for special cases like "boots" and "gloves"
would have fixed that, but this patch goes further and removes case-
sensitivity entirely for both makesingular and makeplural. Words which
get their endings modified work when the input is upper or mixed case.
Any modified letters retain the case of the original, so the reason for
case-sensitivity--user specified fruits that aren't lower case--is covered.
Some makeplural fixes: the plural for dingo is dingoes (dictionary
says "-es", not "-s") and for roshi is roshi (just guessing here; most of
the Japanese names use same spelling for singular and plural, but we were
producing roshis). Several words which makesingular leaves in plural form
(boots, gloves, &c) are now recognized by makeplural (avoiding gloveses).
It also fixes a bunch of incorrect singularizations of plural monster
names: foxes, *wolves, lynxes, fungi/humunculi/succubi, mumakil, wumpuses,
baluchitheria, Aleaxes, *elves, erinyes, djinn, priestesses, & valkyries.
Some non-monsters that makeplural handles correctly were also not being
singularized right: feet, hooves, lice/mice, algae, children, nemeses.
For an explosion caused by the player while the hero is engulfed,
skip adjacent monsters. Also, don't give "you hear a blast" when an
unseen explosion is caused by a scroll of fire (explosion is always unseen
when hero is engulfed, regardless of explosion's cause). [Offhand I'm
not sure whether something other than the player can trigger an explosion
while the hero is engulfed.] Lastly, round up instead of down when a
monster takes half damage, so that non-zero can't be reduced to zero.
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.
New macro slimeproof() to decide whether something is susceptible
to turning into green slime. Most of this is just making use of existing
cached permonst values in damageum() and mdamagem() and shouldn't affect
anything. I wanted to avoid mixing that in with the actual slime changes
which are coming.
pile_limit option - movement feedback "there are objects here" (trunk only)
Something that pops up in the newsgroup periodically, with <Someone>
inevitably pointing out the bit of code that the user needs to tweak,
about control of feedback when hero is walking across floor objects.
Implement new option ``pile_limit'' which allows user to set the point
at which the game switches from listing the objects to giving "there are
several/many objects here". Default is 5, same as previous hard-coded
value (1 object gets listed via pline, 2..4 are listed in a corner popup,
5 or more objects yields a pline message instead). Setting pile_limit
to 0 means no limit, so objects will always be listed regardless of pile
size. Setting it to 1 effectively forces no listing since any non-empty
pile size is always at least that big, so can produce "there is an object
here" even though that's no briefer than a pline() to show one object.
fix #285 - feeling cockatrice corpse while blind (trunk only)
From a bug report: moving while blind
and gloveless onto spot containing a cockatrice corpse is fatal if there
are fewer than 5 items there, but harmless when you get the "there are
several/many objects here" result for 5 or more. I thought that this was
something which had already been changed, but it wasn't. Run a touch
check on the whole pile of objects even when no object-by-object feedback
is being given.
Trunk only because it's using the trunk version of corpse_xname().
Noticed while testing a patch for touching cockatrice corpses;
corpse_xname(,, CXN_ARTICLE) would produce "a cockatrice corpses" when the
object stack quantity was greater than 1. (This applies to the post-3.4.3
expansion of corpse_xname() in the trunk code, so no fixes entry.)
While updating discard_minvent I noticed that m_useupall is using
the wrong routine to get rid of a monster's weapon. It probably doesn't
matter since I don't think monsters can use up items they're wielding or
wield items they could use up.
Genociding * to clear a level in wizard mode, or paying off a
shopkeeper to dismiss kops in any mode, could trigger the recently added
warning about deleting worn items in obfree(). mongone -> discard_minvent
wasn't bothering to unwear/unwield monster gear before deletion.
fix #H285 - hiders not hiding while hero is on another level (trunk only)
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.
From a bug report: rogue's backstab bonus
(extra damage when foe is fleeing) doesn't apply when dual-wielding but
does apply to thrown weapons--unless both conditions apply. Having it
apply to throwing is too powerful. Elbereth makes it trivial to get
monsters to flee and a rogue with expert dagger skill can throw up to 4
of those at a time, so a level 30 rogue could get rnd(30) bonus 4 times
in a single attack. This makes the backstab bonus only applicable to
melee and polearm attacks.
There was a suggestion in the newsgroup that if you use the 'f'
command when your quiver is empty, that whatever missile you supply to the
"what do you want to throw?" prompt be automatically put into the quiver.
This implements that, and separates most of the common code from dothrow()
and dofire() into a separate routine. A post-3.4.3 change to dothrow() to
require hands for throwing wasn't propagated to dofire(). With the common
routine, they're much less likely to get out of sync like that.
This is going into the branch as well as the trunk because the hands
checking mismatch was added there too.
Suggested by <Someone>: in the special level compiler, support
"random" in addition to "open" and "closed" for a drawbridge's inital
state. Drawbridge shares code with door, so the necessary parsing was
already present. This just treats random as valid for drawbridge instead
of explicitly rejecting it, and makes the special level loader process it.
He also suggested that the two drawbridges on the bottom level of
the Valk's quest be changed from open to random, but this patch doesn't
go that far. I think it's a good idea, but since the player can't use a
musicial instrument on those bridges, this has more impact on game play
than it might at first seem. I don't really want to see Valkyries be
required to use magic for occasions where both bridges start out closed.
A couple of things noticed when looking at the death-by-brainlessness
code. The 3.4.3 code ran a loop while life-saving was keeping the hero
alive, which would work if someone added other sources of life-saving than
the amulet but not if they added some form which didn't get used up when
it kicked in. Post-3.4.3, the dev code eliminated the loop but was no
longer guarding against additional forms of life-saving. This attempts to
clear the relevant field once any form of life-saving takes effect (for
brainlessness). It's not perfect since someone could change `Lifesaved'
to look at something other than the hero's properties, but at least it
still avoids the risk of getting stuck in a loop if someone makes a really
bad customization.
Also, make life-saving use min(2*level,10) instead of flat 10 for
amulet or 8*level for explore/wizard survival when it saves someone whose
max HP have been clobbered somehow. Other places assume that 1 HP per
level is the lowest the hero will have; saved-life gives a modest bit more.
Lastly, some post-3.4.3 code to make ghosts/shades immune to brain
sucking was using mon_nam() to start a sentence; Monnam() is needed there.
Reported--more or less--by <email deleted>:
chargeable rings don't show up as likely candidates in the "what do you
want to charge?" prompt. They're supposed to be there once the type has
been discovered but it was using the wrong field so basing that on whether
the player had assigned a name to the type instead. (Picking a chargeable
ring's letter even though it wasn't listed did work correctly though.)
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.
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.]