Another item from the "A few bugs" mail. Casting spell of protection
when previous casting(s) hadn't timed out yet miscalculated the new AC
boost. At low levels--when this spell probably gets its most use--the
bug wasn't noticeable. (At high levels when someone might cast it a
whole bunch of times in succession, the effect could be noticed but
was probably just assumed to be working as intended. Its behavior is
somewhat convoluted.)
Fix another item in the "A few bugs" mail. Monsters who wanted to flee
weren't able to use 'sstairs' (extra stairway leading to different branch
of dungeon) due to a logic error in the find_defensive() choices.
if (terrain==STAIR) {
} else if (terrain==LADDER) {
} else if (x==sstairs.sx && y==sstairs.sy) {
} else { /* check traps */
}
wouldn't find 'sstairs' because they have terrain type STAIRS. (Also,
the sstairs check wasn't screening out immobile monsters, but that bug
didn't have a chance to manifest.)
There's a bunch of reformatting, and some code re-organization to improve
other formatting, and some additional logic fixes.
Make the preface have an unnumbered header and force a new paragraph
for its text;
remove the unterminated switch to bold font;
change "Terry Pratchett" from bold to italics to match Guidebook.tex's
setting.
Allow 'P' and 'R' commands to accept armor and wear/take-off the chosen
item, and 'W' and 'T' commands to accept accessories and put-on/remove
the item. The which-object prompt only lists the type(s) of items that
traditionally go with each command, as does an inventory menu if the
user picks '?', but items of the alternate type(s) can be chosen, by
unshown letter or by the inventory menu given for '*'.
There shouldn't be much difference if you continue picking items that
go with the original commands, although you will somestimes get
"which object? [*]" when the only choices are for alternate command.
And you won't see the all-four-accessories-are-already-worn message
for 'P' unless you also have something worn in all seven armor slots.
The Guidebook.mn changes have been tested (that's how/why I noticed
the preface glitch) but the corresponding Guidebook.tex ones haven't.
Changes to be committed:
modified: doc/window.doc
modified: include/qt_win.h
modified: include/trampoli.h
modified: include/winX.h
modified: include/wingem.h
modified: include/winprocs.h
modified: include/wintty.h
modified: src/display.c
modified: src/windows.c
modified: sys/amiga/winami.p
modified: sys/amiga/winfuncs.c
modified: sys/amiga/winproto.h
modified: sys/wince/mswproc.c
modified: sys/wince/winMS.h
modified: win/Qt/qt_win.cpp
modified: win/X11/winmap.c
modified: win/chain/wc_chainin.c
modified: win/chain/wc_chainout.c
modified: win/chain/wc_trace.c
modified: win/gem/wingem.c
modified: win/gem/wingem1.c
modified: win/gnome/gnbind.c
modified: win/tty/wintty.c
modified: win/win32/mswproc.c
modified: win/win32/winMS.h
print_glyph now takes a second parameter.
Tiles on tiled ports always looked odd on places like the plane of air
where the background color of the tile didn't match the general background
of the surrounding area.
3.6 made that even worse and more glaringly noticeable with the introduction
of darkened room tiles.
The code to actually send something useful through the new parameter
for window ports to take advantage if they want will follow.
Changes to be committed:
modified: dat/history
modified: doc/Guidebook.mn
modified: doc/Guidebook.tex
- include new 3.6.0 beta testers in dungeoneers list
MSGTYPE allows the user to define how messages in the message
area behave. For example:
MSGTYPE=stop "You swap places with "
would always make that message prompt for -more-. Allowed types
are "show" (normal message), "hide" (do not show), "stop" (wait
for user), and "norep" (do not repeat message).
Adding this, because it's relatively simple, proven to work, and
it seemed to be the major thing betatesters felt was lacking when
compared to NAO.
The option defaults to on, which is the old-style behaviour.
Turning the option off will never omit the "uncursed" -status
from inventory lines. This is pretty much required if users
want to use menucolors based on the BUC state.
The code that intended to have mimics occasionally take on the form
of "strange object" always produced downstairs instead because
S_MIMIC_DEF is greater than MAXOCLASSES.
This problem was present in 3.4.3. I didn't try to go back to see
how long it's been there, but strange objects used to occur once
upon a time. Either nobody noticed that they'd gone away or there's
an alternate way to produce them.
Fixes a bug reported by ais523. Rather than account for individual
segments, I opted just to make them unleashable, because it's not very
useful behaviour anyhow.
