From a bug report, if you used the apply command while
not carrying anything applicable except for unknown potion, you would get
"you don't have anything to apply" if that potion wasn't oil but an
inventory selection prompt (with '*' as the default since you wouldn't
have anything considered to be a likely candidate) if that potion was oil,
giving away information.
This fix makes carrying any unknown potion yield the inventory
selection result, unless oil is already discovered and hero can see that
the unknown potion isn't oil.
Conditional on H2344_BROKEN which can be disabled at the top of the file if
necessary. This appears to handle all the cases I was able to reproduce from
Pat's list, with the caveat that msg_window=f fails on very wide windows on
Mac OSX Lion with the default terminal emulation. When the emulation is set
to ANSI, it works (the failure mode is the output from a simple putchar() loop
across the contents of history called up from ^P wraps at about the middle
of the window).
Provide a mechanism for cleanly moving between tentative window system
selections during startup. Now, before a second (or later) system is selected,
the first will be notified that it is losing control. See window.doc.
From the newsgroup: casting spell of drain life at Stormbringer
(or Excalibur or Staff of Aesculapius) would reduce its enchantment just
like any other weapon. Drain resistance should protect against that even
when not actively wielded.
Update the help text in setup.sh. When building with a hints file from TOP,
the path to the hints file should start from TOP (instead of "hints/foo").
Make the notes in the generated makefiles consistent as to case.
There was a second instance of curs()+flush_screen() that had the
calls swapped 5.5 years ago and is being restored to 3.4.3 state here.
It turns out that swapping the other instance of those two calls
didn't help with the original problem (^R during getpos() redrew the
screen but left the cursor at the end of the 2nd status line) at all.
Only adding the pline() call after docrt() fixed it. pline() calls
flush_screen(1) which ultimately puts the cursor back on the hero. I
still don't understand why curs(WIN_MAP,x,y)+flush_screen(0) leaves it
on the status line instead of at the specified map coordinates. That
must be a bug in the tty code somewhere.
This ought to fix the problem excountered by Ken, where the cursor
wasn't at the spot '/y' was reporting on. This reverses part of a change
from May, 2005. I still don't understand the original behavior, which
was that docrt() for ^R followed by positioning the cursor at a specific
map coordinate and calling flush_screen() was leaving the cursor at the
end of the second status line. Reversing flush_screen and curs(WIN_MAP)
made it work for tty but screwed up X11. It turns out that including
pline("Move cursor to %s:") *also* makes things work as intended, so that
the flush/position hack wasn't necessary once that other change went in
(same 2005 patch, but the cursor hack was implemented first at that time;
once this reversal is in place, commenting out the pline() does bring the
odd behavior for tty back).
Undo the win/tty/wintty.c bands of the H2344 fix until the fix is fixed. I
didn't take out the type changes to hopefully avoid putting people through
a full recompile.
branch only. This adds a check when setting a new fruit so that if no fruits
have been created since the last time the option has been set, the current
fruit is overwritten. Result: the user cannot repeatedly set the fruit
option and overflow the maximum fruit number.
The presence of conditional code for both UNICODE_WIDEWINPORT and
NEWAUTOCOMP in hooked_tty_getlin() was making it be pretty hard to read.
This simplifies the UNICODE_WIDEWINPORT parts similar to what was done in
topl.c a year or two back. The NEWAUTOCOMP parts are still cluttered.
This compiles successfully with UNICODE_WIDEWINPORT enabled but that
configuration is otherwise untested.
Change the post-3.4.3 extended command "#terrain" so that it can be
used in normal play rather than just in wizard mode. It's inspired by
a command in 'crawl' that lets you view the bare map without monsters,
objects, and traps so that you can see the floor at locations which have
been covered up by those things.
normal play
redraw map to show the known portion of it without displaying
monsters, objects, or traps; after player responds to --More--, the
map returns to normal.
explore mode
put up a menu so player can choose between the known portion of
the map as above or the full map. If the level isn't fully explored
then the latter provides information to the player that he hasn't
earned yet, but the _hero_ doesn't learn anything and after --More--
the map reverts to what it showed before. (In other words, unlike
with magic mapping, the unknown portion doesn't become known.)
wizard mode
put up a menu so player can choose among four alternatives: the
two above, the text representation of the map's internal levl[][].typ
codes, or a legend explaining those codes. (Originally, I wanted to
be able to toggle back and forth between these last two, but looking
at one and dismissing it, then reissuing #terrain to look at the
other is much simpler to implement and is good enough.)
My #terrain patch had a typo on the command line and was going
to include doc/fixes35.0 as the log text for a half-dozen files. I
aborted the commit but most of them had already made it into the cvs
repository. This reverts those changes so that the entire patch can
be re-comitted with the right log text. Ugh...
Noticed while looking into whether I could use DUNGEON_OVERVIEW data
for something useful, it was recording accurate terrain type for locations
covered by mimics who were mimicking furniture (such as stairs or altars).
Hero should remember the fake terrain rather than whatever is actually
underneath the mimic.
No fixes entry; user-contributed DUNGEON_OVERVIEW is post-3.4.3 code.
Some old wall display debugging code which gets enabled when
WA_VERBOSE is defined was missing the three terrain types (tree, iron
bars, grave) added way back in 3.3.0. It's extermely unlikely that
anyone other than Dean might actually ever be impacted by this....
This compiles with WA_VERBOSE enabled but is otherwise untested.
I haven't bothered with a fixes entry.
