The expansion of the extended commands list to include every command
has made picking extended commands out of X11's menu become tedious.
This uses the existing 'extmenu' option (previously tty-only) to
control whether all the commands are present or just the traditional
subset not bound to non-meta keystrokes ('adjust', 'chat', 'loot', &c).
Fixes#179
The Valkyrie goal level has two drawbridges and one of them was set to
have 50:50 chance to be closed (raised). But 'random' for drawbridge
open/closed (or lowered/raised) state was always choosing open (lowered).
This fixes that and also changes that level to have the old settings
(southern open, northern 50:50) for 75% of the time and new settings
(both 50:50) for 25% of the time. So there's now a 12.5% chance that
both will be closed instead of both always being open (due to the bug
with handling random).
User-contributed fix; bypassed the contact form so no #Hnnnn number.
On the Gnome King's Wine Cellar version of Mines' End, a couple of
wall stubs in the lower far right were diggable, unlike all other
walls on the level. One single-spot wall stub was leftmost of three
undiggable spots, wall+floor+stone. The floor spot wasn't noticeably
different from normal (not sure whether digging a pit was prohibited)
but the stone one was.
Redo the Ft.Ludios entry hack to suppress the lit walls on the left
and top rather than to light the upper-right corner. Only noticeable
if carrying a lit candle. Usually, that is. This simpler hack could
be detected visually from the treasure room side of the walls involved
but normally won't be.
The entry chamber for the Fort Ludios level would be completely lit
except for one corner wall if you arrived carrying a lit candle. The
unlit spot turns out to be correct, it is beyond candle radius, but
spots further away than that were showing up lit. That's due to them
bordering a lit region on the opposite side and lit regions seem to
be bigger than their specified dimensions.
I tried to make the lit walls be unlit but it wasn't working. (Making
the lit region be smaller would probably work but might have unintended
consequences when populating the zoo room. I didn't try that.) This
makes the unlit corner show up if light hits the spot next to it, so
that it behaves like the other lit walls surrounding that entry area.
I haven't marked the bug report closed because I don't think this is
the proper way to fix this.
Even out the difficulty (from one game to another) somewhat. Instead
of a 75% chance that two large areas will be opened up on the left
and right sides of the arrival area plus 13.5 (avg) * 1.5 (avg) extra
monsters in that region, change to 60% chance that the left side will
be opened up with 7 (avg) * 1.5 (avg) extra monsters and a separate
60% chance that the right side will be opened up with 7 * 1.5 (avg)
extra monsters. The chance that both sides get opened up drops to
36% but the chance that neither side gets opened drops to 16%, with
difference made up by 24% chance each for just one side or the other.
I was a little surprised that this actually worked. I hope there's
a less clumsy way to have a loop index.
The phrasing of the data.base entry for the Eyes of the Overworld
reads as if it is continuing some passage in a reference book, but
that comes off strange when using '/' to see it. Rephrase it.
data.base could stand to have an entry for 'lenses'....
Demote #monpolycontrol and #wizdebug_traveldisplay from commands to
simple boolean options. The former has the same name, the latter
is called travel_debug. Rename #wizdebug_bury to #wizbury; it
shouldn't matter that it goes away when compiled without DEBUG.
There are now five wizard-mode boolean options: monpolycontrol,
sanity_check, and wizweight are documented in the Guidebook;
menu_tab_sep and travel_debug are commented out there.
Guidebook.mn has been tested; Guidebook.tex has not.
Remove an extra space from Val 00021.
This does not address github issue #124 where the extra space shown
on the message line is the result of combining two separate plines
rather than coming from the data.
Fixes#120
The one-line summary [for inclusion in message history] of the priest
quest's block message when bringing the quest artifact back to leader
misspelled "congratulations".
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?).
