Followup to 'fix #148' patch: looting a container with menustyle:Full
wasn't offering a chance to remove everything in one go. That was due
to an error I introuduced 2.5 years ago with commit
529dad8ef1 when I changed how the flags
passed to query_category() were being set up. It accidentally switched
'A' from take-out to put-in but the only code to handle 'A' at that
time would take everything out (from container to inventory).
Prior to that, removing everything worked as intended and putting in
everything wasn't supported. Now 'A - autoselect all' is a viable
choice for both in and out.
Fixes#154
With menustyle:Full, picking 'A - autoselect all' when putting items
into a container ran code for taking things out and there wasn't any
corresponding code for putting things in.
Add some put-in-everything code. Taking things out doesn't offer
'A - autoselect all' as a choice so the code mentioned above may now
be dead. Taking everything out seems like something that's much more
likely to be desired than putting everything in.
Hopefully this will be the last one. Change from a text window to
a menu so that it is possible to scroll backwards (without needing
scrollbars) via '^' and '<' keys. End of game disclosure for
attributes still uses a single-forward-pass text window.
Also, move the recently added weapon proficiency line from the new
'basic' section to right after the "you are wielding" line at the
end of the 'status' section.
My "fix github issue #38 - indentation vs 'if {}'" patch, commit
d2ae45984e, broke finding unseen
monsters via searching. Most notable if blind, but applied to
invisible monsters too.
Life-saving was setting u.uswldtim to 0, presumably intending that
to stop the hero from being digested, but it actually resulted in
being totally digested on the swallower's next turn if the death
being short-circuited wasn't digestion. Change life-saving to make
swallower or grabber release the hero instead of tinkering with
u.uswldtim. In addition to rescuing the hero from digestion, it
prevents an eel which has just drowned the hero (who has survived
drowning via life-saving) from pulling him/her back into the water
on its next turn. It will need to make another successful grab to
do that now.
While testing, I noticed that if I was polymorphed and wearing an
amulet of unchanging, life-saving didn't restore my HP-as-a-monster
and due to the recent change to force that to 0 when the hero dies,
I died again immediately after my life was saved. So this bug was
latent in the past and became noticeable in the last couple of days.
Report was for being fried by angry deity. There are lots of deaths
that don't involve subtracting HP until it hits 0 or less; I haven't
bothered tracking down which ones don't set u.uhp to 0 before they
call done().
No effect on life-saving or declining to die except for HP:0 being
visible on the status line during their messages.
Restore handling for keystrokes on PICK_NONE menus so that scrolling
via keys works for them. (That handling was disabled as part of the
patch to support MENUCOLORS.)
Enable [cancel] button for all menus. (That had apparently been
grayed out for PICK_NONE menus since day 1 for X11 windowing.)
Dungeon level wasn't included in ^X output, so it wasn't actually
giving all status fields and attempting to rely on it when turning
off 'status_updates' was leaving a gap in feedback for the player.
Add an extra line to the first section where character's name and
patron deity are reported, giving current location.
|You are in the Dungeons of Doom, on level 5.
or
|You are in the endgame, on the Elemental Plane of Fire.
The information is more explicit than the basic status field, but
you can already get similar information via #overview so it isn't
giving away extra info.
Fixes#150
> A very minor one, but there are some situations where your encumbrance
> level can change, but the message (such as '`Your movements are now
> unencumbered.`') isn't given until your next move or turn, even though
> the status line updates immediately. For example, praying while weak
> and gaining a point of strength. Picking up or dropping items or
> interacting with containers does _not_ have this problem.
This is usually fixed on a case by case basis. Any attempt to add
blanket encumbrance check mid-turn (when updating status, for instance)
is sure to introduce message sequencing problems. Perhaps such a check
could be added at the end of the hero's move....
This fix handles the cases where prayer causes a change to strength:
major: fix starvation, minor: fix weak from hunger, boon: golden glow
(restore strength and satisfy hunger--probably no-ops in this regard
or would have had trouble fixed rather than receive a boon). Directly
curing stat loss (minor: poisoned) already dealt with encumbrance.
> Possibly related to the quirk whereby polymorphing into a form with
> different speed gives you one move movement at your old speed?
> (Polymorphing into a sessile monster gives you one last move.)
Not at all related. That movement bug affected 3.6.0 but was fixed in
3.6.1.
When trapped in a web, trying to move while wielding Sting gives the
message "Sting cuts through the web." In 3.6.1 and earler, that
also released you from the trap, but with 3.6.2-beta nothing happens.
It had nothing to do with the recent web spinning patch. My change
to have being trapped block levitating and flying included replacing
a lot of direct manipulations of u.utrap with set_utrap() and
reset_utrap() in order to keep the lev/fly blocking and unblocking
localized. Unfortunately, the old 'u.utrap = 0' when wielding Sting
while stuck in web was deleted in error at that time.
While looking at something else, I noticed that newsym() was checking
for pool and lava by examining the terrain type directly rather than
using the pool and lava checks, so it would never show a gas cloud at
a closed drawbridge (the spot in front of the portcullis). Level's
terrain at a closed drawbridge spot is DRAWBRIDGE_UP; need to look at
drawbridgemask field to figure out whether the accessible terrain at
that spot is moat or lava.
I started out updating Guidebook.mn to use \(oq and \(cq for single
quotes but ended up including some new text. I've separated that
part out (there are a few instances of altered quoting in the midst
of it--the separation wasn't 100%) to commit separately.
Add verbiage to "choosing race" and several commands: f, s, S, t,
w, and ^X.
Change `E-' and `w-' to use minus sign instead of hyphen. The TeX
edition uses \tt font for those which has the same effect of making
those dashes be more prominent.
Fix typo/thinko in `IX': Guidebook.mn and Guidebook.txt said that
displayed inventory items whose bless/curse state is "known".
Guidebook.tex had it right, "unknown".
The core wants to reuse the permanent inventory window for choosing
an object from inventory, but the perm_invent window could be
hard to focus - it could even be on another display!
Instead, create a temporary new window from which the user can
pick an inventory item.
Dead hero's map coordinates are set to <0,0> part way through bones
creation, then were being used to record grave location for overview
feedback with "final resting place for <dead hero>" if/when another
character got those bones and found the grave (actually, spotted the
location where first hero died regardless of whether a grave gets
placed there). Record dead hero's pre-<0,0> coordinates as intended.
Not previously noticed because in wizard mode the final resting place
becomes part of overview info as soon as bones are loaded rather than
waiting for the death location to be reached.
Putting a box around the simulated screenshot has a side-effect of
forcing it to the next page if there isn't room on the current page.
And it looks at least as good as the old top and bottom horizontal
lines, if not better. This also eliminates the blank left-most
column (relative to those lines) which isn't part of the screenshot.
There are issues:
1) for Guidebook.ps, the "Figure 1" label underneath seems to be
too close to the box; I didn't try to force a blank line in front
of it because that increases the risk of pushing it to the next
page if the figure lands at the bottom;
2) for Guidebook.txt, the "Figure 1" label actually overwrites the
bottom line of the box, and the embedded space allows the line
to show through: "---Figure-1---"; I tried using "\ Figure\ 1\ "
to see if that might hide the issue by making it seem that the
label in intended to be on that line, but it didn't help--
unbreakable-space evidently does not imply always-visible-space;
3) the box is one column wider than the rest of the document (the
previous horizontal lines were two or three columns wider, so
this is actually a tiny imrovement); squeezing out some whitespace
to make the status lines narrower didn't help--or at least not
enough; squeezing some spaces was needed to match STATUS_HILITES-
era status formatting anyway.
4] if there was a footnote (we have some for trademarks) on the same
page as the screenshot, either the footnote or the table would
probably become confused, perhaps both. I think we just pretend
that that will never come up....
5} I've made no attempt to alter Guidebook.tex to try to match.
I'm throwing in the towel. Fixing this up is way beyond my limited
'roff/tbl capability. (There's probably a much more straightforward
way to achieve what we want.)
Reported for Windows beta3 but turns out to be present in 3.6.1
distribution.
| #wait
| Rest one move while doing nothing. Default key is '.', and '
| ' if rest_on_space is on.
where the line split occurs in the middle of "' '". We should
switch from the ascii single quote to the 'nroff open and close
single quote escapes but I haven't gotten around to that.
Preceding the space with backslash prevents a line break there.
Fixes#144
While giving a new character his/her starting equipment, don't clear
alternate weapon when putting on a shield since that weapon should
still be available to swap with primary. Affected knight's lance
and valkyrie's dagger.
Also, guard against wearing an initial shield if already wielding a
two-handed weapon, or wielding such a weapon if already wearing a
shield. Both situations are hypothetical with current starting gear.
Don't "feel like a hypocrite" when on Elberth and attacking a monster
which isn't scared by Elbereth (exception: peaceful creatures aren't
scared but attacking them in such situation is hypocritical anyway).
This means that players can use Elbereth to scare away some creatures
while continuing to fight others. Elbereth won't be automatically
erased, but weapon attacks will scuff the engraving; wand zaps don't.
Reduce the -5 alignment penalty when alignment is 5 or less. Reduced
amount is -(1..5), so -3 average.
Replace the XawList with our own lists of labels and command widgets
to allow for menucolors. Supports only inverse line attribute for now.
Allow key translations to work with menus on Linux.
This was discussed two years ago then nothing happened. Make
autodescribe for feedback when moving the cursor to pick something
default to on instead of off.
Make being trapped in/on/over floor block Levitation and Flying, the
way that being inside solid rock already does, and the way levitating
blocks flight.
Blocked levitation still provides enhanced carrying capacity since
magic is attempting to make the hero's body be bouyant. I think that
that is appropriate but am not completely convinced.
One thing that almost certainly needs fixing is digging a hole when
trapped in the floor or tethered to a buried iron ball, where the
first part of digactualhole() releases the hero from being trapped.
If being released re-enables blocked levitation, the further stages
of digging might not make sense in some circumstances.
I recently realized that being held by a grabbing monster is similar
to being trapped so should also interfere with levitation and flying.
Nothing here attempts to address that.
Save files change, but in a compatible fashion unless trapped at the
time of saving. If someone saves while trapped prior to this patch,
then applies it and restores, the game will behave as if the patch
wasn't in place--until escape from trap is achieved. (Not verified.)
The prior fix for this was a bit flawed. It was only considering
the length of the last field, but what it really needed to do was
consider the placement of the last character of the last field
on the row relative to the placement of the last character of
the last field on the row previously.
If the new placement of that last character of the last field
is left of the previous placement, some clearing must be done.
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.
The pointer could go out of bounds when decremented if it was pointing
at the start of the status_vals[BL_HUNGER] (empty string).
Also, guard tty_status_update() from an out of range index being
passed to it (botl shouldn't do that, but...).
The legal 1st parameter values for tty_status_update() in 3.6.2 are
BL_RESET (-2)
BL_FLUSH (-1)
BL_TITLE ( 0)
...though to...
BL_CONDITION (22)
count MAXBLSTATS = (BL_CONDITION + 1)
There's a BL_CHARACTERISTIC (-3) defined in the botl.h header file,
but it is not used in wintty.c and is now screened out along with
everything lower and everything MAXBLSTATS and above.
closes#142fixes#141
Description for use when an item hasn't been seen up close yet falls
back to real name if there is no separate description, but was doing
so before real name substitution for samurai.
actualn = foo;
dn = description ? description : actualn;
if (Samurai)
actualn = bar;
So player saw a flail (via 'dn') until dknown bit got set, then
nunchaku (via 'actualn' after it got set to samurai-specific value).
Wait until after substitution of Japanese real names before falling
back to real name when there's no description.
Iron bars can be destroyed in some circumstances (hit by yellow
dragon breath or thrown potion of acid, being eaten by rust monser
or black pudding, or by poly'd hero in those forms) and should act
like walls for diggable/non-diggable purposes. But they aren't
walls, so the non-diggable flag was not being set for them by the
special level loader. Even once that was changed, they weren't
being handled consistently. Some places checked for non-diggable
directly (zap_over_floor of acid breath, potion of acid hitting bars)
and started working as intended, others used may_dig() to check
non-diggable (poly'd hero attempting to eat iron bars) but it doesn't
handle iron bars, and still others didn't check at all (bars-eating
monster who moved onto bars location in expectation of eating those
next).
Get rid of bold/non-bold distinction in #wizidentify inventory menu
by only showing items which aren't yet fully identified instead of
full inventory with bold for unID'd. Support for bold text might
be lacking.
I was considering this even before the report that X11 menus ignore
attribute. The "_ - (use ^I for all)" menu entry is still present,
but it could be discarded in favor of '.' to pick everything via
ordinary menu selection.
Most shop messages accurately identify the shopkeeper even when he
or she can't be seen, but some also include a pronoun reference that
ended up as "it" or "its" when not seen. Extend pronoun selection
so that visibility can be ignored: noit_mhe(mon), noit_mhim(mon),
and noit_mhis(mon). Note that despite being called noit_foo(),
those will still return "it" if mon is neuter.
"Accurately identify shopkeeper" is misleading if the hero is
hallucinating; a random shopkeeper name is used then. noit_foo()
yields the pronoun applicable to the actual shopkeeper and might
not match the gender of a hallucinatory name. That could be fixed
in a couple of ways (add shk_mhe()/shk_mhim()/shk_mhis() and either
pass them the randomly chosen name so that they can figure out the
appropriate gender, or just have them use a random gender whenever
hallucinating) but I don't think that's worth bothering with.
A bunch of shop messages needed noit_foo(); only a couple of those
have actually been tested. A bunch more were using shkname() at
the beginning of a sentence where Shknam() should be used instead.
(All the existing shk names are already capitalized so there's no
noticeable difference.)
The three places outside shk.c and vault.c which directly use
pronoun_gender() have been successfully tested.
mondead() -> m_detach() -> m_unleash() suppresses
the m_unleash() slack message, so deliver it in
the caller explmm() in those circumstances.
(The issue of whether it should be possible to leash light
is side-stepped.)
bug H7406, 1548
The original report stated:
"I located a bear trap as a human and just ignored it
for the time. I polymporphed into a Vampire Lord, then
went to #untrap the bear trap. On the first attempt,
I stood beside the trap and attempted to #untrap. I
received the 'Whoops!' message and automatically moved
onto the trap square as a result. The bear trap vanished!
I obviously wasn't trapped since I'm polymorphed into a
flying monster, but the trap glyph was no longer present.
The glyph looked like regular floor - as if I had
untrapped the bear trap and taken the trap with me."
The trap was actually still there but became hidden intentionally
for other valid scenarios, but was an unintended side-effect for
this scenario.
Fix it by failing the #untrap operation for a Flyer earlier on,
and in a more benign manner, since the Flyer ultimately doesn't
end up in the trap anyway. You'll still get the "Whoops!",
followed by a message, but that's as far as the "failed" #untrap
attempt will go under the circumstances.
Address a drum of earthquake inconsistency reported 2017-03-23:
"Drum of earthquake does not make you deaf. Leather drum or depleted
drum of earthquake does."
bug 1099
