This adds BL_RESET to status_update to send a flag to a window
port that every field should be updated because something has
happened in the core to make current values shown to be
untrustworthy or potentially obliterated.
That is now distinguished from BL_FLUSH, which now has no
bearing on whether every field needs to be redone, and instead
can be used by a window port indicator that it is time to render
any buffered status field changes to the display.
tty port now sets WC2_FLUSH_STATUS indicator for BL_FLUSH support
and now does one rendering per bot() call, instead of up to 22.
Side note: The tty hitpoint bar code was relying on the old
behavior of redrawing everything upon BL_FLUSH apparently, so it
initially had some color change lag issues, corrected by marking
BL_STATUS as dirty (in need of updating) in tty_status_update()
whenever BL_HP was marked as dirty.
ensure BL_FLUSH always gets sent down to the window port whenever bot() is
called with context.botlx set so that status updates work as
expected after full screen clear after a level change
Fixes#107
make the transformation message of a deliberate apply of a figurine seem
a bit less definite when blind. Put 'I' unseen monster marker at the spot
you expect it to be.
make transformation message of a deliberate apply of a figurine seem a bit
less definite when blind. Put 'I' unseen monster marker at the spot you
expect it to be.
tty: turn off an optimization that is the suspected cause of Windows reported
partial status lines following level changes. It was turned on for
non-unix platforms only
If pickup has been bound to some other key than ',', the awful hack
did not work correctly. Testing, I couldn't notice the difference,
but probably just not doing the right thing...
Don't display the selection to identify all items if there are none.
Complete an item marked ToDo in cmd.c: allow selection of one or more
particular items to permanently identify rather than just all or nothing.
I noticed that the description of ^O still referred to the 3.6.0
behavior (either #wizwhere or #overview depending upon play mode)
rather than the 3.6.1 behavior (unconditional #overview).
While updating that I changed a bunch of "Wizard-mode" references
to "Debug mode" which is the proper end-user name.
I slightly expanded the descriptions of #wizdetect, #wizgenesis,
\#wizintrinsic, WIZKIT, and Debug mode, and removed at least one
out of date reference to debug mode being a conditional feature.
And for most of the stuff I was looking at, I changed the nroff
source to honor the roff guideline of having each sentence start
on its own line (and also the latex source to use those same line
breaks even though they don't need it).
Not done: a lot of quoted single characters use 'c' instead of `c'
(pair of ticks rather than back-tick and normal tick). One form
or the other should be changed so that they're all consistent.
I'm pretty this was mentioned the last time it was formatted for
the web site.
Guidebook.mn has been tested, Guidebook.tex has not.
Fixes#124
Fix github pull request #124 which was also reported directly (but not
through the contact form so #Hxxx number). Using ^I or #wizidentify
displays inventory with everything ID'd for that command only and adds
a menu entry "_ - use '^I' to identify" that can be chosen to make
those ID's persistent. Picking underscore would work but picking the
alternate '^I' wouldn't work if the platform had unsigned characters
for plain 'char'. Switch the return value from magic number -1 to
magic number ^I which isn't a valid inventory letter and isn't subject
to sign conversion. Casting -1 to '(char) -1' would have worked too
despite some confusion expressed in discussion of the pull request.
If ^I has been bound to some other command and #wizidentify hasn't
been bound to any keystroke, temporary ID didn't disclose any extra
information (ie, acted like ordinary inventory display) and the extra
menu entry to make temporary ID become persistent wasn't available.
This fixes that too.
My change to unify the pet and monster digging weapon choosing
made monsters not actually wield the chosen weapon, even though
they could still dig as if they did. Pets behaved properly.
Also add an explicit check for IS_STWALL so they won't keep
switching away from their current weapon until needed.
for parchment and vellum spellbooks. Parchment and vellum are made
from animal skin rather than from plants, so classifying spellbooks
with those descriptions as paper is inaccurate. Changing them to be
made out of leather has a couple of side-effects: eating them while
polymorphed will break vegetarian conduct and polymorphing them might
result in a leather golem rather than a paper one.
I left "leathery spell book" as paper since that directly refers to
the cover. The composition shouldn't be changed--the pages of such
a book are still made out of paper--but the effect of eating one
possibly should. (That description originally was "leather" and got
changed. I don't remember the details and assumed it was due to odd
wishing behavior, but there's a commented-out routine in eat.c which
suggests it was related to eating instead. Anyway, "leathery" is
still non-leather.)
Augmented death reason with appended "while <helpless-reason>" was
broken in 3.6.0 and got fixed shortly after release (too late to
prevent high-score files from being corrupted). Then within a
couple of weeks it got broken again, and doesn't work in 3.6.1
either (but in this case, it is omitted instead of being cloned
to all following score entries). The problem is in both record
and logfile, but not xlogfile, so we could create a fix up routine
that would use the last to repair record (and perhaps logfile).
But having two fixup routines would probably lead to confusion.
The problem this time was bad logic in the fix for
|alter name of monster causing hero's death if name contains
| characters that could cause confusion when using record,
| logfile, or xlogfile later
killerformat() was going out of bounds of the input string and
using up all of 'siz' so that there was never room to append the
", while helpless" suffix.
Fixes#121
Fix githib issue #121 - shopkeepers don't charge for consecutive
acts of vandalism on the same square. pay_for_damage() keys its
action on the 'when' field of the damage structure, and when a
second type of damage gets added to existing damage, that wasn't
being updated. Both bits of damage (broken door or dug wall plus
trap created at same spot) get repaired together but shopkeeper
wasn't challanging hero to pay for the second one (trap).
The repair process had issues too. If you broke a shop door, paid
off the shopkeeper, then left the level before the repair took
place and came back after (or rather, catching up for lost time
repaired it when you returned to the level), it didn't actually
get fixed and remained a doorless doorway that was considered to
have been successfully repaired (record of damage discarded).
Unless there was also a trap there; then the door did get properly
fixed when the trap was removed.
Object scattering during wall repair was bypassed if trap removal
took place.
Also, trap removal while off level still gave messages when it took
place after you returned. I didn't try to verify that; it's possible
that vision is in a state where you can't see the repair even if you
return to a spot where it would be visible. But the return value
from the repair routine was one which wanted a message instead of
the one to suppress messages.
Not addressed: digging a pit inside a shop (aside from in doorway
or breached wall) is not treated as damage which should be repaired.
This includes the case of digging up a grave which converts the spot
into ordinary floor (plus pit trap).
Fixes#125
When a random grave included some gold among whatever treasure was
generated, that gold was left on top of the grave instead of being
buried inside it like other treasure.
I'm sure this was intentional but only because mkgold() puts the
gold on the ground and merges it with other gold if there is already
some present. Keeping an existing stack of gold distinct from the
new one in order to bury the latter is feasible but clumsy. Just
make a new gold object directly, bypassing mkgold(), and bury that.
Fixes#123
Make sure wallification doesn't go out of bounds when operating
near the map edge. The top and left edges were ok (although the
left edge could uselessly try to wallify unused column 0) but the
right and bottom ones weren't validating the map boundary. None
of the 3.6.x levels were affected.
I've done this a little differently from the suggested commit in
the pull request.
Special levels with FLAGS:inaccessibles could trigger a panic if
a large enough area was subjected to floodfill handling. The buffer
intended to be enough to hold an entire level wasn't big enough when
individual coordinates were being added multiple times. I don't
really understand what this code is doing but the recommended fix
does work to prevent the panic.
None of the levels included with 3.6.x were affected.
Remove an extra space from Val 00021.
This does not address github issue #124 where the extra space shown
on the message line is the result of combining two separate plines
rather than coming from the data.
Noted on rgrn, after being told that you don't fit upon discovery
of a hole or trap door you could then immediately use '>' to
proceed down.
The deliberate situation remains possible and has some
inherent risk.
Interrupt seduction if the hero gets moved away from the seducer, or
if both of them move to another level. Loss of levitation can drop
the hero onto a trap which sends him/her somewhere else, but seduction
was continuing as if nothing had happened. In theory it could continue
despite level change because succubus and incubus are level followers,
but there's no way of knowing whether seducer and victim will arrive
next to each other until they get delivered and that doesn't happen
until long after the attack needs to finish.
I don't think theft has the same problem because it is a multi-turn
activity operating on one item at a time, but I didn't check it out.
Unlike cloak_simple_name() and helm_simple_name(), suit_simple_name()
wasn't guarding against Null. Current usage never trips up against
that, but when I added a new use in doseduce() [pending], it caused
a crash.
