I moved some stuff around after testing the changes in
58583cacf8 before committing it. It
accidentally ended up with 'gold' always being Null at the first
place it gets used (to vary the feedback when stealing everything
except gold).
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.
When mklev() is called multiple times, previous state stored in the
xxstairs_room pointers can be mistakenly used when making decisions about
the new level being constructed. This caused non-deterministic level
creation behavior when replaying from a snapshot.
With 'popup_dialog' On, a prompt which exactly fills the available
width would start the next line with a space (to separate the prompt
from user's answer) and then have the cursor waiting after it. That's
unlike other behavior in the curses interface where the line split
would be instead of the separating space rather than in addition to it.
Old:
|long prompt?|
| X__________|
New:
|long prompt?|
|X___________|
where the X represents the cursor sitting over the start of blank space
waiting for user's answer.
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.
Rescue some old code from bit rot. It may be useful if the shop
side of things ever gets fixed. (Itemized billing reveals container
contents. I'm sure that it's in the bugzilla list but can't find it.)
Noticed after building a curses-only binary; configuration setting
"terminal info library" is only of interest as an optional feature
when the build includes tty. There were several other settings that
apply to some interfaces and not others but would be listed if the
feature was defined (possibly after building for an interface which
supported it, then left in place when switching to another which
doesn't).
I left most of those with commented out conditionals in case other
interfaces start supporting them. So you might still get something
like "tiles file in XPM format" for a binary that doesn't support
tiles if USE_XPM has been defined for some reason.
If a player names an object with a name that ends in '\\', drops
that object on the floor nearby and does a look at nearby objects,
then the game will crash. This is caused by stack corruption when
the decode loop skips over the decode string terminator.
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).
