A bunch of trailing spaces crept in with the most recent udpate;
remove them. Also, most sentences are separated from each other by
two spaces, but 2 or 3 had only one space. Also, rewrap a couple of
the widest lines although none of them were too wide for displaying
within 80 columns.
The comment I added to data.base--to explain that despite what the
short description says, an aklys wouldn't return to sender after being
thrown--was bugging me, so I've made aklyses behave like Mjollnir.
If thrown when wielded as primary weapon, it will usually return and
usually be re-wielded. I also added a new message when either thrown
Mjollnir or thrown aklys is expected to return and fails to do so.
Most of the diff to dothrow.c is a change in indentation level. The
amount of code needed was quite small.
Autopickup for thrown Mjollnir which had failed to return was putting
it into the quiver slot if that was empty. Note quite an outright bug,
but it started wielded and can't be thrown if quivered, so exclude it
from the stuff that will auto-fill the quiver slot when added to invent
(post-3.6.0 issue).
Report indicated that looking up "more info?" for "kittens" would show
the data.base entry for "kitten" and then when the display window was
dismissed, another "--More--" prompt for a empty second display window
would occur. Looking up "2 arrows" from a closely-seen object on the
map behaved similarly. User correctly diagnosed that the two-pass
lookup left the 'found_in_file' flag set from the first pass during
the second but that just clearing that resulted in "I have no info
about such things" on the second pass. The code is on the convoluted
side and needed an extra flag to handle 'seen on first pass' in
addition to clearing found flag after the first pass. I also added a
check to skip the second display if primary and secondary keys don't
match each other but both find the same entry. To test it, I tried
"a +0 aklys named aclys". That found the aclys entry but failed to
find "+0 aklys", so I added another change to have the key massaging
remove +/-N after removing "a", "an", or "the".
If "Want to see more info \"" + lookup string + "\"?" was too long,
the prompt buffer passed to yn() was being left uninitialized. Also,
test for too long was based on BUFSZ but yn() complains (to paniclog)
if the prompt is longer than QBUFSZ. Make checkfile() construct a
truncated prompt if the lookup string is too long.
I untangled some spaghetti by making all the 'goto's be forward. It
didn't help a lot but did simplify a few early returns by having them
jump to a common exit instead of replicating the file close.
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.
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).
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).
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).
Make the formatting of 'opthelp' be more consistent. When entries
span multiple lines, sometimes the default value was shown on the
first line, sometimes on the last. This puts it on the first line
which is more useful for quick looks with 'grep'.
This also adds an explanation for the value of 'disclose', adds
missing choice "full compass" to 'whatis_coord', and expands upon
the explanation for several other compound options.
As mentioned at least once before, menu_* is missing win32 in the
list of interfaces that support the various menu accelerators.
"They say that an ooze will bite your boots and a rockmole will eat them."
'rockmole' should be two words. Also, rock moles won't eat leather
boots, so change 'will eat' to 'might eat'.
Rewrite 3.6.1's compress_str() to avoid peeking past the end of the
input string. This should eliminate the reported valgrind complaint.
The problem was noticed for post-3.6.0 code introduced [by me...] last
June, but it looks like it was present in the old code too.
Also, fix the wording in the paragraph about NUL in the keyhelp text.
tty_putstr() always passes non-message window text through compress_str(),
clobbering usage of two spaces to separate sentences. putstr()'s caller
ought to have more control over that (possibly via its hardly ever used
'attribute' arg?).
The blank symbol set can be used with screen reader software
to prevent it from reading the map symbols.
Prevent a segfault when looking at the map and many symbols
share the same character. Don't list too many symbols when
looking at those, if many share the same character.
I don't know whether this fixes #H4335 but it does eliminate a
bunch of duplicate symbol entries. And the two whose duplicates
had different values are suspicious ones: using linefeed and tab as
the character for object class symbol, which could easily confuse
the tty interface's cursor position tracking. But those should
have been overridden by the later entries which specified the
default object class characters--I couldn't find anything in symbol
processing which would cause it to keep the first value instead of
replacing that with the second one.
The report had a link to screen shot which showed a door (I think
an open one despite the '+' shape) in the corner inside a room,
something like
--+-----------
| |
| =
| ..##
| .+#
----+---------
where the '+#' in the lower right looks like it belongs two rows up
and one column over, the upper left of the three '#' is white and
the other two gray (lit corridor or empty dooryway or what?), the
'=' is actually three horizontal bars in green, and the lower '.'
has the cursor on it. There aren't any object class symbols shown
(unless the triple-barred = is one), so linefeed and tab don't look
like likely culprits.
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.
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.
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.
While looking for things in core which might conceivably trigger the
Windows ctype assertion failure (haven't found any yet), I noticed
that help_dir() was still treating ^O as a wizard mode-only command.
Also, documentation about that command was never brought up to date.
I wish this change to ^O hadn't been done. #overview already has
a meta/alt M-O shortcut and overloading wizard mode commands makes
documentation more complicated since wizard mode stuff traditionally
has been left unmentioned.
Change description of area outside of the swallow animation from
"interior of a monster" to "unreconnoitered". For the animation
characters themselves, don't suppress the list of other screen
features which use the same character ('/' for wand and so on).
Add a data.base entry for "unreconnoitered" in case someone tries
to use it to look up an unfamiliar term.
The lower two levels of Vlad's Tower were got showing the wizard-mode
special level indicator '[level_abbrev]' in #overview, nor appearing
for ^O or in the level teleport menu, indicating that Is_special()
wasn't finding them. It took a while to figure out why, but the fix
is trivial.
The code to apply an automatic annotation to the knox level was looking
for a drawbridge like on the castle level, but knox doesn't have any
drawbridge. Look for its door instead. (It's initially a secret door,
so won't be revealed via magic mapping. It needs to be found or
destroyed to get mapped as a door or empty doorway in order to trigger
the annotation.)
Also, give a tiny bit of variation to the knox level layout. It used
to have both the throne and the secret door on the lower of two similar
rows and the door into the treasure vault on the upper one. Now each
of the three can be on either of those two rows (independently of each
other), making eight possibilities. This doesn't accomplish much,
other than to make the secret door locations not always be at the same
fixed spot.
This set is the same as the default ascii symbols except that corner
walls are represented with '+' instead of '-' or '|' so that wall
joins are clearer. The baalz level looks a little better this way,
although not a lot. Unfortunately, most levels look a bit cluttered
with this, so I imagine it won't get a lot of use. At least it
serves as an example of being able to use "'c'" instead of "\123".
Originally I specified every terrain symbol explicitly, which was
how I noticed that S_darkroom and S_vibrating_square weren't being
handled. This has cut it down to just the wall symbols, serving as
explicit example of accepting default symbols for unspecified ones.
Quite a bit of special case code for something so inconsequential.
Tweak the baalz level layout a little to make it be a bit more
interesting, and perform custom wallification on it so that the
beetle layout becomes clearly visible. It looks great with
DECgraphics (and presumably IBMgraphics). It's recognizeable but
not as interesting with ordinary ascii because corner walls use
'-' or '|' so don't join up nicely. It looks a little weird
with tiles; the square aspect ratio of individual tiles makes it
end up being very elongated compared to character cell map it was
designed for.
As far as the level layout goes, the pair of secret doors into
Baalzebub's chamber have been give a random alternative. The two
right-most accessible columns were diggable--I don't know whether
that was intentional; it's been reduced to one right-most column.
The middle pair of legs were asymmetrical; this fixes that. The
beetle also now has eyes and an entry door in its mouth.
