Prevent using a leash while engulfed. If someone wants to supply a
better message, go ahead. I just tried to get the logic straight.
(The new swallowed part is easy; the previous lack of handling for
remembered unseen monsters wasn't quite so easy.)
Applying a leash was always using a move, even if player cancelled
at the prompt to pick an adjacent monster. Now some of the early
exits don't use a move.
The sequence
You feel the amulet draining your energy away.
You don't have enough energy to cast that spell.
didn't use any energy or cost any time so the player could try over
and over until the randomly chosen drain amount happened to be low
enough to succeed.
The old behavior was that the cost of the current cast attempt got
incresed by a random amount. Now, if hero already lacks sufficient
energy to cast the spell, the Amulet's effect won't take place, the
second message will be given, and no energy or time will be consumed.
When there is enough energy to cast the spell, the drain effect will
occur and some energy will be used up immediately (instead of
increasing the cost of this attempt). The energy drain might then
result in the second message, but if so, a turn will be used.
No longer increasing the energy cost of the current cast has a
side-effect on not increasing the hunger penalty for the current cast
(since that is based on the energy cost) but the energy drain message
doesn't actually imply any effect on hunger.
I started out just reformatting the function header for regularize()
but ended up doing miscellaneous other stuff, including some code
changes. I think the CHDIR code is a bit cleaner now, but shouldn't
have any differences in behavior.
Along the way I noticed that 'nethack -dpath' or 'nethack -d path'
modifies argv[] before PANICTRACE attempted to save argv[0], so would
break having nethack invoke gdb to get a backtrace. ('ARGV0' seems to
be unnecessary since 'hname' holds the same value, but I didn't get rid
of it....)
[Subject was actually "possible bug with shape-shifted vampires".]
The observation was that a pet vampire which took on fog cloud form
would just stay a fog cloud, rendering it nearly useless as a pet.
Fog clouds are too weak to attack dangerous monsters so are rarely
subject to damage from counter-attacks, so they wouldn't even get
killed to revert to vampire form.
Make a vampire in fog cloud form--hostile or tame--sometimes change
to bat form if not in view or out of missile range (the same criteria
used by vampires to change into alternate shape to begin with). Bats
are slightly more useful as pets and definitely more prone to revert
to vampire. The potential transformation from bat to cloud isn't
done randomly; that already occurs when encountering closed doors.
If a vampire, possibly in bat form, on the far side of a closed door
shifted shape to fog cloud in order to pass under the door, you were
told about the shape change if you could see it after being placed at
the door's location even if you couldn't see the vampire's pre-move
location. This is a bug introduced after 3.6.0....
Polymorph control gives the player a chance to accept or reject a form
change due to lycanthropy, but if it occurs during combat or movement
the player might type 'y' before realizing that the prompt is pending.
Provide a paranoid_confirmation setting for 'Were-change' to allow a
player to require "yes" instead of 'y' for that.
The existing setting 'wand' is renamed to 'wand-break' and now requires
at least two letters in the config file options instead of just 1. The
spelling of its synonym is changed from 'breakwand' to 'break-wand';
it can be shorted to as few as 2 letters (same as before) but if more
than 5 are present, the new dash is required.
Both 'wand-break' and 'Were-change' are placed before 'pray' in the 'O'
menu for paranoid_confirmation so that all the "yes" vs 'y' settings
are grouped together.
Bonus fixes:
Reverting from were-critter form to human (due to timeout) did not give
a player with polymorph control the option of remaining in creature
form; now it does.
The 'O' command's menu would not show "wand" (now "wand-break") in the
current value of paranoid_confirmation. (A post 3.6.0 issue, so no
fixes entry included.)
The revised Guidebook.mn has been tested; Guidebook.tex has not.
Some roles' quest message when returning the nemesis lair refer to
sensing the presence/aura/whatever of the quest artifact, but it might
not be there anymore. In reported case, the nemesis had picked it up
and later fled up the stairs to another level. Other situations are
possible; it's feasible for the hero to already have it. So provide
an alternate message, and some extra code to decide whether to use it.
Other anomalous messages, such as looking down on the dead body of a
nemesis who didn't leave a corpse, can still occur.
Change the wording slightly if the hero simultaneously (in theory)
reverts to normal form and splahes acid on his/her attacker. Giving
the passive counterattack message first would be better, but several
types of counterattacks need to know in advance whether the hero has
reverted, producing a chicken-vs-egg seqeuncing situation.
I also took out 'register' directives from a bunch of declarations
since they'd been pretty much applied blindly rather than in
circumstances where someone evaluated the situation and decided that
they might matter.
Reported for nethack.alt.org where impossible events in to-be-3.6.1
trigger a panic instead of just a warning, being polymorphed into a
vampire and draining something to 0 HP (rather than killing it with
the bite attack) didn't properly kill off the victim unless it was
also being drained from level 0 to level -1, resulting in impossible
"dmonsfree: 1 removed doesn't match 0 pending". If the hero got
another move before dead monsters were purged, applying a stethscope
to the victim could trigger an actual crash rather than an impossible
escalated to a panic. Other actions such as attacking again probably
could too.
A followup included a diagnosis and one-line patch. I expanded the
adjacent comment when manually putting the patch into place.
Show the original line from the config file, followed by the line number and
a specific error message. Also show all errors from the config file before
waiting for key press.
Allows the user to define arbitrarily named optional sections
in the config file, and select which of those sections are used.
For example:
OPTIONS=color
CHOOSE=char A,char B
[char A]
OPTIONS=role:arc,race:dwa,align:law,gender:fem
[char B]
OPTIONS=role:wiz,race:elf,align:cha,gender:mal
Reported directly to the devteam. Set hilite_pile on, become
invisible, pick up all but one item from a pile on the floor,
the pile symbol was still there afterwards.
This is yet another case of evil hack, because the gbuf doesn't
distinguish between object piles and single items, see
commit 854fe40609
Reported directly to devteam, the starting inventory for rogue chars
specified that their lock pick be +9, but the 'spe' enchantment field
is meaningless for that type of item. A followup report indicated that
it had been this way since at least the 3.0 era.
It might have been a typo, since 9 and 0 are next to each other. Or
perhaps before lock picks were introduced, rogues started with a
skeleton key. That assumes spe==9 meant skeleton key back in the days
when each key and lock had a designated shape and a non-skeleton key
had to match the lock's shape to work. I don't know whether that was
how skeleton keys were flagged and don't care eough to delve deeper....
Blessed scroll of fire allows to choose the explosion location like
scroll of stinking cloud does. This should make it somewhat useful
in the early game.
From the newsgroup, remarking on an usual cause of death seen at NAO.
Surviving a gas spore's explosion (via hit points, not from life-saving)
left "gas spore's explosion" as stale killer.name. Being killed by
opening a drawbridge (but not by closing or breaking one) only assigned
killer.name if it didn't already have a value, so the stale reason got
used: crushed to death by a gas spore's explosion.
This fixes it two ways: clear the stale value after surviving the
explosion, and assign a specific reason when opening the drawbridge.
This also removes stale reason for death set up by various drawbridge
activity. For the usual case, the hero only survives by life-saving
which does its own clearing of killer.name. But there might have been
cases where it was being set for the hero when operating on a monster,
so no life-saving involved. The drawbridge code is not the easiest
code to navigate....
The BONES_POOLS implementation added an extra dot to the bones file
name (only when enabled) which would be a problem on some filesystems.
This changes the name from "bonD0.15.3" to "bon3D0.15" which avoids
the second dot and also fits within 8.3 characters. To enforce that,
the maximum value for BONES_POOLS is now 10 (yielding single-digit pool
numbers 0 through 9).
BONES_POOLS==1 will omit the pool number (that's not a change, just a
reminder), yielding "bonD0.15" and so on. Right now, BONES_POOLS==0
is equivalent to BONES_POOLS=1, but it could be changed someday to
mean that bones files shouldn't be used if we decide to support that.
The pool number as a suffix was being included in content validation,
so it wasn't possible to move "bonD0.15.3" to pool 2 by renaming it to
"bonD0.15.2". I'm not sure whether that was intentional, but it seems
overly draconian. "bon3D0.15" can be renamed to "bon2D0.15" and then
be loaded by a game assigned to pool 2. Also, pre-pool bones can be
retained by renaming to any valid pool and should still work.
The three letter filecode for quest bones has made the bonesid be
broken since 3.3.0 introduced it (the three letter code, not bones-id).
"QArc.2" for level 2 of the Archeologist quest was being written into
the bones file as "rc.2", but worked as intended because validation
when loading bones had the same mistake. This fixes it to use "QArc.2"
when saving and accept either "QArc.2" or "rc.2" when loading, so 3.6.0
bones files (and existing to-be-3.6.1 bones) will continue to work.
Reduce the chance of a player playing on a public server encountering
their own bones, by implementing separate bones pools. The pool a player
belongs to is determined at game start, and only bones in that pool
are used. The sysconf BONES_POOLS allows the sysadmin to define how
many pools there are.
Reported directly to devteam: if applying a grappling hook towards
a target past some water ended up pulling the hero toward the target,
hero would drown without any chance of crawling out of the water.
It used hurtle() to move, and hurtle assumed levitation so didn't
check for entering pools of water except on the Plane of Water.
Previously the "fast-moving" when getting a target location
was always by 8 units. If this option is on, fast-moving
will instead skip the same map glyphs. This should be much more
useful for blind players.
Compound option whatis_filter, filters the eligible map locations
when getting a cursor location for targeting. Accepts 'n' (none),
'v' (map locations in view), or 'a' (map locations in the same area,
eg. room or corridor).
by Excalibur. Noticed on Reddit by Alex, the attempt to fix being
blasted twice by wielded artifact weapon when changing alignment
ended up preventing wielding other role's quest weapons. At the
moment I can't even see how it prevented the double-blast....
This backs out that change and fixes the double-blasting correctly.
When uwep and uswapwep are tested in advance of the rest of invent,
mark them as already processed before entering the loop that checks
all not-yet-processed inventory.
A couple of days ago when verifying the report about being forced to
pay for a second tin when eating one from a stack on a shop's floor,
wishing for 'tins' (rather than 'tins of foo meat') was repeatedly
producing tin wands instead. The name "tin" and the wand description
"tin" in objects[] were being given 50:50 chance for either one by
the 3.6.1 wishing code. Wishing for "tins of spinach" also gave me
a tin wand on the first attempt. Handle 'tin(s)' more explicitly.
This also does some reformatting.
Mark an old 'unconfirmed' bug as 'fixed'. The report was for win32gui
and I can't reproduce the problem or verify that it's gone, but I'm
sure enough about the cause and long-ago fix to put #H4725 to rest....
Report was that the menu for the name-from-discoveries-list command
was reusing a set of punctuation characters for each class of objects.
The key was that '!' was always first, and it is (' ' + 1) so the core
bug of erroneously specifying space for a selector on object class
header/separator lines was being used as the start of the selector
sequence. (Report that led to the fix was that typing space on that
menu always made it finish instead of advance to the next page.)
Reported directly to devteam, eating 1 of 2 tins of spinach from a
shop's floor forced the hero to buy both. (1 was gone, the other was
intact and now owned by the hero rather than the shop. Tins of other
contents behaved similarly.) The bug is easy to fix but not so easy
to explain: eating split one from the stack but passed the remaining
stack to useupf(obj,1) which also split one off and treated that as
used up. The second one was billed as used up and the first one was
added to the bill--as being subjected to a costly modification made by
the hero--and kept intact, now marked no-charge with hero obligated to
pay for it.
Eating 1 of N tins, for N greater than 2, billed for two, one gone and
the other now in a separate stack and marked no-charge. The remaining
N-2 stayed as normal shop goods in their original stack.
The fix is communicate the splitobj() for costly modification up-call
so that the use_up_tin code operates on the one which was split off
the stack rather than on the remainder of the original stack.
I think ^O changed when the dynamic key-binding code was incorporated.
It's a shortcut for #overview in all modes. To get the old wizard mode
behavior, use #wizwhere.
Add an entry for #terrain, expand several of the descriptions, and fix
up the formatting (remove periods in ^ section, align text in # section).
The different menustyle settings have been offering different degrees
of support for BUCX filtering:
Full : multi-drop, container-in, container-out
Trad, Combo: multi-drop
Partial : none (to be expected; it explicitly jumps past class
filtering, where BUCX gets handled, to a menu of all objects)
This adds pickup, container-in, container-out, multi-unwear/unwield,
and object-ID for Trad and Combo, and multi-unwear/unwield for Full.
(Full behaves like Partial for pickup--not sure why--and for object-ID,
bypassing filters to go straight to a menu of all applicable items.)
There are probably several new bugs--this stuff is very convoluted....
Report #5426 was classified as not-a-bug, but the underlying issue
can be improved.
For item selection where BUCX (bless/curse state) filtering is
supported (mostly for menustyle:Full, but there are a few actions
where Traditional and Combination handle BUCX too), 3.4.3 took the
union of object class and bless/curse state (so ?!B gave all scrolls
and all potions and every blessed item from other classes) but 3.6.0
changed that to the intersection (so ?!B gives blessed scrolls and
blessed potions, period). Since gold is inherently not blessed or
cursed it has been getting excluded during intersection handling
when that includes BUCX filtering. Report #5426 was from a player
who was used to choosing $X when putting newly acquired loot into a
container asking to have the old behavior reinstated.
The ideal fix would be to support both union ($ | X) and intersection
(?! & B), but implementation would be bug prone and the interface,
especially when done for menus, would be cumbersome. Instead, this
adds new boolean option, goldX, to allow the player to decide whether
gold is classified as uncursed--even though it is never described as
such--or unknown. The new-loot-into-container issued can be solved
either via $abcX, where abc lists all classes that have any X items
(when gold is included as one of the classes, its BUCX state is now
ignored for the current selection), or by setting the goldX option
and then just picking X for the types of items to put into the
container (or drop or whatever other action supports BUCX filtering).
The situations where menustyle:Full allows BUCX filtering during
object class specification and styles Traditional and Combination
don't should to be fixed (by extending BUCX support to Traditional
and Combination rather than removing it from Full, obviously).
The extra entry about 'A' was intended to go into the "post-3.6.0
code exposed by git repository" section since that's where the
impossible: "cursed without otmp" was introduced.
I think this finally quashes the "cursed without otmp" issue.
Various ways of destroying wielded weapon used setnotworn() rather
than unwield(), so the previous change to have unwield() clear the
pending W_WEP bit from takeoff.mask wasn't sufficient to prevent
'A' moving on from another item (blindfold--it's the only thing
processed before primary weapon) to weapon which wasn't there any
more. Also, if weapon was already set in takeoff.what to be
processed on the next move, clearing W_WEP from takeoff.mask wasn't
sufficient either.
Move the previous unwield() 'fix' to setworn() and setnotworn() and
extend it to include cancel_don() if the item being replaced or
removed is in progress or scheduled for next. (Most of the time,
remove_worn_item() has already done that before setworn() or
setnotworn() is called.)
This adds new utility routine strNsubst(), a more versatile version
of the existing strsubst(), that can replace the Nth occurrence of
a substring rather than just the first, and replaces all occurrences
if N is 0.
When working on vampire shape-shifting messages a few days ago I
noticed that a constructed pline/sprintf format was vulnerable to
the player giving the vampire a name with '%' in it and included
a fix for that. This fixes two other instances of the same
vulnerability: a monster with reflection triggering a floating
eye's gaze and the hero using a silver weapon against a silver-
hating monster.
I didn't do a lot of experimenting with the failure, just assigned
the name "foo%s" to the floating eye or the weapon. The resulting
feedback for the relevant messages was garbled due to parameters
being substituted in the wrong place. When that caused there to be
too few arguments to satisfy the format, the final message included
"null" for the missing one rather than triggering a crash while
trying to format something arbitrary from the stack.
I don't think these bugs provided sufficient user control to be
vulnerable to stack manipulation that does something naughty.
I found the dynamic format strings by searching for "%%". There
may be others scattered around the code which don't have that as
an indicator....
Noticed while composing a reply to the #H5547 report about named
vampire shape-shift message. The message when a vampire (possibly
in vampire bat form) turned into a fog cloud in order to pass under
a closed door was using a stale cached mon->data value when choosing
the verb. So normal fog cloud or vampire already in fog cloud shape
would "flow" under the door, but newly shifted fog cloud would "ooze"
under the door. I saw this while testing the previous patch but its
significance didn't register at the time.
Report was about "Pet vampire" but the relevant aspect was that the
vampire had been assigned a name, not that it was tame:
You observe a Hilda where a Hilda was.
Investigating this has uncovered two other bugs, one potentially
serious. m_monnam() overrides hallucination but seems to be getting
used to some situations where hallucination should be honored (several
instances). Dynamically constructed format strings are including
monster or object names in the format (rather than the usual use as
arguments), so player assigned names containing percent signs could
cause havoc (a few instances). This fixes some of the former and one
of the latter, but doesn't deal with various other cases revealed by
grep.
> Green dragons should probably not cough in their own breath.
They took no damage, but they did become blind. Make creatures who
breath poison gas (adult green dragons, the Chromatic Dragon) be
immune to gas clouds like non-breathing creatures are.
There's no way to distinguish gas left behind by dragon breath from
that created by scroll of stinking cloud, so gas breathers are no
longer affected by the latter.
Fix a couple of weird messages issued when a shape-shifted vampire
is "killed" and reverts to regular vampire form instead of dying.
First weird one was when vampire has been given a name, as reported.
Second was noticed while fixing that: when cause of death destroys
the creature so thoroughly that there'd be no corpse, the alternate
phrasing for noncorporeal or amorphous form should be used.
old:
The Dracula suddenly transforms and rises as Dracula!
The vampire bat is disintegrated. The seemingly dead vampire bat
suddenly transforms and rises as a vampire!
new:
Dracula suddenly transforms and rises as a vampire!
The vampire bat is disintegrated. The seemingly dead vampire bat
suddenly reconstitutes and rises as a vampire!
Attempting to name the relevant type of item with an artifact's name
(such as a runesword with "Stormbringer") fails with "your hand
slips" in order to prevent turning the item into an aritfact. Since
that only happens when the name is valid, it indicates that the hero
is literate so violate illiterate conduct.
(Naming items in general doesn't affect [il]literacy so that player
can assign names to inventory or stash items to maintain notes.)
This issue has been around for a while but wasn't noticable to players
until some post-3.6.0 tweaking of end of game disclosure. When testing
the DUMPLOG artifact_score fix, I level teleported to the Astral Plane
and performed a cheat ascension. Final disclosure listed high priests
as extinct. Same thing would happen after visiting Moloch's Sanctum
instead. (The latter didn't interfere with creating the Astral high
priests if you got that far, just as creation of the first one there
didn't prevent the other two.)
I forget why high priests are flagged as unique (something I think
I'm responisble for...), but they shouldn't share unique's setting of
extinct during monster creation. (They could be set that way after 4
are created, but this fix doesn't do that. It just treats them like
ordinary monsters so you'd need 127 or 255 or some such to make them
become extinct. Unlike other creatures with a special creation limit,
high priests can be produced when aligned priests gain experience--an
event that I don't recall ever noticing happen.)
