When destroy_item() or destroy_mitem() burned up a glob of green slime,
they had the message index and damage amount reversed. This could give
a nonsense message ("the glob of green slime freezes and shatters") or
go out of array bounds and wreak havoc. Even if the message index had
been correct, fatal damage would have produced an incorrect cause of
death since it would have used a potion or scroll string.
Now globs will boil and explode like potions, and damage will be
proportional to the size (weight) of the glob, which seems to be the
original intent.
Since the attempted fix for the warning about has_color() being
implicitly declared introduced a worse problem of conflicting
declaration in cases where it's already declared, back that change
out.
I noticed that my paniclog had a "Query truncated" entry from testing
the post-3.6.0 changes to #dip prompting. For
"What do you want to dip <the object> into? [xyz or ?*] "
the use of safe_qbuf() didn't account for getobj() appending the list
of choices, so wasn't ensuring that the formatted object name combined
with the other text couldn't overflow QBUFSZ.
I had a more elaborate fix than this that still used safe_qbuf(), but
the extra complexity just wasn't worth it. This potentially truncates
the formatted object description more severely than necessary but is
simple enough to be comprehensible.
No fixes36.1 entry. This is updating a post-3.6.0 revision.
From a July 2011 report listing multiple movement anomalies, fix one
of the easier ones. If you polymorph from a fast from into a slow
one, pending movement points can let the slow form get in some moves
it shouldn't.
I've deliberately avoided adjusting pending movement when you change
into a faster form, which will get it's own movement boost on the
next turn.
From a followup to #H2247, April 2011... Physical damage from a mind
flayer attack was inflicted in the AD_DRIN case for hitmu(), then
being inflicted again in the common code after the switch statement.
The new comment explaining the reason for non-standard damage is just
a guess.
Suppress the "you climb/fly up the stairs/ladder" message if the
'verbose' option is off (unless punishment is going to augment the
message by "with great effort").
Bug report subject was "menu interface things" but this isn't related
to menus, just getobj(). Make the requested change to not list worn
suit as a likely candidate for T (and R) if a worn cloak is going to
prevent it from being removed. (Suit can still be picked, but the
take-off operation for it will be refused, same as when it was being
listed as a candidate.)
In discussion about the request, there was a separate suggestion that
cloaks shouldn't interfere with removing things underneath since
they're generally sleeveless. I haven't done that; I think it is
better to keep the layering as it is.
The bug report also asked for the likely candidates when writing with
a magic marker to exclude non-blank scrolls and books. That has been
implemented already (post-3.6.0).
Chameleon impersonating a vampire and vampire subject to protection
from shape changers weren't the only ways to have a vampire monster
which isn't a vampshifter. One-shot polymorph could produce that too.
For !menu_tab_sep, the boolean options were formatted with a different
width than the compound and 'other' options when the menu for 'O' was
active. Use the same format string for all of them, consider them all
when constructing it, and construct it just once instead of every time.
Reported directly to devteam, with patch: tipping corpses out of an
ice box wasn't restarting their rot timers, producing corpses that
would last indefinitely.
I stumbled across why the Death Quotes hadn't been getting displayed
evenly before being recycled: ones I've added since 3.6.0--probably
even before the release--were unintentionally missing their '%e passage'
directive, so attempted look-up for those returned the very last one
(terminated by '%e title'). The recent change to read_passage() has
made '%e passage' be optional for one-line death quote passages, so
this patch doesn't bother putting them in.
Instead of just using 'random' as the default choice if the user hits
<return> when picking role, race, gender, or alignment, flag it as
pre-selected in the menu so that it can be seen to be the default.
Someday somebody is going to have to fix up the interaction between
PICK_ONE menu and pre-selected choice....
Make the six buttons (ok, cancel, all, none, invert, search) on
menus for X11 all have the same width.
'ok' should probably be changed to 'okay' to be consistent with
X11_getlin(). (Another inconsistency: the extended commands
menu uses 'dismiss' rather than 'cancel'.)
Two cosmetic changes for the X11 version of the getlin() routine:
1) Make the text entry box big enough to hold 60 characters before
sliding the beginning input off the left edge, instead of just 13,
so that user can see much more of what is being typed;
2) Make the cancel button be a little wider, and the okay button be
the same width as the cancel button so they look a little nicer.
When a chameleon/doppelganger/sandestin took vampire or vampire lord
shape, it stopped taking on new shapes. Vampire shapeshifting was
being applied to all vampires rather than just to is_vampshifter().
When is_vampshifter() is false, the vampire is some other shapeshifter
or Protection_from_shape_changers is in effect, so vampire shifting
doesn't apply.
While testing, I noticed that vampires/lords only turned into bats/
wolves during initial creation. They did turn into fog clouds in
order to pass closed doors but the other alternate forms were ignored.
That's fixed too.
This is more robust than the previous hack. The issue of whether to
use it in other places is still unexplored. Ultimately it's the user's
fault if overzealous message suppression hides something important.
[For an eerie game, try 'MSGTYPE=hide .'.]
Increase the lex paramaters in lev_comp.l and replace use of snprintf
with sprintf in lev_comp.y and lev_main.c.
Also some reformatting for lev_comp.y, but I gave up pretty quickly:
some early tab replacement and adjusting of the spacing for casts.
User had
MSGTTYPE=norep "You see here"
and complained that once the message had been given while walking
over an object, using ':' to intentionally look at something would
end up doing nothing if its feedback was a repeat of "You see here".
Trying to classify which actions should deliberately override
no-repeat (or no-show) will be an ordeal. This fixes the case for
the ':' command where the user obviously expects feedback. I think
it could be done better but am settling for something quick and easy.
Rename the option for adding coordinates to autodescribe feedback for
the '/' and ';' commands from 'getpos_coord' to 'whatis_coord', after
the '/' command that uses it instead of after the internal routine
that implements it. The 'whatis' name was only in dat/hh as far as I
could find, so this changes it to 'what-is' and also updates dat/help
and the Guidebook to mention the name too.
Add a 'screen' choice to the option to show coordinates as row,column
rather than x,y or compass direction(s). Revise the /m, /M, /o, /O
operations of 'what-is' to honor the whatis_coord option (mostly; a
value of 'none' gets overridden by 'map' to force coordinates).
Also, update the description of the functionality of the '/' command
in the Guidebook. The .mn version is tested, the .tex one isn't.
Chatting with Death doesn't always deliver a tribute Death Quote but
when it does, it wasn't giving each of them once before reusing them
even though they should have been treated the same as passage
selections from a novel. I'm still not sure why it wasn't working
as intended, but after some revision to the tribute parsing code, now
it is. If you #chat with Death enough times to get 20 tribute quotes,
you will see each of the 20 quotes once (in random order), then
further chatting will give them again (in different random order).
When entering an extended command, allow the user just type
and match a new command immediately, if no match was found,
instead of needing to wait the 2.5 seconds.
There have been several comments on IRC how the Wizard is a very
light sleeper now; aggravate cast by monsters makes him wake up
and come out of the tower. So, lets limit aggravate to either
outside or inside of the tower, depending on which side the player is.
Update X11's status display to include the expanded set of status
conditions. This time the order is
Petrifying <hunger> Blind
Slimed <encumbrance> Deaf
Strangled Levitating Stunned
Food Pois Flying Confused
Term Ill Riding Hallucinating
with the application defaults file specifying red text for the first
column and black for the other two. Previously it was all one column
with seven entries. [Slimed was missing along with the six new ones
(deaf, stone, strngl, lev, fly, ride) and both types of sickness were
shown as 'FoodPois' or 'Ill' or 'FoodPois Ill' on one line.]
So now basic bot2, #if STATUS_VIA_WINDOWPORT genl_status_update, and
#if !STATUS_VIA_WINDOWPORT X11 fancy status have three different
orderings. genl_status_update has hunger and encumbrance first
because all the other status conditions are grouped together as one
bitmask item. bot2 has 'lev', 'fly', 'ride' last so that they're
the first things to be sacrificed if the string of status conditions
ends up being truncated. (genl_status_update also has those last.)
In addition to updating status conditions, I reordered the Hp, Pw, &c
section too so that it's closer to tty in organization.
Hit points Maximum HP
Power Maximum Power
Armor Class Alignment
Exp.Level Exp.Points (if 'showexp')
Gold Moves (if 'time')
Score (if 'showscore')
I didn't have SCORE_OR_BOTL set so haven't seen the last one, but
it's in the same position as it was before.
When levitating on the plane of water, get an unattached iron ball,
and throw it. You'll hurtle in the opposite direction, out of the air
bubble and into water, but don't drown.
Make genl_status_update behave approximately the same as basic bot2
when processing the second status line. Preferred order:
Dlvl Gold Hp(HpMax) Pw(PwMax) AC Xp Time Conditions
Alternate orders if above exceeds COLNO (note several extra spaces
get sequeezed out). First one is used if everything except time fits,
second one is used if everything except experience (which can be wide
if 'showexp' option is on) and time fits, third is last resort:
Dlvl Gold Hp(HpMax) Pw(PwMax) AC Xp Conditions Time
Dlvl Gold Hp(HpMax) Pw(PwMax) AC Conditions Xp Time
Hp(HpMax) Pw(PwMax) AC Conditions Dlvl Gold Xp Time
Basic bot2 currently has Conditions as
Stone Slime Strngl FoodPois TermIll <hunger> <encumbrance> Blind Deaf
Stun Conf Hallu Lev Fly Ride
genl_status_update has
<hunger> <encumbrance> Stone Slime Strngl FoodPois TermIll Blind Deaf
Stun Conf Hallu Lev Fly Ride
which is as close as it can get with the current field organization.
Tested by temporarily changing tty_procs.status_init and .status_update
to use genl_* instead of tty_*.
This fixes bz23: Warning glyph info wrong with TRAPS=50, even
though you don't set the trap symbols via TRAPS anymore, the
bug still existed. To trigger it, use SYMBOL=S_arrow_trap:2
and look at monster that appears as warning '2'.
Adding deafness to the status line spurred me on to something I've
wanted to do for a long time. This adds 'Stone' and 'Strngl' as
new status conditions, and moves the five fatal ones: "Stone Slime
Strngl FoodPois TermIll" to the front of the status list since
information about them is more important than any of the others.
"Ill" has been renamed "TermIll"; "Df" has been renamed "Deaf";
"Lev", "Fly", and "Ride" are three additional new conditions, with
Lev and Fly being mutually exclusive. After the fatal ones, the
order of the rest is now
<hunger> <encumbrance> Blind Deaf Stun Conf Hallu Lev Fly Ride
To handle the longer potential status line, the basic bot2() is now
smarter. If the line is wider than the map, 'T:moves' is moved from
the middle to the end. If the line without time is still wider than
the map, then experience (HD if polyd, Xp:M/nnnnnn is showexp is on,
or Exp:M) is moved in front of time at the end. If the line without
experience and time is still wider than the map, dungeon level plus
gold is moved from the beginning to be in front of experience. The
fields are just reordered, not truncated, so if the interface code
can display lines wider than the map they'll retain the extra info.
The gist is than health and associated fields (Hp, Pw, Ac) get first
priority, status conditions get second priority, then the rest. In
the usual case where there aren't many conditions, status display is
the same as it has been in the past.
STATUS_VIA_WINDOWPORT has been updated too, and it builds for tty
and X11. But the bot2() revision to reorder sections has not been
implemented for that.
win/win32/mswproc.c has been updated but not tested.
STATUS_VIA_WINDOWPORT without STATUS_HILITES had several compile
problems; now fixed for core and tty. STATUS_VIA_WINDOWPORT with
STATUS_HILITES has not been tested.
