...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.
Add fixes36.1 for '&' command's support of altmeta option.
Short command help lacked an entry for '&' command.
Wizard mode help omitted #vanquished and some other obscure commands.
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.
Just noticed that a change of mine to src/drawing.c 2.5 weeks ago
("zap beam symbol descriptions -- they aren't walls") triggered a
set of four complaints when processing tiles.
Update vms/install.com (rather than Makefile.top) to install the new
data file for the 'whatdoes' command.
Also, the 3.6.0 distribution puts version number 3.5.0 into vms
binaries (all the programs, not just nethack itself). It's something
observable with native tools without running the program, nothing to
do with nethack's 'v' command which gets its version number from
patchlevel.h via makedefs.
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.
When confused gold detection finds a door trap or a chest trap, it
puts a bear trap glyph/tile on the map at that location. (They
disappear once they're within sight.) Those should be given their
own glyphs so that they can have their own tiles, but this doesn't
do that. What it does do is describe such fake bear traps as
"trapped door" or "trapped chest" when examined with far-look.
The '^' command--if used while blind so that '^' hasn't disappeared
yet--needs to catch up: it says "I can't see a trap there" when the
adjacent '^' is a fake bear trap.
While testing something I noticed that moving the cursor to visible '^'
by typing '^' while getpos was asking me to pick a location, it didn't
always cycle through all visible traps. The most straightforward
culprit was after trap detection (via confused gold detection, not ^F)
had found a trap door or level teleporter in a closet that itself was
a secret corridor spot. But it turned out to be any location that
hadn't been seen yet. This is a substantial overhaul of the relevant
code and so far works for all the cases I've tried, but there are
bound to be cases I haven't tried yet and those may or may not work
correctly.
There's also a bunch of formatting cleanup, and some simplification of
the m/M/o/O/d/D/x/X handling.
The level teleport arrival regions (which also apply when invoking the
W quest artifact's temporary magic portal) on the Ft.Ludios level had
the wrong bounding coordinates.
While there, I've added a corridor between the welcome/zoo room and
the empty room at the top. The doors are secret so monsters won't be
able to use it until they've been discovered by the player (which
happens with magic mapping as well as with searching). I put a giant
in the formerly empty room, and made that room's original door secret
too so that the giant won't smash it down to get out, then smash down
the door between the zoo room and the main area around the fort.
When travel fails to reach its destination, it remembers the target
spot to use as default next time. But that spot is only meaningful
on the current level. Discard last travel destination when moving
to a different level.
Also, discard unlocking context when changing level unless the
context is for a container being brought along (after having been
picked up since you can't unlock a carried box). Previously, a
door pointer on the new level could happen to match the last one
being unlocked on the old level.
Discard trap setting context when changing level even if the trap
object is brought along.
Somehow the code for applying a touchstone got inserted in between
two sections of code for applying a trap (ages ago; probably since
touchstone was first introduced however many versions back), so
clean that up.
Add MG_BW_LAVA to mapglyph() instead of hijacking MG_DETECT. Used
to display lava in inverse video if color is disabled and lava is
using the same display character as water (which is the default).
(The use_inverse option must be enabled for tty to honor it. X11's
text mode doesn't care. Win32 does care but probably shouldn't--it's
not a case like tty where the hardware might not support it.)
This implements both MG_DETECT and MG_BW_LAVA for X11, but only if
the program is built with TEXTCOLOR enabled. Those should work even
when color is not supported, but I suspect that configuration is
unlikely to ever be used so didn't want to spend the time to figure
out how to do it. (The relevant data is overloaded on the color
data, so not available when TEXTCOLOR is disabled.)
The win32 revision is untested.
Reported almost exactly one year ago by a beta tester proofreading
the Guidebook, the number_pad setting to support the German keyboard
which swaps the Y and Z keys is for a keyboard that is used in other
places too. The report mentioned France and Belgium; Wikipedia's
"keyboard layout" entry mentions "Germany, Austria, Switzerland and
other parts of Central Europe". This changes references to "German
keyboard" (there were only a couple) into "QWERTZ keyboard".
