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.
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, 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.
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.
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.
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.
From a bug report, attempting to respond with ESC when playing an instrument
just continued with the playing sequence. This adds a q choice to the
"Improvise? [yn]" and "Play passtune? [yn]" prompts, and also checks
for ESC as the 5-note tune when not improvising, yielding "Never mind"
and not using up a turn if the player opts not to play any music.
I put the fixes entry in the new features section since the old
behavior wasn't much of a bug.
Someone in the newsgroup has a keyboard where typing '#' is difficult
or impossible to do, and mentioned that he could use Alt+r to get #rub but
was playing a knight and had no way to get #ride. Turns out that there
are several normal-mode extended commands that lacked a meta shortcut.
Since meta chars are case sensitive, I've added Alt+R for #ride, plus
M-A for #annotate, M-O for #overview, M-C for #conduct, and M-T for #tip.
Unfortunately, I've been unable to test them. It turns out that
nethack mode in PuTTY doesn't change the Alt key into a meta shift, it
causes the digits on the number pad to send vi-style movement letters
(with support for shift+digit and ctrl+digit to send modified letters).
That seems relatively useless to me, and I haven't figured out how to
force on high bit for arbitrary characters so can't activate nethack's
meta-key shortcuts.
The Guidebook has been updated via copy+paste and is untested too.
From a bug report, message sequence
when throwing a poisoned weapon which loses its poison was confusing.
|The dart is no longer poisoned.
|The dart hits the acid blob.
|The poison doesn't seem to affect the acid blob.
This patch makes the first sentence come out last.
[It appears that poisoned weapons thrown/shot by monsters or traps
never lose their poison. That can't be right....]
From a bug report, a stunned monster
moved away from the hero, but remained holding him. That behavior was
still present in the dev code, although the hero was free to move and
would become unstuck as soon as he did so. I don't know how many fixes
for this sort of thing have been made, but they evidently haven't been
made in the proper place. [Perhaps it really ought to be done as a
monster is placed somewhere on the map?]
From a bug report, black dragon breath
destroys closed doors didn't acknowledge hitting secret doors. bhit()
reveals secret doors, but zap_over_floor() (called by buzz() for ray-type
wands and spells, and for breath attacks) didn't check for hitting those.
When testing the fix, I noticed that feedback for an explosion caused
by breaking a wand was worded oddly for zaps like magic missile which don't
damage doors. "The door absorbs your bolt" didn't make much sense; what
bolt? That was first changed to "absords your blast", which still sounded
weird, then to "absorbs the blast", which seemed better but was inaccurate.
Next was "absorbs some of the blast" since the explosion continues to hit
adjacent spots, but since it still has full strength that wasn't accurate
either. It's finally become "The door remains intact." Unlike with zaps,
there is no additional range being lost, so no reference to absorption.
From the newsgroup: player saw "The spell hits the <monster>?"
where the question mark punctuation reflected negative damage occurring.
Another player diagnosed it as a 2 point force bolt (from 2d12 dice role)
modified by -3 penalty for hero who has Int less than 10. This changes
spell_damage_bonus() to avoid reducing damage below 1 point.
From the newsgroup: someone using <Someone>'s level-flip patch
(to transpose special levels left-to-right or top-to-bottom or both in
order to get more variety from them) ended up in solid rock. When
climbing the stairs up from the Valley to the Castle, goto_level() was
hardcoded to find a spot in the extreme lower right corner. If the level
is turned upside down, solid rock from an unused row at the top edge of
the map ends up at the bottom, and the placement code could put the hero
there. That code only checked for walls and monsters being in the way,
not rock. Also, if the level is flipped side-to-side than hero ends up
in same area as the upstairs rather than on opposite side of the Castle.
This switches to the same teleport-region code used for other level
changes which don't arrive on stairs; such regions get flipped along with
map by that patch (I hope). Even though no such fix is currently needed
for unmodified nethack, this change gets rid of the special case Castle
placement code entirely, simplifying both goto_level() and u_on_sstairs()
in the process.
The Castle's existing from-below region covers the rightmost half-
dozen or so columns across all rows, so offers a bigger landing zone than
just the bottom corner. That could be tweaked within castle.des but I
don't think it needs to be.
Recent newsgroup discussion complained about a pearl ring becoming
rusty. That has no effect on game play but does feel weird. Rings which
are described by their gems specify a material based on the gem rather
than on the band, so making pearl rings be made out of iron didn't fit.
The substance pearls are made of is the same as in the shells of the
oysters or whatever critters excrete them. The closest matches available
seem to be mineral and bone; I've gone with bone here.
From a bug report, the 'D'
command would list 'u' as an item category choice if you were carrying
unpaid items inside a container, but if those were the only unpaid items
then nothing would happen once the dropping stage was reached. Applied
to all menustyles (except partial, which bypasses categories and goes
straight to a menu listing all items). There were two alternatives for
the fix: suppress 'u' as an applicable category when it only applies
to container contents, or include the container among the drop candidates
even though it isn't an unpaid item itself. I went with the latter; it's
simpler to implement and also feels a little more intuitive than behaving
like there aren't any unpaid items present.
[See cvs log for src/role.c for a much longer description.]
When picking role, race, and so forth, new menu entries allow you to
pick any of the other items before the one currently being handled. After
picking all four of race, role, gender, and alignment (or if you answered
'y' to "shall I pick for you?"), there is a followup prompt to confirm the
choices. It's a menu which also provides a chance to rename the character.
This has only been implemented in win/tty's player_selection(), with
some support code in the core that might be useful to other interfaces.
And so far, the chance to rename is only presented as a menu choice if
you've given an answer to "who are you?" prompt earlier during startup.
Also, ports that use pcmain.c aren't able to perform hero renaming yet.
In #H1820, <email deleted> reported that helms
of opposite alignment didn't work for monsters. There's never been
any attempt to implement that, and it wasn't omitted by accident, so
I wouldn't classify it as a bug. But it does seem buggy that temple
priests and minions of <deity> would be willing to put such helms on
and risk changing allegiance to another deity. This lets other types
of monsters still wear helms of opposite alignment as ordinary head
protection, but the explicity aligned creatures won't do so anymore.
use_whip() prompts with getdir(), which doesn't prevent the player
from deliberately pointing off the edge of the map, so the bullwhip bug
was more general than yesterday's fixes entry. Being confused or stunned
could trigger a problem but one could happen without them.
From a bug report, applying a polearm to make a
short-range ranged attack didn't scuff any engraving you were standing on,
unlike ordinary melee and throwing/shooting attacks. Grappling hooks had
the same omission. Fixing it led to several other minor bugs. Attempting
to target an unseen monster's spot with polearm or grapnel would yield some
permutation of "wait, there's something there" but draw the 'I' glyph at
the wrong spot. It used <u.ux+u.dx,u.uy+u.dy> instead of the actual target,
so put the 'I' one step in front of your most recent move (or throw or zap
or whatever last set u.dx and u.dy). Giving ESC when prompted for target
spot failed to use up a turn even when the polearm or grappling hook had
just been auto-wielded for use. Neither use_pole() nor use_grapple() set
`notonhead' for hmon() (called via thitmonst() in their cases; this was
academic since plain physical damage attacks don't actually care about it).
[The bad 'I' placement was a post-3.4.3 bug.]
Applying a bullwhip to attack an adjacent monster didn't have any of
those issues but did have the possibility of targetting off the edge of
the map when standing at that edge while confused or stunned.
Applying a polearm to target an 'I' would yield "nothing happens" if
the unseen monster wasn't there anymore, and it didn't bother to remove
that 'I' from the map. After changing it to do so, the phrasing no longer
made any sense. This led to a slightly bigger change than I intended:
since statues are now shown as gray monsters (does that work for tiles?)
instead of as chunks of stone, they are likely to be intentional targets
sometimes, so polearm attacks now handle them differently from other
non-monster locations. [I hope that other attack forms don't need
similar handling. Melee certainly doesn't, since walking onto the spot
is enough to distinguish statues from monsters. Having the missile pass
right through a statue's location probably suffices for ranged attacks.]
Noticed while testing the patch for monster ranged attacks when hero
is hidden. Using #monster while in small mimic form would hide you, as
intended, but the first monster (or last monster?) who hit you hand-to-hand
would be grabbed ("It gets stuck on you."). Unlike large and giant mimics,
small ones lack such a grab attack so when you eventually returned to
normal form, u.ustuck would remain set and you would end up being stuck
to an arbitrary monster instead of releasing it from your grasp.
From a bug report, a hero who had
eaten a mimic corpse and was stuck mimicking gold was hit by an approaching
dragon's breath attack. Make monsters usually fail to notice that you're
lined up for their ranged attack when/if you're hidden from them.
The intersection of a couple of recent patches: noticed when
updating movement as a grid bug, and accentuated when fixing the attempt
to move down while levitating. If you can't reach the floor due to
levitation, don't show '>' in the list of likely candidate directions for
the prompt when digging. It was always included so that the list could
never be empty, but it's a poor suggestion to the player when levitating.
Use '<' instead in that situation; also a poor suggestion, but silly
rather than unintentional. :-)
This only affects the bracketted part of the "In what direction?"
prompt, not the actual digging (and player can pick any direction whether
it's shown in the prompt or not, so the digging code is already prepared
to handle attempts to dig up as well as down anyway).
A mimic posing as a statue was displayed as a tengu statue (and
recognizeable as such now that statues are displayed as the corresponding
monster rather than rock-class back tick), but the lookat code described
it as a giant ant statue (since there was no obj->corpsenm available to
indicate the monster type, it defaulted to 0). This adds monst->mextra
field `mcorpsenm' so that mimics have a place to remember what sort of
statue or corpse they are mimicking. And it picks a random monster type
when they take such forms so that the old tengu hack becomes irrelevant.
newmextra() and newoextra() initialized pointers via memset(...,0)
which is not portable; switch to explicit assignments. The wizard mode
code to display memory used for monsters and objects added in amounts
for the miscellaneous things pointed to by monst->mextra and obj->oextra
structs but didn't include memory for those structs themselves; add it.
Simplify monster save/restore slightly; there's no need for extra zeroes
to represent monst->mextra->X sizes when monst->mextra is null.
Update the startup banner for 2009. I should have done this with a
separate patch but I'm taking a shortcut. :-]
From a bug report, attempting to move
diagonally when poly'd into grid bug form doesn't give any useful
feedback in the general case, and in the specific case of using 'u' to
try to move northeast with vi-style keys, it performs #untrap instead.
Diagonal directions were being classified as non-movement when in grid
bug form, so the feedback was usually just "unknown command". But 'u'
is bound to untrap as a a convenience to players who use num_pad-style
movement keys. (Move commands don't actually reach the assigned key
part of command handling, so for forms other than grid bug, !num_pad 'u'
moves NE despite the untrap function given to that key.)
Split the diagonal handling out from movement command recognition.
It now gives "you can't get there from here..." if player tries to move
diagonally as a grid bug. For direction prompts, it now gives "you can't
orient yourself that direction" instead of popping up the command assist
display. (In the prompt string showing likely candidate directions for
digging, diagonal handling for grid bugs is academic because they aren't
strong enough to wield pick-axes.)
From a bug report, a shopkeeper who's been
polymorphed into a limbless creature shouldn't be able to come take your
possessions when you die since you can't pick up items when in that shape.
Rather than add new special case handling for shopkeepers, prevent them
from taking on shapes that render them unable to behave like shopkeepers
so that they can continue to catch thrown pick-axes and assorted other
things that would otherwise need a lot of extra checking introduced.
Ditto for temple priests, vault guards, and quest leaders. Restriction
also applies to wizard mode use of #monpolycontrol, the only place where
players can actually notice this.
It could--perhaps should--restrict them even further, forcing forms
that retain speech capability, but I didn't go that far.
This started out as a one line change. After I saw someone in the
newsgroup mention that Sunsword's light was inferior to that of a lamp,
I decided to make it work better (than in 3.4.3, that is, becoming the
same brightness as a lamp) when blessed and worse when cursed (useless to
hero but still visible if wielded by a monster). But then it needed to
change light radius when its curse/bless state changed, and it needed
message feedback when doing so, and that got kind of complicated. I
wouldn't have bothered if I'd known what I was getting into, but I don't
want to throw it away now that I've done all this work....
Sunsword now gives a light radius of 3 when blessed (same as a lit
lamp), radius of 2 when uncursed (same as a lit candle and as it has been
providing since added in 3.4.0), and a radius of 1 when cursed (nearly
but not completely useless, as mentioned above). Also, it now "shines"
rather than "glows" since we usually use the latter for temporary effects.
Allow potions thrown straight down while hero is mounted to target
steed instead of always hitting the floor. There's already a fixes35.0
entry for potions hitting worn saddle instead of the creature wearing it,
but that only happened when thrown at a nearby saddled monster, not when
the hero was stuck mounted on a steed with cursed saddle.
Eight separate "the <obj> glows <color>" messages were too many...
(four for dipping an item in holy/unholy water, four more for throwing
either of those potions at a saddled monster). Replace the repetitive
code, leaving just two such messages. Setting of bknown flag for the
dipped object is the only intentional change here. That used to be done
unconditionally but now requires that the hero see the glow color.
From the newsgroup:
As you read the scroll, it disappears.
The scroll erupts in a tower of flame!
Your spellbook of force bolt catches fire and burns!
[...]
Your potion of paralysis boils and explodes!
Something seems to be holding you.
Do you want your possessions idenified?
This character survived the burning and boiling objects then succumbed
to the initial flame explosion.
A fatal explosion calls done() without any explanation. Or rather,
it dated to the time where it would immediately follow "the scroll erupts
in flame" (or "you are caught in <some kind of> explosion") without the
chance for intervening messages. Then when item destruction was moved
sooner (for bones file purposes), message sequencing was left dangling.
This patch adds a new "it was fatal" message in front of done().
From a bug report, the feedback
you get when a monster summons insects or snakes is the same when blind
as when you can see. A comment in the code stated as much, but fixing
it is relatively straightforward. (Or not; there are actually a lot of
cases to be handled; this covers enough of them, I hope.)
Suggested by <Someone> <email deleted>, fainting from lack
of food while wielding a cockatrice corpse should fall on that corpse
and be fatal, like triggering a pit or moving down stairs while too
heavily encumbered. I put the fixes entry in the new features section
even though it probably qualifies as a bug.
From a bug report, getting "your
clumsy kick does no damage" when attempting to kick the location of a
concealed mimic or hidden monster didn't bring the target out of hiding.
Mentioned by <email deleted> in his report about
sound anomalies, it was possible for a sleeping hero to "gladly start
removing armor" when attacked by a nymph or succubus. The code
explicitly wakes up the hero if he has fainted from lack of food because
"can't charm without waking you" (according to the existing comment),
but it didn't handle other forms of sleep and paralysis. You could get
|You fall asleep.
|The wood nymph charms you. You gladly start removing your armor.
|The combat awakens you.
Now in the same situation you'll get
|You fall asleep.
|You wake up.
|The wood nymph charms you. You gladly start removing your armor.
From a bug report, the text change applied
when you try to give an artifact's name to am item of that artifact's type
would choose a letter from 'a' through 'y' when replacing the randomly
selected target letter. Rather than fixing the off by one bug which
prevented 'z' from being chosen, this switches to the existing routine
used for mangling engravings. (Unfortunately the fix is not as simple as
first expected, because wipeout_text() doesn't guarantee to change text
which has spaces in it and all the quest artifact names have those.)
From a bug report, pets able to eat
acidic and poisonous corpses (black naga was the case cited) would eat
green slime corpses without turning into green slime, unlike the hero.
This prevents such monsters from eating green slime unless they're
starving, implements transformation into green slime for the case where
it does get eaten, and prevents non-pet gelatinous cubes from devouring
such corpses. meatobj() is reorganized to hopefully become clearer, and
it removes the assumption that the object eater is a g.cube in case we
ever adopt slash'em's "tasmanian devil" monster.
Monsters with digestion attacks who swallow green slime monsters
are turned into green slime, but ones who swallow hero poly'd into green
slime are not. This doesn't address that.
When dragon scales or dragon scale mail becomes embedded in poly'd
hero's skin, the '[' command would report "you are not wearing any armor"
but the '*' command showed "a set of <color> dragon scales (embedded in
your skin)". The '[' feedback is more accurate but the '*' feedback is
probably more useful. This changes '[' to be more specific when lack of
worn armor is accompanied by embedded dragon scales/scale mail.
I put the fixes entry in the new features section since the old
behavior wasn't a bug.
From a bug report, polymorph of self due to
breaking a wand also polymorphed various items that were dropped in the
process, unlike the case of zapping polymorph at monsters which excludes
dropped items from being poly'd. This polymorphs the pile at the hero's
feet before polymorphing the hero. I first tried to handle it using
obj->bypass like with monsters, but that didn't work. Post-3.4.3, the
bypass handling is also used for polyself (by retouch_equipment()) and
it was getting reset at an inconvenient time.
He also complained that he failed to get "you feel shuddering
vibrations" when some polymorphed objects got destroyed. That message
is issued by weffects() which do_break_wand() doesn't call. It ought to
be fixed, but this patch doesn't address it.
Lastly, add code to prevent objects guarded against polymorph via
obj->bypass from getting used up when creating polypile golems.
Inventory formatting for a single slime mold object would be strange
if the user entered a plural word or phrase for fruit name. Forcing the
user-specified value to be singular as it's being set up as current fruit
avoids that. [Something like <Someone>'s "bunch of grapes" is unaffected;
it's already singular and correctly handled as such by makesingular().]
This may have a side-effect of limiting the creativity of some players
who try to trick others via bones files gimickery, but I think the extra
consistency in object naming during ordinary play is worth it.
According to the cvs log info, this issue was actually mentioned in
a patch I made ("fix M203...") in October, 2005. I have no recollection
of that at all....
From the newsgroup: if no co-aligned artifacts are available when
attempting to give the first divine gift for an offered corpse, nothing
would be given. Since the gift counter stayed at 0, subsequent attempts
to select one would still treat it as first gift and always fail again.
The first divine gift from offering corpses must match the hero's
alignment; after that, nonaligned artifacts (Frost Brand, Giant Slayer, &c)
are added to the pool of choices for further divine gifts. It's pretty
easy for a chaotic character to use up the co-aligned artifacts before
getting any divine gift. There aren't many chaotic ones and some are
inelgible due to being race-specific items. Wishing for Stormbringer--or
loading a bones file which contains it--and creating Sting and Orcrist
via naming will do the trick for an elven hero.
This patch expands the pool of candidates to include nonaligned
artifacts during first gift selection if no co-aligned ones are available.
From a bug report, wearing
(or removing) an amulet of restful sleep was overriding permanent
sleepiness which had been obtained previously via eating another amulet.
The setting of timeout clobbered the non-timeout bits for that intrinsic.
This also adds the timeout counter for sleepiness to enlightenment
feedback in wizard mode. Unrelated: rephrase enlightenment feedback for
adornment to more accurately describe what that does.
Reported recently by <Someone>: probing feedback while engulfed
shouldn't claim that the monster is not carrying anything when the hero
is inside of it. The simple case where it's not carrying anything else
was a trivial one line change; handling inventory plus hero was trickier
and I wouldn't have bothered if I'd realized what it was going to take.
But it's done now; trivial case
The purple worm is not carrying anything besides you.
and harder case
The purple worm's possessions:
Weapons
a - an uncursed dagger
Swallowed Creature
> - human archeologist called wizard
Implement something <Someone> suggested a long time ago: eating a
disenchanter corpse has a chance to remove an intrinsic. Uses the same
routine as nighttime gremlin attacks, which chooses an intrinsic randomly
and attempts to remove it, so has no effect if it chooses one the hero
lacks. This can be used to remove "aggravate monster" but is much more
likely to target something the player wants to keep. [By the way, a lot
of potential candidates are missing: sleep, shock, and disintegration
resistance and teleport control come immediately to mind.]
Also, it has been bugging me that you can get both strength and
fire/cold/shock resistance from the same fire/frost/storm giant corpse.
The code prevents mind flayer corpses from conferring both intelligence
and telepathy, so strength handling was inconsistent (even though it
predated mind flayers...). This causes strength boosting to be treated
as an extra candidate when selecting an intrinsic to confer, so you'll
either get strength or resistance (which might be a no-op) but not both
from those giants. And it special cases the other giants to have the
same 50% chance for boosting strength, even though the alternative in
their case is to do nothing instead of trying to confer something else.
Lastly, it now gives a message when you succeed in gaining strength.
From a bug report: an exposed eel in an isolated
pool--swamp rooms sometimes produce those--would never re-hide no matter
how long you left its vicinity. Re-hiding is part of post-move handling
and an eel with no adjacent water to move into would never reach that bit
of code since it didn't move anywhere. The code used to re-hide monsters
when you return to a previous level was ignoring eels altogether. Give
unhidden eels a chance to hide earlier during monster movement and also
when the hero returns to their level.
Also a really minor bit to slow down hit point loss of eels out of
water. I don't think anybody reverse genocides krakens to get experience
any more since they don't provide a big bonus when they're out of water,
so this change won't have much of an affect.
Three years ago <email deleted> reported that
stepping off the end of inventory via typing space to go to the next menu
page wasted his identify scroll. He suggested that some people might do
that because they don't know how to back up in a multi-page menu. I
pointed out the Guidebook section that describes < and ^ to go back one
page or back to start and left things at that. However, traditional mode
reprompts if you step through all of inventory without choosing something,
so this changes identify-via-menu to do likewise. You can dismiss the
menu with ESC to really avoid choosing anything.
This also makes identification of N items when you're carrying N or
fewer unID'd things behave the same as identify all: identify everything
without any prompting.
I'm not a contender to win any spelling bees. (Mimicker does't
seem to even be a real word; I'm not sure if it ought to end in "or"
instead of "er". But changing it to "mime" would be too weird.)
