Back on Feb 28, I committed a patch to prevent the special level
loader from generating mail daemons for levels which specified random
demons. It had a pair of copy+paste mistakes that could result in
mkclass() looping forever. It was looking at the same monster every
time and if that monster was one which mustn't be generated, it would
just keep repeating.
fix #2142 - skipping levels when climbing with Amulet
From a bug report,
when climbing out of Gehennom while carrying the Amulet, you could skip
a handful of levels by taking the magic portal into the Wizard's Tower,
dropping the Amulet, zapping it with a wand of teleportation--possibly
more than once--until it lands outside the tower. Then take the portal
back out of the tower and level teleport--feasible now that you're not
carrying the Amulet any more--back to the tower level and retrieve the
Amulet. Overall probably not much of a savings unless you're having
really bad luck with the mysterious force sending you back whenever you
try to go up. The hero and monsters can't teleport from inside the tower
to the outside or vice versa; this gives the same limitation to objects.
altmeta Alt key hack, mainly for unix (trunk only)
Some time ago we received a patch submission which attempted to
handle the Alt key for terminals or emulators which transmit two char
sequence "ESC c" when Alt+c is pressed, but I can't find it. I don't
remember the details but recall that it had at least once significant
problem (perhaps just that it was unconditional, although it may have
been implemented in a way which interferred with using ESC to cancel).
This patch reimplements the desired fix, making the new behavior be
conditional on a boolean option: altmeta. That option already exists
for the Amiga port, where it deals with low-level keyboard handling but
essentially affects the same thing: whether Alt+key can be used as a
shortcut for various extended commands. This one affects how the core
processes commands, and is only available if ALTMETA is defined at
compile time. I've defined that for Unix and VMS; other ports don't
seem to need it. (I'm not sure whether "options" created by makedefs
ought to mention it. So far, it doesn't since this isn't something
users are expected to tweak. The setting of the non-Amiga altmeta
option doesn't get saved and restored, so won't affect saved data if
someone does toggle ALTMETA and then rebuild.)
When [non-Amiga] altmeta is set, nethack's core will give special
handling to ESC, but only during top level command processing. If ESC
is seen while reading a command, it will be consumed and then the next
character seen will have its meta bit set. This introduces a potential
problem: typing ESC as a command will result in waiting for another
character instead of reporting that that isn't a valid command. Since it
isn't a valid command, this shouldn't be a big deal, but starting a count
intended to prefix your next command and then typing ESC after deciding
to abort that count runs into the same situation: nethack will wait for
another character to complete the two character sequence expected for
"ESC c". There's not much that can be done with this, other than have
the Guidebook mention that an extra ESC is needed to cancel the pending
count, because digits followed by ESC could actually be a numeric prefix
for Alt+something rather than an attempt to abort the count.
fix #2253 - shk dismissing kops from other level (trunk only)
From a bug report, if you rob a shop, let the
angry shopkeeper catch up with you outside his shop, escape to another
level with adjacent shk tagging along, then pacify the shk by paying him
off, he will dismiss kops on the present level and return to his shop
but when you return to his shop level there'll still be kops chasing you
there. This fix adds an extra flag to the eshk structure so that kops
can be dismissed a second time when the shk migrates back to shop level.
The first dismisal (on the "wrong" level) still takes place in case any
kops are around. Neither dismissal actually occurs if there happens to
be another angry shk present on the level where dismissal is being done.
I can't figure out how to make PuTTY use the Alt key to function as
a Meta key and set a character's high bit, so I used this hack to test
the M-5 fix just committed. This lets me specify a character to be used
to force the next character to have its high bit set, so I can fake the
Meta key with a two character sequence. (I used the back-tick/accent,
since nethack doesn't do anything special with it.) Conceivably something
like this should be promoted to the core; this just affects VMS, and only
when vmstty.c is compiled with DEBUG defined.
From a bug report, using Alt+5 when number_pad mode
is set to MSDOS compatibility (where Alt+5 is supposed to function as the
'G' movement prefix) didn't work correctly. The code that did M-5 to G
conversion was being executed after the code which should have gotten G's
direction, resulting in strange behavior, probably using stale values for
u.dx and u.dy. (With current dev code, I evidently had u.dx==0 && u.dy==0
so was getting "You can't get there from here..." which is actually pretty
amusing in the current context. 3.4.3 didn't have that feedback so I'm
not sure what happened in it; possibly just silent refusal to move.)
From a bug report, the weight of a non-cursed bag
of holding would be off by 1 when the weight of contents was a multiple
of 2 (for uncursed) or of 4 (for blessed), since the round off handling
added 1 when it shouldn't in those cases. Mainly noticeable when empty;
the extra 1 unit made it be twice as heavy as it should have been.
Probably never noticed in actual play. He has implemented a patch
which shows weights as part of an object's formatted description, making
this stand out. Supposedly the Vulture's Eye interface also added a
patch like that a farily long time ago; I wonder why nobody using it ever
noticed. (Maybe the weight was suppressed for bags of holding there?)
Optimize yesterday's new code. When calculating magic cancellation,
avoid calling protects() for hero's inventory; the information it's
providing is already available via u.uprops[PROTECTION]. That part of
the inventory scan is only needed for monsters.
Magic cancellation comes from some types of worn armor and has a
value of 0 through 3. A non-zero value guards against some forms of
monster magic attacks (most notably, level drain by vampires and wraiths
and lycanthropy from werecritter bites). This reduces the effectiveness
of mc a moderate amount (the new values happen to be the same as those
adopted by the Spork variant):
chance to block various touch effects
mc old new
1 34.67% 30%
2 67.33% 60%
3 98% 90%
This also makes the Protection intrinsic (strictly speaking, extrinsic)
be the only way to attain an mc factor of 3. Cloak of protection is the
only way to get mc 3 from a single item. Otherwise you need an mc 2 item
and a ring of protection (or one of the recently modified quest artifacts).
Cancellation factor for elven and dwarvish mithril coats and for
robes and oilskin cloaks is reduced from 3 to 2; for elven cloak and
cloak of magic resistance from 3 to 1 (play balance; they're valuable
even without magic cancellation); for dwarven and orcish cloaks and
clocks of invisibility and displacement and for cornuthaum (wizard hat)
from 2 to 1. Plate mail and crystal plate mail stay at 2. A variety of
suits which were at 0 are increased to 1; leather jacket and dragon
scales/scale mail stay at 0 (the latter for play balance rather than for
the amount of your body that's covered).
Having extrinsic protection will increase mc by 1 (unless it's
already 3). That's obtained by wearing a cloak of protection (where the
increase is redundant), a ring (or two) of protection (even if conferring
a negative AC amount), or wearing the Mitre of Holiness or wielding the
Tsurugi of Muramasa. Having multiple sources doesn't make the benefit
cumulative; it's just +1.
Intrinsic protection (bought from priest, gained from prayer, gained
from eating rings of protection while polymorphed into metallivore, or
temporary while spell of protection is active) doesn't increase mc from
armor but does provide minimum mc 1 instead of naked 0 (play balance
again; buying it is too easy to let it increase mc 1 or 2 to 2 or 3).
(Extrinsic protection is a superset; its +1 bonus also increases 0 to 1.)
TODO: add an amulet of protection so player has another option for
extrinsic protection.
This is mostly groundwork prior to making the Protection intrinsic
become more meaningful. The Mitre of Holiness (priest quest artifact)
and the Tsurugi of Muramasa (samurai quest artifact) will now confer
Protection when worn/wielded (though at present that effectively does
nothing). While in there, this also changes the Eye of the Aethiopica
(wizard quest artifact), the Eyes of the Overworld (monk quest artifact),
and the Sceptre of Might (caveman quest artifact) so that they need to
be worn/wielded rather than just carried in order for them to confer
magic resistance. That way they're a little less attractive for wishing
by other roles and a little more likely to be actively used by their own
roles (not an issues for the Eyes, I'm sure). This change actually works
to the player's advantage, since it means that monsters who successfully
steal those items won't instantly obtain magic resistance in the process.
This adds protects() as a predicate routine to check an item for
conferring Protection. In order to do that, it renames the existing
protects() routine to defends_when_carried(), because that predicate is
actually a variant of defends() for items which aren't worn or wielded.
nethack.rankin [Tue, 15 Mar 2011 02:25:28 +0000 (02:25 +0000)]
high level monster spell casting (trunk only)
Mage-spell casters higher than level 23 and cleric-spell casters
higher than level 13 became less and less likely to cast interesting
spells as level went higher, more and more likely to cast the default
psi-bolt or open wounds. [Level 21 caster had 4.75% chance to cast
touch of death; level 22, 9%; level 23, 13% chance; then level 24, 12.5%;
level 25, 12%; level 30, 10%; level 50 (demon lords/princes), only 6%.]
This oddity in spell selection meant that the Wizard of Yendor gradually
became less likely to use "double trouble" to clone himself as he got
killed off more times and his next incarnation arrived at higher level.
This fix makes high level casters who pick too-high spell usually retry
until they get a valid one instead of just reverting to the default.
Still slightly biased towards psi-bolt and open wounds, since they're
effective even though a bit boring.
nethack.rankin [Wed, 9 Mar 2011 02:30:24 +0000 (02:30 +0000)]
Guidebook update (paranoid_confirmation 3 of 2) (trunk only)
This started out just documenting the commands where use of the
new paranoid_confirmation option was relevant, but it end up sprawling
to other stuff so I left it out of the paranoid_confirmation patch.
Eventually I changed all the commands with long-ish descriptions to use
a single line summary of the what the command does, with any additional
explanation or examples forced into a separate paragraph instead of
just being appended to the summary. It increases the number of lines
and probably pages in the document, but I think it makes skimming over
the list of actual commands much easier.
A couple of unmodified command descriptions are 'f' and 'Q'. The
only way I could avoid the temptation to discard "quiver sack" was to
leave those alone entirely.
A couple of others received some spoiler-ish additions, notably
#offer (which doesn't actually give anything away) and #pray (where
someone might assume that the command is useless if their very first
attempt gets rejected). I also added tips for two-weapon combat (how
to set up to use it, not when or why to use it) that ended up being much
more verbose than planned.
I don't know whether nroff+tmac.n offers a better way to get a
non-indented paragraph than using a labeled paragraph with an empty
label; .lp "" achieved what I wanted so I used it quite a bit. I also
wanted the value lists for number_pad and paranoid_confirmation to not
be indented but failed to figure out how to do that properly. In
Guidebook.mn they're still indented; in Guidebook.tex number_pad fakes
it using fixed-with tt font, paranoid_confirmation approximates it with
a ridiculous indentation hack. The number_pad result is wrong, but I've
given up. "~0" lines up with "-1", but "~1" through "~4" line up with
the minus sign instead of with the 1 as if that unbreakable space prefix
wasn't there.
nethack.rankin [Sat, 5 Mar 2011 10:09:48 +0000 (10:09 +0000)]
paranoid_confirmation [expanded user patch] (trunk only; 2 of 2)
[Short writeup; see 'cvs log' of flag.h or options.c for the long one.]
This is a reworking of user contributed patch known as Paranoid_Quit.
Add a new compound option, paranoid_confirmation, accepting a space
separated list of values "quit die attack pray Remove"; default is "pray".
paranoid:quit - yes vs y for "really quit?" and "enter explore mode?"
paranoid:die - yes vs y for "die?" in explore mode or wizard mode
paranoid:attack - yes vs y for "really attack <peacful monster>?"
paranoid:pray - y to pray; supersedes prayconfirm boolean; on by default
paranoid:Remove - always issue an inventory prompt for 'R' an 'T', even
when only one applicable item is currently worn.
nethack.rankin [Sat, 5 Mar 2011 10:08:38 +0000 (10:08 +0000)]
paranoid_confirmation [expanded user patch] (trunk only; 1 of 2)
[Long writeup committed with flag.h and options.c only.]
This is a reworking of a user contributed patch available in Pasi
Kallinen's NetHack Patch Database at http://bilious.homelinux.org under
the name "Paranoid_Quit". It was created by David Damerell and extended
by several others, and I haven't attempted to preserve attribution.
Their patch added three new boolean run-time options (this one
doesn't; details below):
paranoid_quit: if true, change the "really quit?" prompt to require an
answer of yes rather than just y to quit, presumeably for players who
type faster than they read and think (been there, done that...). It
also applies to the "do you want to enter explore mode?" prompt. The
changed prompt shows yes and no rather than yn as possible answers.
After having used it a few times, I find it easily noticeable that
"yes"<return> is expected instead of just single keystroke 'y', and
if you mess up somehow you can just reissue the #quit or X command
with no harm done. (And the default setting is off; the game still
issues the original yn prompt.)
paranoid_hit: if true, make a similar change for the "really attack <the
peaceful monster>?" prompt. Definitely helpful if you bump into a
monster while in the midst of using 'y' to move diagonally upper left.
Note that this just changes the expected/required answer to an existing
prompt; it doesn't change interaction between the hero and monsters.
paranoid_remove: if true, the 'R' and 'T' commands will prompt the player
to select an appropriate item from inventory even when there's only one
applicable item (instead of simply removing or taking off that only
item). Helpful if you think you've got more than one thing on and
intend to take off something other than the last one (which might be a
ring of levitation keeping you from dropping into lava or a blindfold
and you're trying to play the whole game blinded).
Their patch also made two other changes which weren't controllable via
options: when dipping, after picking what to dip, mention it in the
second prompt for what to dip into; and require yes instead of y at the
wizard mode "save bones?" prompt. We've had the enhanced dipping prompt
for a while, and "unknown" installed a fix-up (which wasn't needed with
their version) for it recently. I've left our bones prompt alone, the
original yn query. Anyone who saves bones by accident can remove them,
if not externally they by using wizard mode to revisit the same dungeon
depth, load the bones, and unlink them.
#####
That's a summary of the contributed patch. Now for the implemented
one.... Instead of separate booleans, this adds a single compound option
called "paranoid_confirmation" that takes a string argument of space
separated words: "quit die attack pray Remove". And it puts the actual
yes vs y querying into a new routine instead of duplicating it at each
affected prompting location.
paranoid_confirm:quit - as above, if true then require yes instead of y
to answer the "really quit?" and "do you want to enter explore mode?"
prompts. Can also be supplied as paranoid_confirm:explore or even
"quit explore" but that's just redundant; it's a single flag which
controls prompting for both game-ending or game-altering commands.
paranoid_confirm:die - applicable only for explore and wizard modes but
visible/settable during option viewing/changing in normal play. If
true then require yes instead of y at the "die?" prompt. This wasn't
part of their original patch, but should have been since the effect
of accidental y is just as drastic as unintentionally quitting.
paranoid_confirm:attack - as above, yes vs y for "really attack <the
peaceful monster?". Can also be supplied as paranoid_confirm:hit.
paranoid_confirm:pray - supersedes the existing prayconfirm boolean.
That option is still accepted and honored duing config file processing,
but option viewing/changing with 'O' only handles the new variant.
This does not control "yes" vs 'y', but rather whether there's a prompt
first or prayer simply starts. When used, the prompt itself is the
same yn one already being asked with prayconfirm. Presumably config
file support for prayconfirm will go away in some future version.
Unlike the other paranoid settings, this one defaults to 'on' in order
to match the 3.3.0 through 3.4.3 behavior controlled by prayconfirm,
whose default was on (but maybe should have been off...).
paranoid_confirm:Remove - as above, causes the 'R' and 'T' commands to
use a "what do you want to remove?" or "what do you want to takeoff?"
inventory selection prompt even when only one accessory or piece of
armor is worn. Player can pick the inventory letter and remove/takeoff
the item, use ? or * to see what the candidate item is, or cancel with
ESC. Can be supplied as paranoid_confirm:takeoff or "remove takeoff",
but like with "quit explore", a single flag controls the behavior of
both 'R' and 'T'.
Option file processing accepts two other settings, paranoid_confirm:none
and paranoid_confirm:all, but those are not available (nor needed) when
using the 'O' command. "none" is useful because it's the value shown to
the player by 'O' when none of the paranoia flags are set, and it's a
way to turn off paranoid_confirm:pray without turning on any of the other
choices. "all" probably isn't very useful but was trivial to tack on.
This is an example of the menu that 'O' puts up after picking option
paranoid_confirmation from the main list. I've shifted everything left
to reduce whitespace here; it appears on the right side of the screen for
tty menuing.
Actions requiring extra confirmation:
q - yes vs y to quit or to enter explore mode
d - yes vs y to die (explore mode or debug mode)
a - yes vs y to attack a peaceful monster
p + y to pray (supersedes old "prayconfirm" option)
R - always pick from inventory for Remove and Takeoff
(end)
Currently set paranoia features are marked as preselected and can be
toggled off along with toggling any others on as desired. I've just
realized that this menu relies on showing entries marked via preselection
rather than explicitly annotating each one as [on] or [off]; that seemed
perfectly natural during testing so I think I'll leave it this way, at
least for the time being.
nethack.rankin [Thu, 3 Mar 2011 10:23:47 +0000 (10:23 +0000)]
#dip fix (trunk only)
A post-3.4.3 dipping change (to make the dipping prompt mention
the item that you've chosen to dip) formats a phrase for its eventual
getobj() call in advance, but then was modifying it inappropriately if
you were on a fountain or pool location. If you declined to dip into
the fountain or pool, the prompt for carried potion to dip into was
garbled: "What do you want to Dip <the object> into the fountain??".
instead of "What do you want to dip <the object> into?". Fix to use
a separate buffer in the case of a fountain or pool prompt so that the
"dip <the object> into" phrase will be intact when calling getobj().
nethack.rankin [Tue, 1 Mar 2011 13:39:59 +0000 (13:39 +0000)]
new man/woman (polyself, inevitably...)
Noticed when testing the [trunk] ^X fix: polymorphing into human
form (not reverting to original form) reported "you feel like a new man"
when I resumed being a cavewomen. Like with ^X, it used poly'd hero's
current monster gender instead of the about-to-be-restored role gender.
It's amazing that nobody seems to have ever noticed in all this time.
nethack.rankin [Tue, 1 Mar 2011 13:39:02 +0000 (13:39 +0000)]
^X fixes (trunk only)
Being a cavewoman polymorphed into a male creature revealed multiple
mistakes in the post-3.4.3 ^X code, including the initial title text.
It was using current gender in several places where it should have been
using the saved value that applies when not polymorphed, leading to
confusion as to whether you'd changed genders if/when current and saved
ones were different. More noticeable with gender-distinct role names.
nethack.rankin [Tue, 1 Mar 2011 12:15:51 +0000 (12:15 +0000)]
dragon scale mail degraded by polymorphing into dragon (trunk only)
Apparently I lied yesterday when I said that patch was the last
polyself one. This has been on my agenda for a long time: when dragon
scale mail merges with your skin during polymorph into the corresponding
dragon, have it revert from mail to scales. Its enchantment stays the
same when reverting. So after returning to your original form, using
enchant armor to convert it into scale mail again will eventually risk
its destruction due to over-enchanting. (Cursed scroll of enchant armor,
spell of drain life, or being hit by a disenchanter can be used to reduce
its enchantment back to a safe-to-enchnat value. Or cancellation if
you're desperate. I think those all work on all colors of dragon scales
despite the assorted magical properties that scales confer.)
nethack.rankin [Tue, 1 Mar 2011 00:50:13 +0000 (00:50 +0000)]
fix #H2200 - disintegration by divine wrath (trunk only)
From a bug report, it you're targetted by
divine wratch while swallowed by a shock-resistant engulfer, the
ineffective lightning is followed by a wide-angle disintegration beam
which "fries <the engulfer> to a crisp"; he felt that being fried was
not appropriate for disintegration. I agree. (He also failed to notice
that the exact same terminology is used for killing the hero when not
swallowed.) I wanted to use "disintegrated into a cloud of dust" here,
but if a suit has just been disintegrated you'll have seen "turns to dust
and falls to the floor" for that, so I settled for "into a pile of dust".
nethack.rankin [Mon, 28 Feb 2011 11:29:27 +0000 (11:29 +0000)]
one last(?) polyself bit: no control while stunned (trunk only)
Teleport_control is disabled while the hero is Stunned; do the same
with Polymorph_control. Also now disabled while unconscious, but that
is academic since random polymorphs and were-critter transformations are
postponed until multi is non-negative. I included it for completeness.
(Reverting to original form can occur while unconscious, but control is
not a factor in that situation. Teleporting handles being unconscious
differently but does negate control then.)
The fixes entry could just as easily have gone into the new features
section as into the bug fixes one. The teleport control part actually
belongs in fixes34.4 because it is present in the branch, but I didn't
feel like spreading this across two different files (and the current diff
references ``Unaware'' which doesn't exist in the branch so it isn't
trivial to include this patch there).
nethack.rankin [Mon, 28 Feb 2011 10:32:55 +0000 (10:32 +0000)]
still more polyself fallout (trunk only)
Also noticed while testing polyself changes, a few polymorph related
items weren't being listed as reasons for having some polymorph related
intrinsics during wizard mode enlightenment (a post-3.4.3 feature).
There may be other intrinsics conferred by items where you aren't told
about the item being responsible; I didn't look around for them, just
noticed these three: Unchanging (via amulet), Polymorph (via ring), and
Protection from Shape Changers (also via ring).
nethack.rankin [Mon, 28 Feb 2011 10:32:17 +0000 (10:32 +0000)]
more polyself fallout (trunk only)
When testing the change of "you can't polymorph into that" to
"you can't polymorph into <a monster type>" I noticed that specifying
high priestess told me that I couldn't become a priest (role monster),
but specifying high priest told me that I couldn't become a high priest
(monster as-is). Aligned priestess and high priestess aren't separate
monsters; the user-specific string to monster name code found the latter
as a rank title rather than as a monster and couldn't find the former
at all. This adds those two special monst types to the list of variant
spellings and whatnot that are used to augment name to type lookup.
Since they aren't viable candidates for polyself or for genocide I doubt
that any players ever noticed, so I haven't added a fixes entry for this.
nethack.rankin [Mon, 28 Feb 2011 05:30:06 +0000 (05:30 +0000)]
polyself changes (trunk only)
While making the change to prevent random mail daemons, I noticed
that controlled self-polymorph into a critter specified by class (a post-
3.4.3 feature) rather than by name wasn't excluding NOPOLY monsters so I
checked to see if they were being handled correctly. Accepting NOPOLY
monsters as candidates was intentional but it had a problem (although
many NOPOLY monsters are NOGEN and vice versa, so the problem wouldn't
show up often). If I specified A and Archon was randonly chosen, I'd
be told "you can't polymorph into that" but if I retried A and it chose
couatl, the polymorph succeeded. This changes the way the first case
gets handled: it skips the message and makes another pick from the
specified class, although that consumes the same retry counter as
reprompting so you might still end up with "you can't" if random picks
come out unfavorably too many times (or if you've typed in some bad
choices first and the counter has already been reduced).
When doing that, I changed the "you can't" message to say what it
is you can't polymorph into, instead of just "that".
And I've changed controlled polymorph to accept ESC when prompted
for monster type. When used, either don't polymorph (for wizard mode
#polyself command) or revert to uncontrolled poly (for all other causes
of polyself) instead of just asking again. Specifying "*" or "random"
will also produce uncontrolled polymorph.
nethack.rankin [Mon, 28 Feb 2011 03:36:08 +0000 (03:36 +0000)]
spurious mail daemons (trunk only)
From the newsgroup: when the special level loader is creating
random '&' class monsters, it can produce mail daemons. The thread
reports seeing some on the levels holding the Wizard of Yendor's Tower
and they vanish as soon as it's their turn to move. I didn't reproduce
it, but create_monster() is overriding the NOGEN flag when it calls
mkclass() so getting mail daemons is feasible. This fixes that by
treating them similar to the human/elf/orc/giant placeholder monsters
that are excluded from random generation. More or less.
nethack.rankin [Thu, 17 Feb 2011 03:51:04 +0000 (03:51 +0000)]
fix #H2225 - death by poison after life-saving (trunk only)
From a bug report,
when falling into a spiked pit and being killed and then life-saved, you
could immediately die from fatal poison. It isn't necessarily a bug and
there are other ways to be killed, life-saved, and re-killed (such as
zaps that bounce off walls or reflecting targets), but it does seem to be
somewhat unfair. This patch makes life-saving be more effective: in a
damage-plus-poison situation, if the damage triggers life-saving then the
poison won't deal out any further damage (including its nasty chance for
instant death). The poison still matters, but it will always target an
attribute stat--which is already one possible random outcome--instead of
maybe doing damage. [It is actually possible to get damage if stat loss
tries to take hero's strength below 3, but now there's no chance of that
being fatal immediately after savelife() has restored full hit points.]
nethack.rankin [Fri, 11 Feb 2011 02:25:59 +0000 (02:25 +0000)]
enlightenment/status feedback about wielded weapons (trunk only)
I noticed "you were wielding two weapons at once" in end of game
disclosure from a newsgroup ascension post for the Spork variant and
thought we ought to show that too. Well we already do. This moves it
from an attribute entry for magical enlightenment to a status entry for
^X display since it's something the hero and the player should already
always know. In the process I added feedback for being weaponless and
then went further and added some feedback about what weapon is wielded.
This is stuff that could/would be shown on the status line if there were
room, and fits with the post-3.4.3 ^X expansion of cryptic status stuff.
The "new ^X output" entry in the new features section of fixes35.0
covers this too.
nethack.rankin [Wed, 9 Feb 2011 01:05:29 +0000 (01:05 +0000)]
multishot throwing/shooting tweaks (trunk only)
I've been sitting on this for a long time (29 months?); it got more
elaborate for a while, then got stripped back to something fairly simple.
The original description was once accidentally attached to an unrelated
patch; it was more detailed than this one....
This makes it harder for non-fighter types to throw or shoot
multishot volleys of missiles, and gives a couple of minor new bonues to
try to get a little more variety than the current situation of everyone
(with possible exception of arrow shooting by rangers) just using stacks
of daggers for ranged attacks. Since daggers are so plentiful that's
probably just wishful thinking.
nethack.rankin [Thu, 3 Feb 2011 21:49:36 +0000 (21:49 +0000)]
mimic-as-door stealing key (trunk only)
Suggested by <email deleted> a month ago when he
reported that attempting to unlock a door which was actually a mimic
simply told the player that the door was not locked or that there was
no door. He thought that mimic should take the key/pick/card away from
the hero. This gives a 50% chance for the unlocking tool to be stolen
and become part of the mimic's inventory; it will be dropped when mimic
is killed.
The theft routine has groundwork to be able to be used to take the
hero's wielded or thrown weapon when hitting, but the attack code doesn't
call it so that won't happen (and the theft code hasn't been tested under
that circumstance). I'm not sure whether mimics should be able to grab
weapons, but g.cubes perhaps should, and if puddings could then "pudding
farming" [using a low damage iron weapon to split puddings, yielding tons
of experience, death drops, and #offer fodder when they're killed and
repeatable for as long as at least one pudding is kept healthy enough to
be split again] would become tougher to accomplish. [The item drop and
corpse aspects have been toned down quite a bit since 3.4.3, but with
sufficient patience it is still possible to abuse.]
nethack.rankin [Thu, 3 Feb 2011 21:10:17 +0000 (21:10 +0000)]
stumble_onto_mimic while blind, #untrap vs mimic
Noticed while testing a forthcoming mimic patch: when blind, some
actions (open, close, #untrap, applying a key [as of a month ago],
possibly others) taken against a mimic posing as a door would yield
"Wait! That's a monster!" but leave the map showing the door instead
of replacing it with the unseen monster glyph. Similarly, using #untrap
towards a known trap location covered by a concealed mimic could yield
"It is in the way." or "It isn't trapped.", depending upon the type of
trap present, and not reveal the mimic. Same thing happened when not
blind, except the message would refer to "the <size> mimic" rather than
"it". Now it will expose the mimic, regardless of the type of trap.
nethack.rankin [Sun, 16 Jan 2011 01:29:18 +0000 (01:29 +0000)]
thrownobj, kick[ed]obj (trunk only)
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.
nethack.rankin [Sun, 16 Jan 2011 00:31:28 +0000 (00:31 +0000)]
monsters taking possession of shop items
Noticed while looking through steal.c: theft that takes multiple
turns uses stealarm() callback which removes stolen armor from hero's
shopping bill, but theft that happened without delay did not. So theft
of an unpaid non-armor or non-worn item while in a shop left it on the
bill where it wouldn't show up for either ``I u'' or ``I x'', hiding the
charge from the player ('$' did disclose the total amount that the shk
was owed though), and the shopkeeper would persist in blocking the door.
This makes immediate theft behave the same as delayed theft; the stolen
item is removed from shop's bill when the thieving monster takes it away
from the hero.
Dropped items that a shopkeeper doesn't want have their no_charge
bit set; that's only supposed to be used for floor items inside shops.
But no_charge would stick when an object was picked up by a monster, so
the object would stay free for player if that monster was subsequently
killed in another shop which stocked that kind of item. Probably never
noticed because most monsters won't pick up items off of shop floors,
also most levels don't have other shops dealing with alternate types of
stuff. This clears no_charge, except when the monster picking up the
item is tame (so that a pet picking up and then dropping a no_change
object in the same shop won't cause the shk to silently take possession,
which would certainly lead to reports of a bug...).
nethack.rankin [Tue, 11 Jan 2011 02:21:10 +0000 (02:21 +0000)]
purple worms in wall (trunk only)
From a bug report, a purple worm
could swallow a ghost or xorn and end up inside solid rock. It took a
bunch of tries to reproduce this, but I eventually did. (I'm not sure
why it didn't happen every time a worm swallowed a target which was in
rock; the code for positioning an engulfer after it digests a target
always puts the engulfer in the target's former spot.) After this
patch, worms can still swallow ghosts and xorns, but only when they're
in locations the worm could walk onto.
nethack.rankin [Wed, 5 Jan 2011 01:28:36 +0000 (01:28 +0000)]
more mimic-as-boulder (trunk only)
I started to add handling for doorways containing mimic-as-boulder
to doopen() and doclose() as was done for pick_lock(), but decided that
it was better just to prevent mimics from appearing as boulders at closed
door locations in the first place. So the most recent pick_lock() change
and its fixes entry go away.
This also fixes a post-3.4.3 bug. On the top level of Sokoban I
discovered a boulder over a hole; probing reported it as a mimic with
0 hp. The special level loading code moves mimic-as-boulder away from
trap spots by using place_monster() to put it on another spot, but it
was missing the corresponding remove_monster() to take it away from the
original location so left a stale pointer on the map.
nethack.rankin [Sun, 2 Jan 2011 01:35:14 +0000 (01:35 +0000)]
fix #H2154 - unlocking door blocked by mimic-as-boulder (trunk only)
Reported five months ago by <email deleted>,
the top level of Sokoban has mimics who pose as boulders and if one was
in a doorway (treasure zoo at final destination) you could still unlock
the door there without waking the mimic. Yesterday's fix for unlocking
a door which was actually a mimic posing as one didn't handle this case.
nethack.rankin [Sat, 1 Jan 2011 00:34:19 +0000 (00:34 +0000)]
fix #H2210 - unlocking a mimic masquerading as a door (trunk only)
From a bug report, attempting to use a key,
lock pick, or credit card on an open doorway that contained a mimic posing
as a closed door reported "that doorway has no door" or "you cannot lock
an open door" as if no monster was present, and failed to find the mimic.
cohrs [Thu, 30 Dec 2010 21:47:06 +0000 (21:47 +0000)]
fix grid bug travel bug
From a bug report, grid bug could travel 1 step diagonally
due to special case code in findtravelpath that did not check grid bug
movement restriction
cohrs [Tue, 28 Dec 2010 19:43:01 +0000 (19:43 +0000)]
H2162 - topten handling of long names
<Someone> reported that being killed by a monster with a long name
can result in nethack going into an infinte loop printing spaces. Handle
this by detecting attempts to wrap the topten output on a word that is too
long and just inserting breaks in the middle of the word in this case.
nethack.rankin [Tue, 14 Dec 2010 01:14:37 +0000 (01:14 +0000)]
talking gecko (trunk only)
Suggested by <email deleted>, chatting to a gecko will
give a reference to GEICO's car insurance ads. I limited it to when
the hero is hallucinating. Chatting to a gecko monster, or to anything
capable of speaking--except for a couple of previously handled special
cases, like quest leader--which happens to look like a gecko at the time,
or (50:50 chance) to a shopkeeper regardless of appearance, you'll get
"15 minutes can save you 15 zorkmids", parodying "15 minutes can save you
15% or more on car insurance". (One of my comments says there's a chance
to interfere with shopping, but that's not accurate since using #chat to
get shop price quotes doesn't use the monster-response routine. I left
that comment in anyway; the "15 minutes" response might interfere afterall
if someone mistakenly thinks they can save gold by waiting that long
before paying their shopping bill.)
I don't think we ever found a good place to add some reference to
GEICO's other--and more relevant to nethack--slogan, "so easy a caveman
can do it".
nethack.rankin [Mon, 6 Dec 2010 01:39:33 +0000 (01:39 +0000)]
fix #H2195 - late discovery for teleport scrolls (trunk only)
From a bug report, when reading an unknown
scroll which turns out to be teleportation, if you happened to land on
another scroll of teleportation it wouldn't be discovered yet, even
though you ought to know that type of scroll by then. Fixing it required
moving handling of that scroll into the teleport code, since discovery
depends upon where you arrive and by then it's too late for seffects() to
do anything that affects feedback for any objects you land on.
Also fixes a post-3.4.3 bug where seffects() was making decisions
based on Teleport_control without being aware that Stunned now negates it
during teleportation.
nethack.rankin [Fri, 29 Oct 2010 00:56:49 +0000 (00:56 +0000)]
artifact naming tweak (trunk only)
3.4.3 and earlier had a bug that let players discover luck stones
and amulets of esp by attempting to name unID'd gray stones or amulets
after corresponding quest artifacts and seeing whether they got "your
hand slips" feedback. There's been a fix for this in place for a while,
but after recent newsgroup discussion I wanted to confirm that it works
as intended for amulets as well as for gray stones. It does. I ended
up with "a circular amulet named T*e Eye of the Aethiopica" (where that
asterisk was something other than the original "h" due to slippage)
which looks odd to me. I've modified the code to leave leading "the"
intact and only distort the remainder of such a name. This doesn't go
so far as to make sure distortions don't touch the "of the" portion in
the middle although it probably should.
nethack.rankin [Sat, 28 Aug 2010 00:15:39 +0000 (00:15 +0000)]
stone-to-flesh vs Heart of Ahriman (trunk only)
From the newsgroup: a player accidentally cast the stone-to-flesh
spell at himself (I don't recall whether he chose wrong spell or wrong
direction, or tried to cancel and game used last remembered direction)
and the barbarian quest artifact he was carring turned into a meatball.
Artifacts already have a high chance (95%) to resist being polymorphed
but that doesn't apply for the stone-to-flesh transformation. This
gives stone artifacts a high chance (98%) to resist being turned into
flesh. Non-artifacts also get a small chance (2%) to resist as well.
nethack.rankin [Sat, 14 Aug 2010 00:31:59 +0000 (00:31 +0000)]
fix #H2161 - writing scrolls based on description (trunk only)
From a bug report, you could write scrolls
by type name ("magic mapping") if you had that type of scroll in your
discoveries list via assigning a name to an unknown scroll ("scroll
labeled FOOBIE BLETCH called foo"). Being on that list was enough to
treat the type as known when writing scrolls and books. And he fealt
that it was abusive to be able to collect and name a lot of unknown
scrolls and then write favorite ones which had good odds of being in the
collected set.
This changes it to the original intent: if your discoveries list
has FOOBIE BLETCH on it, you can write a scroll by that label (since we
decided way back when that a scroll's label was its magic, to explain how
a blind hero can read any scroll whose description is known even though
they aren't constructed in braille). If you have identified the type
("scroll of magic mapping labeled FOOBIE BLETCH") then you can write by
type or by description, but you can no longer write one by type when only
the description is known. There is a potential can-of-worms bug here:
if you walked across a "scroll labeled YUM YUM" but have not assigned it
any name, you've still learned its magic words and ought to be able to
write a scroll of YUM YUM. We don't have any mechanism to track items
which have been observed but not been put on the discoveries list. This
patch plugs one obvious hole, by scanning inventory to treat any seen
scroll labels there as an extension of the discoveries list. But the
more general case of something once seen but not named or currently held
is ignored.
This also adds writing scrolls by the user-assigned name, so if
your discoveries list has "scroll labeled FOOBIE BLETCH called foo" you
can write either foo or FOOBIE BLETCH to get the scroll. I'm not sure
the bug report advocated that--parts of it were a bit confusing, at
least to me--and I'm not completely sure that we want to have it, but it
does work. Without it, you got "no such thing as \"foo\"", which seems
counter-intuitive when "foo" is there in plain sight on your discoveries
list. The new code chooses randomly if multiple scrolls have been called
"foo". And if you've called something by an actual object name, it uses
your knowledge of that object rather than anything you've given its name
to. In other words, if you have "scroll labeled YUM YUM called magic
mapping" and try to write magic mapping, it will use your knowledge--or
lack of same--about scroll of magic mapping rather than scroll labeled
YUM YUM to decide whether you'll succeed.
There is also a minor tweak in the chance to write a completely
unknown scroll or book. Wizards almost never failed once their Luck was
5 or more; using rnl(5) instead of rnl(3) requires Luck 11 rather than
just 5 to get that ~39/40 chance of success. Non-wizards didn't change.
Lastly, this fixes an unrelated bug when writing spellbooks. The
message "the spellbook warps strangely, then turns <new description>"
works okay when <new description> is "red" or even "ragged", but not so
well when it's "vellum". A handful of book descriptions refer to the
item composition rather than the appearance of the cover, and turning
into a new composition needs different phrasing. I just tweaked it to
be "turns into vellum", which is probably suboptimal (particularly for
the book description "cloth" :-).
From the newsgroup, losing spells to amnesia always took away the
last 'N' spells after choosing a random N. That kept casting letters
sane, since letters for lost spells became invalid and those for non-lost
ones stayed the same as they were before amnesia. But 3.4.x gave the
player the ability to swap pairs of spells, so he could make his favorites
to be the first spells, and only lose them if the random number of spells
being affected was as large as the whole list. (Also, divine spellbook
gifts give preference to books for unknown spells; in theory, you could
use spell letter manipulation plus deliberate amnesia to make a particular
spell revert to unknown in order to improve the chance of getting a new
spellbook for it. A bit of cleverness by a determined player but it
makes the game and/or its patron deities seem a bit dumb in the process.)
I first implemented losing spells throughout the list, with later
spells moved forward to fill any gaps. But that results in new casting
letters for every spell past the first lost one, potentially wreaking
havoc if a player chooses a casting letter from his own memory of the
pre-amnesia list. So, instead of losing some spells entirely, either
from the end of the list or spread throughout, I've changed amnesia to
set the retention amount (of N spells from throughout the list) to zero,
the same as happens when it's been 20000 turns since the spell was last
learned. Letters for all known spells stay unchanged, and forgetting
due to amnesia becomes the same as the other way of forgetting spells.
(So now a different potential clever use of amnesia occurs; a player who's
trying to a make speed ascension could get access to expired spells--to
cast in order to become confused--without waiting for 20000 turns after
reading the first book.)
From a bug report, the entry
in data.base for towel repeated the word "down" in the quote from Douglas
Adams' _The_Hitchhiker's_Guide_to_the_Galaxy_. I double checked the book
itself to verify that the quote shouldn't say "down down".
fix #H2150 - discovering displacement when can't see its effect
From a bug report, when putting on a
cloak of displacement you discovered what it was even if you were invisible
and unable to see invisible, hence couldn't see yourself. It isn't exactly
clear what the hero sees of himself when displaced, but I think it makes
sense that you shouldn't discover the cloak when you can't see yourself,
which suggests that you shouldn't discover it when blind either.
Discovering it after regaining sight, becoming able to see your
invisible self, or losing invisibility seemed complex and likely to be
bug-prone, so this patch leaves the cloak undiscovered in that situation.
But it does become discovered when taken off (provided that you can see
yourself by then) rather than waiting all the way 'til put back on again.
Elven cloaks had a comparable issue. I assume that stealthiness can
be perceived without being able to see yourself, but it shouldn't become
discovered when you're already stealthy from some other means. (Elven
boots already behaved this way; now elven cloaks work like them.)
Rings of stealth would never be auto-discovered. Now they'll be
like elven cloaks and boots and be discovered if put on when not already
steathy or taken off and losing stealth. In both cases, the ring has to
have its description known; if picked up when blind and still not seen
yet it won't become discovered even when you notice yourself gaining or
losing stealth.
Not tested: feedback given when a worn ring or cloak gets dipped
into a potion of polymorph and changes into or away from a stealth or
displacement conferring item.
Contributed by <email deleted>, give an
alternate message when eating a corpse while hallucinating, including one
that gives homage to Tony the Tiger from old Frosted Flakes commercials
if you happen to be polymorphed into a tiger. Even players who try to
keep their characters hallucinating all the time are unlikely to ever run
into "tastes gr-r-reat!".
I rewrote the conditional expression to only test Hallucination once.
And I added the comment about omnivores, who'll never get "is delicious"
result with the current carnivore vs herbivore logic. (That behavior has
been around for quite a while, but seems somewhat suspect.)
keni [Thu, 13 May 2010 00:54:13 +0000 (00:54 +0000)]
Guidebook update and SEDUCE runtime switch
add SYSCF docs to the Guidebook because it's info needed in a binary distro
Guidebook.tex - also add some missing italics to some "NetHack" occurances
call nethack.org "official"
Guidebook.txt - didn't regenerate cleanly so no diff
add SEDUCE to SYSCF (only partly inspired by the recent email)
keni [Sat, 1 May 2010 20:57:17 +0000 (20:57 +0000)]
makedefs manpage, conditionals, and related bits
Add a man page for makedefs so mdgrep is documented better.
Add missing INSURANCE to mdgrep.h. (yes, LIFE leaks in as well)
Add makefile bits to build makedefs.txt.
Pass dungeon.def through mdgrep internally to makedefs - this will make
it possible to commit the LIFE patch and have config.h actually turn it
all the way off (by skipping bigrm-6).
nethack.rankin [Thu, 4 Mar 2010 01:45:43 +0000 (01:45 +0000)]
crowning bonus (trunk only)
Have being crowned Hand of Elbereth/Envoy of Balance/Glory of Arioch
give a minor extra benefit beyond resistances and an artifact and maybe
unlocking the artifact's skill: one extra skill credit, making it
feasible to earn 30 rather than 29. (Previously the only way to get any
was to receive one for each new experience level, so you could gain one
29 times when going from level 1 to level 30.) Added as a new feature.
nethack.rankin [Mon, 1 Mar 2010 03:27:33 +0000 (03:27 +0000)]
minor readobjnam cleanup (trunk only)
Remove some clutter from the wish handling code, mostly by taking
advantage of the fact that the wizard flag is valid even for the !WIZARD
configuration. No change to game play.
keni [Wed, 10 Feb 2010 16:08:51 +0000 (16:08 +0000)]
First batch of changes from FailSafeC
This is all tiny stuff - allow overriding WIDENED_PROTOTYPES from the hints
file, missing NO_SIGNAL conditionals, remove a GCC-ism, conditional indentation,
void return in a non-void function.
nethack.rankin [Sat, 6 Feb 2010 01:58:33 +0000 (01:58 +0000)]
fix #H2081 - named vault guard messages (trunk only)
From a bug report, assigning
a vault guard a name such as Marcel could result in messages like
|The Marcel, confused, disappears.
Many of the guard messages had article "the" hardcoded. This gets rid
of g_monnam() and uses noit_mon_nam() instead.
I haven't been able to test all the modified messages; it's a pain
trying to get some of them to occur.
nethack.rankin [Tue, 2 Feb 2010 23:10:01 +0000 (23:10 +0000)]
open/close/loot while confused or stunned (trunk only)
Fix a bug From a bug report: while stunned he tried to close
an adjacent open door and when his choice of direction got changed to
some non-door spot, no time elapsed so he could just keep repeating the
attempt until eventually getting the correct direction. Trying to open
an adjacent closed door and trying to remove the saddle from an adjacent
monster via #loot behaved similarly. Applying keys and lock-picks also
did so in 3.4.3, but had already been changed to use up time in the dev
code. There may be other actions which need fixing.
nethack.rankin [Tue, 19 Jan 2010 02:58:59 +0000 (02:58 +0000)]
unix+vms wizard mode feedback (trunk only)
The message "only user <foo> may use wizard mode" formerly given
by the Unix and VMS ports was inadvertently rendered impossible to be
delivered when authorize_wizard_mode() was added to xxxmain.c nearly
3 years ago.
keni [Mon, 18 Jan 2010 02:02:45 +0000 (02:02 +0000)]
MacOS 9 vs MacOS 10 bit
MAC is defined for MacOS 9 but not for 10 (and it shouldn't be). Add a MACOSX
define and use it in eat.c to pick up the joke meant for all Mac systems.
keni [Sun, 17 Jan 2010 19:36:16 +0000 (19:36 +0000)]
make grep's path adjustable for PANICTRACE + more bits
Mac OS X doesn't have /bin/grep, only /usr/bin/grep. Grr.
Don't try to parse PANICTRACE_GLIBC if the field doesn't exist.
projects / nethack / log