From a bug report, a hero hiding on the
ceiling while poly'd into a piercer or lurker-above could be moved long
distances when a monster attacked his location, because when the attacker
moves into hero's spot, hero's new location is chosen before the attacker
had released its own spot. If things are crowded, the nearest open space
can be quite far away, including beyond nonpassable walls. Fix by taking
attacker off the map before choosing hero's destination, so in crowded
conditions they will likely end up trading places.
This also prevents eels and sharks from moving onto land when the
hero has hidden on the ceiling next to their pool. They'll miss without
moving into hero's spot, but the hero will become unhidden so they'll be
able to make ordinary water-to-shore attack on their next turn.
Lastly, when the attacker is a long worm, the spot chosen for hero
might be filled by its tail by the time hero actually moves. So double
check and possibly re-select target spot after moving a worm's tail.
From a bug report, if you dismount
from a steed whose legs are wounded, you won't recover the point of
dexterity which was removed when they becme injured. He noticed the
case where the steed had just died, but it happens for voluntary
dismount too (actually any dismount except one which wounds the hero's
legs in the process: DISMOUNT_THROWN or DISMOUNT_FELL).
It seems rather odd that the hero temporarily loses Dex when the
steed becomes injured, but I haven't changed that.
From a bug report, you could obtain
a saddle for free if it was dropped (while worn) by a dying pet inside a
shop. That's intentional, but it was happening even when the hero was
not in the shop, which doesn't seem right. Change things to only set it
no_charge if hero is within the same shop (including standing in the
doorway or a temporary wall breach, not just when all the way inside) at
the time of the drop.
I hadn't tried the build script vmsbuild.com in a long time....
vmsbuild.com wasn't compiling src/sys.c;
vmsbuild.com and Makefile.src+Makefile.utl had some linking discrepancies;
Makefile.top, Makefile.dat, Makefile.doc - replace old SCCS id/date/rev
comment with current cvs one (done for .src & .utl a month or so back);
config1.h - running DEC C in VAX C compatability mode to test linking
yielded a diagnostic about signed in the schar typedef for every file.
From a bug report, applying unlit Candelabrum
of Invocation when its candles had 1 turn's worth of burning left would
give a message that the candles were burning but not actually light them
if done anywhere other than the invocation location. Their burn time is
cut it half when not at that spot, and dividing an age of 1 yielded 0,
confusing begin_burn(). They wouldn't light and they couldn't be replaced
since they'd never get used up.
The problem is real, but the chance of it actually happening in
normal play is just about zero. This applies his suggested fix of
rounding the halved burn time up instead of down so that it can't yield 0.
It also applies his suggestion that the Candelabrum treat the invocation
spot like any other location once invocation has produced stairs there,
just as the Bell and the Book do.
When requiring "no" to reject in addition to "yes" to confirm one
of the paranoid_confirmation prompts, only loop a handful of times before
giving up and rejecting (in case there's some hangup-like situation that
isn't hangup enough to switch over to using ESC for further input).
There's no "that's enough tries" feedback; after 6 tries it just stops
asking for a yes or no answer and behaves as if it had gotten no.
A couple of extensions to the paranoid_confirmation option:
1) add paranoid_confirmation:Confirm -- setting this means that any
prompt where the other paranoid_confirm flags have been set to require
a yes response instead of y to confirm also require explicit no rather
than arbitrary non-yes to reject. It will reprompt if you don't answer
"yes" or "no" (unless you use ESC, which is treated the same as "no").
2) add paranoid_confirmation:bones -- control whether the "save bones?"
prompt in wizard mode requires yes instead of just y. The original user-
developed paranoid_confirm patch required yes unconditionally here, and
I left that out thinking it was undesireable. But after testing the
"your body rises from the dead as <undead>..." fix a couple of days ago,
where you now get an extra message and consequent --More-- prompt just
before "save bones?", I've changed my mind about its usefulness, provided
that it's settable rather than unconditional.
Handling paranoid_confirmation:bones outside of wizard mode is a
bit tricky. Right now, it can still be seen via 'O' if it has been set
in NETHACKOPTIONS, but it won't show up in the menu if you use 'O' to
interactively change the value of paranoid_confirmation. I'm not sure
whether that's the right way to go; it might be better to let non-wizard
users uselessly toggle it on and off rather than only partially hide it.
Or maybe it should be hidden from the current value even when it's set.
Or decline to set it in first place, despite external option settings.
I don't think this is useful enough to recommend ordinary users
enable it, but it's close enough to being useful that I don't want
to leave it to become subject to bit rot like umpteen other unfinished
patches. Anyone running in wizard mode who has a panic already gets
pushed into the debugger on VMS, although it doesn't work for what might
be considered the most important configuration (a secure playground, as
opposed to the wide-open one I've always been content to leave mine at).
From a bug report, receiving the
message "Your body rises from the dead as an <undead>..." gives away
the fact that bones are being created (and its absence when applicable
undead kills the hero gives away the fact that bones aren't being
created). Not very interesting for single player installations where
5-10 seconds later the player is going to check the playground for new
files, but matters on multi-user installations where players don't have
access to the directory and sometimes race each other to juicy bones,
such as nethack.alt.org.
At the end of disclosure, give the message whether bones are being
saved or not (for cases where it would have happened when bones are
created). Player won't know whether new bones are becoming available.
Also, prevent risen undead-from-hero from being given random monster
inventory, but explicitly give mummy-from-hero a mummy wrapping if the
hero isn't already carrying one. It will end up being worn; that's
the only armor mummies are allowed to put on.
Enable SYSCF_FILE for VMS, and simplify option initialization
in the process. I still need to put a template into the playground
directory during initial install, and the one in sys/unix/ probably
isn't appropriate.
files.c wouldn't compile if SYSCF was defined and PANICLOG wasn't.
Also, a couple of PANICLOG option sanity checks treated 0 as an error
but then said that the value had to be 0, 1, or 2. I went with the
message and changed it to treat 0 as ok. Unfortunately the numeric
value is derived via atoi() so you get 0 from bogus input. Perhaps it
should use sscanf(string,"%d%c",&number,&dummy)==1 to try harder to make
sure it actually gets a number.
Noticed while working on the "lava inconsistencies" patch: it was
possible for lava_effects() to be called recursively, despite a patch
five and half years ago which was supposed to prevent that. That patch
handled the case where the hero dies and gets life-saved, but it didn't
deal with a hero who survives due to water walking boots and then has
those burned away. [Not an issue in 3.4.3 because Boots_off() didn't
call spoteffects() for lava then, but it does in post-3.4.3 branch as
well as trunk. fixes34.4 has an entry about fixing an "object lost"
panic for this but I don't think it's accurate. I think that the panic
only became possible after the post-3.4.3 "handle lava when removing or
losing water walking boots" fix was introduced.]
From a bug report, if you move into lava, die,
and are life-saved or leave bones, your potions will remain intact,
whereas if you have fire resistance and survive, they'll be subjected to
destroy_item() and usually be destroyed (not always, because stacks of
more than 1 don't always destroy the whole stack). Also, wooden ring
will be destroyed even if it happens to be ring of fire resistance.
This addresses both of those bugs.
He also thought that all vulnerable armor should be destroyed rather
than just boots in the case where you have fire resistance and survive,
but I didn't change that. It is a little odd, but presumeably only your
feet are in lava at first (although later sinking further into lava
doesn't actually burn up any other stuff).
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.
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.
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.
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.
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.
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.
