Noticed while testing the fix for the recently reported clairvoyance
bug. I saw a '1' move onto an 'I', then when it moved again the 'I'
reappeared. The remembered unseen monster couldn't be there anymore
if the warned-of monster was able to walk through that spot, so
remove any 'I' when showing a warning (digit) to stop remembering an
unseen monster at the warning spot.
Nobody has ever reported this so fixing it isn't urgent, but fixing
it is trivial so I'm doing it in now (without the clairvoyance fix).
H7074 1311
> When moving from a pit into an adjacent pit, you "fall into" the pit and take
> damage. This happens even when you are walking back and forth between two pits,
> repeatedly, where you should have no way to fall.
>
> The intent seems to be that you can move into the adjacent pit without having
> to climb out of the first one, and this works properly - the only problem is
> that the pit gets triggered when you ought to have no distance to fall.
This is really just stumbling over uncleared clutter, not a pit fall.
There was already a way to clear the clutter between adjacent pits.
Remove trailing spaces from doc/fixes36.1 (only a couple),
doc/Guidebook.mn (several), and doc/Guidebook.tex (many). I re-split
some lines made wider by embedded formatting directives, but tried to
avoid getting carried away with that.
I think I added one missing period to Guidebook.mn and one missing
comma to Guidebook.tex. Aside from that, they should format the same
as they did before this patch.
When a getlin() response is being typed, it wraps to second line if
the cursor tries to go past COLNO-1, but if a previous response is
treated as part of the prompt, using pline() to write prompt+space+text
wraps at a whole word boundary. tty's getlin() assumes that the screen
position can be derived from that prompt+space+text_so_far but that
doesn't match if wrapping at a word boundary leaves blank space at end
of the top line.
When a prompt is accompanied by default answer, output the answer
separately instead of pretending it is part of the prompt. Line-wrap
should occur at same point as when it was originally typed and avoid
the confusion about how far to back up when deleting characters.
This hasn't been exhaustively tested but it seems to work correctly
for ordinary input, input erased one character at a time, and input
killed all at once. One thing which definitely hasn't been tested is
having the prompt itself be so long that it needs to wrap.
Allow the 'm' prefix for wizard mode level teleport command. Using
it skips the initial prompt for level destination and goes directly
to the menu of special level locations that you get when answering
'?' to that prompt.
Some github feedback pointed out that getting annotation input from
the player behaved differently from similar input for naming of
monsters and objects. The complaint stated that hitting <return>
without supplying any input removed the old annotation, where other
naming would leave the old name intact. 3.6.0 did misbehave that
way; current code does too if EDIT_GETLIN is disabled but behaves
as desired when it's enabled. (There's nothing that I can spot in
donamelevel() to explain why. I'm confused. Is tty_getlin()
returning the default answer instead of empty if that default text
is deleted at the prompt and no new text entered prior to <return>?)
Make donamelevel() work like mon/obj naming. Empty input leaves
existing annotation, if any, intact.
Having the autodescribe feature enabled and moving the cursor onto
a statue yields "statue of a <mon>" under normal circumtances, but
when done while hallucinating the feedback was just blank (because
the lookat() code couldn't find any monster at statue's location).
Now it will be "<random mon>" (not "statue of a <random mon>")
instead, same as when moving cursor over glyphs of actual monsters.
I once changed dump_map() to suppress blank lines as it processed the
known portion of current dungeon level so that no blank lines would
be shown above the mapped area and at most one would be shown below.
Any blank lines within were put back. But the count of the current
block of suppressed lines wasn't being zeroed when an internal gap
did get put back, so after that every line got spurious blank lines
inserted in front of it. I'm surprised that no one seems to have
discovered this problem.
This fix also changes the dumped map to suppress trailing spaces. In
the process, I noticed that the original DUMPLOG code was clobbering
column COLNO-1 if that was ever part of known map. buf[x - 2] = '\0'
overwrote the final map character in buf[] with the terminator.
The cavemen quest description includes an 'S' in the lower right
corner of the MAP...ENDMAP section of the locate level. It produced
a secret door as intended but did not have horizontal vs vertical set
because the latter was only being done for DOOR directives. Instead
of adding an explicit directive, make the loading code set horizontal
vs vertical for all doors.
This fixes the orientation of that secret door in the Cav locate
level, but I noticed that it showed up an a visible horizontal wall
when the spots on either side were still blank. It's behaving as
if the door is on a lit spot and the adjacent walls are unlit (this
misbehavior was already present before the current change; it was
just shown incorrectly as a visible vertical wall before).
Wizard mode sanity checking gave spurious "mon not on map" warnings
for steed when hero is mounted. Steed is in the fmon list but not
expected to be present on the map.
The fix to prevent "crushed by a gas spore's explosion" set killer.name
to an empty string after a gas spore explosion finished, but that made
nested explosions end up with empty killer.name after the innermost
call completed. explode() shouldn't have been hanging on to a pointer
to a global value that is subject to change while it executes. Making
a local copy of the current value at the time explode() is called will
solve that (I hope...).
Simply reverting the reset of killer.name wouldn't have been correct.
The innermost explosion would still be clobbering killer.name for any
outer MON_EXPLODE explosions in progress. When the only exploding
monster is gas spore, that wouldn't be noticeable. But having other
types of exploding monsters and a chain reaction which affected more
than one type would have exposed that bug. I think this fixes both
aspects of this problem but don't have a second type of exploding
monster to verify the second part.
Noticed while investigating the broken chest whose lock was already
broken: wishing for locked, unlocked, or broken chest (or large box)
was treated as asking for something unknown. Add support for those
three prefixes, although they only have meaning for chest and box.
If more that one is specified in the same wish, whichever one comes
last overrides the others.
Also, "empty" was already an accepted prefix (for tins); honor it for
containers too.
Lastly, wishing for "box" failed. Give a large box instead. I went
back and forth about whether to do the same for "small box" and ended
up not including it, but turns out that small/medium/large prefix for
globs ends up making "small box" and "medium box" match "box" which
has now become a synonym for "large box". I'm not sure whether that
is a bonus or a bug; small box is clearly not the same thing as large
box, but getting the only available box when asking for any box seems
better than claiming not to understand the request.
When using #force at a spot which has a broken or unlocked chest (or
large box) whose lock state has been previously discovered, avoid
|There is a broken chest here, but its lock is already broken.
|There is an unlocked chest here, but its lock is already unlocked.
by suppressing "broken"/"unlocked" from the chest description for
that particular message.
We might still want to change "broken chest" to "damaged chest" but
I don't think there should be any reference to its lock as the reason
it's broken or damaged. The fact that #loot, #force, and applying a
key still treat it as a container is sufficient to reveal that it
functions as one.
> When you try to #force a large box or chest whose lock is already broken from a
> previous #force, the game tells you "There is a broken large box here, but its
> lock is already broken." It's minor, but this implies that the box being broken
> is separate from the lock being broken (as well as that the box itself *can* be
> broken).
change the wording to "lock-damaged box" and suppress
", but its lock is aleady broken" when "lock-damaged box" has
already been displayed.
(Nobody particularly likes the wording "lock-damaged box" either, but at least
it seems less misleading)
"boxen" may be hacker slang for plural of "box", but "foxen" is
definitely not the plural of "fox". Restrict the "ox"->"oxen"
entry to full word "ox", not "*ox" suffix.
Trying to open at the same location as you did nothing,
make it loot instead. Apparently #looting is also annoying
when using vi-keys.
Based on code by aosdict
The use of debugpline() in tty_curs() got me wondering what would
happen if debugpline() was called while pline() is in progress. I
don't know how to trigger the bad coordinate situation, so I put an
unconditional debugpline() in the NHW_MESSAGE case of tty_putstr()
and used DEBUGFILES=wintty.c to enable it. Instant segfault, and
the backtrace was short and not useful so the stack might have been
clobbered. I didn't spend any time trying to figure where or why
the segfault occurred.
Change pline() so that if it is called while the previous pline()
hasn't finished yet (ie, recursively), use raw_print() and return
early. The raw_print message isn't very useful--it pops up wherever
the cursor happens to be, just like the cursor position bug that has
been an issue recently--but does get delivered without any segualt
and isn't completely useless if DUMPLOG is enabled and you save or
quit before the message buffer gets recycled. Message readability
situation could be improved but avoiding the segfault was my goal.
Putting any debugpline() into *_raw_print() would be inadvisable....
Report classified this as 'segfault' but it's actually a controlled
panic(). When hero has lycanthropy and is wielding a potion of unholy
water while in human form, if that potion is boiled then it triggers
a transformation to beast form which in turn causes wielded weapon to
be dropped. When the code unwinds back up through potionbreathe() to
destroy_item(), the boiled potion won't be found in inventory any more
and useup() -> useupall() -> freeinv() -> extract_nobj() panics.
Reported internally, if a prayer resulted in 'fix all troubles' and
one of those was TROUBLE_STUCK_IN_WALL but safe_teleds() couldn't find
any place to relocate the hero to, nothing was done and STUCK_IN_WALL
would be found again as the next trouble to fix. Since safe_teleds()
eventually resorts to trying every single spot on the map, there was
no other result possible than failing to find an available spot again,
nothing would be done, and next trouble would be STUCK_IN_WALL, ad
naseum.
I started out with a fix that looked for secret corridors to expose
and doors to open, to make more space available, then try to move a
monster off the level, then try digging out rock and/or walls and
smashing boulders. None of those guarantee success and I got bogged
down by the digging case. This was going to be a last resort if all
of those still failed to make somewhere to move the hero, but for now,
at least, I'm skipping all that other stuff and going directly to the
last resort: give the hero Passes_walls ability for a short time, and
let him or her find own way out of trouble. The next trouble to fix
won't be STUCK_IN_WALL because Passes_walls makes that a non-issue.
I'm not thrilled with the new messages involved but want to get this
behind me.
Changes to be committed:
modified: doc/fixes36.1
modified: include/unixconf.h
modified: sys/share/ioctl.c
github pull request #19 made reference to resulting code behaviour
being better when windows were resized when USE_WIN_IOCTL was defined.
The logic for including the necessary enabling code in the build in
sys/share/ioctl.c was an explicit "opt-in" strategy, so anything not
deliberately and explicitly listed was not able to take advantae
of the potentially useful code. The need to add #defines to that
list would have been perpetual as new platforms came online, and
unnecessarily restrictive for everything else.
This switches the logic to include the code by default now,
and thus
unless there is an explicit "opt-out" by uncommenting
AVOID_WIN_IOCTL in include/unixconf.h
Some platforms, and we have no way of knowing which ones, may have
to ensure that AVOID_WIN_IOCTL is #define'd.
The comment I added to data.base--to explain that despite what the
short description says, an aklys wouldn't return to sender after being
thrown--was bugging me, so I've made aklyses behave like Mjollnir.
If thrown when wielded as primary weapon, it will usually return and
usually be re-wielded. I also added a new message when either thrown
Mjollnir or thrown aklys is expected to return and fails to do so.
Most of the diff to dothrow.c is a change in indentation level. The
amount of code needed was quite small.
Autopickup for thrown Mjollnir which had failed to return was putting
it into the quiver slot if that was empty. Note quite an outright bug,
but it started wielded and can't be thrown if quivered, so exclude it
from the stuff that will auto-fill the quiver slot when added to invent
(post-3.6.0 issue).
Reported suggested that "congratulations" was too modern for use by
your god during ascension and that the longer phrases which were
shortened to yield it were too modest for the god to use. Make the
suggested change.
Report indicated that looking up "more info?" for "kittens" would show
the data.base entry for "kitten" and then when the display window was
dismissed, another "--More--" prompt for a empty second display window
would occur. Looking up "2 arrows" from a closely-seen object on the
map behaved similarly. User correctly diagnosed that the two-pass
lookup left the 'found_in_file' flag set from the first pass during
the second but that just clearing that resulted in "I have no info
about such things" on the second pass. The code is on the convoluted
side and needed an extra flag to handle 'seen on first pass' in
addition to clearing found flag after the first pass. I also added a
check to skip the second display if primary and secondary keys don't
match each other but both find the same entry. To test it, I tried
"a +0 aklys named aclys". That found the aclys entry but failed to
find "+0 aklys", so I added another change to have the key massaging
remove +/-N after removing "a", "an", or "the".
If "Want to see more info \"" + lookup string + "\"?" was too long,
the prompt buffer passed to yn() was being left uninitialized. Also,
test for too long was based on BUFSZ but yn() complains (to paniclog)
if the prompt is longer than QBUFSZ. Make checkfile() construct a
truncated prompt if the lookup string is too long.
I untangled some spaghetti by making all the 'goto's be forward. It
didn't help a lot but did simplify a few early returns by having them
jump to a common exit instead of replicating the file close.
The earlier fix for hoizontal vs vertical doors would have worked for
the Cav quest (lower left in leader's chamber) where door handling
occurs before wallification, but it wasn't working for minend-3 (east
wall of entry room) which already had walls. The more recent fix
solved the second case but broke the first one. I think this actually
solves both modes of door classification. I hope....
Forwarded to the contact form from a github "issue": in some
circumtances clairvoyance lets you move the cursor around to examine
the revealed map, and when doing so starts with "for instructions
type '?'". When extended clairvoyance periodically kicks in, as
opposed to explicitly casting the spell, there wasn't sufficient
context to figure out what it was prompting for (unless you actually
answer '?' to get instructions). Depending upon the most recent
message, it could seem like quite a strange prompt. Explicitly give
a clairvoyance-specific message prior to that.
Also, the getpos() help was including suggestions for targetting
monsters that aren't appropriate when it's being used for detection.
do_name.c has had quite a bit of formatting rot slip in since 3.6.0.
This fixes up the stuff I spotted by manual inspection.
Web contact report of a github pull request. A previous fix from
same user dealt with potential crash caused by freeing mailbox data
when the mailbox came from getenv("MAIL"). getenv() doesn't return
a value obtained by malloc so freeing it was bad. The fix was to
allocate memory to hold a copy of getenv("MAIL") so that free() was
valid. Unfortunately it didn't allocate enough space to hold the
terminating '\0' so potentially corrupted malloc/free bookkeeping
data. And the alloc+copy was being performed every time the mailbox
was checked, resulting in leaked memory from the previous check (if
MAIL came from player's environment). Fortunately the recheck only
takes place after new mail is actually detected and reported to the
player so the leak was probably small for most folks.
This compiles for the set of conditionals that apply to me (after
taking out -DNOMAIL that the hints put in my Makefile) but I can't
test that it actually works since mail is never delivered to this
machine.
An inventory of unpaid items where more than one was present would
show
|> bag's contents N zorkmids
if any of the items were inside a container whose contents aren't
known. But if there was only one item (so container must be owned
by hero) the 'Iu' output menu was skipped for pline and yielded
|> scroll of magic mapping 133 zorkmids
Force the menu display if the lone unpaid item is inside a container
whose contents are unknown.
I'm not sure whether a hero-owned container can have both unknown
contents and an unpaid item in normal play. I managed it while
trying to fix a reported problem--except I can no longer find the
relevant report--where itemized shop billing also revealed unseen
container contents (for any number of items, not just 1). That isn't
fixed yet, but I want to get the simpler 'Iu' part out of the way.
Reported about 18 months ago: standing on a scroll of scare monster
while next to a shopkeeper who was blocking the shop entrance because
hero was carrying unpaid shop goods would yield "<shk> turns to flee"
but <shk> wouldn't move. This was a side-effect of making standing
on scrolls of scare monster be stronger than on "Elbereth" when the
latter was nerfed. Make shopkeepers inside their own shops and temple
priests inside their own temples be immune to the effect of hero
standing on scare monster.
Also, make the Wizard, lawful minions, Angels of any alignment, the
Riders, and shopkeepers and priests in their own special rooms (ie,
all creatures that now ignore standing on scare monster) be immune to
the fright effect of tooled horns. Innate magic resistance usually
prevented them from being scared anyway, but make it explicit.
Reading a scroll of scare monster or casting the spell of cause fear
still rely on innate resistance to avoid chasing away those monsters.
I'm not sure whether they should have the same adjustment.
Apply user-contributed patch to make do_vision() handle FILE_PREFIX
correctly. It was putting that value into the filename buffer, then
overwriting it with the ordinary filename instead of appending.
Deletion of just-made vis_tab.h when creation of vis_tab.c fails would
have failed too if FILE_PREFIX had been working.
The patch was against 3.4.3 and didn't apply cleanly to current code,
but it is a staightforward fix, although the file deletion case was
buggy (failed to clear "vis_tab.c" from buffer before reconstructing
"vis_tab.h" via appending stuff). FILE_PREFIX seems to be Amiga-only
so I've only tested the usual case where it isn't defined.
