Orcs are innately poison resistant, so orcish wizard's random ring
shouldn't be poison resistance. Presumeably an orc who is bright
enough to become a wizard is not so dumb as to bring a useless ring
with him/her into the dungeon....
Make wishing for an artifact and not getting it because it already
exists break never-wished-for-artifact conduct. The wish was made
even if the result wasn't what the player wanted.
You kill poor goblin.
"poor" implies a pet; pet has a name; "the" is omitted for named
creature; hallucination suppresses name, so "the" needs to be
reinstated.
You kill the poor goblin.
Make it be cannabalism for a were<foo> to eat a <foo> corpse.
Let werejackals summon foxes and coyotes in addition to jackals,
and werewolves summon wargs in addition to wolves and winter wolves.
Reported by me ;-} during beta testing last Fall, engulfers have a
tendency to re-engulf the hero immediately after expelling him/her.
Use mspec_used (set when expelling rather than engulfing) to make
them wait a turn or two. Initially that made the too-soon engulf
attacks always miss, so this changes too-soon engulf to a touch or
claw attack instead. Some tuning in damage or message may be needed.
Reported directly to devteam in late December, when blind and
lacking gloves, you could safely locate cockatrice corpses on the
floor by using 'm' prefix to move without pickup followed by 'e'
and then answering no when ask whether to eat a cockatrice corpse.
When underwater and an attempt to move onto adjacent land fails
because the destination is a wall or solid rock or closed door,
report that there's an obstacle instead of just silently failing
to make the move.
If the user has 'mention_walls' option set, give feedback for
failing to move diagonally into or out of a doorway instead of
just silently not moving.
Having 'mention_walls' set could yield "you cannot pass through
the bars" when travel was testing (not moving) for a path past
iron bars, and when it happened it tended to be delivered a whole
bunch of times.
Config file handling remembers the name of the last config file
read in order for options processing to use it in messages, but
it was also reused as default config file name if user-supplied
config file name failed access() test. So the SYSCF file became
the default user config file after it was used. The config file
handling was a real mess.
This patch fixes it for Unix but there is a lot of scope for
typos in the changes for other platforms. Testing is needed.
The character attributes (^X) description of alignment includes
information about whether the alignment is different from what it
started out as, and is used in a verbose sentence which names the
entire three-deity pantheon. Someone thought
You were chaotic, temporarily on a mission for Foo
who was opposed by Bar (lawful) and Quux (neutral).
was in need to better phrasing. It looks straightforward to me
(the temporary aspect indicates that a helm of opposite alignment
was causing 'chaotic'). I was going to mark it "won't fix" until
I noticed that you could also get
You were lawful, now on a mission for Bar
(when permanent, one-time alignment change was causing 'lawful').
The first one is changed for the present tense:
You are chaotic, currently on a mission for Foo
and stays the same for end-of-game disclosure past tense. I
considered using "formerly"--as best past tense of "currently"--
but it could be confused as a reference to the original alignment
rather than the alignment in place when the game ended.
The second is unchanged for present tense:
You are lawful, now on a mission for Bar
For past tense, it's changed to:
You were lawful, belatedly on a mission for Bar
Past tense of "now" should be "then", but if used it that message
it would sound absurdly stilted. "Belatedly" is meant to suggest
that if you intended to be on a mission for Bar, you should have
started out as lawful. (It's beside the point that some roles or
races couldn't start out at as lawful.)
Both of these changes leave something to be desired, but I'm
going to mark the bz entry closed.
...when alignment was toggled by helm of opposite alignment. The
touch/retouch code is quite convoluted, but I think this simple
change is the right fix.
The if/elif/else/endif interpretor for '&' command data was too
simplistic. It would allow multiple else clauses, elif clauses
after an else clause, and worst of all, accept a should-be-rejected
conditional block if an else or elif which evaluated true followed
an elif which evaluated false which in turn followed an earlier
true clause. (dat/cmdhelp trigger any of those bugs.)
Implement a rudimentary if/elif/else/endif interpretor and use
conditionals in dat/cmdhelp to describe what command each keystroke
currently invokes, so that there isn't a lot of "(debug mode only)"
and "(if number_pad is off)" cluttering the feedback that the user
sees. (The conditionals add quite a bit of clutter to the raw data
but users don't see that. number_pad produces a lot of conditional
commands: basic letters vs digits, 'g' vs 'G' for '5', phone
keypad vs normal layout of digits, and QWERTZ keyboard swap between
y/Y/^Y/M-y/M-Y/M-^Y and z/Z/^Z/M-z/M-Z/M-^Z.)
The interpretor understands
'&#' for comment,
'&? option' for 'if' (also '&? !option'
or '&? option=value[,value2,...]'
or '&? !option=value[,value2,...]'),
'&: option' for 'elif' (with argument variations same as 'if';
any number of instances for each 'if'),
'&:' for 'else' (also '&: #comment';
0 or 1 instance for a given 'if'), and
'&.' for 'endif' (also '&. #comment'; required for each 'if').
The option handling is a bit of a mess, with no generality for
which options to deal with and only a comma separated list of
integer values for the '=value' part. number_pad is the only
supported option that has a value; the few others (wizard/debug,
rest_on_space, #if SHELL, #if SUSPEND) are booleans.
An attempt to simplify handling of missiles which stop at hero's
location (either hit or reached end of range) would have resulted
in missiles that hit the hero not being put on the map. I had
realized this earlier but for some reason didn't get around to
dealing with it before the previous commit.
Some reformatting of the recently added pet ranged attack code.
The redundant--but different--multishot volley code has been replaced
so that there are only two versions (hero and monster) instead of
three (hero and monster vs hero and pet vs other monster). The monst
version was out of date relative to post-3.4.3 changes to the hero one.
The pet version was way out of date and had some bugs: wielding an
elven bow gave a +1 multishot increment to volley count for fast weapon
even when throwing something rather than shooting arrows, wielding any
weapon which had at least +2 enchantment gave 1/3 enchantment bonus to
volley count when throwing instead of shooting shoot ammo, and a pet
which got killed in the midst of a multishot volley--perhaps by a gas
spore explosion or some other passive counterattack--would keep on
shooting/throwing until the volley count was exhausted.
Pet use of ranged weapons is not ready for prime-time. Pets don't
hang on to missiles or launchers+ammo, they just drop them if there is
no target immediately available.
Make the whatdoes ('&' or '?f') command support the 'altmeta' option
for meta-characters generated by two character seqeunce 'ESC char'.
Also, make it be more descriptive when reporting "no such command"
by including the numeric value it operated on when failing to match
any command. That might provide a way for us to get some extra
information when players report problems with odd keystrokes: we ask
them to type such at the "what command?" prompt and then tell us what
numbers come up.
It's been given a help file to deal with assorted idiosyncracies
which can come up when querying what keys do. Unfortunately that
ended up being way more verbose than intended.
Installation of the extra data file has only been done for Unix.
Other platforms will get "can't open file" if they respond with
'&' or '?' to the "what command?" prompt. The command will still
work though, just without the extra text.
Restore the ability to look up a single space by 'name'.
I thought mungspaces("<all spaces>") kept one space, but it doesn't.
It's a lucky accident that unnaming monsters and objects still works.
There may be other places which intend to give a special meaning to
a single space that don't still work....
This is the Pet ranged attack -patch by Darshan Shaligram,
with the spellcaster parts removed to keep it simpler.
Pets will now throw, spit and breathe at other monsters.
When examining a buried object (after detection has revealed it),
suppress setting of its dknown bit when hero is adjacent. [That
couldn't actually happen, because the glyph on the map that we're
trying to examine would be replaced by one for whatever is on the
surface when sighted hero moved next to it, and an earlier clause
in the same test prevents blinded hero from getting to this point.]
Change most instances of detection to offer the player a chance to
move the cursor around on the map so that the getpos() autodescribe
feature can explain things that might go away as soon as the
current detection completes. The few instances that don't offer
such a chance are the ones where everything which has been revealed
will still be there once the action finishes (such as regular magic
mapping and blessed/persistent monster detection).
There were quite a lot of inconsistencies in things like handling
for detection while swallowed or underwater. I didn't keep track
of them to distinguish between 3.6.0, current dev code, or my patch
in progess. They should be much more consistent now but without a
comprehensive fixes36.1 entry.
Blessed clairvoyance (divination spells at skilled or expert) now
shows monsters as well as terrain. I first had it like that for
any clairvoyance, but having getpos/autodescribe kick in every 15
or 30 turns once you have the amulet--or pay the appropriate amount
to a temple preist--was nearly unplayable. When it only follows an
explicit spell cast it is not intrusive.
Hero was poly'd into a hider monster and was swallowed by something.
Attempting to hide via '#monster' gave "You can't hide while you're
being held." It correctly blocked hiding due to u.ustuck but the
feedback ignored the possibility of u.ustuck+u.uswallow.
Some groundwork for detection enhancements.
you.h - just formatting
flag.h - add iflags.save_uswallow so that u.uswallow manipulation ...
save.c - ... can be undone if a hangup save occurs
Make the '^' command catch up with far-look as far as identifying
trapped doors and trapped chests revealed by confused gold detect.
You need to be blinded when approaching the '^', otherwise as soon
as you can see a door or chest or whatever else is there the fake
bear trap will be removed from the map.
rnd_otyp_by_namedesc() had an off by one error when choosing which
matching item to return, making it impossible to successfully wish
for the Amulet of Yendor, always yielding the plastic imitation.
n == 2, maxprob == 2
prob = rn2(maxprob); => 0 or 1
i = 0; while (i < n - 1 && (prob -= ... + 1) > 0) i++;
always exited the loop on the first test of the condition because
subtracting 1 from 0 or 1 never yielded a result greater than 0.
It's still suboptimal: "amulet of yendor" should find an exact match
and should never return "cheap plastic imitation of amulet of yendor"
from the partial match.
I think biasing the choice among multiple candidates based on their
generation probabilities only makes sense when all the candidates are
within the same class. If scroll of light occurred in 5% of scrolls
and spellbook of light occurred in 10% of spellbooks (both percentages
pulled out of thin air), having "light" get a 2 out 3 chance to be a
spellbook doesn't seem right because scrolls are four times more
likely than spellbooks (in most of the dungeon; books aren't randomly
generated at all on the rogue level or in Gehennom).
...by thrown potion. The reported case was a shopkeeper killed by
system shock from thrown potion of polymorph, but any death (acid,
burning oil explosion, water against iron golem, holy water against
undead, demon, or werecritter) to any peaceful monster could cause
similar result.
