Nymphs won't steal gold from the hero (so that their steal-item damage
isn't a superset of lerprechaun's steal-gold damage; straightforward
back when gold wasn't kept in inventory), but hero poly'd into a nymph
would steal gold from monsters.
Fixes#204
3.6.2's attempts to fix turning off SEDUCE in 'sysconf' introduced
an unintentional change in behavior for hero poly'd into nymph form:
theft attack always angered the target. The actual change was
intentional but its ramifications were unexpected.
Asking curses to report whether the Ctrl key was being pressed during
a mouse click was sending mouse position reports--even those aren't
being requested--and actual Ctrl+Left_click was reporting a pair of
duplicate Ctrl+Mouse_position_report events when a click was actually
performed. So turn off Ctrl key reporting.
Mac with one-button mouse can be configured to send "secondary click"
for Ctrl+Click. A laptop trackpad handles that differently (press the
button while two fingers are on the touchpad to send secondary click)
and doesn't support Ctrl+Click as an alternate way to do that. If this
would work within curses then they could operate the same regardless
of how the user set the mouse or trackpad configuraiton. But I wasn't
able to make it work right.
Fixes#200
The Guidebook claims that there's no symbol for 'S_strange_object'
which is literally true, but there is one for S_strange_obj. It has
been in place longer than the paragraph claiming that there's no way
to customize that symbol. I'm not sure why variant spelling was used.
Also, files.c doesn't use loadsyms[], it calls a routine which returns
a pointer to a specific element in that array.
would describe it as trapped if you could see its location, but if
the trap was unseen that trap would remain unseen, at least in some
circumstances. Mark the trap as seen.
Wizard mode ^E and any mode spell of detect unseen or wand of secret
door detection failed to find mon->mundetected monsters if they were
hiding under objects, and failed to find those or other hiders or
mimics when the hidden monster was at a trap location. The fix for
the latter initially only worked if the trap was known, so took two
tries when a monster hid at the location of an unseen trap. So this
makes the additional change to find both things at the same time; it
isn't manual searching that stops as soon as something is found.
For ^X and final disclosure, report external issues that affect game
play: midnight, other night, new or full moon, and Friday the 13th.
The 'new feature' entry in the fixes file rambles a bit but if it
heads off even one spurious bug report, it'll have been worth it.
When kicking an altar, trigger divine wrath (minor: luck or alignment
loss) before deciding whether hero has hurt himself in the process.
Add some variation to the wrath penalty so that it can't be used to
precisely control Luck.
Typing ^H actually passed a 16-bit value back to the core which got
interpreted as ^G after the extra bits were discarded. I don't think
any previous changes to the curses interface caused this. It's
astonishing that no one ever noticed; the world must be full of numpad
users.
Fixes#202
When swallowed, you can take things from the engulfer's inventory, if
there are any, via pickup. Items might be worn by the engulfer and
when "picked up" those weren't being unworn before being added to
hero's inventory. Then they would be formatted as "(being worn)" and
could trigger warnings or worse.
Conceptually they should be worn on the outside and not be accessible
from the inside, so I've made attempts to pick up worn items fail
rather than fix up the unwearing.
Using ':' when swallowed to look at the engulfer's inventory describes
that inventory as "contents of <mon>'s stomach". That's weird for any
worn items, but the situation is so rare I haven't made any attempt to
deal with it.
Extend support for highlight rules that specify percentages from HP
and spell power to experience level and experience points. For both
of those, the percentage is based on progress from the start of the
current Xp level to the start of the next Xp level. 100% isn't
possible so is used to enable highlighting a special case: 1 point
shy of next level, most likely to occur after losing a level.
This is something I had in mind a long time ago and then forgot all
about until fiddling with the final disclosure of experience points
recently. It turned out to be trickier than expected because it needs
to check whether Xp should have a status update when it hasn't changed
but Exp has gone up. The latter might hit a percentage threshold that
switches to another highlight rule. Fortunately changes to Exp, at
least that aren't part of level gain or loss (which always trigger
status updating), are all funnelled through a single place (I hope).
Highlighting via attributes got broken three months ago. May or
may not have been noticeable depending upon which attributes are
supported. Too many variations of attribute designations...
When I implemented getmsghistory()/putmsghistory() for curses I was
assuming that DUMPLOG would only be used with tty, but it is interface
neutral and can be used with curses (or others). So curses message
history needs to behave like tty message history and be sure to pass
along messages that bypass pline() and the normal message window.
(Mainly one-line summaries of long quest messages, but also old
messages fetched from a save file and available to be re-saved without
having been shown if new session doesn't generate enough new messages
to flush them.)
Wizard mode shows the number of points needed to reach the next level
(unless already maxxed out at 30) for ^X and end of game disclosure.
Do it in normal play for the latter too. (I think it would ok to do
that for ^X too but haven't gone that far.)
Even when it was wizard mode only, the phrasing for past tense had a
minor grammar bug, and it could make the line a little too long for
tty and curses (not sure about others) when level was high, resulting
in wrapped text. That looked bad for tty, which first tries removing
indentation (just 1 space in this case), making that line outdented
as well as wrapped. So change the phrasing slightly when experience
level is 'too high'. I had a version which formatted, measured, and
re-formatted if necessary but that was overkill; simple hardcoded
rephrasing suffices particularly when measuring was against assumed
display width (80) rather than actual width.
Turns the "fix" in commit 319dcf4746
handled removing the default answer for single-line-prompt plus
multi-line-answer but not for multi-line-prompt plus long-enough-
answer-to-reach-another-line. The logic wasn't quite right and I
misunderstood what is stored in linestarts[] so even correct logic
wouldn't have solved things.
A recent fix for #wizidentify showing "Not carrying anything" after
listing inventory items still showed "Not carrying anything" after
"(all items are already identified)". Fix is easy.
Trickier bug was that ^I performs object ID on selected items while
the inventory routine is still in progress (but after it has processed
every item) and the ID routine will call update_inventory() which
will call the inventory routine to reformat invent. So the inventory
display routine was called recursively without having returned to
wizidentify where iflags.override_ID gets cleared to revert to normal
inventory. The nested call was unintentionally narrowing the contents
of persistent inventory window to whatever items were still unIDed.
(Any inventory update, including ^R, restored it to full inventory.)
With 'popup_dialog' On, a one line popup with question and likely
responses and default answer was shown, but without having the
cursor displayed at the end of emphasize that it was waiting for an
answer. Make the popup be one character wider so that there is room
to show the cursor. No effect when 'popup_dialog' is Off and prompts
are shown at the bottom of the message window; those already have the
cursor sitting at the end.
Make final inventory disclosure use a full width menu instead of
the default 38-column width with lots of wrapping. Also, increase
that default from 38 to 40 for the rest of the time. Commit
9f6588af49 made the 38 vs 40 portion
matter much less but I decided to keep it in anyway.
When a menu or 'things that are here' popup has only a couple of
lines and they happen to be narrow, a sized-to-fit window isn't
always easy to spot when it is shown over the ends of old messages
rather than over the map, even with a border box around it. Give
such windows a minimum size of 5x25 so that they always stand out
enough to be immediately seen. This will cause more message text to
be rewritten occasionally (after dismissing the menu or text window)
but the curses interface seems to discount that as something to be
concerned about.
Fully support the mouse_support option for curses, via 'O' as well as
via config file. At the moment, mouse_support:1 and mouse_support:2
are equivalent.
Also, fix the screen-to-map coordinate translation. When the mouse
is active and over the map, the pointer's cursor becomes a cross-hair
(may very by platform) and the character cell chosen for a click
seems to be a few pixels to the right of the center of the '+'.
Support user's terminal settings for erase char and for kill char.
Erase char is typically <delete> or <backspace>, both of which are
already explicitly handled so probably no effect there. Kill char
(generally ^U these days) will be honored unless it is a printable
character (don't know whether there are any troglodytes out there
who still use '@' for that...). The current handling for ESC works
the same if there is any input to kill, but yields 'cancelled' when
there isn't.
That's for message window getline(), which operates char-by-char.
The popup getline() uses a curses routine to get an entire string
and already honors kill char but treats ESC as input of ^[.
The position bars shown by curses when the map is clipped weren't
being drawn as intended (integer arithmetic). Changing parentheses
was enough to get it working, but it didn't handle the edge case
where non-zero got rounded to 0 (so when map was panned down, the
uppermost character of the vertical position bar still showed '*',
falsely indicating that top of map was currently within view.
Followup to 1c03d0970115c776d1c4791fea3c33f70b0b5378; that had been
too easy. When map was clipped and panned to the side, the highlight
for hero's spot was shown next to the '@' instead of on it.
Using ':' to have search string matching toggle items chosen for
selection would show selection highlighting on the current page for
items matched off-page.
The persistent inventory window wasn't being updated if you toggled
the 'sortpack' option interactively. (The new setting was honored
once something else triggered a 'perm_invent' update.)
The logic for toggling 'fixinv' seemed backwards. I hope this "fix"
for that hasn't actually broken it.
I noticed the wrapping issue while testing out the 'bad fruit' fix,
then the other things while fixing it.
1) inventory entries too wide for narrow persistent inventory window
wrapped without any control; normally can't be seen except for the
last entry when the list is short enough to leave at least one line
available; it looked fairly reasonable with window borders Off, but
when On the last char of the first line and first char of second
line were clobbered by the border box;
2) when there were too many entries to fit within the height, those
after the last one which fit were appended to it for borders Off
(or written on bottom line and then overwritten by the border box
for borders On); noticed because the selector letter is highlighted
with inverse video, even when written at an unexpected place;
3) suppress the inverse video hightlighting of inventory letters since
they can't be selected from that 'menu';
4) for borders Off, the top line was left blank as if a border was
going to be drawn there;
5) since the entries are truncated due to the narrow window (on a
modest sized display), strip off leading "a", "an", or "the" prefix
for inventory entries (written to curses perm_invent window only);
lets a couple more characters of more interesting stuff be seen.
savebones() sets all the fruit indices negative, then resets to the
normal positive value for each fruit it actually writes into the bones
file. But if 'perm_invent' is enabled and something triggers an
update_inventory() while bones saving is in progress, object formatting
for the inventory display won't be able to find any fruits, resulting
in impossible "Bad fruit #N". Fix is to turn off 'perm_invent' when
the game ends, so it won't be On when bones are written. Disclosure
uses a popup for inventory so persistent window is obsolete by then
anyway.
[I don't know what is triggering update_inventory() while savebones()
is executing. Also, I don't see where the fruits whose index stayed
negative--because there aren't any on level being saved--get purged.
Maybe when those bones are loaded by another game?]
when carrying things. The fuzzer toggled on 'perm_invent' and after
interrupting it I used ^I. Having 'perm_invent' enabled makes the
inventory code avoid having a totally empty inventory display (by
supplying "Not carrying anything" instead--in the menu rather than
via normal pline) so that interface code will see a change and know
that an update is needed. But to decide whether the menu was empty,
the inventory code was testing union 'any' field 'a_char' to check
whether some item had used the union (implying that something had
been passed to add_menu()), but wizidentify (^I) uses field 'a_obj'
instead. Apparently the a_char bits stayed 0 because the menu ended
up with "Not carrying anything" after a list of inventory items.
Switch to a separate variable to track whether anything has been put
into the menu instead of trying to rely on the union.
Unrelated but noticed when checking other "Not carrying anything"
instances, the #adjust command ends early when there's no inventory
but it was asking for a letter to adjust even when the only thing in
inventory was gold in '$' slot, which isn't allowed to be adjusted
away from that slot. Treat gold-only like no-invent.
Observed on a text file with crlf endings on Linux, where the
so-called blank lines weren't being ignored as they should
have been, despite there being a line to remove \r from the
end.
A pointer was being pre-decremented before the check for a
matching whitespace character.
and receiving a random amulet instead of an "amulet of <foo>".
Although the failure to produce the 'right' amulet wasn't a regression
compared to earlier versions as the report indicated, supporting that
wish is straightforward.
Even though it isn't using verbalize() to make a specific statement,
don't let a demon ask the hero for a bribe when the hero is deaf.
Also, give alternate setup messages in a couple of places where a
divine voice is overriding deafness.
Recent commit 5d59b288c9 changed monster
zapping a fire horn at self to cure sliming to not use the wand-zap
feedback routine, but inadvertently did for zaps of wands of fire too.
Use the zap routine for wand and play-instrument routine for horn.
Most of the entries for '?' looked awful because curses was using
((terminal_width / 2) - 2) for the window width ('- 2' was to make
for for a border around the popup window, regardless of what the
'windowborder' option was set to). Splitting text that has been
manually formatted for 80 columns "worked" but looked bad when not
required.
Some of the help files are using 79 characters on a few lines,
producing wrapped text when displayed. Those would look better if
limited them to 78 or if curses can be modified to suppress the
window border when the entire display is being covered by a popup.
tty ignores map column #0 (0-based index), like the core, and draws
the map in screen columns 1 (1-based index) through 79, leaving screen
column 80 blank. curses was drawing all 80 map columns and since #0
was always unused, screen column 1 was blank and the map was shown in
2 through 80. Change curses to work like tty.
This was too easy; there may be problems lurking. One known issue: it
should be made smarter about when clipping/panning is necessary since
it thinks that a full 80 columns are needed but 79 suffice.
Like #annotate, #name monster, #name individual object, and #name
object type are places where it makes some sense to have an existing
name be the default for the new name, in case taking off from the end
and/or adding to the end is more convenient than retyping everything.
When there is an existing name used as default, clearing that default
and hitting <return> is not enough to remove the name, you still need
to 'assign a new name' of <space> to do that.
Messages on tty which bypass message history weren't handling long
lines properly. If the text wrapped to line 2, that continuation
portion was left on the screen after whatever operation that put it
here was finished. (To reproduce: assign a long name to a monster
with a long type name so that the combined length exceeds the display
width, then move the cursor over it with ';' or '/' while autodescribe
is On.)
This time prompting isn't adversely affected.
This effectively reverts 1ad2415315
because it was interfering with prompts that spanned more than one
line (by inserting '--More-- + erase' between displaying of prompt and
getting input for the answer).
So we're back to the situation where autodescribe feedback when moving
the cursor will leave text on the second line if it generates text too
wide for one line. (^R redraws the screen correctly.)
For wizard mode 'monpolycontrol', the getlin() answer buffer for the
"Change <monster> @ <x,y> into what kind of monster?" prompt is also
used to format the coordinate portion of that prompt, so when
EDIT_GETLIN is enabled getlin() was inadvertently given "<x,y>" to use
as default response. Clear it after the prompt is formatted instead
of via an initializer. Also, shorten the prompt on the first try:
"Change <monster> @ <x,y> into what?", expanding to the old prompt if
retry is needed.
This also allows specifying 'chameleon' when <monster> is a chameleon,
'doppelganger' when it's a doppelganger, and 'sandestin' when it's one
of those (but not 'doppelganger' when it's a chameleon or sandestin,
and so forth), instead of blanket refusal to accept any non-vampire
shapechanger as the choice.
Messages on tty which bypass message history weren't handling long
lines properly. If the text wrapped to line 2, that continuation
portion was left on the screen after whatever operation that put it
here was finished. (To reproduce: assign a long name to a monster
with a long type name so that the combined length exceeds the display
width, then move the cursor over it with ';' or '/' while autodescribe
is On.)
The wizard mode runtime option 'wizweight' appends an object's weight
to its formatted description, but that was skipped for globs on the
assumption that it had already been included. But that inclusion only
happens in shops so most globs lacked weight feedback.
One of the claims in #H8849 was that a monster which zapped a wand
that the hero had fully identified made hero's knowledge of it revert
to "a wand". That doesn't happen; it had to have been a different
wand which hadn't been seen up close yet. But the hero should lose
track of known number of charges if a wand is zapped outside his/her
view. When implementing that I noticed that a monster playing a fire
horn to burn away slime was using the routine that gives wand
feedback. Add a separate, similar routine for magical horn feedback.
Half this diff is due to moving a naming support routine from mhitm.c
to do_name.c.
EDIT_GETLIN is more complicated on curses than on tty due to way that
long lines are handled....
Using ESC to get rid of the default response removed it from the
answer buffer but didn't erase back to the end of actual prompt,
making it look as if it was still there. Fixing that for a one-line
prompt+answer was needed and would have been easy but it also needs to
be prepared to go back to prior lines. Both the prompt and the answer
could conceivably span lines although in practice it will usually just
be one line or else prompt+answer combined spanning to a second line.
This hasn't been exhaustively tested been seems to be working correctly.
Fix a couple of glitches and add an enchancement. The monster
attributes structure left the 'hidden' field uninitialized unless user
specified "hidden". Mimics were being flagged with mon->mundetected
because they pass the is_hider() test but they 'hide' by taking on an
appearance rather than being unseen due to mundetected. hides_under()
monsters fail the is_hider() test, but can become mundetected if there
is at least one object present. Eels/other fish are neither is_hider()
nor hides_under() but can be mundetected at water locations. So alter
'hidden' handling to deal with these various circumstances.
Asking for 'hidden' for any type of creature will result in having its
location be highlighted if it can't be actively seen or detected. So
using '2000 ^G piranha' will fill up the Plane of Water "normally" but
'2000 ^G hidden piranha' will result in a ton of draw-glyph/delay/
draw-other-glyph/delay sequences and take a painfully long time. Moral
of the story: don't combine 'hidden' with a large count unless you
want to spend quite a while watching the level's fill pattern. Turning
off the 'sparkle' option will cut the flashing in half but still take
a long time. If you really need to fill a level with hidden creatures
and can't bear the flashing/highlighting, use blessed potion of monster
detection or #wizintrinsics to have extended detect. Then all created
monsters will be seen so none will trigger location highlighting.
If you create a 'stalker' or 'invisible stalker' or 'invisible <other-
mon>' its location won't be highlighted, but for 'hidden stalker' or
'hidden invisible stalker' or 'hidden invisible <other-mon>' it will
(provided you don't actually see it due to See_invisible or sensemon()).
